Docker vs máquinas virtuales: diferencias de rendimiento y guía de elección en 5 minutos

En una reunión de equipo, el jefe preguntó: «¿El nuevo proyecto va con Docker o con máquinas virtuales?». Había usado ambos, pero explicar la diferencia con claridad no era tan fácil. De vuelta al escritorio, busqué información y vi artículos demasiado teóricos o que se quedaban en «Docker es más ligero» — pero ¿ligero en qué sentido? ¿Cuánto cambia el rendimiento? ¿En qué escenario conviene cada uno? No lo aclaraban.

Me llevó tres días entenderlo bien. Hoy te lo explico de la forma más simple para que quede clara la diferencia entre Docker y las máquinas virtuales. Al terminar sabrás: la diferencia esencial (con una analogía muy clara), cuánto cambia el rendimiento (con datos reales) y un árbol de decisión para elegir la tecnología adecuada.

Diferencia esencial: contenedor vs habitación independiente

Empecemos con la analogía más fácil de entender.

Una máquina virtual es como un apartamento independiente en un edificio. Cada apartamento tiene su cocina, baño y sistema eléctrico: es una unidad completa. Vives en el segundo piso, tu vecino en el tercero, y no os molestáis. Cada VM ejecuta un sistema operativo completo (Windows, Linux, etc.) con su propio kernel, controladores y servicios: todo el paquete.

Un contenedor Docker es como un contenedor en un puerto. Todos comparten la infraestructura del puerto: grúas, electricidad, carreteras. Dentro solo va la aplicación y sus dependencias; no hace falta que cada caja tenga su propia infraestructura. Los contenedores Docker comparten el kernel del SO del host y empaquetan solo la aplicación y su entorno de ejecución.

La diferencia parece pequeña, pero el impacto es total.

En arquitectura, la VM lleva dos capas extra: Guest OS (sistema operativo invitado) y Hypervisor (capa de virtualización). El hypervisor simula todo el hardware — CPU, memoria, disco, red — y al arrancar cada VM primero arranca ese SO completo: carga el kernel, inicia servicios, como reiniciar un ordenador.

Docker, en cambio, corre directamente sobre el kernel del host. Arrancar un contenedor es arrancar un proceso: se abre al instante. Sin overhead de virtualizar hardware ni capa extra de SO: muy ligero.

Quizá te preguntes: ¿compartir kernel no es un problema? Más adelante verás que es precisamente el punto débil de Docker — el aislamiento no es tan fuerte como en una VM. Pero también es su ventaja: rápido, ligero y eficiente en recursos.

Con esta diferencia esencial, la comparación de rendimiento y los escenarios de uso encajan solos.

Duelo de rendimiento: los datos hablan

La teoría sola no basta; veamos números.

Velocidad de arranque: segundos vs minutos

La semana pasada probé arrancar una VM configurada (2 núcleos, 4 GB): desde el encendido hasta poder hacer SSH tardó casi 4 minutos. Me dio tiempo a preparar un café y mirar el móvil.

El mismo servicio Redis con Docker: 3 segundos.

Ni siquiera tuve que soltar el ratón.

No es casual. La VM debe cargar un SO completo: inicializar el kernel, arrancar servicios, configurar la red. Docker arranca un proceso; el kernel ya está en marcha y listo para trabajar.

Uso de recursos: MB vs GB

Lo más llamativo es el consumo. ¿El overhead de Docker? 6-8 MB de memoria. Sí, unidades de MB.

Probé un contenedor Redis: CPU 0,08 %, memoria 2,6 MB. Casi imperceptible.

La VM, aunque no ejecute nada, solo el SO ya consume 1-2 GB de memoria. Una VM con MySQL: 4 GB como mínimo.

Eso lleva a una realidad dura: en el mismo servidor físico, con VM quizá llegas a unas decenas; con Docker, a miles. Vi un entorno de producción real: un servidor de 32 núcleos y 128 GB con más de 800 contenedores Docker sin estrés. Con VM, 30 ya es mucho.

Pérdida de rendimiento: casi nativo vs perceptible

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Hay estudios que comparan ambos enfoques: el rendimiento de contenedores Docker en casi todos los escenarios iguala al de aplicaciones nativas; en algunos casos es incluso mejor (sin overhead de virtualización). Las VM suelen perder un 10-20 %.

En tareas intensivas de CPU se nota más. Compilé un proyecto grande: en VM 25 minutos, en contenedor 21, en máquina física 20. El contenedor casi no pierde rendimiento.

Una tabla para verlo de un vistazo:

Con esta tabla entiendes por qué la arquitectura de microservicios migra a Docker: la utilización de recursos puede diferir un orden de magnitud.

Aislamiento y seguridad: no siempre más es mejor

Tras las ventajas de rendimiento, toca el punto débil de Docker.

Diferencia en el nivel de aislamiento

La VM aísla a nivel de hardware. Cada una tiene su propio kernel de SO, como dos ordenadores separados. Si hackean la VM A, en teoría el atacante no salta a la VM B ni al host. Eso es «hard isolation».

Docker aísla a nivel de proceso. Todos los contenedores comparten el kernel del host; solo separan recursos con namespace y cgroups de Linux. Suena menos seguro, ¿verdad?

Y en la práctica también. El «container escape» ataca precisamente esa debilidad: si encuentran una vulnerabilidad en el contenedor, pueden romper el aislamiento y atacar el host. El año pasado CVE-2024-21626 permitió escapar del contenedor al host.

¿Las VM tienen ese riesgo? Sí, pero es mucho más difícil de explotar.

¿En qué escenarios hay que usar VM?

No significa que Docker sea inseguro: depende de cuánto aislamiento necesites.

Si eres proveedor de servicios en la nube y cada cliente debe quedar totalmente aislado, usa VM. Alibaba Cloud, AWS y otros clouds públicos aíslan tenants con VM. No puedes dejar que el cliente A y el B compartan kernel: si A es atacado, B también corre riesgo.

Si eres una empresa financiera con compliance estricto (equivalente a niveles de protección altos), un auditor puede rechazar Docker por el kernel compartido — mejor VM.

Si ejecutas código no confiable, como en una plataforma de compilación online donde los usuarios envían código arbitrario, Docker es arriesgado; hace falta VM.

¿Cómo reforzar la seguridad en Docker?

En la mayoría de escenarios no es tan extremo. Microservicios internos con código propio: Docker basta. Con tres medidas básicas:

1. No ejecutar contenedores como root. Por defecto van con permisos root; si los comprometen, el impacto es mayor. Usa un usuario sin privilegios.
2. Limitar permisos del contenedor (Capabilities). No concedas capacidades del sistema que no necesite.
3. Escanear vulnerabilidades de imágenes con regularidad. Herramientas como Trivy; si hay fallos, actualiza la imagen base.

En nuestro equipo aplicamos estas tres medidas en todos los contenedores Docker; en dos años no tuvimos incidentes de seguridad.

En pocas palabras: la fuerza del aislamiento depende de tu modelo de amenazas. Docker basta para apps internas; VM para multi-tenant expuesto.

Escenarios de uso: el árbol de decisión

Después de todo esto, ¿cuándo usar cada uno? Un flujo de decisión directo.

4 escenarios donde Docker va primero

1. Arquitectura de microservicios

Si trabajas con microservicios, no lo dudes: Docker.

¿Por qué? Los microservicios dividen una app grande en decenas o cientos de servicios pequeños, cada uno desplegado por separado. Con VM, el servicio de usuarios ocupa una VM, el de pedidos otra, el de pagos otra… los recursos no aguantan.

Docker encaja perfecto: ligero, arranque en segundos, alta densidad. En una plataforma de e-commerce, usuarios, pedidos y pagos pueden ir cada uno en un contenedor, aislados y escalables en horizontal en minutos.

Participé en un proyecto con más de 30 microservicios containerizados en 5 servidores. Con VM, el costo de servidores se habría triplicado.

2. DevOps y pipelines CI/CD

Entornos de desarrollo, prueba y producción distintos: la pesadilla de todo desarrollador. «En mi máquina funciona» lo has oído mil veces.

Docker nació para eso. Empaqueta app y dependencias en una imagen: si corre en desarrollo, corre en pruebas y en producción. Mismo entorno.

También en CI/CD. Jenkins necesita un entorno limpio en cada build: levanta un contenedor, ejecuta tests, lo destruye. Todo en 20 segundos. Con VM, 5 minutos solo de arranque y limpieza manual: un fastidio.

3. Despliegue rápido y escalado elástico

Son las 23:00 y llega un pico de tráfico; necesitas 10 instancias más ya.

Docker: en segundos, 10 contenedores listos.
VM: espera; cada una tarda 5 minutos en arrancar, 10 son 50 minutos. Los usuarios ya se fueron.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Ahí está la ventaja de Docker: elasticidad. Kubernetes (K8s) escala contenedores según el tráfico, casi sin que lo notes. Una VM no llega a esa velocidad.

4. Entorno de desarrollo unificado

Equipo de 5 personas: uno con macOS, otro con Windows, otro con Ubuntu. Versiones distintas de MySQL, Node, etc. — «¿a ti te funciona?» cada día.

Docker con una imagen de entorno: todos hacen docker-compose up y tienen MySQL, Redis y Nginx con versiones fijadas. Sin más problemas de entorno.

4 escenarios donde la VM es obligatoria

1. Aplicación monolítica tradicional

Un ERP de hace 10 años: Java 6 + Oracle en CentOS 6. Cientos de miles de líneas de código; no se toca ni se atreve a tocarse.

No fuerces Docker. Déjalo en VM: estabilidad primero. Containerizar cuesta mucho y el riesgo es alto.

2. Necesidad de varios sistemas operativos

Debes ejecutar apps Windows y Linux a la vez: por ejemplo, .NET en Windows Server y servicios Java en Linux.

Docker no sirve: solo contenedores Linux (Windows containers existen, pero el soporte es pobre). Hacen falta VM: una Windows, otra Linux.

O un desarrollador en Mac que prueba software Windows: solo VMware o VirtualBox con una VM Windows.

3. Aislamiento fuerte

Proveedores cloud, plataformas SaaS multi-tenant: cada cliente totalmente aislado. Con VM, un cliente = una VM con kernel propio.

Finanzas, proyectos gubernamentales: compliance estricto; en auditoría hay que demostrar aislamiento fuerte. El kernel compartido de Docker puede no pasar.

4. Simular un entorno de SO completo

Desarrollo de drivers embebidos con kernel y hardware concretos, o trabajo de bajo nivel del sistema operativo.

Docker no vale: comparte el kernel del host. La VM simula hardware y kernel completos; instalas lo que necesites.

El enfoque mixto es lo habitual

La mayoría de empresas mezcla ambos.

En nuestra empresa:

• Sistema core de transacciones (5 años estable): VM
• Nuevas API gateway y microservicios: Docker + Kubernetes
• Entornos de desarrollo y prueba: todo Docker
• Pruebas de sistemas de oficina Windows: VMware

Así se mantiene la estabilidad del core y la agilidad de los contenedores.

Un árbol de decisión para elegir rápido

¿Tu aplicación es nueva?
├─ Sí → ¿Es arquitectura de microservicios?
│   ├─ Sí → Elige Docker ✅
│   └─ No → ¿Necesitas despliegues frecuentes?
│       ├─ Sí → Elige Docker ✅
│       └─ No → Decide según otros factores
└─ No (sistema heredado) → ¿Necesitas SO/kernel específico?
    ├─ Sí → Elige VM ✅
    └─ No → ¿Necesitas aislamiento fuerte?
        ├─ Sí → Elige VM ✅
        └─ No → Puedes intentar containerizar → Elige Docker ✅

Sigue este flujo y en general la decisión queda clara.

Casos reales: cómo eligen otros

La teoría no basta; veamos escenarios reales.

Caso 1: startup all-in Docker

La startup de un amigo, SaaS, 15 personas. Presupuesto ajustado: 3 ECS de Alibaba Cloud (4 núcleos, 8 GB) para más de una docena de servicios.

Con VM, 3 máquinas físicas como mucho 15 VM y se acabó la capacidad. Fueron directo a Docker + Kubernetes: 60+ contenedores en 3 máquinas, con margen.

El entorno de desarrollo también se unificó. Día uno del nuevo: clona el repo, docker-compose up, entorno listo en 5 minutos. Antes con VM, medio día configurando.

¿Cuánto ahorraron? Estiman que con VM necesitarían 10 servidores. Con 3 bastó: miles de dólares al año en infraestructura.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Para una startup, eso es dinero real.

Caso 2: transformación gradual en empresa tradicional

Una empresa manufacturera con ERP core de 15 años: SAP + Oracle en servidores IBM antiguos (VM). Intocable.

El año pasado quisieron digitalizar la cadena de suministro. El director de IT fue listo: ERP core sin tocar, nuevos negocios en microservicios Docker.

Arquitectura actual:

• ERP antiguo: VM, 5 servidores, estable como una roca
• Nueva cadena de suministro: Docker + K8s, 3 servidores, 70+ contenedores
• Integración vía API gateway

Estabilidad del core (cientos de personas dependen de él) y agilidad en lo nuevo. Típico «dual-mode IT».

Caso 3: aislamiento de seguridad en proveedor cloud

Un pequeño proveedor de hosting virtual para empresas. Cada cliente necesita un entorno independiente.

Al principio pensaron en Docker por el costo. El director técnico lo vetó: aislamiento total entre clientes; si hackean un sitio, no puede afectar a otros. Kernel compartido en Docker, riesgo alto.

Terminaron con KVM: un cliente, una VM, kernels separados. Más caro, pero seguro. Los clientes lo valoran — el contrato dice «servidor virtual independiente», no contenedor.

Seguridad por encima del costo.

Caso 4: mejor práctica en arquitectura híbrida

Una empresa de internet, negocio de juegos. La base de datos core debe estar on-premise (seguridad de datos); los servidores de juego necesitan escalado elástico (picos en eventos).

Su esquema:

• On-premise: MySQL master en VM, estabilidad primero
• En la nube: servicios de juego en Docker + K8s, escalado automático en picos
• Durante eventos: de 10 a 100 contenedores en 10 minutos
• Tras el evento: vuelta a 20, ahorro de costos

Equilibrio entre estabilidad, elasticidad y costo. VM en el core, Docker en el perímetro: lo mejor de cada uno.

Tras estos casos verás que no hay respuesta absoluta: solo encaje con el contexto.

Conclusión

Docker y las máquinas virtuales no son excluyentes: son herramientas con fortalezas distintas.

Si haces un proyecto nuevo, buscas iteración rápida y consistencia de entornos, Docker suele ser mejor. Arranque rápido, poco consumo, ideal para microservicios y DevOps. Mis proyectos nuevos casi siempre empiezan con Docker.

Si mantienes sistemas heredados, necesitas aislamiento fuerte o varios SO, la VM encaja mejor. Estabilidad y seguridad cuando hace falta.

Muchas empresas mezclan: VM para el core, Docker para el perímetro. Sin dogmas: pragmatismo.

Tres recomendaciones finales:

1. Evalúa tu proyecto: usa el árbol de decisión y dedica 5 minutos a ver qué encaja
2. Prueba en pequeño: si vas con Docker, empieza por servicios no críticos; no containerices todo de golpe
3. Sigue aprendiendo: contenedores, Kubernetes, serverless y edge computing evolucionan rápido

Si te interesa Docker, en el próximo artículo escribiré «Docker desde cero: de la instalación al primer contenedor», paso a paso.

Elegir bien la herramienta multiplica el resultado. Espero que este artículo te ayude a decidir.