Hva er en service mesh og hvorfor ville du brukt en?

Question

Accepted Answer

En **service mesh** (Istio, Linkerd) flytter kryss-kutt nettverksproblemer — retries, timeouts, mTLS, traffic routing, observability — **ut av applikasjonskoden** og inn i ett nettverksinfrastrukturrlag av **sidecar proxies**.

## Hvordan det fungerer

Hver service-instans kjører ved siden av en **sidecar proxy** (f.eks. Envoy). All trafikk flyter gjennom proxyene, som danner **data plane**; en **control plane** konfigurerer dem.

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

## Hva det gir

- **mTLS** mellom tjenester automatisk (null appendringer).
- **Motstandskraft** — retries, timeouts, circuit breaking i proxyen.
- **Trafikkstyring** — canary, A/B, vektet routing.
- **Observability** — ensartede metrikker, traces, logger.

## Eksempelpolicy

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

## Avveiinger

En mesh legger til latency (ekstra hopp), ressursoverhead (en proxy per pod), og ekte operasjonell kompleksitet.

## Hvorfor det betyr noe

En mesh standardiserer motstandskraft, sikkerhet og observability på tvers av hver service uten at hvert team reimplementerer dem på ulike språk.

Men det er tungt: adopter det bare når du har nok tjenester slik at duplisert nettverkslogikk oppveier meshens operasjonelle kostnad.