Dejémonos de tonterías. Docker fue el icono de DevOps durante casi una década.

Pero las cosas han cambiado. Rápido. Si todavía estás tratando a Docker como tu martillo de oro en 2025, es hora de un chequeo de la realidad.

Esto no es un artículo de odio. Se trata de un desglose práctico de por qué Docker se está retirando silenciosamente, y lo que los equipos de infraestructura modernos están haciendo en su lugar.

Lo que Docker hizo bien


Docker cambió nuestra forma de concebir la infraestructura. En lugar de máquinas virtuales, teníamos contenedores ligeros. Portátiles, repetibles y rapidísimos (por aquel entonces).

En 2013-2018:

  • Los desarrolladores podían "Dockerizar" una aplicación y enviarla.
  • Los procesos CI/CD se simplificaron.
  • Kubernetes adoptó Docker como su tiempo de ejecución de contenedores por defecto.
  • Todo el mundo y su perro hicieron un Dockerfile.
  • Todo iba bien. Hasta que dejó de serlo.

¿Qué ha fallado?

El demonio Docker Problema


Docker se basa en un único proceso de larga duración: el demonio Docker. Esto significa:

  • Es un único punto de fallo.
  • Se ejecuta como root, lo que plantea problemas de seguridad.
  • ¿Depurar el demonio? Buena suerte. Si lo matas, matas todo.
  • Alternativas como containerd no necesitan este demonio central. Son más pequeños, más rápidos y no necesitan el modo Dios para funcionar.
# Traditional Docker run
docker run nginx

# With containerd
ctr run --rm docker.io/library/nginx:latest nginx /bin/sh

Docker Desktop Paywall


Docker hizo el peor movimiento de su ciclo de vida: cobrar a los desarrolladores por Docker Desktop en entornos empresariales.

Los equipos empezaron a buscar alternativas como Podman, Rancher Desktop y Colima.
A los desarrolladores no les gustan las sorpresas en su cadena de herramientas. Esta fue una.

Kubernetes abandonó Docker


Seamos claros: Kubernetes no abandonó los contenedores. Abandonó Docker como tiempo de ejecución.

En su lugar, se trasladó a containerd y CRI-O.

Diagrama UML: Ciclo de vida del contenedor en Kubernetes (antes y después de la eliminación de Docker)

K8s prefiere los tiempos de ejecución que implementan CRI (Container Runtime Interface) de forma nativa. Docker no lo hace. Eso añadió capas de calce innecesarias.

Podman > Docker (para la mayoría de los casos de uso)


Podman es básicamente un sustituto directo de Docker.

Pero mejor:

  • Daemonless
  • Rootless
  • Totalmente compatible con los comandos de Docker.
# Docker
docker build -t my-app .

# Podman (same)
podman build -t my-app .

¿Y lo mejor? Puedes ponerle un alias:

alias docker=podman

La mayoría de los desarrolladores ni siquiera notarían la diferencia. Excepto por el hecho de que Podman es más rápido y más seguro.

Entonces, ¿qué deberías usar?

  • Para desarrollo local, usa Podman, Colima o NerdCTL. Son ligeros, rápidos y no requieren Docker Desktop.
  • Para CI/CD pipelines, usa containerd. Es más eficiente, se integra mejor con Kubernetes y no depende de un demonio.
  • Para el tiempo de ejecución de Kubernetes, prefiera CRI-O o containerd. Ambos son nativos de Kubernetes y no requieren shims adicionales.
  • Para los usuarios de escritorio, herramientas como Rancher Desktop (si quieres una GUI) o Podman (para la gente de terminal) son excelentes alternativas.

¿Pero DockerHub?


Sí, DockerHub sigue siendo relevante para el alojamiento de imágenes. Todavía se puede utilizar sin Docker la herramienta. Herramientas como skopeo o ctr pueden tirar de DockerHub.

skopeo copy docker://nginx:latest dir:/tmp/nginx

Historia real de migración


Estábamos ejecutando un grupo de microservicios con Docker y Docker Compose para el desarrollo local. Entonces nos encontramos con:

  • Entornos de desarrollo inconsistentes
  • CI builds timing out due to Docker caching issues
  • Docker Desktop licensing issues

Qué hicimos:

  • Reemplazamos Docker Compose con podman-compos
  • Usamos nerdctl + containerd en CI
  • Cambiamos a Rancher Desktop para los miembros del equipo que necesitaban GUI

¿Resultado?

  • Las compilaciones de CI fueron un 30% más rápidas
  • Sin problemas de licencias
  • El equipo se incorporó a Podman sin ningún tipo de fricción

Conclusión


Docker no está muerto. Simplemente... ya no es esencial.

Como jQuery - resolvió un problema que ahora se resuelve mejor con otras herramientas.

Si estás construyendo algo en 2025 y todavía utilizas Docker por defecto, pregúntate a ti mismo:

¿Esta herramienta me está ayudando, o simplemente la estoy usando porque siempre lo hice?

Fuente