Cos'è una service mesh e perché la utilizzeresti?

Question

Accepted Answer

Una **service mesh** (Istio, Linkerd) sposta i cross-cutting networking concerns — retry, timeout, mTLS, traffic routing, observability — **fuori dal codice applicativo** e in un layer di infrastruttura di rete di **sidecar proxy**.

## Come funziona

Ogni istanza di servizio esegue accanto a un **sidecar proxy** (ad es. Envoy). Tutto il traffico fluisce attraverso i proxy, che formano il **data plane**; un **control plane** li configura.

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

## Cosa fornisce

- **mTLS** tra servizi automaticamente (zero modifiche app).
- **Resilienza** — retry, timeout, circuit breaking al proxy.
- **Traffic management** — canary, A/B, weighted routing.
- **Observability** — metriche uniformi, trace, log.

## Esempio di 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-off

Una mesh aggiunge latenza (hop extra), overhead di risorse (un proxy per pod), e reale complessità operativa.

## Perché è importante

Una mesh standardizza resilienza, sicurezza e observability su ogni servizio senza che ogni team le reimplementi in linguaggi diversi.

Ma è pesante: adottala solo quando hai abbastanza servizi da far sì che la logica di networking duplicata superi il costo operativo della mesh.