Why API Gateways Face an Identity Crisis: Roles, Patterns & Service Mesh

Recently I came across a translated article about API gateways that introduced three roles: API management, cluster ingress control, and the API gateway pattern, and also discussed their relationship with service meshes, providing a more comprehensive understanding of the purpose of API gateways.

Original: "API Gateways are going through an identity crisis"

The article (originally published on Medium) points out that API gateways have been questioned over the years regarding whether they truly add value.

Do they centralize and share resources to facilitate external API management?

Do they act as an ingress controller to strictly manage traffic entering or leaving a cluster?

Are they a kind of API linker that makes APIs easier to use for specific clients?

And the obvious elephant in the room: "Will service meshes make API gateways obsolete?"

Background

Technology evolves rapidly, reshuffling the industry through new architectures. This article aims to summarize the different identities of an API gateway, clarify which groups can benefit from it, and reiterate the fundamental principles.

My Definition of an API

An interface with a clear definition and purpose that, via network calls, allows developers to safely and conveniently access target data and functionality.

These interfaces abstract away the underlying technical architecture. For well‑designed network endpoints we expect usage guidelines and mature backward compatibility.

Creating APIs provides abstracted services for various business parts, enabling new features and occasional innovations.

API Management

Many consider API gateways from the perspective of API management. Their primary functions include controlling who can use an API, tracking usage, enforcing permissions, providing a service catalog, and establishing governance policies such as authentication and rate limiting.

Management also enables self‑service for API consumers, allowing them to subscribe to usage plans (e.g., calls per user per time window). The gateway layer enforces authentication, rate limits, metrics collection, and other policies.

Examples of API‑management gateways include:

Google Cloud Apigee

Red Hat 3Scale

Mulesoft

Kong

Cluster Ingress

When deploying to cloud platforms, multiple clusters host applications and services. An ingress controller (e.g., Kubernetes Ingress) provides a controlled entry point, defining rules such as host, port, and protocol to strictly manage inbound and outbound traffic.

At this layer the focus is on exposing services (APIs, gRPC, GraphQL, websockets, etc.) to external callers while the controller monitors traffic entering the cluster.

Typical ingress controller implementations include:

Envoy‑based projects such as Datawire Ambassador, Solo.io Gloo, Heptio Contour

HAProxy, OpenShift Router (based on HAProxy)

NGINX, Traefik, Kong

API Gateway Pattern

The API gateway pattern, described in Chris Richardson’s "Microservices Patterns," optimizes API usage for different consumer groups by providing an indirect access layer. It aggregates backend calls, performs protocol translation, routing, resilience, and response aggregation.

Compared with the ingress controller, this pattern is developer‑centric, handling REST, gRPC, SOAP, GraphQL, websockets, and message‑queue interactions.

Examples of API‑gateway implementations include:

Spring Cloud Gateway

Solo.io Gloo

Netflix Zuul

IBM‑Strongloop Loopback/Microgateway

General integration frameworks that can also serve as gateways:

Apache Camel

Spring Integration

Ballerina.io

Eclipse Vert.x

NodeJS

Because this type of gateway is tightly coupled with application development, developers should be involved in specifying exposed APIs, aggregation logic, and rapid testing, while operations engineers focus on security, resilience, and observability.

Entering the Service Mesh

Running services on cloud infrastructure raises challenges around observability and control. Service meshes provide transparent solutions for east‑west traffic, offering resilience, security (mTLS, RBAC/ABAC), observability (metrics, tracing), and rate limiting.

Service‑to‑service resilience

Security including end‑user authentication and mutual TLS

Observability of network communication (requests/sec, latency, failures, circuit breaking, distributed tracing)

Service‑to‑service rate limiting and quota enforcement

While API gateways and service meshes overlap in functionality, they operate at different layers: the mesh handles intra‑cluster (L7) traffic, whereas the gateway sits above the mesh to manage north‑south traffic for applications.

The ideal solution places each component—API management, API gateway, and service mesh—in the appropriate layer, establishing clear boundaries and allowing developers and operators to work together efficiently.