Understanding the Relationship Between Service Mesh and API Gateway
This article examines how Service Mesh and API Gateway differ in function and deployment, explores the philosophical debate over east‑west versus north‑south traffic when a gateway accesses internal services, and traces the evolving integration of sidecars, BFF layers, and cloud‑native architectures.
Service Mesh and API Gateway are frequently compared topics; this article compiles existing material and adds personal insights to clarify their relationship.
Clear boundaries: Service Mesh provides the network infrastructure for internal service‑to‑service communication, while API Gateway exposes services as APIs to external clients.
Functional and deployment view: Atomic microservices and composite services run inside the system. Service Mesh handles intra‑service traffic, whereas API Gateway sits at the system edge to receive external requests and forward them internally.
Terminology: "East‑west" traffic refers to internal service communication, while "north‑south" traffic denotes external requests entering the system via the gateway.
Philosophical question: When API Gateway accesses internal services, is the traffic east‑west or north‑south? The answer depends on whether the gateway is viewed as a whole or split into external and internal components.
Two implementation approaches: 1) Keep API Gateway separate from internal communication mechanisms; 2) Reuse Service Mesh capabilities for the gateway’s internal calls. Product choices (e.g., Kong vs. Spring Cloud Gateway) often reflect this decision.
Sidecar overlap: The Service Mesh sidecar can be attached to API Gateway, merging their functionalities and allowing the gateway to leverage the mesh’s east‑west features.
This integration shifts the relationship from "clear separation" to "compatible coexistence," as seen in products like SOFA Gateway (based on MOSN) and open‑source solutions Ambassador and Gloo (based on Envoy).
BFF (Backend‑For‑Frontend) impact: Adding a BFF layer between API Gateway and internal services further tightens the coupling. The BFF can share a sidecar with the gateway, or the gateway’s sidecar can be merged into the BFF, leading to a decentralized architecture where each BFF instance handles both gateway and service‑mesh responsibilities.
Summary: Initially, Service Mesh and API Gateway had distinct roles, but over time their implementations have converged, especially through sidecar reuse and BFF integration, suggesting a future where the boundaries between mesh and gateway become increasingly blurred.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.