Was ist ein Service Mesh und warum würde man eines verwenden?

Question

Accepted Answer

Ein **Service Mesh** (Istio, Linkerd) verlagert Cross-Cutting Networking Concerns — Retries, Timeouts, mTLS, Traffic Routing, Observability — **aus dem Anwendungscode** in eine Netzwerk-Infrastrukturschicht von **Sidecar Proxies**.

## Wie es funktioniert

Jede Service-Instanz läuft neben einem **Sidecar Proxy** (z. B. Envoy). Der gesamte Traffic fließt durch die Proxies, die die **Data Plane** bilden; eine **Control Plane** konfiguriert sie.

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

## Was es bietet

- **mTLS** zwischen Services automatisch (ohne App-Änderungen).
- **Resilienz** — Retries, Timeouts, Circuit Breaking im Proxy.
- **Traffic Management** — Canary, A/B, gewichtetes Routing.
- **Observability** — einheitliche Metriken, Traces, Logs.

## Beispiel-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

Ein Mesh fügt Latenz (Extra-Hops) hinzu, Ressourcen-Overhead (ein Proxy pro Pod) und echte operationelle Komplexität.

## Warum es wichtig ist

Ein Mesh standardisiert Resilienz, Sicherheit und Observability über jeden Service hinweg, ohne dass jedes Team sie in verschiedenen Sprachen neu implementieren muss.

Aber es ist schwer: Adoptieren Sie es nur, wenn Sie genug Services haben, dass die duplizierte Netzwerk-Logik die operationellen Kosten des Mesh aufwiegt.