In our [last blog](https://konghq.com/blog/api-infrastructure-esb-versus-api-gateway)last blog, we discussed the connectivity solution – Enterprise Service Bus (ESB) which was a preferred method for connecting monolithic applications.
In this blog, we will discuss the role of an API gateway in today's modern distributed world. We'll also compare ESBs with API gateways and discuss how these connectivity solutions can co-exist to support both legacy and modern applications.
[
An API gateway is a modern infrastructure component between clients and services, acting as a single point of entry for clients. Similar to ESBs, API gateways connect and integrate disparate services. However, with the rise of APIs, the task of connectivity is more focused.
Figure: API gateway
ESBs, in their original form, were a technical solution to a former standards problem. That problem has been solved through the standardization of protocols in APIs. Now, spec-first API development decouples development teams and brings focus to business requirements by prioritizing business and customer outcomes. API-first design leads to better reuse and relevance for business-led "products."
Microservice-based architectures have led to a dramatic increase in the number of services to manage. API management simplifies this oversight task by considering the entire API lifecycle—design, documentation, deployment, discovery, and Day 2 concerns. Central to this is the concern of connectivity, which the API gateway addresses. Let's consider how.
By centralizing functions common across all APIs, the API gateway reduces overhead and enables leaner microservices. Cross-cutting concerns such as authentication, logging, and monitoring can be implemented once and handled at the gateway level.
API gateways also decouple clients from the services' implementation details, allowing for the orchestration of multiple microservices into one client API.
A developer portal working alongside an API gateway promotes API adoption and reuse by ensuring that APIs are highly discoverable, well documented, and easy to consume.
By reducing the number of roundtrips required for a given API call, API gateways can improve performance. Through orchestration, several API calls on the backend can be aggregated into one roundtrip from the client to the API gateway and back. API gateways can also leverage caching strategies to reduce the load on services.
The API gateway is also well positioned to provide logging, monitoring, and analytics data as it relates to requests between the client and the API gateway.
Finally, the application of [plugins](https://docs.konghq.com/hub/plugins/overview/#terminology)plugins and policies at the API gateway level yields consistently applied best practices across all services. This includes areas like security, traffic control, request and response transformation, logging, and more.
The similarities between API gateways and ESBs are clear. Both solutions function as the centralized intermediary for communication with services. However, API gateways offer a modern approach with additional advantages.
ESBs can evolve into massively complex systems. On the other hand, API gateways have a clear scope, focusing specifically on cross-cutting concerns and client-service communication. This allows the API gateway to stay lean and specialized.
In contrast to ESBs, API gateways allow for decentralization and distribution. This aspect empowers both kinds of enterprises—those which are journeying to the cloud, and those which are taking a hybrid approach.
ESBs are large, central monoliths that increase coupling between teams and decrease independence. API gateways, on the other hand, enable teams to be leaner and more specialized, freeing them up to focus on their individual tasks.
API gateways—with developer portals—also foster a design-first API approach and promote a mindset of discovery-led consumption. By providing the right API for each client, API gateways enable increased adoption and reuse.
The selection of an API gateway requires the consideration of several criteria.
First, consider the technical requirements of the gateway. How many pieces must be set up to get to a minimum viable installation? Initial deployment complexity is likely to inform future maintenance requirements.
Consider the extensibility of the platform as well as the probability of long-term support. Introducing an API gateway into your environment is a significant architecture-level change that affects many teams. It is not something you want to be forced to remove due to the end-of-life situation of a third party.
The API gateway will be in the critical path for every client-service interaction. Consider your growth plans and whether the API gateway can scale—horizontally *and* vertically. Scale management is best achieved through orchestrated and declarative approaches like Kubernetes.
An API gateway must support the full API lifecycle. Beyond this, an organization should consider carefully the role of the API gateway, looking for a product that specifically fulfills that role, regardless of feature set size.
What are the next steps for organizations currently using an ESB but considering the introduction of an API gateway into their architecture?
When an IT organization wants to move toward agility and rapid innovation, it must build a culture of teams that are independent, lean, and focused. This requires embracing a diversity of technical solutions and approaches. Some examples of this heterogeneity would include:
With regard to integration platforms, the focus should now move to APIs. API connectivity is the new competitive battleground, and API gateways are a solution specifically geared toward this purpose.
A gradual hybrid approach is often the best starting point. Implement an API gateway with new APIs, and gradually break apart the monolith ESB by bringing over more services as opportunity and time allow. Piece by piece, extract the business logic from the ESB and distribute it into new microservices.
The goal is to move the ESB out of the critical path for new development, not necessarily to replace it entirely. After all, the ESB still has a role to play for legacy services that may never get upgraded.
Additionally, focus on those new APIs and the API Management capabilities unlocked by the API gateway. Generate value through connectivity, and the underlying implementation should naturally shift towards the place with the most value. A focus on API connectivity will generate value for the modern enterprise.
Interested in [learning more about how Kong's API gateway](https://konghq.com/kong)learning more about how Kong's API gateway can enable your organization to become customer-obsessed?
Imagine 47 million requests hitting your platform last month. Can you prove who made each one—and invoice with confidence? If that question tightens your stomach, you're not alone. Metered billing for APIs promises fair, transparent pricing that s
[](https://konghq.com/blog/enterprise/guide-to-metered-billing-for-apis)
The challenges of an acquisition frequently appear in a number of critical areas, especially when dealing with a platform as important as Kafka: API Instability and Change : Merged entities frequently rationalize or re-architect their services, whic
[](https://konghq.com/blog/enterprise/vendor-agnostic-abstraction-layer-kafka-acquisition)
Managed Redis cache is a turnkey "Shared State" add-on for Kong Dedicated Cloud Gateways. It is designed to combine the performance of an in-memory data store with the simplicity of a SaaS product. When you spin up a Dedicated Cloud Gateway in Kong
[](https://konghq.com/blog/product-releases/multicloud-cloud-gateways-managed-redis-cache)
Modern organizations rely on APIs to power their digital customer experiences. This can lead to stronger brand loyalty and higher revenues — if they play their cards right. The driving factor in delivering personalized content is connectivity to mor
[](https://konghq.com/blog/enterprise/how-to-choose-an-api-gateway)
Almost all aspects of businesses are transforming to digital and internet-based solutions. It’s happening from the ground up, starting with developers. You're building applications for your organizations, and you're racing to get software and servic
[](https://konghq.com/blog/enterprise/api-gateway-governance)
This article was written by Jeremy Justus and Ross Sbriscia, senior software engineers from UnitedHealth Group/Optum. As part of the UnitedHealth Group (UHG), Optum optimizes healthcare technology, and one of our important missions is to provide the
[](https://konghq.com/blog/enterprise/unitedhealth-group-kong-gateway)
This article was written by Ivan Rylach, a staff software engineer from Checkr. Checkr is the leading technology company in the background check industry. The company was moving to a services-oriented architecture. To scale this process, we switche
[](https://konghq.com/blog/enterprise/checkr-kong-gateway)