Hi,
I think that there are a few aspects to this topic. And I was wondering if we
can break the questions down.
** Situation Description **
My understanding of the situation is:
* At an overall functional architecture, we have the External API GW, which
current provides 3 TMF based APIS, and supportive APIs (health check). It can
evolve the support future APIs. The consumer of these APIs should not be aware
of the functional architecture inside ONAP, and if that was to change, the
consumer of the APIs should not be impacted.
* There is a agreed scope of the MSB project wise to support a internal and
external gateway “to the external world”.
* The code for the external gateway has not been contributed, and there is
now the idea to contribute it.
* There is a proposal on the table for an external GW levering alternative
technologies:
* Facad, API LCM, compose/aggregate APIs, and more.
With this in mind:
* I do not think that we have properly articulated the difference between
External APIs and the External GW in MSB. While by rights, MSB has the
external GW in its scope, and can execute on that unless the TSC changes the
project scope, I do think that we should debate the positioning of the External
APIs function and the External GW in MSB and arrive at a conclusion.
* Some parts of the new APIGW proposal appear to describe a technical
capability that projects can use, and some parts indicate that this is a
function that potentially other projects can call.
* I know there was a comment from Mike indicating a concern regarding
footprint (indeed an important consideration), equally though that has to be
balanced against technical efficiency and the functional architecture.
* The GWAPI proposal comes with a problem statement, however – the
mapping between the solution and the problem statement hasn’t yet being
articulated:
* Example: APIS are managed at an individual project level etc.
* However I understood that each project will still have their own
APIs, hence that remains the same
* Example: enhancing multiple components for standard APIs is time
consuming
* Does this result in an approach where all standards interactions
are centralized in one place (which maybe a view supported by those wanting to
show how standards compliant boxes can interact with ONAP, but raises other
architecture questions) or does this result in an approach where there is a
technology to effiently support API conversion at different parts of the
architecture (which maybe a view supported by those who try to build standard
compliant products based on ONAP)
* And so on.
** Overall Functional architecture **
* I was hearing alignment that we don’t want to introduce a new “function”
for an API GW in addition to the functions we have
* I am hearing that we need to further articulate the difference between
the MSB External GW and the External API functionalities:
* What is the essential difference.
* What type of scenarios should use External APIs, what type of
scenarios should use MSB External GW
* Is this for mediation between communication of ONAP components
**Technology **
* What are the needs on the technology.
* Does the technology support one functional entity, or is it used by many
* Do we have only one technology solution or allow for multiple?
** Project **
* Based on the conclusions above, we can address the project questions of
whether we need a new project, or this could be part of an existing project;
and if so are any scope changes. Here it would be good to understand as well
are there further stakeholders in the project beyond the project itself.
** how to move forward **
To move forward, can we step back and agree on the questions that we need to
answer, and work through them.
* What is functional difference between the External API GW, and the MSB GW.
* Do we need both, or only one. If we need both, how do we articulate
the types of scenarios that use External APIs vs MSB gateway.
* What is the mapping between the problem statement and how the solution
proposes to address the identified problems.
* Based on the functional needs, is there a value in a common technology
for solving those needs.
* Is it one technology or several technologies
The above may not be the right questions, I am suggesting that we identify the
questions we need to solve. Lets spend some time in the next architecture
meeting to identify the questions.
I am open to other suggested approaches in moving forward.
As an aside comment - Regarding the relationship to ISTIO, I think that the
follow-on comments below are good regarding the intent and approach.
Consideration has to be given to the administrative domains as well (i.e. who
configures the permissions etc) where a “GW” can be a bridge between the domains
BR,
Steve.
From: [email protected] <[email protected]>
Sent: Thursday 23 May 2019 10:23
To: [email protected]; [email protected]; Stephen
Terrill <[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 (#17214): https://lists.onap.org/g/onap-discuss/message/17214
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]]
-=-=-=-=-=-=-=-=-=-=-=-
