Construir aplicaciones distribuidas exige mucho más que levantar contenedores. Necesitas visibilidad completa de lo que ocurre entre tus servicios, control sobre el tráfico y seguridad sin modificar código. La malla de servicio (service mesh) reúne estas tres dimensiones en una sola capa de infraestructura, y entender sus beneficios cambia la forma en que equipos de desarrollo y operaciones colaboran.
¿Qué es la observabilidad unificada y por qué importa?
La observabilidad unificada se refiere a tener un flujo consistente de logs, métricas y trazabilidad de peticiones en un solo lugar [0:10]. No basta con saber si un servidor está arriba o abajo; lo que necesitas es una visión centrada en el usuario que te diga cuándo las cosas se alentan, cuándo responden bien y dónde están las áreas de mejora.
Un concepto fundamental aquí son los SLOs (service level objectives) [0:42]. Son definiciones que tu equipo establece para describir un estado aceptable del servicio. Por ejemplo: que el 95 % de las peticiones se resuelvan en menos de trescientos milisegundos durante un periodo de siete días. Esto te permite mejorar la calidad de tus servicios de forma gradual y medible.
¿Cómo funciona la gráfica topológica?
La malla genera una gráfica topológica que muestra visualmente quién habla con quién [1:28]. Puedes analizar cuánto tarda la invocación de un servicio a otro en promedio y, algo crítico, detectar si alguien empieza a comunicarse con un componente que no debería.
¿Qué es el presupuesto de error?
Los indicadores de salud alimentan una abstracción llamada presupuesto de error (error budget) [1:50]. Cuando tu servicio cae fuera de los rangos definidos, empiezas a consumir ese presupuesto. Si los desarrolladores se quedan sin presupuesto, dejan de construir funcionalidades nuevas y se concentran en estabilidad. Esta es la base de la responsabilidad compartida entre desarrollo y operaciones, tal como se practica en Google. Los libros de Site Reliability Engineering, disponibles de forma gratuita, profundizan en estos conceptos [2:24].
¿Qué agilidad operacional ofrece la malla de servicio?
La segunda dimensión es la agilidad operacional, que te da herramientas para controlar el tráfico sin tocar código [2:46].
- Bifurcación de tráfico: permite despliegues canario donde una nueva versión recibe, por ejemplo, solo el cinco por ciento del tráfico e incrementas gradualmente [3:18].
- Circuit breaking: cuando un servicio falla, se deja de congestionar la red y se espera a que se recupere [3:00].
- Controles de egreso: establecen comunicación de salida segura.
- Inyección de fallas: simula condiciones de error para probar cómo se comporta el sistema cuando un componente cae, sin escribir ni mantener código adicional [3:08].
En Kubernetes puro, cuando introduces una nueva versión el tráfico se balancea de forma aleatoria y equitativa [4:00]. Si quieres un balanceo inteligente con despliegues canario, necesitas la malla de servicio.
¿Cómo se implementa la seguridad dirigida por políticas?
La tercera dimensión es la seguridad dirigida por políticas [4:18]. La malla encripta la comunicación entre servicios, asigna una identidad y credencial por canal, y aplica controles de autorización y políticas de acceso. En la consola puedes ver un candado verde confirmando que la comunicación entre dos servicios es segura, todo sin programar nada.
¿Qué es mTLS y cómo se adopta gradualmente?
El mutual TLS (mTLS) garantiza que ambos extremos de una conexión se autentiquen mutuamente [4:56]. Al instalar la malla, comienzas en modo permisivo para dar tiempo a los equipos de configurar sus servicios. Una vez listos, transicionas a modo estricto. Es configuración, no cambios en código [5:16].
Por defecto, Kubernetes permite toda la comunicación entre pods. Las políticas de red te permiten cerrar puertas y habilitar solo las rutas necesarias [5:34].
¿Qué son las funciones de red avanzadas y el tráfico East-West?
Entre las funciones avanzadas destacan el locality routing, que dirige clientes a la región más cercana en despliegues multirregionales [4:38], y el failover automático que redirige tráfico si una región falla. La topología East-West conecta clusters en distintas nubes, donde cada uno tiene su propia malla y se comunican entre sí mediante gateways [5:56]. Este tipo de arquitectura híbrida multinube es precisamente lo que se implementa en los laboratorios prácticos.
Si alguna vez has tenido que programar fallas para probar la resiliencia de un sistema, comparte tu experiencia en los comentarios.
