3 min de lectura<\/p>\n
Kubernetes se ha impuesto en el mercado de la orquestaci\u00f3n de contenedores. Pero la dominancia en el mercado no significa que sea la opci\u00f3n adecuada para todos los casos de uso. Para un equipo de cinco desarrolladores con diez servicios, Kubernetes suele ser una soluci\u00f3n excesiva: su curva de aprendizaje consume semanas y su complejidad operativa requiere la dedicaci\u00f3n de medio equipo de operaciones. Existen alternativas.<\/strong><\/p>\n Kubernetes puede hacer pr\u00e1cticamente cualquier cosa: despliegues progresivos (rolling deployments), escalado autom\u00e1tico (auto-scaling), descubrimiento de servicios (service discovery), gesti\u00f3n de secretos (secret management), pol\u00edticas de red (network policies), definiciones de recursos personalizados (Custom Resource Definitions). Esta potencia tiene un precio: un cl\u00faster de Kubernetes listo para producci\u00f3n exige conocimientos profundos sobre redes (plugins CNI, controladores Ingress), almacenamiento (CSI, PersistentVolumes), seguridad (RBAC, NetworkPolicies, PodSecurityStandards) y monitorizaci\u00f3n (Prometheus, Grafana, Alertmanager).<\/p>\n Para un equipo de plataforma con tres o m\u00e1s ingenieros experimentados en Kubernetes, esto es manejable. Para un equipo peque\u00f1o que, adem\u00e1s, debe desarrollar nuevas funcionalidades, se convierte en un consumidor masivo de recursos. La pregunta no deber\u00eda ser \u00ab\u00bfPodemos implementar Kubernetes?\u00bb, sino \u00ab\u00bfNecesitamos Kubernetes?\u00bb.<\/p>\n Docker Swarm est\u00e1 integrado directamente en Docker, no requiere herramientas adicionales y se configura en 15 minutos. Un cl\u00faster Swarm soporta actualizaciones progresivas, descubrimiento de servicios, equilibrio de carga y gesti\u00f3n de secretos: funciones que cubren las necesidades del 80 % de los equipos.<\/p>\n Sus limitaciones: no dispone de escalado autom\u00e1tico nativo (solo manual o mediante scripts), carece de un controlador Ingress integrado (se pueden usar soluciones alternativas como Traefik o Nginx), y su comunidad y ecosistema est\u00e1n muy reducidos. Docker ha suspendido de facto el desarrollo de Swarm: sigue funcionando, pero ya no se desarrolla activamente.<\/p>\n Para qui\u00e9n: equipos con entre 3 y 20 servicios que necesitan orquestaci\u00f3n de contenedores, pero que no pueden justificar la complejidad de Kubernetes. A menudo se utiliza como punto de entrada antes de migrar, a largo plazo, a Kubernetes.<\/p>\n Nomad no orquesta \u00fanicamente contenedores, sino tambi\u00e9n m\u00e1quinas virtuales, aplicaciones Java y trabajos por lotes (batch jobs). Esto lo convierte en la \u00fanica alternativa capaz de gestionar cargas de trabajo heterog\u00e9neas de forma nativa. Su arquitectura es m\u00e1s sencilla que la de Kubernetes: un cl\u00faster Nomad consta simplemente de servidores y clientes – sin necesidad de cl\u00fasteres etcd, sin configuraci\u00f3n de servidores API ni plugins CNI.<\/p>\n Nomad se integra perfectamente con el ecosistema de HashiCorp: Consul para el descubrimiento de servicios, Vault para la gesti\u00f3n de secretos y Terraform para la infraestructura como c\u00f3digo. Para empresas que ya utilizan herramientas de HashiCorp, Nomad es la opci\u00f3n m\u00e1s natural.<\/p>\n Su limitaci\u00f3n: su ecosistema es m\u00e1s peque\u00f1o que el de Kubernetes. Hay menos integraciones de terceros, menos soporte comunitario y menos ingenieros con experiencia en Nomad disponibles en el mercado laboral.<\/p>\n AWS ECS (Elastic Container Service)<\/strong> es el orquestador de contenedores propio de Amazon – totalmente integrado en el ecosistema de AWS y m\u00e1s sencillo de usar que EKS (Kubernetes en AWS). Con Fargate como backend de c\u00f3mputo, incluso la gesti\u00f3n del cl\u00faster desaparece por completo: basta con definir tareas y servicios; AWS se encarga de toda la infraestructura.<\/p>\n Google Cloud Run<\/strong> va un paso m\u00e1s all\u00e1: despliegue de contenedores con un solo clic, escalado autom\u00e1tico (incluido escalado a cero) y facturaci\u00f3n por solicitud (pay-per-request). Para cargas de trabajo basadas en HTTP sin necesidad de comunicaciones complejas entre servicios, Cloud Run es la opci\u00f3n m\u00e1s sencilla disponible en el mercado.<\/p>\n Azure Container Apps<\/strong> se posiciona de forma similar a Cloud Run: contenedores sin servidor (serverless), con escalado autom\u00e1tico basado en KEDA e integraci\u00f3n con Dapr para patrones de microservicios.<\/p>\n Kubernetes<\/strong> cuando: m\u00e1s de 50 servicios, requisito de multi-nube, equipo de plataforma grande, redes complejas o necesidad de controladores personalizados.<\/p>\n Docker Swarm<\/strong> cuando: equipo peque\u00f1o (< 5 desarrolladores), menos de 20 servicios, necesidad de una puesta en marcha r\u00e1pida, entorno on-premise y ausencia de experiencia en Kubernetes.<\/p>\n Nomad<\/strong> cuando: cargas de trabajo heterog\u00e9neas (contenedores + m\u00e1quinas virtuales + trabajos por lotes), uso previo del stack de HashiCorp y necesidad de simplicidad sin renunciar a capacidades empresariales.<\/p>\n ECS\/Cloud Run<\/strong> cuando: preferencia por AWS\/GCP, equipo centrado en el c\u00f3digo m\u00e1s que en la infraestructura, servicios basados en HTTP y sin necesidad de multi-nube.<\/p>\n No est\u00e1 muerto, pero s\u00ed en modo de mantenimiento. Docker centra sus esfuerzos en Docker Desktop y Docker Hub. Swarm sigue funcionando de forma estable, pero ya no recibe nuevas funcionalidades. Para entornos existentes no supone un problema. En proyectos nuevos, conviene evaluar su viabilidad a largo plazo.<\/p>\n<\/details>\nEl dilema de Kubernetes: potente, pero complejo<\/h2>\n
Docker Swarm: la alternativa pragm\u00e1tica<\/h2>\n
HashiCorp Nomad: el generalista<\/h2>\n
Servicios gestionados: ning\u00fan cl\u00faster, ning\u00fan problema<\/h2>\n
Matriz de decisi\u00f3n: qu\u00e9 herramienta conviene en cada contexto<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfEst\u00e1 muerto Docker Swarm?<\/strong><\/summary>\n