Service Mesh
A service mesh is a dedicated infrastructure layer, typically implemented as lightweight network proxies deployed alongside each service, that handles service-to-service communication concerns — traffic routing, retries, encryption, and…
Definition
A service mesh is a dedicated infrastructure layer, typically implemented as lightweight network proxies deployed alongside each service, that handles service-to-service communication concerns — traffic routing, retries, encryption, and observability — outside of application code.
Overview
As applications split into dozens or hundreds of microservices, the network calls between them become a major source of complexity: retries, timeouts, mutual TLS encryption, load balancing, and failure handling all need to be implemented consistently everywhere. A service mesh moves that logic out of each application and into a uniform infrastructure layer, most commonly using the sidecar pattern — a small proxy, such as Envoy, deployed next to every service instance that transparently intercepts and manages all its network traffic. Because every request flows through this proxy layer, a service mesh becomes a natural place to enforce cross-cutting policy uniformly: automatic mutual TLS between services, fine-grained traffic splitting for canary deployments, circuit breaking via patterns like the circuit breaker pattern, and rich telemetry for distributed tracing and observability — all without any application code changes. Istio is the best-known service mesh implementation, typically deployed on top of Kubernetes alongside its native container orchestration capabilities. The tradeoff is real operational complexity: a service mesh adds another distributed system to operate, introduces latency at each proxy hop, and has a genuine learning curve. Most teams adopt one only once the number of services and the cross-cutting policy requirements have grown enough that solving these problems individually in each service's code has become unsustainable.
Key Concepts
- Sidecar proxies deployed alongside each service instance to manage its network traffic
- Automatic mutual TLS encryption between services with no application code changes
- Fine-grained traffic control — routing, retries, timeouts, and circuit breaking
- Rich telemetry for distributed tracing, metrics, and observability out of the box
- Traffic splitting to support canary and blue-green deployment strategies
- Centralized policy enforcement (rate limits, access control) at the infrastructure layer