Open APIs

Expand all | Collapse all

Impact of microservices in exposing Open APIs

  • 1.  Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 16 days ago
    Hello.

    What is TM Forum's view on - when one application (i.e. Application X) consumes a TMF Open API exposed by another application (i.e. Application Y) that is microservices based, should the consuming application know which particular microservice is serving the call?

    The assumption here is that Application Y has different microservices to serve one TMF Open API exposed.

    Thanks.

    ------------------------------
    Jay Dela Cruz
    Globe Telecom Inc.
    ------------------------------


  • 2.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 16 days ago
    Hi Jay

    From Open API perspective, there is no prescription for how an API is implemented. At least in principle you could have a huge monolith, written in COBOL, that could implement all (or many) of the Open APIs. The consumer of an API needs a REST endpoint that will be directed (presumably by an API gateway) to the actual implementation, and so should be completely unaware of which software is implementing the API. It is even possible that (e.g. in a canary deployment) some calls will go to one implementation while other calls will go to a different implementation.

    Perhaps you can give a concrete business example of what is bothering you.

    In the ODA project, they are defining components (which may or may not be microservices), where to my best understanding (subject to correction by ODA experts) an API cannot be exposed by more than one component, so there is no ambiguity.

    Hope it helps.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 3.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 16 days ago
    Edited by Jay Dela Cruz 16 days ago
    Hi, Jonathan. Thanks for responding right away. Ah and your statement on an API cannot be exposed by more than one component - I completely agree and is actually the point of my question. Maybe I wasn't able to state it clearly. But if we restate it as - an API cannot be exposed by more than one microservice will still hold true right?

    To give a business example, let's say a customer orders from a Digital Marketplace. The marketplace will issue a TMF 622 Product Order call (via an API Gateway) to the BSS Order Management system. I'd think the marketplace only needs to know the API endpoint exposed in the API Gateway, since it's the gateway that will take care of calling the Order Management system.

    Now, what's bothering me is this:
    • If it's a monolith, the API Gateway would just have to know one API end point for the 622.
    • But if it's a microservice architecture and let's say there are several microservices that contribute to serve the purpose of a Product Order flow, the API Gateway should just know one API endpoint for 622 right? Having several microservices that support one TMF Open API doesn't mean the API Gateway would need to know each of the microservices because that would change how the APIs are called. Would you agree?

    Thanks!

    ------------------------------
    Jay Dela Cruz
    Globe Telecom Inc.
    ------------------------------



  • 4.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 16 days ago
    Edited by Vance Shipley 13 days ago

    On Jun 03, 2021 11:27 @Jonathan Goldberg wrote:
    ​​> In the ODA project, they are defining components (which may or may not be microservices), where to my best understanding (subject to correction by ODA experts) an API cannot be exposed by more than one component, so there is no ambiguity.

    That statement leaves room for doubt.

    Is it that a specific API (i.e. TMF620) may only be produced by a single ODA Component in an ODA System?  No, I don't think that works. In both BOS Catalyst projects we demonstrated Product Catalog federation between ODA Components which produce TMF620. In BOS I we had a hierarchy and described various delegation patterns.

    Is it that one instance of an API may be provided by at most one ODA Component? What is an instance? That might seem obvious if you consider that an IP Address:Port is bound to a socket with a listener process on a server. However the ODA Decoupling and Integration functional block accomplishes API exposure so that level of detail is obfuscated entirely.  To apply an API exposure rule which demands that /productCatalogManagement/productSpecification/ MUST be routed to the same ODA Component as /productCatalogManagement/productOffering/ and  /productCatalogManagement/catalog/ seems unnecessary, arbitrary and indeed harmful. How would this even be enforced?  For what purpose?

    This issue has triggered me because I've been highlighting of late just how arbitrary TMFXXX granularity is. TMF620, for example, should be decomposed into a list of services/capabilities it provides and those should exist in a registry, available for discovery, and that forms a much more appropriate level of 
    granularity for this type of discussion.



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 5.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 15 days ago
    To continue the discussion on "an API cannot be exposed by more than one component" in ODA, another set of usecases to consider:
    • Multiple order capture systems (divided across country borders or lines of business etc) feeding into common stack
    • Multiple shipping systems that are used based on nature of shipment and destination
    • Multiple partners exposing various TMF APIs that need to be integrated via delegation or federation
    • ...

    We do need an unambiguous way of routing information back and forth under all these circumstances.  Perhaps this can be seen as part of TMF688's remit?


    ------------------------------
    Rakshit Simha
    Oracle Corporation
    ------------------------------



  • 6.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 13 days ago
    This brings out several important points:
    • Use of terms API and component need to be qualified by whether one is talking about the concept, a specification, an implementation  or a deployed instance.
    • Use of virtualisation makes instance coupling a run time issue decision than a design decision
    • Arbitrary  boundaries  to current API specifications  and the need for service based description of API functions


    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 7.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 12 days ago
    I would add that the lack of emphasis on even-driven-architecture (EDA) concerns me.  For example, the BSS Order Management system's primary focus on orchestration results in extreme coupling in a concentrated area which produces the same issues as monoliths.  I know that basic events are defined in the specs, but throughout the conversations and even looking at the emphasis in the specs themselves, EDA seems like an afterthought.

    ------------------------------
    Brian Larson
    AT&T Inc.
    ------------------------------



  • 8.  RE: Impact of microservices in exposing Open APIs

    Posted 11 days ago
    Edited by Tomáš Hajný 11 days ago
    To be honest, my previous experience with integrations (especially in the customer and order area!) built on top of event-driven-architecture has been that solutions based on this pattern resulted in questionable customer experience and rather limited usability (to say the least) for digital services. In particular, this pattern led to longer overall processing (which made it difficult for use with digital services, but to some extent also in mobile area, because customers usually expected immediate results for these) and also difficulty with processing of outcomes in the originating process.

    I certainly don't want to say that event-driven-architecture should not be used, it's a valid and in certain cases very effective pattern, but I'm not convinced that BSS Order Management is the most suitable candidate for this approach.

    Just my two cents

    ------------------------------
    Tomáš Hajný
    CD - Telematika
    ------------------------------



  • 9.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 12 days ago
    I wonder if these topics require an ODA IG Guide - along with some work on evolving the API specs too. Perhaps a topic to be added to the IG Guide backlog.

    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------



  • 10.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 12 days ago
    I'm glad that my reply has posted some discussion while I was absent on vacation. Apart from anything else this has highlighted a lack of clarity in what I said regarding the ODA component approach (apologies for that), so let me try again.

    Part of the ODA work is defining functional components (such as Product Catalog, Party Management, and many more), see the recently draft component list here (it's in team approved status, I guess waiting for member approval). So what I meant to say was: it doesn't make sense in general (to me at any rate) that more than one functional ODA component definition should expose the same API. Violating this guide would mean that multiple different systems are somehow "owning" the same data item. It could be that we will discover specific deviations from this guideline that would need to be discussed and justified.

    Vance, Rakshit, and others correctly pointed out that there can potentially be multiple instances of the same ODA component in a deployment, coming from different suppliers (vendors), e.g. multiple federated product catalogs all exposing operations from the same TMF620 API. And then we have the challenge of how to route consumer calls to the "correct" implementation.

    Vance also makes a very good point about the API granularity - the API is "just" a document (swagger file, user guide). What is important for implementations is which operations are exposed, and indeed the ODA component spec is going into that level of detail, see the first pilot guide published here (for product catalog).

    Hope this is now clearer.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 11.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 11 days ago
    Your clarifications are very useful @Jonathan Goldberg  Thanks for providing those references. ​

    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------



  • 12.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 11 days ago
    Edited by Vance Shipley 11 days ago
    On Jun 8, 2021 6:12 AM, @Jonathan Goldberg wrote:​
    > it doesn't make sense in general (to me at any rate) that more than one functional ODA component definition should expose the same API. Violating this guide would mean that multiple different systems are somehow "owning" the same data item. It could be that we will discover specific deviations from this guideline that would need to be discussed and justified.

    The Component definition work you referenced contains one such deviation as each Component may expose the same APIs on it's management surface.

    In my view the APIs implement operation patterns specific to a type of data. Any Component exposing service capabilities involving that type of data should use a matching API.  Every Component could be a producer of APIs implementing the inventory archetype (639,638,637) to make it's internal data available.

    > the API is "just" a document (swagger file, user guide). What is important for implementations is which operations are exposed

    Yes!  The granularity produced by the packaging is unimportant architecturally.  Having a complete "swagger" file, with no external references, makes the APIs more digestible for those who need just one, however we could also create one giant object supporting the resource paths of all APIs, or any other combination.

    It is my opinion that we should be focusing on the service capabilities produced and consumed. Today those are made available through Open APIs (could change as technology evolves) but it is not a 1:1 relationship.  We should begin by introducing management service discovery and registration as a normative set of ODA System Services (using 639 and 634).

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 13.  RE: Impact of microservices in exposing Open APIs

    TM Forum Member
    Posted 11 days ago
    Beyond design terminology defining "what is a component" in this context, there being multiple components in a landscape exposing the same type of API (federation), there is also the runtime and implementation aspect.

    The latter was part of the BOS Catalyst II where we demonstrated event-driven (EDA) micro-services that use the CQRS pattern, packaged as an ODA component (also as Vance mentioned, federation is being explored in that series). Here 1 ODA component envelope contained many micro-services all serving parts of several TMF OpenAPI schemas. We used ISTIO service mesh with virtual services and a swagger aggregator to achieve one API surface being served by many (independently deployable and scalable) runtime services to achieve TMF OpenAPI compliancy.

    Specifically for CQRS (a pattern often associated with micro-services), there can be a command and query implementation that should be scalable independently and as such have different endpoints. If you expose those as REST API's like TMF OpenAPI, you end up with multiple API surfaces (which you then need to aggregate, to form a single API surface). Also when you talk about design paradigms often associated with micro-service design like DDD, following these will probably not end up in a situation where something like TMF620 is served by just one component (DDD and REST to begin with do not go hand-in-hand).

    ------------------------------
    Pieter Pabst
    Tech Mahindra Limited
    ------------------------------