API Infrastructure: ESB Versus API Gateway (Part 1)
Brad Drysdale

By on December 22, 2021

API Infrastructure: ESB Versus API Gateway (Part 1)

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. 

API Infrastructure: ESB Versus API Gateway

The Enterprise Service Bus

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.

ESB as the Central Connector

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

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.

Benefits and Drawbacks of an ESB

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.

Benefits of ESBs

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.

How ESBs fail organizations

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.

The Future of ESBs

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

Conclusion 

In the next blog, we’ll look at this modern solution for connectivity, the API gateway. We’ll also compare that solution to the ESB. Finally, we’ll discuss how organizations can continue using an ESB while also adopting the API gateway to support their legacy applicatons as well as modern applications.

To learn more about ESBs and API gateways, download the “API Infrastructure: ESB versus API gateway” eBook today! 

Share Post