What is a service mesh and why would you use one?

Question

Accepted Answer

A **service mesh** (Istio, Linkerd) moves cross-cutting networking concerns — retries, timeouts, mTLS, traffic routing, observability — **out of application code** and into a network infrastructure layer of **sidecar proxies**.

## How it works

Each service instance runs next to a **sidecar proxy** (e.g., Envoy). All traffic flows through the proxies, which form the **data plane**; a **control plane** configures them.

```text
┌─────────────────┐        ┌─────────────────┐
│ Service A       │        │ Service B       │
│  app  ⇄ [proxy] │◀──────▶│ [proxy] ⇄  app  │
└─────────────────┘  mTLS  └─────────────────┘
        ▲ configured by ▲
        └──── Control Plane (Istio/Linkerd) ────┘
```

## What it provides

- **mTLS** between services automatically (zero app changes).
- **Resilience** — retries, timeouts, circuit breaking at the proxy.
- **Traffic management** — canary, A/B, weighted routing.
- **Observability** — uniform metrics, traces, logs.

## Example policy

```yaml
# shift 10% of traffic to v2 (canary), no code change
route:
  - destination: { host: orders, subset: v1 }
    weight: 90
  - destination: { host: orders, subset: v2 }
    weight: 10
```

## Trade-offs

A mesh adds latency (extra hops), resource overhead (a proxy per pod), and real operational complexity.

## Why it matters

A mesh standardizes resilience, security, and observability across every service without each team re-implementing them in different languages.

But it's heavy: only adopt it when you have enough services that the duplicated networking logic outweighs the mesh's operational cost.