Service Mesh

A Service Mesh is an infrastructure layer that handles the network communication between services so the services themselves do not have to. It moves resilience, security, and observability for east-west (service-to-service) traffic out of application code and into a fleet of proxies governed by a central control plane.

How It Works

Each service instance is paired with a lightweight proxy, usually deployed as a sidecar in the same pod. All traffic to and from the service flows through its proxy. These proxies form the data plane and collectively carry every request in the mesh. A control plane configures them dynamically, distributing routing rules, security policy, and certificates.

With this arrangement the mesh can transparently provide mutual TLS between services, fine-grained traffic routing (canary, blue-green, weighted splits), retries, timeouts, circuit breaking, and rich telemetry (metrics, logs, traces) for every call, all without changing application code. Istio with Envoy, Linkerd, and Consul Connect are common implementations.

Newer meshes also offer a sidecar-less mode using per-node proxies or eBPF to cut the per-pod overhead, trading some isolation for efficiency. Regardless of data-plane design, the control plane is where operators define intent, routing rules, retry budgets, and authorization policies, which it compiles and pushes to the proxies, giving a single declarative place to govern all internal traffic.

When to Use It

A mesh pays off when you have many services communicating over the network and need consistent security and reliability across all of them, when you want uniform mTLS and zero-trust networking, or when you need fine-grained traffic control and deep observability that would be costly to build into each service.

For a handful of services, the operational weight of a mesh usually outweighs the benefit; libraries or an ambassador may be enough.

Regulated environments often adopt a mesh specifically for verifiable, uniform mTLS and authorization between services, which auditors can confirm centrally rather than service by service.

Trade-offs

The mesh adds significant operational complexity: another distributed system to run, upgrade, and debug. The per-instance proxies add latency and resource overhead. The control plane is critical infrastructure. Teams often underestimate the learning curve. In return they get policy and observability that are uniform and decoupled from application code. A frequent recommendation is to adopt the mesh incrementally, enabling mTLS first, then telemetry, then advanced traffic policy, so the team absorbs the operational learning curve one capability at a time.

Related Patterns

A service mesh is fleet-wide Sidecar plus Ambassador deployment with centralized control. An API Gateway handles north-south traffic at the edge while the mesh handles east-west traffic inside. Circuit Breaker, Retry, and mTLS are features the mesh provides.

Example

A bank runs 40 microservices on Kubernetes and must encrypt all internal traffic and roll out releases gradually. They deploy Istio. Every pod gets an Envoy sidecar; Istio issues certificates so all service-to-service calls use mTLS automatically. To release a new checkout version, they configure a rule sending 5% of traffic to it, watch the mesh-collected error rate, and shift to 100% once healthy, with no application code changes.