Cuándo Kubernetes es la respuesta equivocada.

Kubernetes rara vez se elige. Se toma por defecto. La disciplina está en preguntarse, en voz alta, antes de que exista el primer cluster, si el problema que tenés enfrente realmente lo necesita.

Toda decisión de plataforma cuenta dos historias. Una es el diagrama de arquitectura, ese que se ve ambicioso en una diapositiva. La otra es la guardia que crea, los llamados a las 3 de la mañana, la actualización que nadie quiere hacerse cargo, el YAML que en silencio se volvió un segundo código. Kubernetes hace que la primera historia se vea impresionante y la segunda, mucho más larga.

Nada de esto es un argumento en contra de Kubernetes. Es un argumento en contra de recurrir a él por reflejo. Es una pieza de ingeniería extraordinaria, construida para resolver los problemas de equipos que corren cientos de servicios a una escala que la mayoría de las empresas nunca va a tocar. El problema empieza cuando se adopta su complejidad mucho antes de necesitar sus capacidades, cuando un equipo de seis hereda la superficie operativa de una plataforma hecha para seiscientos.

Preguntá por qué se está eligiendo y la respuesta honesta suele ser algo distinto a la carga de trabajo: es lo que viene por defecto en cada charla de conferencia, queda bien en un currículum, es lo que usaba la empresa anterior. Son fuerzas reales. Ninguna es tu tráfico. La encuesta anual de la CNCF ubica el uso de Kubernetes en producción por encima del 80%, contra 66% un año antes, y así es exactamente como se forma el reflejo. Cuando algo está en todas partes, adoptarlo deja de sentirse como una decisión y empieza a sentirse como la ausencia de una.

La complejidad que no necesitás no es poder. Es riesgo que aceptaste pagar.

La complejidad tiene que vivir en algún lado

Kubernetes no elimina la complejidad; la reubica. La aplicación se vuelve más simple de desplegar y, a cambio, ahora operás un sistema distribuido: un control plane, una red overlay, RBAC, ingress, secrets, autoscalers y una cadencia de upgrades de cluster que no para nunca. Es un trato justo cuando la complejidad te compra algo real, muchos equipos, muchos servicios, elasticidad genuina. Es pésimo cuando te cargaste el trabajo de un equipo de plataforma para correr tres containers que un solo servicio administrado habría hospedado por una fracción de la atención. Y ese trabajo es real: la misma encuesta de la CNCF reporta que la principal barrera para correr containers en producción ya no es técnica, es cultural, citada por el 47% de los equipos, por delante de la capacitación, la seguridad y la complejidad. El cluster no es la parte difícil. Construir una organización capaz de operarlo, sí.

La mayoría de los equipos no son Google

Las opciones aburridas son la respuesta correcta mucho más seguido de lo que se les reconoce. Un runner de containers administrado como Fargate o App Runner, una cola, una base de datos administrada y una sola VM bien entendida llevan a una empresa más lejos de lo que la mayoría de los fundadores espera, casi siempre hasta el punto en que tienen la escala, y la gente, para realmente querer Kubernetes. Y la parte de la gente no es un detalle: cerca de tres de cada cuatro organizaciones reportan que les faltan las habilidades para operar bien infraestructura cloud-native, lo que significa que la mayoría de los equipos que adoptan Kubernetes se comprometen a operar algo que no pueden dotar de personal por completo. Y ese punto en que vale la pena igual existe. Varios equipos desplegando de forma independiente, escala horizontal real, un requisito firme de portabilidad entre nubes, esas son razones genuinas, y cuando son genuinas, Kubernetes se gana su complejidad. La disciplina está en distinguir entre necesitarlo y querer haberlo elegido.

Elegí las fallas que podés sostener

Toda arquitectura es un conjunto de modos de falla que aceptaste hacerte cargo. La pregunta correcta no es qué sistema es más poderoso, es cuál puede correr tu equipo realmente a las 3 de la mañana, con la gente que tenés, en la peor noche del trimestre. Una plataforma que no podés operar con calma bajo presión no es un activo; es un pasivo con muy buena documentación. Elegí el sistema más chico que resuelva el problema real y que todavía te deje la capacidad de correrlo bien.

Levantar Kubernetes hoy es fácil, un cluster administrado son unos clics y un fin de semana de tutoriales. Saber si deberías es el juicio más difícil y más valioso, y es el que se acumula: cada pieza de complejidad que no adoptás es atención que te guardás para los problemas que sí son tuyos. El objetivo nunca fue la plataforma más sofisticada. Fue la del tamaño justo.

Elegí lo más chico que resuelva el problema real. Eso no es sub-ingeniería, eso es la ingeniería.