Docker vs máquina virtual

Una máquina virtual virtualiza el hardware completo: un hipervisor (VMware, KVM, Hyper-V) simula una CPU, memoria, disco y red virtuales sobre los que se instala un sistema operativo invitado completo, con su propio kernel, totalmente independiente del sistema anfitrión. Esto da un aislamiento muy fuerte —dos VMs no comparten prácticamente nada— a costa de más consumo de recursos y tiempos de arranque de minutos.

Docker (y los contenedores en general) toman un enfoque distinto: en lugar de virtualizar hardware, aíslan procesos dentro del mismo kernel del sistema operativo anfitrión, usando funcionalidades del propio kernel Linux (namespaces para aislar vista de procesos/red/filesystem, cgroups para limitar recursos). El resultado es que un contenedor arranca en segundos, pesa órdenes de magnitud menos que una VM, y se pueden ejecutar muchos más contenedores que VMs en el mismo servidor físico.

La contrapartida es el aislamiento: al compartir el kernel del host, una vulnerabilidad grave del kernel podría en teoría afectar a todos los contenedores que corren sobre él, algo que no ocurre entre VMs distintas. Por eso en entornos multi-tenant muy sensibles a veces se combinan ambas técnicas: VMs para el aislamiento fuerte entre clientes, y contenedores dentro de cada VM para la densidad y velocidad de despliegue.

Para el desarrollo y despliegue de aplicaciones modernas, Docker (y su orquestación con Kubernetes) se ha convertido en el estándar de facto: empaquetar una aplicación con todas sus dependencias en una imagen reproducible, desplegable igual en el portátil del desarrollador que en producción, resuelve el clásico problema de "en mi máquina funciona". Las máquinas virtuales siguen siendo imprescindibles para aislar cargas de trabajo completas, ejecutar sistemas operativos distintos al del host, o cuando se necesita el aislamiento más fuerte posible.