Docker Swarm en 2023: cuando sigue teniendo sentido

javi
Enjambre de abejas representando coordinación de servicios

La narrativa popular dice que Kubernetes ganó y Docker Swarm está muerto. La realidad es más matizada. Swarm sigue siendo mantenido (forma parte de Docker Engine), funciona perfectamente en producción, y para una franja específica de casos sigue siendo la opción correcta — no una opción legacy. Cubrimos cuándo Swarm sigue teniendo sentido, qué cuesta menos, y qué limitaciones aceptas a cambio.

El estado real en 2023

Algunos hechos sobre el estado actual:

  • Swarm está integrado en Docker Engine — no es un proyecto aparte que pueda ser abandonado independientemente.
  • Recibe mantenimiento regular aunque sin features llamativas nuevas.
  • Mirantis adquirió Docker Enterprise en 2019 y mantiene la tecnología — no es huérfano.
  • Adopción establecida en pequeñas y medianas organizaciones que no necesitan la complejidad de Kubernetes.

Lo que NO es en 2023:

  • No es lo más cool ni lo que verás en charlas de DevOps.
  • No tiene el ecosistema de operators y herramientas de Kubernetes.
  • No es una opción para grandes hyperscale.

Cuándo Swarm es la mejor opción

Hay casos concretos donde Swarm gana sin discusión:

Equipos pequeños sin SRE dedicado

Si tu equipo de desarrollo es de 5-15 personas y no tienes SRE/ops dedicados, Swarm cuesta significativamente menos operar que Kubernetes:

  • Setup en minutos vs días.
  • Conceptos limitados (services, stacks, secrets, configs, networks). No CRDs, no operators, no Helm.
  • docker stack deploy -c stack.yml mi-app y listo.
  • Curva aprendizaje compatible con saber Docker Compose.

Para una organización de 30-50 personas total con 3-10 servicios, Swarm puede deliver el 95% del valor con 20% del coste operativo.

Self-hosted en VPS

Para servicios que se hospedan en VPSs propios (1-5 nodos), Swarm es la herramienta natural. Kubernetes en este tamaño es over-engineering — la mayoría de su valor está en escala que no tienes.

Despliegues típicos:

  • Sitios web propios y de clientes en pocos VPS.
  • Stacks self-hosted (Nextcloud, Mailcow, Gitea).
  • Mini-empresas con su propia infra.

Migración suave desde Docker Compose

Si ya usas Compose en producción (síntoma común en pequeñas empresas), Swarm es el siguiente paso natural. Tus archivos docker-compose.yml funcionan casi sin cambios — solo añades el campo deploy: con replicas, resources, y placement.

Migrar a Kubernetes desde Compose requiere reescribir manifests, aprender concepts nuevos, configurar muchas piezas. Swarm es continuidad.

Edge computing en mini-clusters

Para clusters de 3-10 nodos en edge (oficinas remotas, fábricas, ubicaciones geográficamente distribuidas), Swarm es ligero, simple y suficiente. Kubernetes en edge requiere distribuciones especializadas (k3s, microk8s) que añaden complejidad propia.

Cuándo Kubernetes es claramente mejor

Honestidad: Swarm no escala a todos los casos. K8s gana cuando:

  • Necesitas operators avanzados. PostgreSQL HA, Cassandra, Kafka clusters — Kubernetes tiene operators maduros, Swarm no.
  • Multi-tenancy fuerte con namespaces. Swarm no tiene equivalente real de namespaces.
  • Autoscaling sofisticado. HPA/VPA, autoscalers basados en métricas custom — Swarm tiene scaling manual o muy básico.
  • Service mesh, ingress controllers, GitOps maduro. Todo el ecosistema CNCF está alineado con K8s.
  • Hire-ability. En 2023 mucha más gente sabe Kubernetes que Swarm.
  • Multi-cluster cross-region. K8s con federación o herramientas; Swarm es single-cluster.

Para una organización con 20+ servicios, equipos múltiples y necesidades enterprise, K8s es la elección correcta.

Lo que aceptas con Swarm

Si eliges Swarm, asumes algunas limitaciones:

  • Ecosistema limitado. Helm, ArgoCD, Backstage — todo eso es Kubernetes-only.
  • Networking más simple (overlay basado en VXLAN). Funciona pero no es CNI con plugins.
  • Sin RBAC granular comparable al de K8s. Roles más limitados.
  • Documentación y tutoriales menores. Cualquier problema “moderno” tiene 100 respuestas en K8s, 5 en Swarm.
  • Sin features modernas como sidecar pattern formal. Puedes hacerlo pero menos idiomático.

Para casos donde estas limitaciones no son problema, son trade-offs aceptables.

Stack típico Swarm en producción

Una arquitectura que veo funcionar bien en proyectos reales:

Cluster Swarm (1 manager + 2 workers, o 3 managers en HA)
   │
   ├── Traefik como proxy/ingress (con Let's Encrypt automático)
   ├── PostgreSQL/MariaDB como service de Swarm con volume bind
   ├── Apps en stacks separados (cada cliente o dominio = stack)
   ├── Portainer como UI de gestión
   ├── Prometheus + Grafana + Loki para observabilidad
   ├── Watchtower para auto-update (en monitor mode)
   └── Backups con restic a object storage externo

Es operable por una persona. Es razonable de monitorizar. Cubre la inmensa mayoría de necesidades de hosting compartido propio.

Comandos esenciales

Para alguien viniendo de Compose, los conceptos clave:

# Inicializar Swarm
docker swarm init --advertise-addr <ip>

# Añadir worker
docker swarm join --token <token> <manager-ip>:2377

# Listar nodos
docker node ls

# Desplegar stack
docker stack deploy -c stack.yml mi-app

# Listar stacks y servicios
docker stack ls
docker service ls

# Logs de un servicio
docker service logs mi-app_web -f

# Escalar
docker service scale mi-app_web=3

# Update con rolling
docker service update --image nginx:1.25 mi-app_web

# Quitar stack
docker stack rm mi-app

Si sabes Compose, ya tienes 70% de Swarm.

Conclusión

Docker Swarm está vivo en 2023 y sigue siendo la elección correcta para casos donde Kubernetes es over-engineering. Equipos pequeños, self-hosted, mini-clusters edge — todos casos donde la simplicidad y bajo coste operativo de Swarm valen más que las features avanzadas de K8s. El estigma “Swarm está muerto” es exagerado: para el caso correcto, sigue siendo la herramienta adecuada. La pregunta importante es honesto: ¿necesitas K8s o necesitas algo simple que orqueste contenedores?

Síguenos en jacar.es para más sobre orquestación, self-hosting y arquitecturas pragmáticas.

Entradas relacionadas