API Academy

Sponsored by Layer7

API Management 302: Using an API Gateway in Microservice Architecture

By Ronnie MitraPosted on

Get to grips with the specifics of deploying an API gateway in a microservice architecture

In  Lesson 304: API Design for Microservices, we describe the essential role APIs play in microservice architectures. In Lesson 101: API Management Basics, we explain why an API gateway is essential to ensuring API security, usability, scalability and reliability. Here, we focus on the specifics of deploying an API gateway in a microservice architecture.

As we noted in lesson 101, the core component of a full-featured API management solution is an API gateway. This is a networking appliance that ensures APIs do not have to directly interact with client apps. It represents a central point where key API functionality is managed via a set of policies.

In this way, the gateway removes the need to build functionality into each API individually. It efficiently provides consistent, up-to-date functionality, governance and performance across all APIs and client apps. This is particularly vital in the complex context of an enterprise microservice architecture, where a great many APIs may need to be managed.

In successful enterprise microservice architectures, API gateways are commonly used to deliver three vital functions:

  • Security
  • Orchestration
  • Routing

Security

The high degree of freedom necessitated by the large number of moving parts in a microservice architecture is a potential security nightmare. That is why, in mature microservice deployments, it is normal to ensure that all interactions with external clients (mobile apps, Web sites etc.) happen via APIs and that a capable gateway is used for securing API endpoints.

However, there is every reason to believe that all communication between microservices, including those that would normally be considered purely internal, should happen through secured APIs. The fact is, if an API is called by an external client―even if this happens internally via another microservice―that API should no longer be considered purely internal.

The assumption that an API will never be reached by an external party is particularly dangerous as the validity of this assumption is likely to be eroded over time, as the interface is adopted for new use cases. On the other hand, the overhead involved in using an already-deployed gateway to secure these supposedly internal APIs is relatively negligible.

Orchestration

Microservice architecture reflects the Unix philosophy of “do one thing and do it wellâ€. In Unix, this approach is possible due to the universal “piping†standards that make it simple to connect diverse utilities. Clearly then, a similar system is needed in order to simplify the process of connecting and orchestrating microservices via APIs.

Orchestrating microservice APIs in this way is particularly vital because Web and mobile developers typically shun “chatty†interfaces that require multiple calls for a single result. RESTful APIs are often criticized as being overly chatty. When functionality is spread across multiple microservices, the potential for chattiness is particularly high.

However, it is precisely because of the inherent problem of chattiness in Web APIs that a solution is close at hand. A mature gateway will make it simple to create an API that orchestrates multiple backend microservices, hiding their chattiness and presenting developers with a much more user-friendly interface.

Routing

A similar challenge arises in relation to discovery and routing. Service discovery systems make it easy to present which ports and IP addresses a microservice is currently available at. But client app developers expect to able to retrieve an API at a consistent URI, regardless of the fluctuations and complex architectural wiring behind that API.

Again, there is a need to hide the complexity of the microservice architecture in order to present something more developer-friendly. This is where an API gateway comes in―a mature gateway will be ideally placed to hide the routing complexities between a client app and the microservices that power it.

An API gateway can interface with service discovery systems and route a client to the correct service when an external URI associated with the microservice is requested. A load balancer or smart-reverse proxy can achieve the same goal but as an API gateway should already be in place for security and orchestration, routing via the gateway is the simplest solution.