Cuándo NO usar Kubernetes (que es más seguido de lo que crees)

Kubernetes resuelve problemas reales, pero cobra un impuesto de complejidad permanente. Cuatro señales de que no lo necesitas todavía.

Kubernetes es una pieza de ingeniería excelente y en los proyectos correctos no tiene sustituto. También es la decisión de arquitectura que con más frecuencia vemos tomada por razones equivocadas: porque está en el currículo del equipo, porque el consultor anterior lo dejó a medias, o porque suena a que es lo que hacen los serios.

El impuesto que nadie cotiza

Kubernetes no se instala, se opera. Actualizaciones de versión cada cuatro meses, gestión de certificados, políticas de red, controladores de ingreso, escalado de nodos y un ecosistema de herramientas que también hay que mantener. Ese trabajo es permanente y rara vez aparece en la cotización inicial.

Para un equipo de menos de diez ingenieros sin una persona dedicada a plataforma, ese impuesto se paga con capacidad que se le quita al producto.

Cuatro señales de que no lo necesitas

• Tienes menos de cinco servicios desplegables y no esperas pasar de diez este año.
• Tu carga es predecible y no necesitas escalar de cero a cientos de instancias en minutos.
• Nadie en el equipo ha operado un clúster en producción antes.
• Tu tiempo de despliegue actual no es el cuello de botella del negocio.

La mejor infraestructura es la que tu equipo puede depurar un viernes a las 7 de la tarde.

Las alternativas que sí sirven

Cloud Run, ECS Fargate y App Service resuelven el 80 % de los casos de uso reales con una fracción de la superficie operativa. Escalan a cero, se despliegan con un comando y no requieren que alguien entienda el ciclo de vida de un pod.

Y si más adelante realmente necesitas Kubernetes, la migración desde contenedores administrados es sencilla, porque el trabajo difícil —contenerizar bien la aplicación— ya está hecho.