How Is A Service Mesh Different From An API Gateway?
API Management, API Gateway and Design Patterns
It’s fair to to mix the terms API management and API gateway, But we will try to make some distinction.
API management is the answer for the following use case: We want to expose our system via API to the outside world or the customers. Here we need to think about the following questions:
- Who can use the API (authentication) and which endpoints (authorization)?
- How to track the use of the API (monitoring and analytics)?
- How many calls are allowed per user per endpoint (limit rating and governance)?
So API management is more a concept that a service! The piece of infrastructure where we are able to enforce these kind of management functions is the API gateway.
Azure API management and Kong are examples of API gateways that implement the API management concept and other concepts and features.
API gateway is deployed normally on a shared infrastructure. This is a good practice to enforce a level of governance and policy. We should be careful not to allow any business logic into this layer. It’s an attractive place to do so because the API traffic traverse it and it become an all-knowing god (similar to Enterprise Service Bus EBS)
Microservices Design Patterns
the API-gateway pattern introduced by Chris Richardson in his famous book “ Microservices Patterns” is about curating an API for more optimal usage by different classes of consumers. It involves a level of API indirection. Another variation that represents the API gateway pattern is backend for frontends where “front end” can be literal front ends (UIs), mobile clients, IoT clients, or even other service developers.
This “API gateway implementing the design pattern” is also different from the API management mentioned before (where we are managing existing APIs). It hides the complexity of the system behind it (we may have legacy system, RPC calls, non-REST protocol) and is a good to do: message-level transformation, complex routing, network resilience/fallbacks, and aggregation of responses.
Lets first tag the API gateway with the name “north-south traffic” while service mesh with the name “east-west traffic”. We will compare them in the later sections.
In a distributed environment like Kubernetes, we may build and maintain multiple clusters to host our applications and need some way of accessing the applications and services inside those clusters. Kubernetes Ingress controller allows us to access the Kubernetes cluster (Ingress is the only K8s component accessible from the outside). That way we keep very tight control over what traffic may enter (or even leave) our cluster with well-defined entry points like domain/virtual hosts, ports, protocols, …etc.
A service mesh, like the open source project Istio, is a way to control how different services share data with one another. Unlike other systems for managing this communication, a service mesh is a dedicated infrastructure layer built right into an app (using the sidecar pattern). This visible infrastructure layer can observe how well (or not) different parts of an app interact, so it becomes easier to optimize communication and avoid downtime as an app grows.
A service mesh brings the following capabilities to a platform:
- Service to service (east-west traffic) resilience
- Service to service security (mutual TLS, RBAC/ABAC…)
- Black-box service observability (tracing, telemetry and logging)
- Service to service rate limiting
It’s obvious that there is an overlap in the functionality with an API gateway. But we still can distinguish the difference!
The main purpose of an API gateway is to accept traffic from outside the network (outside the cluster in K8s) and distribute it internally. The main purpose of a service mesh is to route and manage traffic within your network.
In a deployment with an API gateway and a service mesh, incoming traffic from outside the cluster would first be routed through the API gateway, then into the mesh.
The following diagram shows the whole picture of distributed system deployed in K8s and the usage and placement of both API gateway and service mesh.
Service Mesh and API gateway overlap in functionality in some areas but are complementary in that they live at different levels and solve different problems. The ideal solution would be to plug and play each of the components (API Management, API Gateway, Service Mesh) into your solution with nice boundaries between the components as you need them (or exclude them as you don’t need them).