¿Qué es un service mesh y por qué lo usarías?

Question

Accepted Answer

Un **service mesh** (Istio, Linkerd) traslada cross-cutting networking concerns — reintentos, timeouts, mTLS, enrutamiento de tráfico, observabilidad — **fuera del código de la aplicación** y hacia una capa de infraestructura de red de **sidecar proxies**.

## Cómo funciona

Cada instancia de servicio se ejecuta junto a un **sidecar proxy** (p. ej., Envoy). Todo el tráfico fluye a través de los proxies, que forman el **data plane**; un **control plane** los configura.

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

## Lo que proporciona

- **mTLS** entre servicios automáticamente (sin cambios de aplicación).
- **Resiliencia** — reintentos, timeouts, circuit breaking en el proxy.
- **Gestión de tráfico** — canary, A/B, enrutamiento ponderado.
- **Observabilidad** — métricas uniformes, traces, logs.

## Ejemplo de política

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

## Compensaciones

Un mesh añade latencia (saltos adicionales), sobrecarga de recursos (un proxy por pod) y verdadera complejidad operativa.

## Por qué es importante

Un mesh estandariza resiliencia, seguridad y observabilidad en todos los servicios sin que cada equipo tenga que reimplementarlos en diferentes lenguajes.

Pero es pesado: solo adóptalo cuando tengas suficientes servicios para que la lógica de red duplicada supere el costo operativo del mesh.