Hvad er en service mesh, og hvorfor ville du bruge en?

Question

Accepted Answer

En **service mesh** (Istio, Linkerd) flytter cross-cutting networking concerns — retry'er, timeouts, mTLS, trafikruting, observability — **ud af applicationskoden** og ind i et netværksinfrastrukturlayer af **sidecar proxies**.

## Hvordan det fungerer

Hver serviceinstans kører ved siden af en **sidecar proxy** (f.eks. Envoy). Al trafik strømmer gennem proxy'erne, som danner **data plane**; et **control plane** konfigurerer dem.

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

## Hvad det giver

- **mTLS** mellem services automatisk (nul appændringer).
- **Modstandskraft** — retry'er, timeouts, circuit breaking på proxy'en.
- **Trafikmanagement** — canary, A/B, vægtet routing.
- **Observability** — ensartede metrics, traces, logs.

## Eksempel på politik

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

## Afvejninger

En mesh tilføjer latency (ekstra hop'er), ressourceomkostninger (en proxy pr. pod) og ægte operationel kompleksitet.

## Hvorfor det betyder noget

En mesh standardiserer modstandskraft, sikkerhed og observability på tværs af hver service uden at hver team skal genimplementere dem i forskellige sprog.

Men det er tungt: adoptér det kun, når du har nok services, så den dublerede netværkslogik opvejer mesh'ens operationelle omkostninger.