I agree with the points raised by Srini. There is some definite overlap in functionality with Service Mesh. And with some of the existing efforts already in progress.
* Istio (traffic management and TLS) * Ingress (N-S routing and access control) * Network Polices (E-W access control) These topics have been presented a few of times in archcom and seccom meetings and events. Some functionality has been delivered in Dublin (e.g. Ingress Controller) and others are part of release planning efforts for El Alto and Frankfurt. OOM and members of the Security Subcomittee are working together to address security vulnerabilities raised at the TSC using ingress. From a footprint reduction standpoint, we should be cautious when introducing new components into the ONAP architecture that overlap or are redundant. It also concerns me that the recent proposal was to allow for not 1 instance but the possibility of 2 instances for the API Gateway (external facing and internal facing). I second the suggestion to use industry best practices first, and fill gaps as necessary. Thanks, Mike. From: <[email protected]> on behalf of Srini <[email protected]> Date: Wednesday, May 22, 2019 at 10:32 AM To: Manoj K Nair <[email protected]>, Stephen Terrill <[email protected]>, ??? <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: 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]] On Behalf Of Manoj K Nair Sent: Wednesday, May 22, 2019 1:33 AM To: Stephen Terrill <[email protected]>; 赵化冰 <[email protected]> Cc: [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. This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service <https://www.amdocs.com/about/email-terms-of-service> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17206): https://lists.onap.org/g/onap-discuss/message/17206 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]] -=-=-=-=-=-=-=-=-=-=-=-
