Keep The Microservice Madness Going With API Gateway

Understanding The Need For API Gateway

Suppose there are two teams working within an organization: one focusing on front-end development and the other on back-end microservices. The organization is currently in the process of transitioning from a monolithic system to a more modular one. As a result, the number of microservices is steadily increasing each month. The front-end teams are tasked with integrating various services to retrieve different sets of data.

In certain instances, they find themselves needing to refactor existing features. This situation arises when the endpoints they were utilizing from a particular microservice have been decomposed into multiple smaller microservices. Consequently, the front-end team is grappling with the challenge of maintaining numerous service integrations. They are becoming increasingly frustrated with the situation, as they perceive themselves to be bearing the burden of the back-end team's experimental endeavors.

The frustration of the front-end team is entirely justified. The increasing number of microservices has become a significant maintenance challenge. The front-end application is burdened with managing distinct integrations for each service. This requirement forces the application to be aware of individual microservices in the system, thereby discouraging any potential efforts by the back-end team to reorganize their microservices. Consequently, a tightly-coupled relationship is established between the microservices and the front end.

A solution is needed to address this issue without hindering the expansion of the back-end team's microservice architectures. One viable approach involves the creation of an abstraction layer – an API Gateway. Positioned between the client and the array of microservices, this gateway acts as an intermediary. It efficiently directs client requests to the appropriate microservices, all while shielding the client from the intricacies of the various microservices' existence. The client only has to know the API Gateway. On the other hand, the back-end team the flexibility to modify their microservice structure while upholding the established contract between the API Gateway and the front end.

The Problems With Direct Client To Microservices Communication

As previously discussed, direct communication gives rise to a range of issues. Let's now take a closer look at some of these challenges and concerns:

• Tight Coupling: When client applications directly interact with internal microservices, they become tightly coupled with them. This means that the client apps need to be always aware of each individual microservice in the system which is not a desirable situation. As these microservices undergo changes or improvements, it directly impacts the maintenance process of the client apps as direct connections can lead to frequent updates in the client apps, making it harder for the overall solution to evolve smoothly. On the other hand, implementing the API Gateway pattern helps reduce this tight coupling, allowing for a more flexible and adaptable system design.
• Client-Unfriendly IPC Mechanism: Services could potentially employ inter-process communication (IPC) mechanisms that are inconvenient or impractical for clients. For example, certain services within an application may employ gRPC for communication, while others may use a messaging protocol. Although these protocols are effective for service to service communication, they might not be suitable for client apps. In this context, an API Gateway serves as an intermediary, facilitating communication with such services and transforming the data into a format suitable for transmission over a client-friendly communication mechanism, such as HTTP APIs.
• Increased Round Trips: In a Microservices System without an API Gateway, each time a client app wants information for a page or screen, it has to make several separate requests to different services. This causes delays, adds network strain, complicates the app's inner workings, and can lead to inefficient data use. The solution is an API Gateway. Acting as a middleman, it fetches requests over a fast private network and consolidates responses, reducing client round trips and making communication smoother between the client and various services.
• Security Issues: When clients directly access microservices, the risk of security breaches increases significantly due to a larger number of potential entry points for attackers. This wider "attack surface" makes it easier for malicious actors to find and exploit vulnerabilities in the microservices. However, using an intermediary layer like an API Gateway reduces this risk by consolidating access points and allowing for more effective security measures to be implemented.
• Cross-cutting concerns: Direct client-microservice communication leads to duplicated cross-cutting concerns, like security and logging, across services. This creates inconsistency, complexity, and maintenance challenges. Centralizing these in an API Gateway or a centralized service streamlines development, improves consistency, and reduces overhead.

The API Gateway Pattern

The API Gateway pattern is an entry point through which requests from external sources are directed to different internal services or resources. Instead of allowing direct connections between external sources and internal services, all requests must pass through the API Gateway. The API Gateway acts as a sort of traffic controller for incoming requests. It receives requests, examines their intended destinations, and forwards them to the appropriate internal services. Sometimes the API Gateway serves as a coordinator when it receives a request. It communicates with the necessary internal services, gathers their individual responses, and then combines these responses into a single reply that is sent back to the external requester. These functionalities help to abstract the complexity of the underlying system from external sources. Additionally, the API Gateway can handle various tasks such as request transformation, authentication, authorization, rate limiting, and caching. This simplifies the client's interaction with the system and enhances security and performance since the underlying services are shielded from direct external access.

Back-ends For Front-ends

When a variety of client applications utilize the API Gateway, it can grow and evolve in cases when different clients have different requirements. It might be necessary to expose different APIs designed specifically for different clients. Over time, the API Gateway could become overly extensive, resembling a large and complex monolithic application.

In such cases, it is highly recommend that the API Gateway be split into multiple smaller API Gateways, each dedicated to serving a specific client application. This approach helps prevent the API Gateway from becoming overloaded and maintains a more organized and efficient structure. By creating separate instances tailored to individual client apps, the system remains adaptable, manageable, and responsive to the diverse demands of each client.

Main Functions of API Gateway

Request Forwarding

The API Gateway's primary task is to redirect incoming web traffic to the correct internal service that can handle it. It acts as a reverse proxy, essentially standing between clients and services. By checking a predefined route map, it decides where to send each request. For example, it may look at the request path to forward the request to the appropriate microservice. This function not only efficiently channels traffic but also helps decouple client apps from the microservices. This is valuable during the transition from a monolithic API to multiple services, as the API Gateway ensures that existing client applications continue to work seamlessly while the underlying architecture undergoes transformation.

API Composition

In the Microservice Architecture, each microservice manages a specific portion of the overall business domain within its own database. However, situations arise where the client application requires data that spans multiple microservices. To gather this needed data, the client must make multiple calls to different services, await their responses, and then aggregate and display the information in the user interface. These exchanges occur across the slow public internet. To make this process efficient, an API Gateway offers a solution: it provides a single endpoint for the call, orchestrates calls to the necessary microservices within the system's internal network, and then combines the responses of the calls to send back to the client. By using the API Gateway to communicate with the relevant microservices through a faster private network, the process becomes notably quicker compared to the client reaching out to multiple services via the slower public internet. Furthermore, this offloads the task of data aggregation from the client, as the API Gateway seamlessly manages this complex task on its own.

Protocol Translation

The protocol translation functionality of an API Gateway bridges the gap between different communication protocols used by servers and client applications. The API Gateway acts as an intermediary, facilitating communication when servers use protocols like AMQP or gRPC that lacks broad client-side support. It accepts requests from client apps using client-friendly protocols such as REST, then smoothly translates and communicates with the servers using more specialized, server-to-server communication protocols. After processing, the API Gateway returns the server's response back to the client using client’s communication protocol. This approach ensures that client applications can effectively interact with services utilizing protocols that might not be natively supported on the client side.

Edge Functions

The API Gateway offers a way to take some load off separate microservices by implementing edge functions processing requests at edge. It's particularly useful for handling complex cross-cutting concerns that might be tricky to set up in every individual microservice. Instead of having each microservice manage these complex processing, the API Gateway takes on the responsibility in one central location. This makes the microservices simpler and more targeted towards solving specific business problems. Below are some of the edge functions that can be implemented in the API Gateway:

• Authentication and Authorization
• SSL Termination
• Rate Limiting and Throttling
• Caching
• Metrics Collection
• Request Logging
• Retry policies, circuit breaker
• IP Whitelisting

Drawbacks

Despite clear benefits of the pattern, there are a few drawbacks to consider:

• Creates an additional single point of failure
• Creates an additional hop, increasing response times a bit
• It is another moving part of the system which requires maintenance and development if pattern such as API composition and protocol translation are used
• Can quickly become a development bottleneck if it is managed by a single team and the Gateway has to offer client specific API endpoints

Design Considerations

The API Gateway serves as the entry point for a microservices system, acting as the gateway through which all requests flow so constructing it requires thoughtful considerations. One critical choice is whether to use a synchronous or asynchronous I/O model. Synchronous is simpler, but it has a drawback: heavyweight OS threads that are limited in number, thus restricting concurrent connections. On the flip side, asynchronous relies on an event loop system, avoiding thread overhead. Yet, this approach is more intricate, requiring quick return of callbacks to prevent event loop blockage. Reliability is paramount for the API Gateway. This can be achieved by deploying multiple instances behind a load balancer. To handle failed and unresponsive requests, implementing retry policies and circuit breakers is essential.

Available Implementations

There exist various implementations of the API Gateway pattern, with some of the most common ones being Amazon API Gateway, Netflix Zuul, and Kong API Gateway. The choice of which implementation to use in a project can depend on different criteria, including factors like simplicity, open-source versus proprietary solutions, managed or self-hosted options, scalability and flexibility, features offered, pricing considerations, and more. It's worth noting that many implementations may not support certain valuable API Gateway patterns, such as API composition and Protocol Translation, which are significant features in a Microservice System. If these specific features are required within a system, it is possible to create a custom API Gateway service that fulfills these needs.

In conclusion, the integration of powerful API Gateway features like API Composition, Request Re-routing, and Protocol Translation plays a vital role in enabling the seamless evolution of microservices architecture without compromising the functionality of client applications. By offloading cross-cutting concerns from individual services, API Gateways contribute to leaner and more business focused microservice implementations. This approach not only optimizes performance but also enhances security by minimizing potential attack surfaces. As the microservices system continues to grow and expand, these gateway functionalities stand as indispensable tools, ensuring a seamless and gratifying development experience.