Service Mesh

Resumen

Un Service Mesh es una capa de infraestructura que maneja la comunicación servicio-a-servicio de forma transparente. En lugar de que cada microservicio implemente lógica de retries, circuit breaking, TLS mutuo, métricas y tracing, el mesh lo hace por ellos mediante proxies sidecar —típicamente Envoy— que interceptan todo el tráfico.

El mesh se divide en dos planos: el data plane —los sidecars que manejan el tráfico— y el control plane —el componente central que configura y monitorea los sidecars—. Istio, Linkerd y Consul Connect son las implementaciones más conocidas.

Alcance y supuestos

Este paquete cubre el concepto de Service Mesh, su arquitectura en dos planos y su relación con sidecars. Asume familiaridad con microservicios.

Modelo mental

Una ciudad con un sistema de correo interno. Las empresas no contratan mensajeros propios ni definen rutas de entrega. El servicio postal de la ciudad se encarga de todo: recoge, enruta, entrega, verifica identidad y notifica si hay problemas. El service mesh es el servicio postal de tus microservicios.

Uso práctico

• ✅ mTLS automático entre servicios, observabilidad sin tocar código, resiliencia configurable.
• ❌ Agrega latencia y complejidad operativa. No justifica su costo en sistemas con pocos servicios.

Ejemplo trabajado: Istio en un clúster de producción

Un equipo con 40 microservicios instala Istio. Cada Pod recibe un sidecar Envoy. Desde el control plane configuran: mTLS entre todos los servicios, retries con backoff para el 2% de fallas transitorias, circuit breaker para el servicio de recomendaciones que se satura los lunes, y métricas de latencia por servicio sin tocar una línea de código de aplicación.

Evidencia

• Istio y Linkerd son los service meshes más adoptados. Ambos usan Envoy como sidecar proxy.