Service Mesh y microservicios Kotlin: del caos al orden

¿Sus microservicios Kotlin han dejado de ser simplemente microservicios?

Si alguna vez ha puesto en producción un sistema de una docena de servicios Kotlin, conoce ese momento. Al principio todo es maravilloso: ktor susurra, spring-webflux vuela, la base de datos respuesta al instante. Pero pasa un mes y el mundo familiar se derrumba. El tráfico comienza a serpentear, los reintentos se multiplican, los timeouts aparecen donde no deberían, y los registros se convierten en una mezcla de un millón de líneas.

En ese momento, comienza a buscar service mesh. Y ese es el camino correcto. Analicemos cómo esta tecnología transforma el caos en orden y cómo implementarla correctamente en el mundo Kotlin.

¿Qué es service mesh y por qué lo necesita un desarrollador Kotlin?

Service mesh (malla de servicios) es una capa de infraestructura dedicada para gestionar la comunicación entre servicios. Asume todo el "trabajo sucio": enrutamiento, balanceo, cifrado, observabilidad y circuit breaking. Y lo hace sin cambiar el código de sus aplicaciones Kotlin.

¿Por qué es crítico para Kotlin? Los microservicios Kotlin a menudo se escriben en frameworks como Ktor o Spring Boot. Ambos manejan bien la lógica de negocio, pero cuando hay 20+, cada servicio comienza a cargar con un montón de código repetitivo: métricas, trazado, mTLS, mecanismos de reintento. Service mesh traslada todo esto al nivel de infraestructura.

Imagine: escribe un endpoint REST simple en Ktor, y service mesh le agrega automáticamente cifrado, trazado y balanceo. Hermoso, ¿verdad?

Componentes principales de service mesh

Cualquier malla de servicios se construye sobre dos componentes clave:

\n
• Control plane (plano de control) — el "cerebro" del sistema. Recopila configuración, gestiona reglas de enrutamiento, políticas de seguridad. En Istio es istiod, en Linkerd es linkerd-controller.
\n
• Data plane (plano de datos) — los "músculos". Un conjunto de proxies sidecar (generalmente Envoy) que se colocan junto a cada uno de sus servicios Kotlin e interceptan todo el tráfico entrante/saliente.
\n

Cuando el servicio Kotlin A quiere llamar al servicio B, su solicitud primero llega al proxy sidecar. El proxy verifica las reglas, aplica mTLS, balancea la carga, agrega encabezados para trazado — y solo entonces envía la solicitud más allá. Su código ni siquiera se entera.

Práctica: configurando service mesh para un microservicio Kotlin

Escribamos un servicio Kotlin simple en Ktor y veamos cómo service mesh cambia su comportamiento.

Paso 1. Escribimos la aplicación en Kotlin

// build.gradle.kts\ndependencies {\n    implementation("io.ktor:ktor-server-netty:2.3.7")\n    implementation("io.ktor:ktor-server-content-negotiation:2.3.7")\n    implementation("io.ktor:ktor-serialization-kotlinx-json:2.3.7")\n    implementation("ch.qos.logback:logback-classic:1.4.14")\n}\n\n// Application.kt\npackage com.example\n\nimport io.ktor.server.engine.*\nimport io.ktor.server.netty.*\nimport io.ktor.server.routing.*\nimport io.ktor.server.response.*\nimport io.ktor.serialization.kotlinx.json.*\nimport io.ktor.server.plugins.contentnegotiation.*\n\nfun main() {\n    embeddedServer(Netty, port = 8080) {\n        install(ContentNegotiation) {\n            json()\n        }\n        routing {\n            get("/health") {\n                call.respond(mapOf("status" to "UP", "service" to "payment"))\n            }\n            get("/api/payments/{id}") {\n                val id = call.parameters["id"] ?: "unknown"\n                call.respond(mapOf("paymentId" to id, "amount" to 150.00))\n            }\n        }\n    }.start(wait = true)\n}\n

Este servicio no sabe nada sobre service mesh. Simplemente responde a las solicitudes. Pero tan pronto como lo despleguemos en un clúster Kubernetes con Istio, todo cambiará.

Paso 2. Desplegamos con