Service mesh

Un service mesh (malla de servicios) es infraestructura que se mete entre los servicios de un sistema de microservicios y administra cada llamada que se hacen entre ellos. En vez de que cada equipo escriba su propio código para reintentos, timeouts, cifrado y métricas, la malla lo resuelve igual para todos, por fuera del código de la aplicación.

El diseño clásico pone un proxy chico, un sidecar, al lado de cada instancia de un servicio, en general dentro del mismo pod de Kubernetes. El servicio cree que llama directo a otro servicio, pero el pedido en realidad pasa por su sidecar, cruza la red y entra por el sidecar del otro lado. Todos los sidecars juntos forman el plano de datos (data plane). Un plano de control (control plane) los configura desde un lugar central: qué servicio puede llamar a cuál, cuánto tráfico va a una versión nueva, qué certificados usar. Los diseños más nuevos sacan el sidecar por pod y comparten proxies por nodo para ahorrar recursos.

Lo que ganás: TLS mutuo entre todos los servicios sin tocar el código, reglas finas de tráfico útiles para canary releases, reintentos automáticos y telemetría pareja para la observabilidad. Lo que cuesta: otro sistema complejo para operar, latencia extra en cada salto y más memoria. Suele convenir con decenas o cientos de servicios, no con cinco. Istio y Linkerd son las mallas open source más conocidas.