Why use an API gateway in microservice architecture?

This article discusses:

• Use Cases and Features of an API Gateway

• Downsides of API Gateways

Along with the microservice architecture, we see organisations using API gateways to manage both their external and internal services. In this article, we examine why the API gateway is needed and what it is capable of.

For simple applications, this approach can still work. But for large enterprise systems, we will soon encounter serious issues. The most obvious being the number of network calls. With net-work speed and bandwidth coming at a premium, is there a way to keep the microservice architecture and still allow clients to make as little calls to the backend as possible? Here is where the API gateway pattern comes in.

Many companies today are deploying their microservices and API gateway to the cloud under the same cloud provider. By doing so, these services can now communicate internally and enjoy the benefit of faster network speeds and higher bandwidth. The end result is an overall improvement in the response time of the API, and if done correctly, a reduction in the number of network calls.

From the above diagram, we also observe that the API gateway is also a single point of entry for the clients to consume APIs. This positions the API gateway to handle key responsibilities including but not limited to security, authentication and rate-limiting.

Use Cases and Features of an API Gateway

API Composition
The most classic use case would be that of request routing. Beyond just forwarding the requests to the respective backend services, the API gateway can use API composition to aggregate the responses from several microservices and serve them as one response back to the client. This streamlines the process and in turn, potentially reduces the number of requests required to be made to the backend services.

API Transformation
Most modern clients consume API responses in the form of REST/JSON, but before this was popular, many older systems used SOAP/XML to communicate. With the gateway, it can use API transformation which translates REST calls from the modern clients to compatible SOAP calls to communicate with legacy systems. Many organisations with legacy systems will see this as a huge positive as they would not have to spend time and money to redevelop working systems which are often very large and complex.

Serving Multiple Platforms
Mobile and TV devices are now much more connected than before and that brings a new set of challenges to developers who serve this group of users. These platforms are usually limited by their hardware and that translates into having very d ifferent network and bandwidth requirements from the traditional desktop computer. As an example, a mobile device connected to the internet via mobile network would have less bandwidth to transmit data as compared to a desktop connected via LAN. An API gateway will be a perfect candidate to serve the right data to the right clients based on differing device requirements. This is also known as the Backend-for-Frontend pattern.

Security and Gateway Offloading of Cross-cutting Concerns
More device types also mean more requests made to backend systems. It is therefore not hard to see that there is a need to protect microservices from potential attacks. Without an API gate-way, each team that develops the microservice will have to implement their own authentication mechanism and also manage their security updates. By having to focus on cross-cutting concerns, it distracts the team from focusing on their main service.

What if we can offload these responsibilities to a centralised service? This is where the gateway offloading pattern can be used where cross-cutting concerns are assumed by the API gate-way. If multiple microservices share the same concerns such as authentication, monitoring, throttling etc, this pattern will be highly beneficial as a dedicated team with the necessary skills can manage this aspect.

As discussed, the API gateway is the single point of entry for all requests and therefore has the ability to potentially stop a malicious attack before it reaches the backend services. Enforcing request authentication at the gateway makes calls to microservices more secure by ensuring that each request has the right to make the call.

Another form of security measure is the enforcement of certain rules and policies. One key security feature is rate-limiting of APIs. In order to provide APIs reliably without overloading the backend services, steps have to be taken to make sure that any exposed API is not open to un-limited calls from a single source. Even if those calls are legitimate, it is important to ensure that other consumers are able to also use the API at an optimal level.

What are the downsides of API gateway?

The additional layer of infrastructure requires development and maintenance. This is not much of a downside because while you can develop your own API gateway, there are already major players in this field offering their version of the gateway. Popular options include Kong, AWS, NGINX, Red Hat, etc.

Being a critical piece of infrastructure, you might find yourself being locked-in to one of the abovementioned service providers. Features offered will differ and it might not be straightforward to migrate from one provider to another. One way to mitigate this risk is to examine your needs properly and decide if a gateway provider has all the features you seek. Another way is to use different gateway providers when adapting the Backend-for-Frontend pattern for different parts of your architecture.

As a single point of entry, there is the risk of it being a bottleneck. It is therefore important to scale your gateway correctly to cater to spikes in traffic and have the right procedures in place when updating your gateways.

The API gateway pattern is an important infrastructure in any modern large-scale system simply because of the many benefits it brings to the table. It is therefore not hard to see why organisations of all sizes are using API gateways to better manage their services.