Are ESBs Relevant in the Age of Microservices?

Webcast replay

Centralized control over a monolithic IT architecture is giving way to agile microservices that are easily consumable and scalable. How should businesses in the middle of this transition think about the move to microservices?

Nikhil Hasija, CEO of cloud services orchestration provider Azuqua, joined Apigee's Alan Ho to share how companies make the transition and gradually shed older toolsets.

This webcast replay covers:

  • a brief history of ESBs, API integrations, and microservices 
  • best practices for creating and consuming microservices
  • how to empower self-service through distributed management
  • recommended tools and technology to help with microservices implementations



The Internet Doesn't Run on a Bus—Your APIs Shouldn't, Either

There is no bus in the internet. It is the caller’s responsibility to make the right call. Yes, there's a broken link or two on the internet, but then one of the two parties fixes it and the problem doesn't last too long.

The world of internal APIs looks like the figure on the right, not the one on the left. Don’t move into the future using a bus architecture. DON’T.

  • The scale of thousands of microservices and billions of internal calls rules out the monolithic architecture on the left.
  • Connectors are legacy; every service will expose clean, RESTful APIs.
  • Orchestration is pushed to code and logic within the services; what remains is much less onerous.
  • Stable interactions are less common; things change in months, not years.
  • Centralization of interaction is an antipattern

Keep your current integration architecture. Definitely. But build your future around APIs, and not integration architectures masquerading as APIs.

For more on this topic, check out the eBook, "Beyond ESB Architecture with APIs: How APIs Displace ESBs and SOA in the Enterprise."

Thoughts? Comments? Questions? Join the conversation (or start one) in the Apigee Community.


The Differences Between API and ESB Patterns

As enterprises embark on their digital journeys, APIs are often used to connect the fast pace of digital innovation with the more stable system of records. This is in contrast with ESBs, which are used to integrate various systems of record, for stable, well-understood business processes.  

diagram comparing ESBs to APIs


There are two stark differences between the world of APIs and the world of ESBs:

  1. APIs are consumption-centric, whereas services exposed through ESBs are exposure/reuse focused.  
  2. The logic for “orchestration” is not a significant driver for the API layer—apps are perfectly capable of calling service1, service2 and then service3, depending on the digital experience they need to deliver. Of course, some amount of orchestration might be present in the API layer, but it is not expected to be the dominant pattern.

You might ask, Anant and Arvind, all of this sounds great, but the proof of the pudding is in its eating, right? You did not think we didn’t have proof, did you?

Consumption patterns in APIs

We analyzed, for the top 450 APIs (based on call volume) of customers, the “structure of the APIs,” and their “orchestration/chaining patterns.”

Within Apigee Edge, an API can be configured to have policies that affect something in the APIs—sometimes to benefit the backend, and sometimes to enable developers to use them better. We classify the former as “exposure-centric”, and the latter as “consumption-centric.” 


API policy based call pattern diagram

API policy-based call pattern


We classified the over 30 different types of policies that our customers use into four broad categories, and, within them, whether they represent exposure or consumption concerns (the same broad category can have both exposure and consumption policies). As you can see from the figure below, a far larger set of policies affect consumption concerns.  

Once again, if you are not thinking consumption, you are not thinking about APIs right!

API proxy features distribution diagram

API proxy features distribution

Lack of chaining patterns in APIs

We also looked across more than 9,000 production-deployed APIs to discern whether they call other APIs, or whether they call target systems directly.


Direct access and chained APIs


As you can see in the diagram below, chaining is not a common pattern. We do find a few “experience APIs,” and some “orchestration” examples, but they are reasonably rare.

Once again, if you are thinking heavy orchestration, you are thinking ESBs, not APIs.

API call patterns diagram

API call patterns

Apigee has all the capabilities for exposure and API chaining, of course, and it is often used for microservices and chaining calling patterns, but the current dominant patterns are consumption and light orchestration. When the goal is speed of implementation, the Apigee platform, with support for Java, Node.js, and Python, is perfectly suitable for orchestrating services and mashing up content. The Apigee platform provides customers the ability to get into production quickly and to migrate if and when it makes sense to do so.

Special thanks to our head of product strategy Ed Anuff for helping us think through this topic.

For more on the differences between API patterns and ESB patterns, download the eBook "Beyond ESB Architecture with APIs."

Vantiv: Simplifying Payments Innovation with APIs

A payment layer to help developers build powerful user experiences

Vantiv's Shawn McCarthy has a simple mission: simplify payments innovation. 

The company’s director of IT, portals, and APIs explained in a recent interview how Vantiv is trying to achieve this goal by leveraging its unique position as an "integrated payments layer” that exists between the worlds of merchants and payments systems.

Vantiv built this position from a legacy in payments processing. It was founded in 1971 by Cincinnati’s Fifth Third Bank as Midwest Payment Systems to supply electronic funds transfer services to financial institutions.

For a long time, Vantiv (the name the company took a year before its 2012 IPO) focused on investing in ESB technologies—“We were more concerned with publishing from our systems of record,” as McCarthy put it. 

But as Vantiv wanted to leverage its technology to create new and powerful digital experiences, it realized the need to take more of an "outside-in" view.

“We had never thought of this from a consumption perspective, which is really the developer side of it and how they leverage the APIs,” McCarthy said.

And payments processing requires far more than just enabling a payment, he added. It requires the support of refunds, returns, chargebacks, and settlement, McCarthy said. 

"The developer or partner who is creating the experiences needs to exercise all those APIs," he argued.  “We want to be that integrated payment layer that they use whenever they want to facilitate the payment part of that experience."

Using Apigee enables Vantiv to more easily speed developers on this path to innovation, he said.

"I want to focus on business of simplfying payments innovation, while I still care a lot about security, compatibility, measurability, and monetization," McCarthy said. "But it's nice to have a platorm that is best of breed to handle those things for me so I can put more energy into simplifying payments innovation."

How the API Tier Trumps Monolithic Web Architecture

The evolution to today's unified app interaction channel

Previously in this video series, we discussed the differences between APIs and SOA, and how SOA simply wasn't designed for horizontal scale. 

In our latest fireside chat, I sat down with my colleague Brian Pagano to discuss how we progressed from a monolithic web architecture to today's unified app interaction channel architecture.

Each step in the evolution is not simply a bolt-on to a previous architecture; a modern API architecture requires thinking "outside in," and it requires consideration of the needs of people beyond certain trust boundaries. An API tier requires a completely different way of thinking about exposure and consumption.


For more on the evolution of the modern API architecture and the difference between APIs and SOA, download the free eBooks, "APIs are Different than Integration" and "Beyond ESB Architecture with APIs."


The "A" in SOA Doesn't Stand for "App"

The impedance mismatch between delivering modern apps and SOA

Most readers probably know that the “A” in API stands for “application” and that the “S” in SOA stands for “services.”

So what does that mean to you when contemplating whether to adopt an API-based strategy or a services oriented architecture (SOA) strategy?

Apigee’s Ed Anuff and Brian Pagano, two self-described “old SOA guys,” recently sat down together to discuss the differences between APIs and SOA, and the importance of choosing the right tool for the right job.



For more details on the impedance mismatch between delivering modern apps and SOA, download the free eBook, "Beyond ESB Architecture with APIs."