See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
7 MIN READ
For the modern enterprise, the focus on customer obsession—an endeavor shown by research to bring better revenue growth and customer retention—requires connectivity across all of an organization’s resources. Back in the day, the Enterprise Service Bus (ESB) was the primary provider of connectivity for a service-oriented architecture (SOA).
Today, however, organizations are moving towards decentralization, replacing monoliths with microservices, and migrating their applications to the cloud. They are liberating siloed data and modernizing legacy applications—and they’re using APIs to do so.
The connectivity needed to provide delightful customer experiences is more critical than ever. In this post, we’ll look at the connectivity solution of the past: the ESB—what it is, its benefits and its shortcomings.
Connectivity has always been important. In the past, companies focused on organizational efficiency. The ESB was originally envisioned as the connector in a service-oriented architecture (SOA), connecting different services with different standards and protocols. The ESB enabled a monolithic enterprise architecture with on-premise applications and databases.
In an SOA-based IT environment, each service sets up a single integration with the ESB. The ESB makes that service available to other services, handling format transformation, protocol negotiation and queueing. In some cases, it even manages additional business logic. The ESB is the central connector for any applications or services looking to consume or publish data.
Diagram 1: The Enterprise Service Bus
In this role, the ESB becomes a hub of IT infrastructure, effectively decoupling services from one another.
As more services go through the ESB, the drive to bring every new service through the ESB increases. Eventually, the ESB becomes a monolith service of its own. Each integration with the ESB contains a little more logic. Before long, the business logic no longer lives in the individual services but rather in the ESB.
Naturally, the ever-growing ESB requires more attention, and a dedicated IT team bears responsibility for maintaining the ESB. Since the ESB acts as a centralized hub for all service-to-service communication, the ESB team must function similarly, communicating and working with the various application teams.
Without the ESB, the need to build specific service-to-service integrations grows exponentially with each service added to the system. With an ESB, each new service only requires one new integration—directly with the ESB.
ESBs bring service discovery, acting as a continuous, up-to-date directory of all the services in an organization. The ESB coordinates the consumption and use of data from each service.
By serving as a message queue, the ESB decouples services, which no longer need to be online at the same time to communicate. The ESB, therefore, makes inter-service communication more resilient and able to withstand the failure of any individual component.
ESBs also add load balancing for increased service availability and transactions for performing complex operations as atomic units with rollback capability.
As each service produces and consumes data in its own way, the ESB team becomes responsible for all the integrations with the ESB. The team also needs to develop and maintain any new ESB functionality. While the ESB originally promised to decrease complexity to the overall IT architecture, it introduces its own complexity and overhead.
The centralization of the ESB results in a high coupling of teams and decreased team independence. Since every service needs to integrate with the ESB, the team managing that service must work closely with the ESB team on each individual change.
As the ESB facilitates integration and bolsters business logic, it becomes not just another monolith service but a monolith service that all other services are required to work with.
The overall result of this team coupling and increased overhead is less agility for each team and the organization as a whole.
Today’s IT teams are increasingly becoming distributed. The high value placed on agility leads to small, autonomous development teams that cannot be coupled to a central team (like an ESB team).
Today’s IT environments are heterogeneous. Organizations are working with hybrid-cloud and multi-cloud environments. As a result, points of integration must be able to span various types of environments.
The move towards microservices is fundamentally at odds with the traditional, monolithic ESB. By breaking down the monolith ESB into multiple focused services, organizations retain many advantages all while increasing flexibility and agility.
This leads us to the new model of integration and connectivity: the API gateway.
So far we have discussed the connectivity solution – Enterprise Service Bus (ESB) which was a preferred method for connecting monolithic applications.
Now 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.
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 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 can enable your organization to become customer-obsessed?
Share Post
Learn how to make your API strategy a competitive advantage.