Durante años, elegir una tecnología fue una decisión de ingeniería: costes, riesgos, habilidades del equipo y necesidades reales. Pero en parte del sector del software, Kubernetes ha pasado de ser una herramienta —potente, sí— a convertirse en un símbolo de estatus. En algunas entrevistas técnicas, en propuestas comerciales y hasta en conversaciones de pasillo, la pregunta parece obligatoria: “¿Usáis Kubernetes?”. Y, con demasiada frecuencia, la respuesta se interpreta como certificado de madurez o de obsolescencia.

Esa es la crítica de fondo que ha vuelto a circular con fuerza en comunidades técnicas a raíz de una larga reflexión publicada en LinkedIn por un profesional del ámbito cloud. Su tesis es provocadora, pero reconocible para cualquiera que haya trabajado en infraestructuras modernas: Kubernetes es extraordinario cuando resuelve el problema correcto; para el resto, puede convertirse en un impuesto de complejidad innecesario.

De la ingeniería al “cargo cult”: imitar la forma sin entender el coste

El texto recupera una idea clásica del mundo tecnológico: el “cargo cult”, una metáfora sobre copiar rituales externos con la esperanza de obtener los mismos resultados. Trasladado a la nube, sería algo así como ver que compañías hiperescalars o plataformas globales usan Kubernetes y asumir que replicar esa arquitectura traerá automáticamente fiabilidad, velocidad o éxito.

En la práctica, lo que muchas organizaciones descubren tarde es que Kubernetes no solo “orquesta contenedores”: introduce un ecosistema operativo completo. Ingress controllers, gestión de certificados, DNS automatizado, políticas de red, observabilidad, control de secretos, upgrades frecuentes, compatibilidades entre versiones… y, sobre todo, conocimiento especializado para operar todo eso sin convertir cada incidencia en una noche larga.

El autor lo expresa con ironía: la industria ha confundido “escalabilidad” con “credibilidad”, como si cualquiera estuviera a las puertas de un problema de millones de usuarios. Y no lo está. La mayoría de empresas quiere algo mucho más mundano: desplegar con rapidez, sin fallos humanos, con alta disponibilidad razonable y sin dedicar medio equipo a la plataforma.

El regreso del sysadmin: fundamentos antes que liturgia

Otra parte del mensaje conecta con un debate más cultural: la sensación de que se ha minusvalorado el perfil clásico del administrador de sistemas —la persona que entiende procesos, memoria, red, permisos, diagnóstico— frente a roles modernos llenos de siglas y herramientas que prometen abstraerlo todo.

La crítica no va contra la nube ni contra DevOps como disciplina, sino contra el “teatro de la complejidad”: adoptar capas y más capas como prueba de sofisticación. El recordatorio es simple: cuando algo se rompe a las 3 de la mañana, lo que salva el sistema no es el eslogan, sino el dominio de los fundamentos y la capacidad de depurar.

El caso práctico: bajar despliegues de horas a minutos sin Kubernetes

La parte más concreta —y la que más interesa a equipos de producto— llega cuando el autor cuenta cómo su equipo pasó de despliegues manuales de unas 2,5 horas a un flujo automatizado de pocos minutos, sin recurrir a Kubernetes.

La alternativa que describe se apoya en una estrategia habitual en AWS: ECS con Fargate (contenedores “serverless” en el sentido de que no se administran nodos), más automatización con scripts (por ejemplo, en Python con boto3) para crear y configurar recursos de forma idempotente. La receta, resumida, suena poco glamourosa, pero muy efectiva:

• construir y publicar la imagen del contenedor,
• desplegar o actualizar el servicio,
• configurar balanceador, certificados y DNS de forma programática,
• y dejar que la plataforma gestione el rolling deployment y los health checks.

El punto no es vender Fargate como una solución universal, sino mostrar que, para ciertos tamaños de equipo y cargas de trabajo, la victoria está en reducir superficie operativa, no en ampliarla.

¿Cuándo tiene sentido Kubernetes y cuándo no?

La reflexión, pese al tono combativo, no cae en el “anti-Kubernetes”. De hecho, propone un criterio bastante razonable que muchas consultoras repiten… aunque no siempre se aplica:

Kubernetes suele tener sentido cuando:

• hay decenas o cientos de servicios con necesidades complejas,
• existe un equipo de plataforma dedicado,
• la portabilidad (multi-cloud o híbrido real) es requisito,
• se necesitan patrones avanzados (operadores, stateful sets complejos, jobs masivos, mallas de servicio, etc.).

Alternativas como ECS/Fargate (u otras plataformas gestionadas) suelen encajar mejor cuando:

• el número de servicios es moderado,
• el equipo es pequeño o quiere enfocarse en producto,
• se prioriza velocidad de entrega sobre control milimétrico,
• se quiere minimizar el mantenimiento de la capa de orquestación.

En el fondo, es una llamada a volver a hacer la pregunta correcta: “¿Cuál es el problema real que intentamos resolver?” Si la respuesta es “desplegar rápido y sin sustos”, la solución no siempre necesita el mismo nivel de complejidad que una plataforma que opera a escala global.

La trampa del “estándar de la industria”

Kubernetes se ha convertido en estándar, sí. Pero “estándar” no significa “obligatorio”. Y esa confusión tiene un coste: arquitecturas sobredimensionadas, equipos quemados por la operación, presupuestos que se van en plataforma en lugar de producto y, paradójicamente, entregas más lentas.

El debate no va a terminar pronto, porque mezcla tecnología con identidad profesional. Pero la discusión tiene valor: en un momento en que muchas empresas buscan eficiencia, recortar fricción y mejorar time-to-market, cuestionar el “porque sí” puede ser la decisión más rentable.

---

Preguntas frecuentes

¿Kubernetes es imprescindible para una empresa mediana?
No necesariamente. Puede ser una gran opción si hay requisitos de escala, complejidad y un equipo preparado para operarlo, pero muchas empresas medianas logran despliegues robustos con plataformas gestionadas y automatización.

¿Qué significa “cargo cult” aplicado a Kubernetes?
Se usa para describir la adopción de herramientas o arquitecturas por imitación (porque las usan grandes empresas) sin evaluar si el coste operativo y la complejidad encajan con el problema real y el tamaño del equipo.

¿Qué alternativas hay a Kubernetes para desplegar contenedores en producción?
Depende del proveedor y del caso: AWS ECS/Fargate, servicios gestionados de contenedores, PaaS orientados a despliegue continuo, o incluso enfoques más simples con automatización y buenas prácticas en VMs cuando el contexto lo permite.

¿Cómo saber si mi empresa “necesita” Kubernetes o solo lo está adoptando por presión del mercado?
Una señal práctica: si operar la plataforma exige un equipo dedicado (o te está quitando foco de producto), si los upgrades y el debugging consumen demasiado tiempo, y si tus necesidades reales no requieren orquestación avanzada, probablemente estás pagando complejidad de más.