Service mesh: Controlling communication between services

In short: An infrastructure layer that takes over, secures and makes observable the network traffic between microservices, without each service having to program this itself.

In more detail: In a system with many services, all of them need the same things: encrypted connections, retries, timeouts, load distribution, metrics. A service mesh (for example Istio or Linkerd) moves this out of the application code into small helper proxies that run next to every service (“sidecar”).

In Depth

Structure

• Data plane: the proxies (often Envoy) next to each service. All traffic runs through them.
• Control plane: central control that distributes rules and certificates to the proxies. The service seemingly talks normally to http://order, the sidecar intercepts the connection and does the rest.

What the mesh takes over

• mTLS: mutually authenticated, encrypted connections between services, with automatically renewed certificates.
• Traffic control: 5 % of traffic to a new version (canary), mirroring traffic for testing.
• Resilience: retries, timeouts, circuit breakers.
• Observability: metrics, traces and access logs without code changes.
• Policies: which service may talk to which.

Costs

A mesh increases complexity: additional proxies need memory and compute time, add latency and have to be operated and updated. Newer approaches such as Istio Ambient or eBPF-based solutions (Cilium) manage without a sidecar per pod.

When it pays off

With few services, libraries and an ingress suffice. A service mesh pays off with many services, several teams, high security requirements (zero trust) and the wish for uniform observability.

See also: Microservices, Circuit breaker and backpressure, Observability, Container security