Docker y las máquinas virtuales aíslan aplicaciones de maneras distintas. Un contenedor empaqueta la aplicación y sus dependencias sobre el kernel del sistema anfitrión; una máquina virtual incluye un sistema operativo invitado gestionado por un hipervisor.
La elección depende de la frontera de aislamiento, la portabilidad y la operación que necesite el proyecto.
Qué contiene un contenedor
Una imagen define capas de archivos y metadatos que el runtime utiliza para crear un contenedor. El proceso puede iniciarse rápido y consumir menos memoria que un sistema operativo completo, pero comparte el kernel del host. Los volúmenes y bases de datos deben tratarse aparte si los contenedores son reemplazables.
Un contenedor recreado desde una imagen no debería depender de cambios manuales hechos dentro de la instancia. La configuración y los secretos deben gestionarse de forma explícita.
Qué aporta una máquina virtual
La VM ofrece un sistema operativo invitado con su propio kernel y una frontera más amplia respecto al host. Permite ejecutar distribuciones distintas y separar ciclos de actualización, a cambio de más consumo de almacenamiento, memoria y tiempo de arranque.
El aislamiento no es absoluto en ningún modelo: un fallo del hipervisor, del kernel o una mala configuración puede afectar al conjunto. La seguridad debe incluir actualizaciones y permisos.
Red, almacenamiento y despliegue
Los contenedores requieren redes virtuales, publicación de puertos y volúmenes persistentes. Las VMs necesitan discos virtuales, interfaces y mantenimiento del sistema invitado. En ambos casos, una aplicación con estado necesita copias y un procedimiento de recuperación.
Un ejemplo: un contenedor de aplicación puede sustituirse después de un despliegue, pero la base de datos debe seguir en un volumen o servicio con una política independiente.
Portabilidad con límites
Una imagen Docker facilita repetir una versión, pero no elimina diferencias de kernel, arquitectura, red o almacenamiento entre entornos. Una VM también puede moverse, aunque el tamaño de sus discos y la licencia del sistema condicionen el proceso.
Cuándo elegir cada frontera
Los contenedores encajan bien en servicios que se despliegan de forma repetible y tienen dependencias controladas. Las VMs son útiles cuando se necesita un sistema operativo completo, una separación más amplia o software que no se adapta al modelo de contenedor.
No son alternativas absolutas: es frecuente ejecutar contenedores dentro de una VM para separar la plataforma y la carga. La decisión debe considerar operación, copias, registros y conocimientos del equipo.
Persistencia y ciclo de vida
El sistema de archivos de un contenedor suele tratarse como reemplazable. Los datos que deben sobrevivir a un despliegue se colocan en volúmenes o servicios externos y se incluyen en las copias. Una VM puede contener más estado local, pero también necesita una política de copia y restauración.
Seguridad de la frontera
Compartir kernel reduce consumo, pero hace importante mantener actualizado el host y controlar capacidades, usuarios, imágenes y puertos. Una imagen de origen desconocido puede introducir código no revisado. Firmas, inventario y escaneo ayudan, aunque no sustituyen una revisión de la aplicación.
Operación diaria
Docker facilita empaquetar versiones, pero requiere gestionar registros de imágenes, redes, secretos, logs y límites de CPU y memoria. Las máquinas virtuales requieren parches del sistema invitado, agentes, discos y acceso de administración. En ambos modelos, la sencillez inicial no elimina la responsabilidad operativa.
Imágenes, versiones y reproducibilidad
Una imagen debe poder reconstruirse desde una definición y dependencias conocidas. Etiquetar solo como latest dificulta saber qué código se ejecutaba cuando ocurrió un error. Conserva versiones y registra cambios antes de desplegar.
En una VM, el equivalente es mantener una imagen base actualizada y documentar paquetes y configuración. La repetibilidad no depende exclusivamente del formato elegido.
Red y exposición
Publicar un puerto del contenedor lo hace accesible a través del host, pero no convierte el servicio en seguro. Limita interfaces, separa redes y no incluyas secretos en la imagen. En una VM aplica el mismo principio a interfaces, servicios y reglas del sistema.
Decidir por responsabilidad operativa
El equipo debe poder corregir imágenes, revisar vulnerabilidades, recuperar volúmenes y entender los logs. Si no puede mantener el runtime de contenedores, una VM sencilla puede ser más previsible. Si necesita despliegues repetibles de varios servicios, el empaquetado puede compensar su complejidad.
Pruebas y recuperación
Prueba reconstruir el contenedor desde la imagen y restaurar sus volúmenes. En una VM prueba también el arranque, los discos y la red después de recuperar una copia. El tiempo de recuperación depende de los datos y de la configuración, no solo del formato de empaquetado.
Documenta qué artefactos se necesitan para volver a poner el servicio en funcionamiento.
El entorno no termina en el proceso
Incluye en el diseño los logs, métricas, certificados, redes, volúmenes y secretos. Un contenedor puede estar sano y la aplicación fallar porque no alcanza la base de datos o porque el volumen se ha llenado.
Las VMs requieren una revisión equivalente del sistema invitado y de sus agentes. En ambos modelos, define qué se observa y qué acción se toma ante una alerta.
La frontera elegida debe ser comprensible para quien mantenga el sistema después del despliegue. La portabilidad no compensa una operación que no puede actualizarse, observarse y recuperarse.
Antes de elegir, enumera qué parte del estado debe persistir, qué versión debe repetirse y qué permisos necesita el proceso. Esa lista permite decidir si conviene una imagen ligera, una VM completa o una combinación de ambas.