Što je service mesh i zašto biste ga koristili?

Question

Accepted Answer

A **service mesh** (Istio, Linkerd) premješta cross-cutting mrežne probleme — retries, timeouts, mTLS, traffic routing, observability — **izvan koda aplikacije** u mrežnu infrastrukturnu sloj **sidecar proxies**.

## Kako funkcionira

Svaka instanca servisa pokreće se uz **sidecar proxy** (npr. Envoy). Sav promet prolazi kroz proxye, koji čine **data plane**; **control plane** ih konfigurira.

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

## Što pruža

- **mTLS** između servisa automatski (nula promjena aplikacije).
- **Resilience** — retries, timeouts, circuit breaking na proxyu.
- **Traffic management** — canary, A/B, weighted routing.
- **Observability** — uniformne metrike, trace-ovi, logovi.

## Primjer politike

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

Mesh dodaje latenciju (dodatne skokove), overhead resursa (jedan proxy po pod-u) i stvarnu operativnu složenost.

## Zašto je to važno

Mesh standardizira resilience, sigurnost i observability na svim servisima bez da svaki tim mora ponovno implementirati u različitim jezicima.

Ali je teška: prihvatite je samo kada imate dovoljno servisa da duplicirana mrežna logika nadmaši operativne troškove mesh-a.