¿Qué problema resuelve realmente un service mesh (Istio/Linkerd) que no podrías resolver ya en el código de la aplicación?

#Todo lo que hace un mesh, podrías escribirlo tú mismo

Esa es la verdad incómoda que buscan los entrevistadores. TLS mutuo entre servicios, reintentos con backoff, timeouts, circuit breakers, reparto de tráfico ponderado para canary releases y dashboards de latencia por ruta son todas cosas que puedes implementar con librerías a nivel de aplicación — resilience4j, interceptores de gRPC, un job casero de rotación de certificados. Netflix operó durante años una flota de microservicios enorme y exitosa apoyándose exactamente en eso: Eureka, Ribbon y Hystrix como librerías de la JVM. Entonces, si nada de esto es técnicamente nuevo, ¿qué te da realmente un service mesh?

#El problema no es la lista de funciones, es quién es dueño de ellas

En el modelo de "librería por servicio", cada una de estas preocupaciones transversales vive dentro del código de la aplicación, lo que significa que cada equipo, en cada lenguaje, tiene que adoptar la librería, configurarla correctamente y mantenerla actualizada. Un servicio en Python, uno en Go y uno en Java necesitan cada uno su propia librería de reintentos, su propio manejo de certificados, su propia instrumentación de tracing — y con el tiempo divergen. Un equipo se queda anclado en una versión vieja con un bug conocido. Otro equipo nunca activa mTLS porque "está en el roadmap". Cambiar una política de reintentos implica coordinar un despliegue en cuarenta repositorios en lugar de editar una configuración.

Un service mesh saca todo esto del proceso de la aplicación y lo mueve a un proxy sidecar — un proxy ligero (Envoy, en el caso de Istio; Linkerd trae su propio proxy minimalista) desplegado junto a cada instancia de servicio, normalmente como un segundo contenedor dentro del mismo pod de Kubernetes?. Cada byte de tráfico entrante y saliente de ese servicio se redirige de forma transparente a través de su sidecar. La aplicación simplemente sigue haciendo una llamada HTTP o gRPC normal a localhost — no tiene ni idea de que hay un proxy de por medio.

#Plano de control y plano de datos

Los sidecars son el plano de datos — hacen el trabajo real de interceptar, cifrar, reintentar y enrutar el tráfico. Un plano de control (istiod en Istio, el equivalente en Linkerd) es un conjunto de componentes separado que calcula la configuración deseada — reglas de enrutamiento, certificados TLS, políticas de reintento — y la empuja a cada sidecar. Cambiar una política de reintentos o desplegar un canary ahora significa actualizar un recurso en el plano de control; cada sidecar de la malla lo recoge sin un solo redeploy de aplicación, en cualquier lenguaje.

#Qué significa realmente "que no podrías hacer en código de aplicación"

Podrías hacer cada pieza individual en código de aplicación. Lo que no podrías hacer fácilmente es que fuera uniforme, independiente del lenguaje y gobernado centralmente sin que cada equipo reimplemente y vuelva a certificar el mismo comportamiento. Un mesh le da a cada workload una identidad criptográfica (siguiendo comúnmente el estándar SPIFFE), emite y rota certificados de corta duración automáticamente, y aplica TLS mutuo entre servicios sin una sola línea de código de manejo de certificados en ningún servicio. Te da un grafo de topología en vivo y dashboards consistentes de señales doradas (latencia, tráfico, errores, saturación) para cada servicio en el momento en que se une a la malla, generados a partir de la telemetría del proxy en lugar de las decisiones de instrumentación de cada equipo. Y permite que un equipo de plataforma imponga una política de autorización — "solo el servicio de checkout puede llamar al servicio de pagos" — como configuración de infraestructura, independientemente de lo que el código de cada servicio individual verifique o deje de verificar.

#Lo que te cuesta

Nada de esto es gratis. Cada llamada ahora hace dos saltos extra — sidecar del cliente, luego sidecar del servidor — añadiendo latencia real, típicamente de unos pocos milisegundos por salto, pero que se acumula a lo largo de una cadena de llamadas profunda. Cada pod carga un contenedor adicional que consume CPU y memoria, multiplicado por toda tu flota. El propio plano de control es otro sistema distribuido que ahora operas, actualizas y depuras, y un bug o una mala configuración ahí puede afectar a todos los servicios a la vez. Diagnosticar un problema ahora implica razonar sobre proxies que no escribiste tú, lo cual es un costo real cuando algo falla a las 2 de la madrugada. Para una plataforma con menos de una o dos docenas de servicios, el overhead operativo de correr un mesh suele superar el valor que aporta — a esa escala, los mismos comportamientos de resiliencia suelen salir más baratos hechos a mano con una librería compartida.

#Cuándo el intercambio realmente vale la pena

El argumento a favor de un mesh se fortalece a medida que crecen tanto el número de servicios como el número de lenguajes, y se fortalece todavía más cuando un equipo de plataforma necesita imponer una política de seguridad o de tráfico de forma consistente sin depender de que cada equipo de aplicación la implemente correctamente. Si estás corriendo un puñado de servicios en un solo lenguaje con un solo equipo, un mesh normalmente está resolviendo un problema que todavía no tienes.