¿Está perdiendo Docker su ventaja?
En su día, Docker fue el icono de DevOps. Se asoció con la portabilidad, la repetibilidad y la agilidad del desarrollador y trajo al mundo la contenedorización contemporánea. Decir «Docker» fue esencialmente lo mismo durante mucho tiempo que decir «contenedores». Revolucionó fundamentalmente la forma de desarrollar, probar e implementar el software.
Pero la ecología de los contenedores no será un concurso de un solo caballo en 2025. Aunque Docker sigue siendo algo popular, un número creciente de empresas y desarrolladores lo están sustituyendo por soluciones más ligeras, modulares y nativas de Kubernetes. El debate se centra ahora en qué tiempo de ejecución liderará el próximo capítulo de la innovación en contenedores, no en si los contenedores han llegado para quedarse.
¿Está muriendo Docker? No del todo. En las áreas que más cuentan hoy en día -rendimiento, seguridad, adaptabilidad y coste- está siendo superado.
Investiguemos las fuerzas que están detrás de este cambio.
El problema con Docker en el panorama actual:
Cambios en las licencias y el coste de Docker Desktop:
La elección de Docker de posicionar Docker Desktop detrás de una membresía pagada para organizaciones más grandes fue uno de los puntos de inflexión más obvios.
Mientras que las personas y los pequeños proyectos podían seguir utilizándolo libremente, las empresas descubrieron que tenían que pagar por algo que antes era gratuito, y no siempre mejor que las nuevas opciones.
Esta acción no sólo me enfureció , sino que también permitió a los desarrolladores examinar más de cerca su dependencia de Docker.
Los defensores del código abierto y los equipos preocupados por los costes empezaron a preguntarse si el valor de Docker justificaba el desembolso adicional.
Problemas de rendimiento, especialmente con Windows y macOS
Docker funciona bastante bien en Linux. Sin embargo, Docker Desktop ha sido durante mucho tiempo una molestia para los usuarios de macOS y Windows.
Especialmente durante compilaciones pesadas u orquestación de múltiples contenedores, emula contenedores Linux utilizando máquinas virtuales, lo que resulta en un rendimiento lento, consumo excesivo de CPU y agotamiento de la batería.
Por el contrario, las nuevas soluciones como Lima utilizadas bajo el capó por Finch ofrecen una virtualización más eficaz personalizada para los desarrolladores, mejorando así el rendimiento sin la complejidad y la hinchazón de Docker Desktop.
Riesgo de seguridad: el problema del demonio raíz
La dependencia de Docker de un demonio raíz es una de las opciones arquitectónicas por las que más se le critica. Este servicio central controla los contenedores y exige privilegios superiores, por lo que aumenta la posible superficie de ataque en entornos de fabricación.
Aunque Docker ha evolucionado con el tiempo con características como los espacios de nombres de usuario y el modo sin raíz, las organizaciones preocupadas por la seguridad suelen querer alternativas creadas desde la base con la seguridad en mente, como Podman, que funciona totalmente sin un demonio y puede funcionar como un usuario no raíz.
Un enfoque monolítico en un mundo modular:
El ecosistema de Docker se expandió rápidamente. Para la orquestación multicontenedor, Swarm para la agrupación en clústeres y Docker Hub para los registros, todos estrechamente acoplados. Esta estrategia «todo en uno» fue lo primero que hizo interesante a Docker.
Pero el mundo de las tecnologías nativas de la nube ha evolucionado, y la tendencia es hacia herramientas un tanto vinculadas y especializadas. Hoy en día, Kubernetes gobierna la orquestación por completo.
Helm se ocupa del empaquetado. Container funciona como Containerd, concentrándose sólo en la gestión de contenedores.
El amplio pero opinable conjunto de herramientas de Docker parece más constrictivo en este terreno que beneficioso.
Miedo al bloqueo del proveedor
Los desarrolladores son finalmente cautelosos a la hora de profundizar demasiado en las herramientas privadas de Docker. Aunque generalmente se acepta, incluso la sintaxis de Dockerfile no está controlada por un estándar abierto como los requisitos de imagen y tiempo de ejecución de OCI.
Especialmente cuando los estándares abiertos prometen más flexibilidad y estabilidad a largo plazo, los desarrolladores prefieren evitar verse limitados a una única cadena de herramientas.
Tiempos de ejecución de contenedores alternativos
Varios tiempos de ejecución de contenedores se han hecho bastante populares, ya que Docker no es el único disponible hoy en día. La seguridad, la modularidad, el rendimiento y la apertura definen cada uno de ellos para determinados casos de uso y reflejan los valores del mundo de los contenedores nativos de hoy en día.
Podman: un sustituto seguro y sin demonio:
Creado originalmente por Red Hat, Podman se ha convertido rápidamente en una opción líder para los administradores de sistemas y desarrolladores, dando prioridad a la seguridad y el cumplimiento.
Podman, a diferencia de Docker, no depende de un demonio central. En lugar de ello, hace que sea naturalmente más seguro y sencillo hacer sandboxing utilizando un modelo fork/exec.
Podman también aboga por los contenedores sin raíz, que permiten a los usuarios operar contenedores sin derechos mejorados. Dado que su CLI es casi exactamente igual a la de Docker, los equipos que busquen un sustituto más seguro sin reescribir los procesos encontrarán fácil el cambio.
Containerd: La elección nativa de Kubernetes
Originalmente fundamental para Docker, containerd se ramificó y ayudó a la Cloud Native Computing Foundation (CNCF). Tras la eliminación del soporte de Docker en Kubernetes 1.24, las distribuciones de Kubernetes utilizan ahora este tiempo de ejecución de contenedores por defecto.
Containerd es producible, ligero y ampliable. Realiza una sola función -gestionar los ciclos de vida de los contenedores- y sobresale. Bajo el capó, los proveedores de la nube, incluidos AWS (EKS), Google Cloud (GKE) y Azure (AKS) confían en containerd como solución fiable y escalable para entornos gestionados.
CRI-O: Diseñado para Kubernetes:
Otro tiempo de ejecución alojado en el CNCF y diseñado especialmente para Kubernetes es CRI-O. Siguiendo estrictamente la Container Runtime Interface (CRI), mantiene un entorno de ejecución ligero y específico.
Aunque se trata de una característica más que de un defecto, no admite cargas de trabajo que no sean Kubernetes.
CRI-O simplifica la seguridad eliminando elementos superfluos y concentrándose únicamente en Kubernetes. El tiempo de ejecución predeterminado de Red Hat OpenShift está aquí, y los equipos que enfatizan el minimalismo y el cumplimiento están comenzando a usarlo.
Lima y Finch: Experiencias superiores en macOS
Los problemas de rendimiento de Docker Desktop en macOS produjeron un vacío que tecnologías como Lima y Finch están cubriendo. Lima desarrolla máquinas virtuales Linux para macOS adaptadas para la construcción de contenedores en macOS.
Basado en Lima y nerdctl, una CLI compatible con Docker, Finch, un proyecto respaldado por AWS, ofrece un sustituto impecable y de alto rendimiento para Docker Desktop, libre de restricciones de licencia.
Finch se está convirtiendo rápidamente en la alternativa preferida para los desarrolladores de macOS que buscan una experiencia nativa con herramientas contemporáneas.
Otros datos destacables:
- Diseñado para desarrolladores que desean utilizar sintaxis conocida con un tiempo de ejecución moderno, nerdctl ofrece comandos compatibles con Docker sobre containerd.
- Perfecta para las canalizaciones CI/CD, Buildah es una herramienta para crear imágenes compatibles con OCI sin necesidad de demonio.
- Creada por AWS, la tecnología microVM se utiliza en Lambda y Fargate. Diseñada para sistemas multiinquilino y cargas de trabajo sin servidor, es increíblemente ligera y muy segura.
Qué significa esto para los desarrolladores y los equipos DevOps:
La aparición de sustitutos no significa que debas abandonar Docker ahora mismo. Significa, sin embargo, que los desarrolladores deben reconsiderar dónde encaja Docker y dónde no.
Docker sigue siendo valioso para el desarrollo. Su ecosistema, conjunto de herramientas y documentación son avanzados. Para la definición y ejecución local de configuraciones multicontenedor, Docker Compose sigue siendo un gran instrumento.
Pero en entornos de producción -especialmente los que emplean Kubernetes- Docker puede no ser la opción ideal. En la actualidad, Kubernetes prefiere tiempos de ejecución como containerd y CRI-O.
El funcionamiento sin raíz a través de Podman ayuda a los entornos preocupados por la seguridad. Especialmente en macOS, las plataformas sensibles al rendimiento se están decantando por otros sistemas.
Además, la modularización del panorama de los contenedores permite a los equipos elegir las mejores soluciones de su clase para cada trabajo en lugar de depender únicamente de una solución de clase completa.
¿Deberá seguir utilizando Docker en 2025?
Depende:
Utilice Docker si:
- Quieres una interfaz rápida y sencilla y estás construyendo y probando localmente.
- Su personal depende principalmente de Docker Compose y de enfoques tradicionales.
- Está ejecutando programas sencillos sin coordinación.
Piensa en sustitutos si:
- Está utilizando clústeres Kubernetes; un mejor ajuste es containerd o CRI-O.
- Especialmente en entornos multi-tenant o regulados, necesita una seguridad reforzada.
- Desea optar por herramientas abiertas en lugar del enfoque de licencias de Docker.
- Usted está maximizando para las pipes de CI o el rendimiento de macOS.
Otra estrategia híbrida popular es depender de containerd o Podman en entornos de CI/CD y producción mientras se desarrolla localmente con Docker.
El futuro de la contenedorización:
Docker está cambiando, no desapareciendo. El cambiante mundo de los contenedores se orienta hacia estándares abiertos, tiempos de ejecución ligeros e ideas nativas de la nube. Aunque ya no es el centro del universo de los contenedores, Docker puede seguir siendo importante.
Lo que estamos viendo es que el ecosistema que Docker ayudó a hacer crecer está madurando en lugar de su desaparición. Más opciones ahora disponibles para los desarrolladores son un beneficio.
Los ganadores en este nuevo terreno serán herramientas suficientemente modulares que se adapten a cualquier flujo de trabajo, abiertas por diseño y seguras por defecto.
Docker dejó el camino despejado. Pero una gama más amplia de actores -cada uno avanzando en la contenedorización al siguiente nivel- está ayudando a definir el camino a seguir.
En cuanto a usted.
¿Te has alejado de Docker? ¿Usas Podman, containerd, o cualquier otra cosa? ¿Cómo ha sido tu experiencia?
Acompáñanos en la discusión. El futuro del desarrollo de contenedores se está escribiendo ahora mismo; desarrolladores como tú están sosteniendo la pluma.