O que é um service mesh e por que você usaria um?

Question

Accepted Answer

Um **service mesh** (Istio, Linkerd) move preocupações de rede transversais — retries, timeouts, mTLS, roteamento de tráfego, observabilidade — **para fora do código da aplicação** e para uma camada de infraestrutura de rede de **sidecar proxies**.

## Como funciona

Cada instância de serviço executa ao lado de um **sidecar proxy** (por ex., Envoy). Todo o tráfego flui através dos proxies, que formam o **data plane**; um **control plane** os configura.

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

## O que fornece

- **mTLS** entre serviços automaticamente (zero alterações de aplicação).
- **Resiliência** — retries, timeouts, circuit breaking no proxy.
- **Gerenciamento de tráfego** — canary, A/B, weighted routing.
- **Observabilidade** — métricas uniformes, traces, logs.

## Política de exemplo

```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
```

## Compromissos

Um mesh adiciona latência (hops extras), sobrecarga de recursos (um proxy por pod) e verdadeira complexidade operacional.

## Por que isso importa

Um mesh padroniza resiliência, segurança e observabilidade em cada serviço sem que cada equipe os reimplemente em linguagens diferentes.

Mas é pesado: apenas adote quando você tiver serviços suficientes para que a lógica de rede duplicada compense o custo operacional do mesh.