Wat is een service mesh en waarom zou je er een gebruiken?

Question

Accepted Answer

Een **service mesh** (Istio, Linkerd) verplaatst cross-cutting netwerkproblemen — retries, timeouts, mTLS, traffic routing, observability — **uit de applicatiecode** naar een netwerkinfrastructuurlaag van **sidecar proxies**.

## Hoe het werkt

Elke service-instantie draait naast een **sidecar proxy** (bijv. Envoy). Al het verkeer stroomt door de proxies, die het **data plane** vormen; een **control plane** configureert ze.

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

## Wat het biedt

- **mTLS** tussen services automatisch (nul appwijzigingen).
- **Veerkracht** — retries, timeouts, circuit breaking in de proxy.
- **Verkeersbeheer** — canary, A/B, weighted routing.
- **Observability** — uniforme metriek, traces, logs.

## Voorbeeldbeleid

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

## Afwegingen

Een mesh voegt latentie toe (extra hops), resource overhead (een proxy per pod), en echte operationele complexiteit.

## Waarom het belangrijk is

Een mesh standaardiseert veerkracht, beveiliging en observability in elke service zonder dat elk team ze opnieuw in verschillende talen implementeert.

Maar het is zwaar: neem het alleen in gebruik als je genoeg services hebt zodat de gedupliceerde netwerklogica opweegt tegen de operationele kosten van de mesh.