Submit support requests and browse self-service resources.
What's the difference between ESB and API gateway? In this blog, we compare ESB vs. API gateway and provide guidance on when you should use which one.
Enterprise Service Bus (ESB) is a legacy technology for connecting your digital services. An API gateway is a proxy layer for your digital services which manages a variety of features via APIs. An API gateway is often preferred over ESB for its orchestration, integration, and security capabilities.
Enterprise service buses (ESBs) are legacy tools for achieving enterprise application integration (EAI) tasks. They offered an abstraction layer and allowed for orchestration of various application-to-application transfers. They offered somewhat of a precursor to API gateways and focused on exposing services for reuse. Yet as enterprise needs shift and APIs have become increasingly important, API gateways have proven a more useful tool to achieve orchestration of digital services
An API gateway is better suited to helping you achieve digital transformation, when compared to an ESB. Here are the key differences with ESBs vs. API gateway.
An API gateway is better suited to orchestrating digital services, databases, or applications than ESBs.
API gateways are simply more flexible and platform-agnostic. Likewise, they align with how critical APIs have become in achieving digital transformation in the modern enterprise. Here are a few key advantages:
And sure, an ESB can be used to orchestrate or aggregate multiple services. But ESBs are not purpose-built to deal with APIs, which is a huge shortcoming.
Again, API gateways provide stronger integration capabilities than ESBs.
An API gateway aggregates data from different sources with its API integration capabilities.
An obvious example is customer data. In many cases, data about customers is distributed across multiple applications. Think about your banking data. You likely have checking, savings, investment, mortgage, and maybe many other linked accounts. These are most likely not managed by the same backend applications. But your web or mobile application wants to be able to make a single API call to retrieve balance and status information for all these accounts.
You could do this in an ESB, but these capabilities are often more easily and efficiently provided by your API gateway solution.
Most ESBs come from a time where SOAP was dominant. ESBs still use it as a primary communication protocol, often with RESTful capabilities loosely-bolted on.
SOAP still has its place. It is better suited than RESTful approaches for some scenarios.
But an API integration platform needs a deep understanding of:
An API gateway delivers on all that — and more.
An ESB is prescriptive, while an API gateway is declarative.
ESBs tend to require developers to write code to manage even fairly simple mediation tasks. ESBs act in a prescriptive manner, doing exactly what they are instructed to do.
A good API Gateway abstracts interfaces from implementations. It further abstracts policies allowing for a configuration-driven approach to integration. This makes it declarative.
API gateways are better than ESB for network edge deployments.
A core function of an API gateway is threat management and prevention. API gateways provide extensive security capabilities that are typically missing from an ESB. This means that an ESB is not suitable for network edge (DMZ) deployment.
Why is this such an issue for internal integration?
Because the definition of internal has changed. In many cases, with enterprise adoption of cloud platforms, the system you’re integrating with is distributed across multiple data centers, business partners, and cloud providers. You need an integration solution that provides the protection you need while still offering the rich integration capabilities you want.
How to Secure Edge APIs and Microservices MeshAPIs can be major points of vulnerability. That's why it's critical that you learn how to secure edge APIs and the microservices mesh. Get our recent white paper to learn how. 📕 Get the White Paper
APIs can be major points of vulnerability. That's why it's critical that you learn how to secure edge APIs and the microservices mesh. Get our recent white paper to learn how.
📕 Get the White Paper
API gateways are preferable to ESB in many ways.
API gateways are:
An API gateway is an important part of the API lifecycle — and one of the key API basics.
There are still some enterprise integration patterns where the API gateway isn’t the right choice.
Although we do recommend you modernize your approach to ditch these old patterns.
API gateways like to work in a stateless manner offering high-performance and seamless scaling. Long-running transactions consume resources and force a different model in the gateway. It’s not that API gateways can’t handle long-running transactions. It’s more that there are often better approaches.
Where transactions involve human interaction (a special form of long-running transaction) you should really be thinking about breaking the transaction up into multiple different API calls. This is better than trying to implement the workflow in the API Gateway. This is one of the areas where use of ESBs got a bit out of hand in many organizations.
Most API gateways do not include their own messaging system. But a good API gateway can act as an intermediary between the messaging system. And a really good one can even maintain the guaranteed “once and once-only” heuristic of a messaging system.
Where API gateways come into their own is in creating APIs (REST/JSON for example) from an application that listens on and writes to a queue. Good gateways can also do this the other way around, listening on queues themselves and acting appropriately when they see a new message.
All this said, let me reiterate that an API gateway will not typically include its own message broker, and this can be a good thing.
This is another fine line. In the past, we would always say that a gateway should stick to syntactic mediation (think in terms of dealing with the envelope of a message, or the packaging of a parcel). It should not involve itself in semantic mediation (handling the meaning of the content).
A classic example would be transformation of a purchase order form from one company’s format to another. Today this has changed somewhat. Many gateways offer strong content mediation (even if it’s just XMLJSON). Some even offer sophisticated mechanisms for converting documents from one semantic form to another.
Still, be careful about how sophisticated you want to make your document mappings in the gateway as it can quickly become a management challenge.
An API Gateway provides an excellent integration solution and is often superior to an ESB.
So, now that you’re armed with all this information, what should you do next?
At the very least ensure that when you look at new projects, you take advantage of new capabilities rather than continuing to pour money into an already aging and expensive infrastructure.
If you're looking for an API gateway, give Akana a try.
Akana's API gateway protects your data and secures access to APIs. It provides:
See for yourself why the Akana API gateway makes it easy to integrate services — and go beyond ESB.
Click below to find out if you qualify for a free 6-month trial of the Akana API management platform, including the API gateway.
Try AKANA ▶️ WATCH A DEMO