3 min de lectura
En resumen
- Kubernetes es el estándar de facto para la orquestación de contenedores, pero no siempre es la mejor opción.
- Docker Swarm ofrece el 80 % de las funcionalidades con solo el 20 % de la complejidad, ideal para equipos pequeños y medianos.
- HashiCorp Nomad orquesta contenedores, máquinas virtuales y trabajos por lotes (batch jobs) mediante una única plataforma.
- AWS ECS y Google Cloud Run eliminan por completo la gestión de clústeres al ofrecerse como servicios gestionados (managed services).
- La elección depende del tamaño del equipo, del tipo de cargas de trabajo y de la capacidad operativa disponible – no del hype.
Kubernetes se ha impuesto en el mercado de la orquestación de contenedores. Pero la dominancia en el mercado no significa que sea la opción adecuada para todos los casos de uso. Para un equipo de cinco desarrolladores con diez servicios, Kubernetes suele ser una solución excesiva: su curva de aprendizaje consume semanas y su complejidad operativa requiere la dedicación de medio equipo de operaciones. Existen alternativas.
El dilema de Kubernetes: potente, pero complejo
Kubernetes puede hacer prácticamente cualquier cosa: despliegues progresivos (rolling deployments), escalado automático (auto-scaling), descubrimiento de servicios (service discovery), gestión de secretos (secret management), políticas de red (network policies), definiciones de recursos personalizados (Custom Resource Definitions). Esta potencia tiene un precio: un clúster de Kubernetes listo para producción exige conocimientos profundos sobre redes (plugins CNI, controladores Ingress), almacenamiento (CSI, PersistentVolumes), seguridad (RBAC, NetworkPolicies, PodSecurityStandards) y monitorización (Prometheus, Grafana, Alertmanager).
Para un equipo de plataforma con tres o más ingenieros experimentados en Kubernetes, esto es manejable. Para un equipo pequeño que, además, debe desarrollar nuevas funcionalidades, se convierte en un consumidor masivo de recursos. La pregunta no debería ser «¿Podemos implementar Kubernetes?», sino «¿Necesitamos Kubernetes?».
Docker Swarm: la alternativa pragmática
Docker Swarm está integrado directamente en Docker, no requiere herramientas adicionales y se configura en 15 minutos. Un clúster Swarm soporta actualizaciones progresivas, descubrimiento de servicios, equilibrio de carga y gestión de secretos: funciones que cubren las necesidades del 80 % de los equipos.
Sus limitaciones: no dispone de escalado automático 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án muy reducidos. Docker ha suspendido de facto el desarrollo de Swarm: sigue funcionando, pero ya no se desarrolla activamente.
Para quién: equipos con entre 3 y 20 servicios que necesitan orquestación 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.
HashiCorp Nomad: el generalista
Nomad no orquesta únicamente contenedores, sino también máquinas virtuales, aplicaciones Java y trabajos por lotes (batch jobs). Esto lo convierte en la única alternativa capaz de gestionar cargas de trabajo heterogéneas de forma nativa. Su arquitectura es más sencilla que la de Kubernetes: un clúster Nomad consta simplemente de servidores y clientes – sin necesidad de clústeres etcd, sin configuración de servidores API ni plugins CNI.
Nomad se integra perfectamente con el ecosistema de HashiCorp: Consul para el descubrimiento de servicios, Vault para la gestión de secretos y Terraform para la infraestructura como código. Para empresas que ya utilizan herramientas de HashiCorp, Nomad es la opción más natural.
Su limitación: su ecosistema es más pequeño que el de Kubernetes. Hay menos integraciones de terceros, menos soporte comunitario y menos ingenieros con experiencia en Nomad disponibles en el mercado laboral.
Servicios gestionados: ningún clúster, ningún problema
AWS ECS (Elastic Container Service) es el orquestador de contenedores propio de Amazon – totalmente integrado en el ecosistema de AWS y más sencillo de usar que EKS (Kubernetes en AWS). Con Fargate como backend de cómputo, incluso la gestión del clúster desaparece por completo: basta con definir tareas y servicios; AWS se encarga de toda la infraestructura.
Google Cloud Run va un paso más allá: despliegue de contenedores con un solo clic, escalado automático (incluido escalado a cero) y facturación por solicitud (pay-per-request). Para cargas de trabajo basadas en HTTP sin necesidad de comunicaciones complejas entre servicios, Cloud Run es la opción más sencilla disponible en el mercado.
Azure Container Apps se posiciona de forma similar a Cloud Run: contenedores sin servidor (serverless), con escalado automático basado en KEDA e integración con Dapr para patrones de microservicios.
Matriz de decisión: qué herramienta conviene en cada contexto
Kubernetes cuando: más de 50 servicios, requisito de multi-nube, equipo de plataforma grande, redes complejas o necesidad de controladores personalizados.
Docker Swarm cuando: equipo pequeño (< 5 desarrolladores), menos de 20 servicios, necesidad de una puesta en marcha rápida, entorno on-premise y ausencia de experiencia en Kubernetes.
Nomad cuando: cargas de trabajo heterogéneas (contenedores + máquinas virtuales + trabajos por lotes), uso previo del stack de HashiCorp y necesidad de simplicidad sin renunciar a capacidades empresariales.
ECS/Cloud Run cuando: preferencia por AWS/GCP, equipo centrado en el código más que en la infraestructura, servicios basados en HTTP y sin necesidad de multi-nube.
Preguntas frecuentes
¿Está muerto Docker Swarm?
No está muerto, pero sí 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.
¿Es posible migrar de Docker Swarm a Kubernetes?
Sí, y es más sencillo que migrar desde entornos basados en máquinas virtuales. Las imágenes de contenedor son idénticas. Los archivos Docker Compose se pueden convertir fácilmente en manifiestos de Kubernetes mediante la herramienta kompose. La migración afecta principalmente a la configuración de redes, almacenamiento y despliegues.
¿Es ECS más económico que EKS?
ECS en sí mismo es gratuito: solo se paga por los recursos de cómputo (EC2 o Fargate). EKS tiene una tarifa fija por clúster de 0,10 USD/hora (~73 USD/mes), además de los costes de cómputo. Para entornos pequeños, ECS resulta más económico. En entornos mayores, esta diferencia pierde relevancia.
¿Por qué no todos usan Google Cloud Run?
Cloud Run es ideal para cargas de trabajo basadas en solicitudes (APIs, sitios web). Para cargas de trabajo con conexiones persistentes (WebSockets, streaming), malla de servicios compleja o requisitos específicos de red, Kubernetes sigue siendo la mejor opción. Cloud Run abstrae demasiado para estos escenarios.
¿Necesitamos realmente orquestación de contenedores?
No necesariamente. Para un puñado de servicios, suele bastar un servidor sencillo con Docker Compose y un proxy inverso. La orquestación de contenedores gana relevancia a partir de unos 10 servicios, especialmente cuando se requieren despliegues progresivos, escalado automático y descubrimiento de servicios.
Fuente de imagen: Pexels / Jan van der Wolf
