Mikä on service mesh ja miksi sitä käytettäisiin?

Question

Accepted Answer

**Service mesh** (Istio, Linkerd) siirtää cross-cutting networking concerns — uudelleenyritykset, timeoutit, mTLS, liikenteen reititys, havainnointikyky — **pois sovelluskoodeista** ja **sidecar proxy** -verkon infrastruktuurikerrokseen.

## Kuinka se toimii

Jokaisella palvelun instanssilla on **sidecar proxy** sen vieressä (esim. Envoy). Kaikki liikenne kulkee proxy-palvelimien kautta, jotka muodostavat **data planen**; **control plane** määrittää ne.

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

## Mitä se tarjoaa

- **mTLS** palveluiden välillä automaattisesti (ei sovelluksen muutoksia).
- **Kestävyys** — uudelleenyritykset, timeoutit, piirikatkaisu proxy-palvelimessa.
- **Liikenteen hallinta** — canary, A/B, painotettu reititys.
- **Havainnointikyky** — yhtenäiset mittarit, jäljitykset, lokit.

## Käytäntöesimerkki

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

## Kompromissit

Mesh lisää viiveistä (ylimääräiset hyppyt), resurssien ylikuormaa (yksi proxy per pod) ja todellista operatiivista monimutkaisuutta.

## Miksi sillä on merkitystä

Mesh standardoi kestävyyden, turvallisuuden ja havainnointikykyä kaikissa palveluissa ilman, että jokaisen tiimin tarvitsee toteuttaa ne uudelleen eri kielillä.

Mutta se on raskas: ota se käyttöön vain silloin, kun sinulla on tarpeeksi palveluita niin, että päällekkäinen verkkologiikka kompensoi meshin operatiivisten kustannuksien.