April 3, 2020

API and microservices vs ESB

When ever we talk about APIs, people always think about the legacy ESB/SOA/ESF stack.  They are not meant to solve the same problems.

  • SOA uses APIs – that’s about the only similarities. SOA is for integration, long running provisioning tasks, doing heavy protocol conversions.
  • APIM is about automation: taking those APIs, and managing it: with a dev portal, analytics, API catalogue for re-use, security.

SOA is NOT only for internal APIs, just as APIM is NOT only for external APIs APIM is for all APIs - to make APIs self-service, discoverable, and documented so that you dont need to email WSDLs/docs around. Internal developers will benefit as well.

But those are just outputs, what we really interested in is outcomes. And this is where APIM + microservices shine: because their outcome is measured in hours and days, not weeks and months like SOA. SOA spends most of their time worrying about Governance (with a big G), while MAD-API is allow about delivery, and just the bare-minimum governance (small g) as required.

To being understanding MAD-API and API Management, the first starting point is the 3 API layer design: API-Led connectivity

Where does Orchestration sit? ESB/SOA...or  microservices architecture MSA?

MuleSoft's API driven approach infers there are three fundamental types of APIs that should be created. System API' for system of record integration, Process APIs for ESB orchestration, and Experience APIs for each consuming client.

We took that design, and built the solution like this. We have Apigee as the Experience Layer, microservices as the Process Layer, and dedicated microservices for each system layer, going through another layer of Apigee for analytics, stats, consolidated API catalogue and routing.

The biggest learning we made was that using a Microgateway, is very different to an ESB, as a single large bus. Rather, each domain in each OpCo will need their own MGWs, that are dedicated for that domain. E.g. separate runtimes for Billing, portals, etc. This allows different teams to run and deploy at different speeds, and allows flexibility of having a different SI partner doing the API development for each domain.

Our design is based on something like this:  using API MGWs per domain, rather than a general purpose one,

Another problem with the general-purpose API backend is that they are by definition providing functionality to multiple, user-facing applications. This means that the single API backend can become a bottleneck when rolling out new delivery, as so many changes are trying to be made to the same deployable artifact.

The tendency for the general-purpose API backend to take on multiple responsibilities, and therefore require lots of work, often results in a team being created specifically to handle this code base. This can make the problem much worse, as now front-end teams have to interface with a separate team to get changes made - a team which will have to balance both the priorities of the different client teams, and also work with multiple downstream teams to consume new APIs as they become available. It could be argued that at this point we have just created a smart-piece of middleware in our architecture, something which is not focused on any particular business domain - something which goes against many people's views of what sensible Service Oriented Architecture should look like.


I attended this WSO2 talk last year, and this stuck out for me: https://www.slideshare.net/NadeeshaGamage5/api-management-within-a-microservices-architecture


So you can de-centralise functionality using MGWs, but still have centralised API Catalogue and Analytics: https://docs.apigee.com/api-platform/microgateway/2.5.x/overview-edge-microgateway


Also, referencing one of the common questions about about Cloud vs local Apigee deployments, we have already decided to go with a Hybrid approach.

Which means a:

  • Cloud-based Centralised API Management, API Catalogue and Analytics
  • Locally deployed MGWs, which pull their config from the Cloud, and push analytics and stats to the Cloud

https://docs.axway.com/bundle/APICentralService_UserGuide_allOS_en_HTML5/page/Content/Getting_Started/api_central_concepts.htm


Here is a brilliant article discussion what MGWs are, and the benefits of the Hybrid approach, and another article about MGW deployments with Microservices:

API Gateway Deployment Patterns in MSA

In the MSA, API governance can be achieved via 3 main API Gateway deployment patterns.

  1. Centralize API Gateway
  2. Private Jet API Gateway
  3. Sidecar API Gateway


Taking that concept further, and using microservices, brings us to Cell-based:


Which brings us to the main point about ESB and SOA:

https://apigee.com/about/blog/digital-business/differences-between-api-and-esb-patterns

Apigee is very commonly deployed alongside ESB technologies, and API Management as a technology can be seen to be complementary to ESBs. An ESB is an integration focussed technology that is concerned with the exposure of data, and typically features legacy adapters, and complex orchestrations that can be long-lived and transactional. In contrast API Management is a consumption focussed technology that is primarily concerned with presenting a consumable facade, along with all the tools to effectively publicize the APIs, make documentation available, and to manage the API consumers. Whilst API Management does provide some overlap with ESB technologies in terms of orchestration and transformation / mediation capabilities, the orchestrations and transformations done in the API Management layer should be those that are consumer focussed (e.g. reducing payloads to present appropriate data only to specific consumers, providing access to data in different formats, synchronously mashing up data from multiple back-end systems etc.) Refer to this article for a discussion on the key differences between API Management and ESB patterns, and also some insight of what we have seen from our 450+ API Management customers in terms of their usage of the Apigee platform


On the surface, the Microservices Architecture pattern is similar to SOA. With both approaches, the architecture consists of a set of services. However, one way to think about the Microservices Architecture pattern is that it’s SOA without the commercialization and perceived baggage of web service specifications (WS‑*) and an Enterprise Service Bus (ESB). Microservice‑based applications favor simpler, lightweight protocols such as REST, rather than WS‑*. They also very much avoid using ESBs and instead implement ESB‑like functionality in the microservices themselves. The Microservices Architecture pattern also rejects other parts of SOA, such as the concept of a canonical schema.

Both Mulesoft and WSO2 hail from ESB backgrounds, and they have are including micro-ESBs as part of the Microgateways. So again, no need for a large centralised (or even federated) ESB. I like this article, which ties up some concepts nicely:

The following is referenced from Gartner documents:

Enabling Agile Integration: 3 main points stick out, that aligns 100% to our chosen design:

  • It talks about having a distributed platform, each with the own lifecycle, to make it a logical platform, rather than a physical co-located one.
  • Allows multiple independent teams to develop on the different platforms per domain
  • Our job is to define the platform, guideline for development, roadmap, CI/CD processes and make it available to developers across the business.

Which also talks about Hybrid integration platform (HIP), that are formed of distinct and complementary tools including application integration platforms (enterprise service bus), integration platform as a service (iPaaS), API management and integration frameworks. Hybrid Integration Platform Is a Box of Tools, Not a Multitool.

Examples of vendor products that meet the criteria for a DIP are MuleSoft Anypoint (deployed on- premises), Red Hat Fuse on OpenShift and TIBCO BusinessWorks Container Edition.

Choosing Application Integration Technology mentions:

  • Use platform ESB deployments for predictable and systematic integration requirements that must be centrally developed, managed, monitored and governed, particularly when you integrate with legacy packaged applications and other systems of record.
  • Use distributed ESB deployments with modern application platforms to decentralize your integration implementation work to independent development teams,

So that again talks about having independent development teams deliver APIs and integration, in order to be agile. But how then to you govern it?

Integration Strategies

  • Traditional centralized integration competency centers (ICCs) are unable to keep pace with the volume of change required to enable business transformation and optimization.
  • Deliver fast, adaptive integration by setting up an integration strategy empowerment team (ISET).
  • Position the ISET as a “service provider” that supports a pervasively distributed approach to integration by enabling application teams, lines of business (LOBs), subsidiaries, departments and, eventually, business users via a self-service HIP-inspired infrastructure.

They all kinda have the same theme: have a mix of platforms (ESBs, APIM) to form a distributed Hybrid integration platform, have independent teams develop on them per domain, and govern it to control and shape it. So I think our role as Architectures is to be play the role of the Integration strategy empowerment team (ISET)

  • To be charge of designing and driving the overall integration strategy,
  • implementing the HIP, collecting and sharing best practices,
  • and delivering training, support, consulting, help desk and other services.
  • The ISET’s ultimate goal is to make these capabilities available, in a self-service way, to a variety of integration personas

NoESB: Not Only ESB - see Choosing an Architecture for Managing APIs and Services.pdf

The ESB is often viewed as the linchpin of an SOA, but it can be an overly complex and expensive choice of service container and mediator. "ESB" is also a much overloaded term. In this context, however, ESB refers to application integration platforms, rather than simple message-oriented middleware.

In the modern application service environment, the API gateway is now the most essential piece of service infrastructure. The API gateway consistently enforces runtime governance across any number of service implementations, irrespective of platform, and hence supports centralized policy management. The API gateway also enforces a clear separation of concerns between policy and application logic because it is not a service container. Advanced gateways can also support orchestration and integration capabilities. However, these should be used with extreme caution as they can break the separation of concerns by implementing service logic. They can also create scalability issues by moving compute-intensive work to the gateway. The lack of separation between policy and application logic will lead to management and maintenance issues over time.

The API gateway is an architecture pattern — the actual implementation will vary depending on priorities. It may be hybrid, centralized and clustered for resilience. Alternatively, it may be distributed to provide isolation of individual services or groups of related services. Regardless of how you structure the deployment of the gateway, the API management solution must centralize both policy control and visibility of API utilization (see Figure 4).

Gartner refers to this model as a "not only ESB" (NoESB) architecture, simply because the ESB's role is entirely optional. We consider NoESB the preferred architecture for a majority of modern application initiatives.

Address Digital Business Demands - Interesting read from Gartner about using an API-led approach to BSS (CRM, ERP). So instead of using the CRM or ERPs built in UI, you create your own customised UIs, using the APIs that CRM/ERP expose. They identify that this API approach requires different skills, and needs to align with Business:

And I think that pretty much sums up the way legacy corporates are adapting and changing. Legacy mentality wanted simplicity, turnkey, end-2-end from a single vendor. Now, we want flexibility, agility and modulatory, and an API-oriented approach allows for that

And how it looks, using an APIM Platform:

Read VMWare/Pivotals Migrating an ESB to a Cloud-Native Platform for a discussion on ESB and microservices, orchestration and choreography, and light-weight ESB frameweworks (Spring Cloud Stream, Apache Camel)

In summary, we promoting:

  • Many MGWs per domain/Cell
  • No need for a centralised SI/Dev team – each domain/Cell can have their own Scrum team, but follow centralised governance: API Style guides, CI/CD, Git, Monitoring, etc
  • Which allows each time to run at their own pace
  • Light/Query Orchestration can happen at the domain/Cell level, using API MGW and MSA – eventual consistency
  • Long running orchestration, that changes/updates a customer that needs immediate consistency all the time, should be done at ESB/SOA layer.



Further Reading: