Co to jest service mesh i dlaczego byś go używał?

Question

Accepted Answer

**Service mesh** (Istio, Linkerd) przenosi zagadnienia dotyczące sieci (cross-cutting) — ponowne próby, timeouty, mTLS, routing ruchu, obserwabilność — **poza kod aplikacji** i do warstwy infrastruktury sieciowej **sidecar proxies**.

## Jak to działa

Każda instancja usługi uruchamia się obok **sidecar proxy** (np. Envoy). Cały ruch przechodzi przez proxy, które tworzą **data plane**; **control plane** je konfiguruje.

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

## Co to zapewnia

- **mTLS** między usługami automatycznie (zero zmian aplikacji).
- **Odporność** — ponowne próby, timeouty, circuit breaking w proxy.
- **Zarządzanie ruchem** — canary, A/B, weighted routing.
- **Obserwabilność** — jednolite metryki, traces, logi.

## Przykładowa polityka

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

## Kompromisy

Mesh dodaje opóźnienie (dodatkowe przeskoki), narzut zasobów (jeden proxy na pod) i rzeczywistą złożoność operacyjną.

## Dlaczego to ważne

Mesh standaryzuje odporność, bezpieczeństwo i obserwabilność w każdej usłudze bez konieczności ponownego wdrażania ich w różnych językach przez każdy zespół.

Ale to ciężkie: przyjmuj je tylko wtedy, gdy masz wystarczająco wiele usług, aby zduplikowana logika sieciowa przewyższała koszt operacyjny mesh.