Hi Marcus, Yes. You are right that service meshes are started with E-W API, but in recent past, service meshes are coming with integrated API gateways for external communications. Hence, service mesh term is used generically to represent all both internal and external service communication. Adding to this, Industry is thinking about service meshes across K8S clusters too, that encompasses even bigger domain.
On your points: - how authentication is done across APIs exposed by different ONAP components. SRINI> One of the advantages of service meshes are that authentication/authorization and traffic routing is taken out of application containers, thereby making it generic across all services. - how these API are discovered when there is a change or a new API is being added. SRINI> There is good support for version management including canary and A/B testing. - we must take into consideration that ONAP components could be used in a standalone fashion, which means no dependencies shall be created on a service mesh or API GW pattern (the more generally used systems are used for that problem the better). SRINI> Yes. I agree. Today, there is no dependency between application containers and service meshes. Industry is taking this forward even from the service mesh control plane interfaces and common items for interoperability. Essentially, if some services use one service mesh and other use some other service mesh and if both those projects are combined, then there is a need for service mesh interoperability. Microsoft started this initiative : (https://www.sdxcentral.com/articles/news/microsoft-spearheads-service-mesh-interoperability-push/2019/05/) Thanks Srini From: [email protected] [mailto:[email protected]] Sent: Thursday, May 23, 2019 1:23 AM To: Addepalli, Srinivasa R <[email protected]>; [email protected]; [email protected]; [email protected] Cc: [email protected]; [email protected] Subject: Re: [Onap-arc] API GW Proposal Hi Srini, Manoj, Though we agree that the overlap between API gateway and service mesh patterns is significant. They can both handle service discovery, request routing, authentication, rate limiting, and monitoring, but there are differences in architectures and intentions. A service mesh's primary purpose is to manage internal service-to-service communication, while an API Gateway is primarily meant for external client-to-service communication. Whether both of those intentions and mechanisms therefore are available in both proposals has in our opinion not been studied yet and what to choose seems for us a bit premature. We believe that an API GW or a service mesh can provide a solution for current issues in ONAP with a growing set of components interacting with each other and interacting with outsisde systems incl. legacy OSS/BSS functions. In our opinion, the areas in which a new pattern must provide a solution include: - how authentication is done across APIs exposed by different ONAP components. - how these API are discovered when there is a change or a new API is being added. - we must take into consideration that ONAP components could be used in a standalone fashion, which means no dependencies shall be created on a service mesh or API GW pattern (the more generally used systems are used for that problem the better). Marcus Von: <[email protected]<mailto:[email protected]>> im Auftrag von Srini <[email protected]<mailto:[email protected]>> Datum: Mittwoch, 22. Mai 2019 um 16:31 An: Manoj K Nair <[email protected]<mailto:[email protected]>>, Stephen Terrill <[email protected]<mailto:[email protected]>>, ??? <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Betreff: Re: [Onap-arc] API GW Proposal Hi Manoj, I think industry is converging on service mesh technologies to solve this problem. For example, ISTIO with envoy and gloo/ambassador/ingress is being used for both E-W and N-S APIs. It does take of many of the requirements you cited. - API Routing - API Management such as users, roles (RBAC) - API transformation - Etc.. With the integration of APIGEE as ISTIO Mixer adapter, one can even have comprehensive API management too. Only thing that is not satisfied is : Breaking big API into smaller APIs. I argue whether it belongs in service mesh as it requires application understanding. I feel that functionality should be implemented as additional application micro-service. My suggestion is to put efforts in using industry best practices ☺, see what is missing in applying those to ONAP and fix those gaps. Thanks Srini From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Manoj K Nair Sent: Wednesday, May 22, 2019 1:33 AM To: Stephen Terrill <[email protected]<mailto:[email protected]>>; 赵化冰 <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [Onap-arc] API GW Proposal Hi Stephen, Huabing, I just noted the following comments in the ArchComm MoM yesterday * ArchCom views that the APIGW functionally in MSB with the following notes: * .. * There was a discussino about ExtGW in MSB vs External APIs. External APIs exposes functional capabilities. ExtGW in MSB is communication connection. We have concern with the last comment. Our proposal for API GW is not limited to enable “communication connection”. I guess using API GW for just routing the request is not very efficient. We are proposing API GW functionality to be leveraged for the following use cases * Compose low level/object level API of the ONAP components behind API GW through a Façade and enable more manageable integration with external solutions. This in a way is expected to address the modularity requirements driven by Architecture team. * Host Business/High-Level/Standard APIs/Adaptation and transformation logic for Use Cases, App Developers with tools to hook business logic or policies if required. * Consistent Security/Policy enforcement for ONAP exposed/consumed APIs. Additionally ensure consistency of ONAP exposed APIs in terms of style, version, documentation. * RBAC enforcement for ONAP exposed/Consumed APIs * Support Tenancy management * ‘ONAP as a Service’ Enabler . * As a gateway for enabling transactions with cross domain solutions- with partner solutions, legacy solutions, with edge management solutions and enforce appropriate business policies We don’t think the above use cases are being addressed today. We are focusing on the above use cases to be enabled than focusing on enabling external (or NBI) communication channel for ONAP components. In our view Ext-API, Various adaptors (SOL005/SOL003/Multi-Cloud Adaptors) are doing some level of adaptation and bit more (level of composition with additional business logic). These redundant modules can offload majority of the transactional logic and chaining to well-known API GW solutions as there are already built in toolsets for incorporating that. The new proposal is not intended for or require any refactoring of existing projects, it just require adding a service in either common service or MSB for hiding the complexity of ONAP capability consumption. While we discuss the capabilities and technology choices with MSB team, we would also like to get clarity on the following open items which will help us to arrive at an appropriate technology choice. * Views from project teams and use case team on whether the use cases stated above are valid and enhancement of API GW is fine to address those ? * Is API GW, with additional seed code in future releases, expect to handle only the NBI calls via Ext-API or all the external calls – inbound/outbound (e.g. calls from OSS/BSS directed to Ext-API or all types/formats of APIs – SOL005/SOL003/Cloud specific, REST/non-REST etc or NBI + East/WEST API Calls) . Is the need currently to support only the NBI to Ext-API and selectively ignore API calls to ONAP components as required (for example SOL005 directly to SO instead of passing through API GW or Ext-API) ? * How project teams expect to develop the adaptors or Façade (API Composition logic – simplified or single API call exposed for multiple internal low level APIs) for various use cases/end user applications ? Within project boundary as separate microservice using project specific toolsets or as part of API GW or using common API GW microservice in different components? * Is there any need for additional toolsets and plugins to be developed in API GW for developing standard adaptors (e.g. SOL005/SOL003 etc) or Façade APIs or Security/Policy enablers? Does it required to be developed by the API GW functional owner or respective teams that require such API plugins/enablers? Are we open to put additional effort required for developing the feature debt jointly irrespective of the technology of choice or programming language of choice? Regards Manoj ________________________________ The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17223): https://lists.onap.org/g/onap-discuss/message/17223 Mute This Topic: https://lists.onap.org/mt/31720416/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
