Qué es un service mesh y para qué sirve

Un service mesh es una capa dedicada para controlar cómo se comunican los servicios de una aplicación distribuida. En lugar de repetir autenticación, cifrado, reintentos y métricas dentro de cada servicio, la plataforma coordina esas políticas alrededor del tráfico entre procesos. Istio y Linkerd describen esta separación como una forma de mover capacidades de red fuera del código de negocio.

También puede servirte: Qué es un circuit breaker en microservicios y cómo funciona

La arquitectura suele dividirse entre un plano de datos, que participa en cada llamada, y un plano de control, que distribuye configuración. El tráfico sigue viajando entre servicios, pero una pieza cercana a cada proceso puede aplicar reglas y emitir telemetría de manera uniforme. Esa separación agrega componentes y exige una operación cuidadosa.

Con muchos servicios, un mesh puede centralizar mTLS, políticas de autorización, límites, balanceo, reintentos y observabilidad. También permite describir rutas y cambios de tráfico sin modificar cada aplicación. AWS lo presenta como una manera de administrar comunicaciones entre microservicios y mantener esas reglas separadas de la lógica que resuelve el negocio.

La contracara es complejidad. Cada salto puede sumar latencia y consumo, y un error de configuración puede afectar a muchos servicios a la vez. El equipo debe entender certificados, versiones, proxies, métricas y recuperación. Si la aplicación todavía tiene pocos servicios o una red simple, la capa puede costar más de lo que aporta.

Contá cuántos servicios se llaman entre sí y qué políticas se repiten. Un mesh empieza a tener sentido cuando el equipo necesita cifrado entre servicios, reglas consistentes de identidad y telemetría transversal, pero no quiere implementar cada capacidad una y otra vez. La cantidad no es el único criterio: también importa si existe una necesidad operativa concreta.

Antes de adoptarlo, definí quién mantiene el plano de control, cómo se prueba una política y qué ocurre si el proxy no responde. Elegí un caso pequeño, medí latencia y errores, y documentá una salida para desactivar reglas. Si no podés responder esas preguntas, primero mejorá observabilidad y contratos entre servicios.

Separá las métricas del proxy de las métricas de la aplicación: solicitudes, códigos de error, tiempos, reintentos y saturación. Una vista útil muestra el recorrido completo y permite distinguir si falló el cliente, el proxy o el servicio destino. Las trazas distribuidas ayudan a seguir una llamada, pero no reemplazan logs y métricas básicas.

Aplicá cambios de manera gradual y mantené una política mínima por defecto. Probá certificados, timeouts y rutas de emergencia antes de habilitar funciones para toda la malla. Un service mesh es una herramienta de plataforma: funciona cuando reduce trabajo repetido sin ocultar la salud real de los servicios.