How API gateways complement ESBs

For the modern enterprise, providing delightful customer experiences may be an all-encompassing task, but obsessing about customers is well worth the effort. Forrester research reveals that customer-obsessed companies achieve 2.5 times higher revenue growth and 2.2 times better customer retention.

Implementing systems that put the customer in the center requires harnessing all of an organization’s resources in a way that is greater than the sum of its parts. Connectivity is a key part of any modern IT infrastructure, and it’s becoming more complicated and important than ever before.

Enterprises across industries are embracing decentralization, replacing monoliths with microservices, and abandoning the idea of having whole organizations use a single technology stack. Instead, teams are embracing a diversity of languages, platforms, and solutions, and they are using APIs to liberate siloed data and modernize legacy applications.

In this article, I’ll compare two enablers of connectivity: the enterprise service bus (ESB) and the API gateway. My goal is to explain the environments and use cases for which each is best suited, including recommendations for how organizations can best move forward in modernizing their API infrastructure in a thoughtful, incremental way.

Connectivity reigns supreme

To provide customers with great digital experiences, it is important to connect all of your organization’s interactions with the customer across marketing, sales, IT, and all other departments. Only through this complete connectivity can you gain a more holistic understanding of the customer—order history, demographic information, loyalty data, complaint history, and more.

To generate this 360-degree view and the resulting omni-channel experience, you must have connectivity as the core of your IT strategy. Every system and business process within the company must be connected, and kept up-to-date, to enable a seamless, personalized, and delightful customer experience.

Connectivity and the ESB

In the past, companies focused on organizational efficiency with their connectivity endeavors. The enterprise service bus (ESB) was originally envisioned as a connector for all services. In a service-oriented architecture (SOA)—which was still growing and evolving—the challenge of connecting different services with different standards and protocols was significant, and the ESB rose to meet that challenge.

In environments that were becoming more centralized, the ESB was a significant enabler of monolithic enterprise architecture. With the need to connect large, on-premises applications and databases, the ESB achieved that connectivity.

The function of the ESB

The role of an ESB is to decouple services and applications that exist in a SOA-based IT environment. Each service must set up just a single integration with the ESB, and the ESB makes that service available to all other services connected to the ESB. The ESB serves as a one-stop shop for any application or service looking to consume or publish data. The ESB typically handles:

Format transformation
Protocol negotiation
Queueing
Additional business logic (in some cases)

The ESB is an intermediary for all service-to-service communication. In its role as a negotiator and mediator of inter-service communication, the ESB tends to become a central hub of IT infrastructure, providing many features that allow it to integrate with just about every service, including legacy services.

ESB at scale

As more services go through the ESB, the drive to bring every new service through the ESB increases. There is a “network effect” like those of large social networking apps. The more people that are on the network, the more draw there is for others to join.

The ESB eventually becomes an essential monolithic service of its own. Each integration with the ESB goes just a bit further and contains a little more logic. Before long, the business logic no longer lives in the individual services but rather in the ESB.

As the ESB grows, it naturally requires more maintenance and attention. This responsibility typically goes to a dedicated IT team. Because 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. Coordinating new features and rollouts avoids breaking downstream dependencies.

Drawbacks of ESBs in modern environments

In the modern IT landscape, service development has moved toward an API-first and spec-first approach. IT environments are also becoming increasingly distributed. After all, organizations are no longer on-premises or even cloud-only, but working with hybrid cloud and multicloud environments. And their teams are physically distributed, too. Therefore, points of integration must be able to span various types of environments.

The move toward microservices is fundamentally at odds with the traditional, monolithic ESB. By breaking down the ESB monolith into multiple focused services, you can retain many of the ESB’s advantages while increasing flexibility and agility.

With an understanding of ESBs and the shifts that are occurring in the modern enterprise, let’s look at the API gateway as a model for integration.

The API gateway

An API gateway is a modern infrastructure component between clients and services. The API gateway acts as a single point of entry for clients, in contrast to an ESB, which handles all inter-service communication.

Similar to ESBs, API gateways connect disparate services and integrate that information. However, with the rise of APIs, the task of connectivity is more focused.

A shift from service-first (ESB view) to API-first

APIs provide the standardized contract that was missing from the SOAP environment. In their original form, ESBs were a technical solution to a former standards problem. Additionally, with the advent of spec-first API development, the contract between client and service no longer needs to wait for the service to be developed, further decoupling development teams. API-first design leads to better reuse and relevance for business-led “products.”

The API gateway allows you to simplify the task of connecting to any API. An API gateway handles cross-cutting concerns such as authentication, logging, and monitoring, as well as orchestration to reduce round trips and provide the correct API for each client.

API gateways offer many benefits, including the following:

Leaner microservices allow the centralization of common functions to reduce overhead. Rather than reinventing the wheel with every service, cross-cutting concerns such as authentication, logging, and monitoring can be handled at the gateway level. This also decreases overall system complexity, as these cross-cutting concerns can be implemented once in the gateway.
Decoupled clients and services allow for the orchestration of multiple microservices into one client API. Similarly, different clients can receive different APIs tailored to their needs, in a variation on the “back end for front end” pattern.
Accelerated API discovery speeds up the development of new clients and features.
Decreased number of required requests increases performance. Through orchestration, several API calls on the back end can be aggregated into one round trip between the client to the API gateway. This can improve the user experience.
Consistency through plugins enables best practice governance, security, observability, and handling of all other cross-cutting concerns.

Comparing API gateways and ESBs

The similarities between API gateways and ESBs are clear. Both solutions occupy a similar place in the architecture: as the centralized intermediary for communication with services. However, API gateways offer advantages as well as a more modern approach to achieve those advantages.

The main advantage is that API gateways have a clear scope. ESBs were envisioned as the end-all, be-all solution to communication between all applications and services. As they grew into that role, additional features were added, allowing for business rules and logic to be incorporated into the system. As such, the ESB became too convenient. What began as a project to reduce system complexity evolved into a massively complex system of its own.

API gateways, on the other hand, play a more focused role. First, the API gateway is not responsible for (as much) transformation and protocol negotiation. As API standards have matured, the API gateway can be leaner than an ESB, focused specifically on cross-cutting concerns. Additionally, the API gateway is focused primarily on client-service communication, rather than on all service-to-service communication.

This specificity of scope allows API gateways to avoid scope creep, keeping them from becoming yet another monolith that needs to be broken down. When selecting an API gateway, it is important to find a product with a clear identity rather than an extensive feature set.

In contrast to the centralized and highly coupled nature of ESBs, API gateways allow for decentralization and distribution. This aspect empowers both kinds of enterprises—those on the journey to the cloud, and those taking a hybrid approach.

When to use an API gateway

API gateways are a good fit for businesses focused on moving faster and enabling innovation, which is achieved through distributed teams with the independence and ability to do their work.

ESBs fail this standard, as they are large, centralized monoliths that increase the coupling or interdependence between teams and decrease independence.

API gateways—with developer portals—also foster a design-first approach to APIs and promote a discovery-led consumption approach. By providing the right API for each client, API gateways can enable increased adoption, reuse, and iteration velocity. API gateways also facilitate the consumption and discovery of APIs across the organization, and enable the use of no-code or low-code tools. Again, the focus is on enabling independent teams rather than coupling to the API gateway team.

ESBs and API gateways for the modern enterprise

The journey of the modern enterprise involves enabling agility and rapid innovation to delight the customer. This journey depends on increasing team independence and enabling those teams to remain lean and focused.

To do this, IT organizations must become technically heterogeneous and diverse rather than homogenous. They must embrace the best-of-breed solution for each use case. This shift requires diversity in technical solutions and approaches. After all, the shift in direction is multifaceted. Here are some examples:

On-premises or cloud-only ➡ Hybrid cloud and/or multicloud environments
Centralized ➡ Distributed
Monolithic architecture ➡ Microservices
Servers ➡ Serverless, functions, Kubernetes, containers
Organization-wide languages ➡ Polyglot teams and organizations

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 for this purpose.

In most situations, a gradual hybrid approach is the best starting point. Start by implementing an API gateway with new APIs, and slowly bring over more services as opportunity and time allow. Over time, this gradual approach will break apart the ESB monolith. Take the opportunity to extract the business logic inside the ESB and distribute it into new microservices.

The goal is not to replace the ESB entirely, as it still has a place with legacy services that may never get upgraded. The focus is on moving the ESB out of the critical path for new development. However, in the mid-term, the API contract will be longer-lived by building business-level dependencies on top of them. As such, a focus on API connectivity will generate value for the modern enterprise.

Marco Palladino, an inventor, software developer and Internet entrepreneur based in San Francisco, is the CTO and co-founder of Kong Inc. Marco is well known in the tech community, speaks regularly at industry conferences (like Web Summit, KubeCon/ServiceMeshCon), and has previously published articles on media sites including The New Stack and InfoWorld.

—

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.