Navigating API gateways landscape

API Gateway is a component that provides a single entry point to a set of backend APIs. It’s similar to the Facade pattern from the object-oriented paradigm, but in this context, it’s an essential component of a distributed system. Sometimes known also as the backend for frontend. It plays a role of an entry point into our system for external API clients.

API Gateways can be perceived as reverse proxies on steroids that offer more flexibility and automation capabilities than a plain reverse proxy. The most popular ones are built on top of Envoy, HAProxy, and NGINX.

In this article, I will consider API Gateways in the context of modern architectures, highly integrated with other cloud services or natively working within increasingly popular Kubernetes space.

Core capabilities we should expect:

• network traffic routing,
• throttling,
• caching,
• observability,
• authorisation and authentication,
• payload enrichment,
• SSL termination,
• circuit breaking,
• load balancing,
• managing paid API access.

Typical network traffic flow with API Gateway deployed

Backend for frontend approach

Many articles over the internet interchangeably use API Gateway and backend for frontend terms which indicates that you can implement such business rules, additional payload mappings, and hot fixes. In my opinion, you should minimise the amount of custom logic to achieve the high resilience and maintainability of such components.

Using multiple API gateways

More often than not, you will want to combine Cloud-provided capabilities (such as Firewall and Worldwide traffic routing) with your internal infrastructure.

Popular implementations to be run within Kubernetes:

• Ambassador,
• Kong,
• Traefik,
• Spring Cloud Gateway.

Popular Cloud providers include:

• Apigee,
• Azure API Management,
• Amazon API Gateway.

Some of the companies that were developing ESBs have also entered the API Gateways market. An example of ESB, which provides API Gateway features is MuleSoft ESB.

Beware of ESBs pretending to be API Gateways

Instead of elaborating myself, let’s look at recommendations from industry experts:

The most important drawback is that when you implement an API Gateway, you’re coupling that tier with the internal microservices. Coupling like this might introduce serious difficulties for your application. — Clemens Vaster, Architect at the Azure Service Bus team

ESBs in API Gateway’s clothing: Hold! We’ve long warned against centralized enterprise services buses and defined “smart endpoints, dumb pipes” as one of the core characteristics of a microservices architecture. Unfortunately, we’re observing a pattern of traditional ESBs rebranding themselves, creating ESBs in API gateway’s clothing that naturally encourage overambitious API gateways. Don’t let the marketing fool you: regardless of what you call it, putting business logic (including orchestration and transformation) in a centralized tool creates architectural coupling, decreases transparency, and increases vendor lock-in with no clear upside.API gateways can still act as a useful abstraction for crosscutting concerns, but we believe the smarts should live in the APIs themselves. — Thoughtworks, Technology Radar Volume 234

Identify what architecture style you want to implement

When selecting API Gateway for your greenfield project, consider what architectural style you want to follow and pick what suits you best. Although the choreography is often more suitable for building highly scalable distributed systems.

Sample configuration

A sample of a declarative configuration of routing rule in Open Source Ambassador/Emissary Gateway:

This configuration will simply pick up a request that has the prefix “your-api”, strip it, and forward the request to Your API Kubernetes Service.

Emissary was recently accepted as one of the Cloud Native Computing Foundation projects. There are a lot of interesting Cloud Native projects supported by CNCF, I recommend tracking their website: https://www.cncf.io/

A few tips for successful implementation

Let’s outline a few points on how to use API Gateways with resilience and maintainability in mind:

• Such a component is usually a single point of failure, if you will introduce some small elements of business logic, you risk breaking your entire platform, not only the backend service to which the given change relates.
• In large ecosystems where your backend consists of tens or hundreds of microservices, teams making changes in their area should not have the possibility to break other team’s API’s, which can be caused by putting any custom logic inside our Gateway.
• Some popular API Gateways require multiple components to be deployed, consider how that impacts your SLA.
• If your Kubernetes Ingress Gateway does require a Database to function, you should become a stateful workloads expert within the Kubernetes space.
• You can validate incoming credentials at API Gateway, but that does not mean your backend service should not also check them, always apply minimum trust policy.
• Select solutions which can be managed through declarative configuration.
• Each team can manage their config without the risk of breaking other APIs.
• Consider ease of local development, if you need to run API Gateway to test locally your microservice, consider it as a failure.
• Reduce failure surface as much as possible.
• Follow the “smart endpoints, dumb pipes” approach.

I also highly recommend Netflix’s tech team talk available on YouTube: Mastering Chaos – A Netflix Guide to Microservices.