Qu'est-ce qu'une service mesh et pourquoi l'utiliser ?

Question

Accepted Answer

Une **service mesh** (Istio, Linkerd) déplace les préoccupations réseau transversales — tentatives, délais d'expiration, mTLS, routage du trafic, observabilité — **hors du code applicatif** et dans une couche infrastructure réseau de **sidecar proxies**.

## Fonctionnement

Chaque instance de service exécute un **sidecar proxy** à côté (p. ex., Envoy). Tout le trafic circule via les proxies, qui forment le **data plane** ; un **control plane** les configure.

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

## Ce qu'elle offre

- **mTLS** entre services automatiquement (zéro changement applicatif).
- **Résilience** — tentatives, délais d'expiration, circuit breaking au niveau du proxy.
- **Gestion du trafic** — canary, A/B, routage pondéré.
- **Observabilité** — métriques, traces, logs uniformes.

## Exemple de politique

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

## Compromis

Une mesh ajoute de la latence (sauts supplémentaires), surcharge en ressources (un proxy par pod) et une vraie complexité opérationnelle.

## Pourquoi c'est important

Une mesh standardise la résilience, la sécurité et l'observabilité dans tous les services sans que chaque équipe ne les réimplémente dans des langages différents.

Mais c'est lourd : adoptez-la seulement quand vous avez assez de services pour que la logique réseau dupliquée compense le coût opérationnel de la mesh.