In our 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.
The API Gateway
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
API-first design and API management
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.
Benefits of the API gateway
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.
Comparing API gateways with ESBs
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.
Select the right API gateway
The selection of an API gateway requires the consideration of several criteria.
Deployment complexity
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.
Proprietary versus open source
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.
Ease of scaling
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.
Feature set
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.
The power of ESB + API gateway for the modern enterprise
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:
- On-premise or cloud-only ➡ Hybrid-cloud and/or multi-cloud environments
- Centralized ➡ Distributed
- Monolith 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 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?