É comum ver gente tratando Docker como “uma VM mais rápida”, e isso gera confusão na hora de decidir qual usar num projeto. Container e máquina virtual resolvem o mesmo problema geral — rodar aplicações isoladas do resto do sistema — mas de formas tecnicamente bem diferentes, e essa diferença de arquitetura é o que determina qual ferramenta faz sentido em cada situação.
A diferença que realmente importa: o kernel
Uma máquina virtual roda sobre um hipervisor (VMware, VirtualBox, Hyper-V, KVM) que simula hardware completo para cada VM — cada uma tem seu próprio sistema operacional inteiro, com kernel próprio, drivers próprios, tudo isolado do host em nível de hardware virtualizado. Um container Docker, por outro lado, compartilha o kernel do sistema operacional host e isola só o espaço de processos, sistema de arquivos e rede da aplicação. É essa diferença — SO completo vs. compartilhamento de kernel — que explica praticamente todas as outras diferenças práticas entre os dois.
Por que containers sobem em segundos e VMs levam minutos
Como a VM precisa inicializar um sistema operacional completo do zero (bootloader, kernel, serviços do SO), o tempo de start fica na casa de minutos, mesmo em hardware rápido. Um container Docker não inicializa SO nenhum — ele só inicia o processo da aplicação dentro de um ambiente isolado que já usa o kernel que já está rodando no host. Na prática, isso significa subir um container em menos de um segundo, contra minutos de uma VM. Essa diferença de velocidade é o motivo principal pelo qual containers dominaram cenários de CI/CD e escala automática — você não tem tempo de esperar minutos toda vez que precisa escalar um serviço sob demanda de tráfego.
Consumo de recursos: onde o Docker ganha disparado
Cada VM carrega o peso de um SO inteiro na memória e no disco — geralmente gigabytes só de sistema operacional, antes mesmo da aplicação em si. Um container, sem esse overhead, costuma pesar megabytes. Na prática, um mesmo servidor físico roda uma quantidade muito maior de containers do que rodaria de VMs equivalentes — é comum ver dezenas de containers convivendo tranquilamente num host onde só caberiam poucas VMs com a mesma alocação de recursos.
Onde a VM ainda ganha: isolamento e segurança
Vale ser honesto sobre o outro lado da moeda: como cada VM tem kernel próprio, o isolamento é feito no nível de hardware virtualizado pelo hipervisor — uma falha de segurança dentro de uma VM tem barreira mais forte para escapar e afetar outras VMs ou o host. Containers, por compartilharem o kernel do host, têm superfície de ataque teoricamente maior: uma vulnerabilidade grave no kernel pode, em teoria, ser explorada para escapar do isolamento do container. Na prática, esse risco é mitigado com boas práticas (rodar containers sem privilégio root, manter imagens atualizadas, usar runtime seguro), mas é um fator real na decisão quando o requisito é isolamento máximo — por exemplo, rodar cargas de trabalho de clientes diferentes e não confiáveis no mesmo hardware físico.
Compatibilidade de sistema operacional
Outra diferença prática que pega muita gente: como o container compartilha o kernel do host, você não roda container Windows num host Linux (nem o contrário) sem uma camada extra de virtualização por baixo — no Docker Desktop para Windows/Mac, por exemplo, o que roda por trás é uma VM Linux leve para viabilizar containers Linux. Já uma VM roda praticamente qualquer sistema operacional dentro de qualquer host, porque ela emula hardware completo, não depende do kernel do host.
Quando usar cada um na prática
Container faz mais sentido quando: a aplicação é stateless ou fácil de tornar stateless, você precisa escalar rápido sob demanda, o time já trabalha com CI/CD e deploy automatizado, ou o objetivo é empacotar a aplicação com todas as dependências para rodar igual em qualquer ambiente (dev, staging, produção).
VM ainda faz mais sentido quando: você precisa rodar sistemas operacionais diferentes lado a lado no mesmo hardware, o requisito de isolamento de segurança é rígido (multi-tenant com clientes não confiáveis, por exemplo), ou existe uma aplicação legada que só roda de forma estável dentro de um SO completo com configuração específica.
Na prática, a maioria das infraestruturas modernas usa as duas coisas juntas: VMs para prover a infraestrutura base (servidores na nuvem, isolamento entre clientes) e containers rodando dentro dessas VMs para as aplicações em si — é o modelo padrão de qualquer provedor de nuvem hoje.
Perguntas frequentes
Docker substitui completamente a necessidade de VM?
Não. Na maioria dos ambientes de produção real, containers rodam dentro de VMs (ou de instâncias de nuvem que são, no fundo, VMs) — as duas tecnologias se complementam mais do que competem.
É mais fácil migrar uma aplicação de VM para container, ou o contrário?
Migrar de VM para container costuma dar mais trabalho, porque exige repensar a aplicação para funcionar bem no modelo de container (statelessness, configuração via variáveis de ambiente, sem depender de estado salvo no disco local). O caminho contrário é mais simples tecnicamente, mas raramente faz sentido na prática.
Container é sempre mais rápido que VM em qualquer cenário?
Para start de aplicação e uso de recursos, sim, quase sempre. Mas para cargas de trabalho que precisam de isolamento total de kernel ou rodar SO diferente do host, VM continua sendo a única opção viável, independente de velocidade.
Para aprofundar em infraestrutura e ambientes de desenvolvimento, veja também Como Configurar um Ambiente Docker do Zero: Guia Prático para Iniciantes.
