Docker vs. máquina virtual: entenda as diferenças de desempenho e saiba quando usar cada um

Na reunião da equipe, o chefe perguntou: “No projeto novo, vamos usar Docker ou máquina virtual?” Eu já tinha trabalhado com os dois, mas, na hora de explicar claramente a diferença, percebi que ainda estava um pouco confuso. Quando voltei para minha mesa e pesquisei sobre o assunto, encontrei artigos muito teóricos ou explicações que paravam em “Docker é mais leve”. Mas onde exatamente está essa leveza? Qual é a diferença real de desempenho? E em que cenário vale usar cada opção? Quase ninguém explicava isso direito.

Depois de três dias estudando o tema, finalmente consegui organizar tudo. Neste artigo, vou explicar da forma mais simples possível as diferenças entre Docker e máquinas virtuais. Ao final, você vai entender a diferença essencial entre eles, com uma analogia bem visual; quanto o desempenho realmente muda, com dados práticos; e como usar uma árvore de decisão para escolher rapidamente a tecnologia certa.

Diferença essencial: contêiner de carga vs. apartamento independente

Vamos começar com uma analogia fácil de visualizar.

Uma máquina virtual é como um apartamento independente em um edifício. Cada apartamento tem sua própria cozinha, banheiro, eletricidade e encanamento: é uma unidade completa. Você mora no segundo andar, o vizinho mora no terceiro e um não interfere no outro. Da mesma forma, cada máquina virtual executa um sistema operacional completo, como Windows ou Linux, com kernel, drivers e serviços de sistema próprios.

Um contêiner Docker é como um contêiner de carga em um porto. Todos os contêineres usam a mesma infraestrutura do porto: guindastes, rede elétrica e vias de circulação. Dentro de cada unidade ficam apenas a aplicação e as dependências necessárias; não é preciso duplicar toda a infraestrutura. Os contêineres Docker compartilham o kernel do sistema operacional do host e empacotam somente a aplicação e seu ambiente de execução.

Essa diferença pode parecer pequena, mas afeta praticamente tudo.

Em termos de arquitetura, a máquina virtual carrega duas camadas adicionais: o Guest OS, ou sistema operacional convidado, e o hypervisor, a camada de virtualização. O hypervisor precisa simular todo o ambiente de hardware — CPU, memória, disco e placa de rede. Ao iniciar uma VM, primeiro é necessário inicializar o sistema operacional completo, carregar o kernel e ativar os serviços, como se um computador estivesse sendo reiniciado.

E o Docker? Ele funciona diretamente sobre o kernel do host. Iniciar um contêiner equivale a iniciar um processo, por isso leva apenas alguns segundos. Não há o custo de virtualizar o hardware nem uma camada adicional de sistema operacional. É extremamente leve.

Talvez você esteja pensando: compartilhar o kernel não causa problemas? Falarei disso mais adiante. Esse é justamente o ponto fraco do Docker: seu isolamento não é tão forte quanto o de uma máquina virtual. Ao mesmo tempo, é daí que vem sua principal vantagem: ele é rápido, leve e econômico no uso de recursos.

Quando você entende essa diferença essencial, a comparação de desempenho e os cenários de uso passam a fazer sentido.

Comparação de desempenho: os dados falam por si

Só a teoria não basta. Vamos olhar os números.

Velocidade de inicialização: segundos vs. minutos

Na semana passada, testei uma máquina virtual configurada com 2 núcleos e 4 GB. Do momento em que liguei a VM até conseguir entrar por SSH, passaram-se quase 4 minutos. Nesse intervalo, deu tempo de fazer um café e conferir algumas atualizações no celular.

E para iniciar o mesmo serviço Redis com Docker? 3 segundos.

Terminou antes mesmo de eu tirar a mão do mouse.

Isso não foi uma exceção. A máquina virtual precisa carregar um sistema operacional inteiro: inicializar o kernel, ativar os serviços do sistema e configurar a rede. Nenhuma etapa pode ser ignorada. Iniciar um contêiner Docker é apenas iniciar um processo; o kernel já está funcionando e tudo começa imediatamente.

Uso de recursos: megabytes vs. gigabytes

A diferença no uso de recursos é ainda mais impressionante. O custo do próprio Docker? De 6 a 8 MB de memória. Sim, você leu certo: poucos megabytes.

Executei um contêiner Redis e medi o consumo real: 0,08% de CPU e 2,6 MB de memória. É tão leve que quase passa despercebido.

E a máquina virtual? Mesmo sem executar nenhuma aplicação, só o sistema operacional já consome de 1 a 2 GB de memória. Para uma VM com MySQL, 4 GB de memória é o ponto de partida.

Isso leva a uma realidade inevitável: no mesmo servidor físico, é difícil passar de algumas dezenas de máquinas virtuais, enquanto o Docker permite executar mais de mil contêineres. Já vi um ambiente de produção real no qual um servidor com 32 núcleos e 128 GB executava mais de 800 contêineres Docker com tranquilidade. Com máquinas virtuais? Até 30 seriam um desafio.

Perda de desempenho: quase nula vs. lentidão perceptível

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Instituições de pesquisa já fizeram testes comparativos, e o desempenho dos contêineres Docker fica no mesmo nível das aplicações nativas em quase todos os cenários. Em alguns casos, chega a ser melhor, pois não existe o custo adicional da virtualização. Já as máquinas virtuais normalmente apresentam uma perda de desempenho de 10% a 20%.

A diferença fica especialmente clara em tarefas que exigem muita CPU. Em um teste que fiz ao compilar um projeto grande, a tarefa levou 25 minutos em uma máquina virtual, 21 minutos em um contêiner e 20 minutos no servidor físico. O contêiner praticamente não teve perda de desempenho.

Veja a comparação na tabela:

Depois de ver essa tabela, fica fácil entender por que as arquiteturas de microsserviços migraram em massa para o Docker. A utilização dos recursos pode melhorar em uma ordem de grandeza. É uma diferença difícil de ignorar.

Isolamento e segurança: nem sempre mais é melhor

Depois das vantagens de desempenho, precisamos falar sobre o ponto fraco do Docker.

A diferença entre os níveis de isolamento

Uma máquina virtual oferece isolamento no nível de hardware. Cada VM tem seu próprio kernel de sistema operacional, como se fossem dois computadores totalmente separados. Se a máquina virtual A for comprometida, em teoria o invasor não conseguirá saltar para a máquina B nem para o host. É o chamado “isolamento forte”.

E o Docker? Ele oferece isolamento no nível de processo. Todos os contêineres compartilham o kernel do host e usam tecnologias do Linux, como namespaces e cgroups, para separar recursos. Isso parece menos seguro, certo?

E realmente é. Há um tipo de ataque voltado especificamente ao Docker chamado fuga de contêiner, ou Container Escape. Se um invasor encontra uma vulnerabilidade no contêiner, pode conseguir romper o isolamento e atacar diretamente o host. Uma vulnerabilidade CVE descoberta no ano passado, a CVE-2024-21626, permitia justamente escapar do contêiner para o host.

Máquinas virtuais também estão sujeitas a esse risco? Sim, mas a dificuldade é muito maior.

Em quais cenários é obrigatório usar uma máquina virtual?

Isso não significa que o Docker seja inseguro. A escolha depende do grau de isolamento exigido pelo seu cenário.

Se você é um provedor de serviços de nuvem e atende vários clientes, os ambientes precisam ficar totalmente separados. Nesse caso, use máquinas virtuais. Nuvens públicas como Alibaba Cloud e AWS usam máquinas virtuais na camada inferior para isolar diferentes tenants. Não dá para permitir que os clientes A e B compartilhem o mesmo kernel: se A for atacado, B também pode ser afetado.

Se você trabalha em uma instituição financeira com requisitos rigorosos de conformidade, o uso de um kernel compartilhado pelo Docker pode ser rejeitado durante uma auditoria. Nesse caso, é melhor usar máquinas virtuais.

Se você precisa executar código não confiável, como em uma plataforma de compilação online que recebe e executa qualquer código enviado por usuários, o risco do Docker é alto demais. É necessário usar máquinas virtuais.

Como reforçar a segurança do Docker?

Dito isso, a maioria dos cenários não é tão extrema. Para microsserviços internos de uma empresa, todos feitos com código próprio, o Docker é perfeitamente adequado. Basta seguir estes cuidados:

1. Não execute contêineres com o usuário root. Por padrão, o contêiner usa permissões de root, o que aumenta o impacto de uma invasão. Prefira um usuário sem privilégios.
2. Limite as permissões do contêiner com Capabilities. Não conceda ao contêiner várias permissões de sistema das quais ele não precisa.
3. Verifique regularmente as imagens em busca de vulnerabilidades. Use uma ferramenta como o Trivy e atualize a imagem-base assim que encontrar um problema.

Nossa equipe aplica essas três medidas a todos os contêineres Docker e não teve nenhum incidente de segurança nos últimos dois anos.

Em resumo, o nível de isolamento necessário depende do seu modelo de ameaças. Para aplicações internas, o Docker é suficiente. Máquinas virtuais devem ser consideradas em ambientes multi-tenant expostos externamente.

Cenários de uso: a árvore de decisão

Depois de tudo isso, quando usar cada tecnologia? Aqui está um processo de decisão bem direto.

Quatro cenários em que você deve priorizar o Docker

1. Arquitetura de microsserviços

Se você está trabalhando com microsserviços, não hesite: use Docker.

Por quê? A ideia dos microsserviços é dividir uma aplicação grande em dezenas ou centenas de serviços pequenos, cada um implantado de forma independente. Com máquinas virtuais, o serviço de usuários ocuparia uma VM, o serviço de pedidos precisaria de outra, o de pagamentos de mais uma… Os recursos simplesmente não seriam suficientes.

O Docker se encaixa perfeitamente nesse modelo: é leve, inicia em segundos e permite alta densidade. Em uma plataforma de comércio eletrônico, os serviços de usuários, pedidos e pagamentos podem rodar cada um em seu contêiner, com recursos isolados. Além disso, aumentar o número de instâncias leva poucos minutos.

Participei de um projeto em que mais de 30 microsserviços foram colocados em contêineres e implantados em 5 servidores. Se usássemos máquinas virtuais, o custo dos servidores teria sido três vezes maior.

2. Pipelines de DevOps, CI e CD

Diferenças entre os ambientes de desenvolvimento, testes e produção são o pesadelo de qualquer pessoa desenvolvedora. Você provavelmente já ouviu inúmeras vezes a frase “na minha máquina funciona”, não é?

O Docker nasceu para resolver esse problema. A aplicação e todas as suas dependências são empacotadas em uma imagem. Se funciona no ambiente de desenvolvimento, funcionará também nos ambientes de teste e produção. O ambiente permanece idêntico.

O mesmo vale para pipelines de CI e CD. Cada build automático no Jenkins precisa de um ambiente limpo. Com Docker, basta iniciar um contêiner, executar os testes e destruí-lo. Todo o processo leva 20 segundos. Com uma máquina virtual? Só a inicialização leva 5 minutos, e ainda seria necessário limpar o ambiente manualmente. É muito mais trabalhoso.

3. Implantação rápida e escalabilidade elástica

São 23h e surge um pico repentino de tráfego. Você precisa adicionar 10 instâncias com urgência.

Docker: em poucos segundos, os 10 contêineres estão funcionando.
Máquina virtual: é preciso esperar. Se cada VM leva 5 minutos para iniciar, as 10 levam 50 minutos. Nesse tempo, os usuários já foram embora.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Esse é um dos maiores trunfos do Docker: a escalabilidade elástica. O K8s, ou Kubernetes, consegue aumentar ou reduzir automaticamente o número de contêineres de acordo com o tráfego, sem que o usuário perceba. Máquinas virtuais não conseguem acompanhar essa velocidade.

4. Padronização do ambiente de desenvolvimento

A equipe tem cinco pessoas: uma usa macOS, outra Windows e outra Ubuntu. Como cada ambiente é diferente, as versões do MySQL e do Node também variam, e todo dia alguém pergunta: “Aí está funcionando?”

Com uma única imagem de ambiente Docker, todo mundo executa docker-compose up e inicia MySQL, Redis e Nginx de uma só vez. As versões ficam fixas, o ambiente é igual para toda a equipe e os problemas de configuração desaparecem.

Quatro cenários em que é necessário escolher uma máquina virtual

1. Aplicações monolíticas tradicionais

Sua empresa tem um ERP de dez anos, feito com Java 6 e banco de dados Oracle, que ainda roda no CentOS 6. São centenas de milhares de linhas de código que ninguém consegue, nem ousa, alterar.

Nesse caso, não tente forçar uma migração para Docker. Mantenha o sistema em uma máquina virtual e priorize a estabilidade. O custo e o risco de modernizá-lo com contêineres seriam altos demais.

2. Necessidade de vários sistemas operacionais

Você precisa executar aplicações Windows e Linux ao mesmo tempo. Por exemplo, a equipe de testes precisa rodar um programa .NET no Windows Server e um serviço Java no Linux.

O Docker não resolve bem esse caso. Ele é usado principalmente para contêineres Linux; também existem contêineres Windows, mas o suporte é muito limitado. É necessário usar máquinas virtuais: uma com Windows e outra com Linux.

Da mesma forma, quem desenvolve no Mac e precisa testar um software Windows só consegue fazer isso abrindo uma máquina virtual Windows com VMware ou VirtualBox.

3. Requisitos de isolamento forte

Provedores de nuvem e plataformas SaaS multi-tenant precisam manter cada cliente totalmente isolado. Com máquinas virtuais, cada cliente recebe uma VM e um kernel independente.

Em instituições financeiras e projetos governamentais, os requisitos de conformidade são rigorosos e as auditorias exigem uma prova de isolamento forte. O modelo de kernel compartilhado do Docker pode não ser aprovado.

4. Necessidade de simular um sistema operacional completo

Talvez você esteja desenvolvendo drivers para um sistema embarcado e precise de uma versão específica do kernel e de um ambiente de hardware próprio. Ou esteja trabalhando no desenvolvimento de baixo nível de um sistema operacional.

O Docker não atende a esse caso, pois compartilha o kernel do host. Uma máquina virtual consegue simular hardware e kernel completos, permitindo instalar o que for necessário.

A melhor abordagem é combinar as duas opções

Na prática, a maioria das empresas usa uma combinação.

Na nossa empresa, por exemplo:

• Sistema central de transações, estável há cinco anos: máquina virtual
• Novo gateway de API e microsserviços: Docker + Kubernetes
• Ambientes de desenvolvimento e testes: todos em Docker
• Testes de sistemas corporativos Windows: máquina virtual VMware

Assim, mantemos a estabilidade dos sistemas centrais e, ao mesmo tempo, aproveitamos a agilidade dos contêineres.

Uma árvore de decisão para escolher rapidamente

Sua aplicação está sendo desenvolvida agora?
├─ Sim → É uma arquitetura de microsserviços?
│   ├─ Sim → Escolha Docker ✅
│   └─ Não → Precisa de atualizações e implantações frequentes?
│       ├─ Sim → Escolha Docker ✅
│       └─ Não → Avalie os demais fatores
└─ Não, é um sistema legado → Exige um sistema operacional ou kernel específico?
    ├─ Sim → Escolha uma máquina virtual ✅
    └─ Não → Precisa de isolamento forte?
        ├─ Sim → Escolha uma máquina virtual ✅
        └─ Não → Pode ser modernizado com contêineres → Escolha Docker ✅

Siga esse fluxograma uma vez e você provavelmente chegará a uma decisão.

Casos reais: veja como outras equipes escolhem

Só a teoria não basta. Vamos analisar alguns cenários reais.

Caso 1: uma startup que adotou Docker em tudo

A startup de um amigo oferece um produto SaaS e tem uma equipe de 15 pessoas. No início, o orçamento para servidores era apertado: três instâncias ECS da Alibaba Cloud, cada uma com 4 núcleos e 8 GB, precisavam executar mais de dez serviços.

Com máquinas virtuais, os três servidores físicos conseguiriam hospedar no máximo 15 VMs antes de esgotar os recursos. A equipe adotou diretamente Docker + Kubernetes e passou a executar mais de 60 contêineres nas três máquinas, ainda com capacidade disponível.

O ambiente de desenvolvimento também foi padronizado. No primeiro dia, uma pessoa recém-contratada clonava o código, executava docker-compose up e deixava tudo pronto em 5 minutos. Antes, com máquinas virtuais, apenas configurar o ambiente levava metade do dia.

Qual foi a economia? Segundo a estimativa da equipe, seriam necessários 10 servidores com máquinas virtuais. Hoje, três dão conta do trabalho, o que reduz os gastos anuais com servidores em dezenas de milhares.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Para uma startup, esse é um valor muito concreto.

Caso 2: modernização gradual em uma empresa tradicional

Uma empresa do setor industrial usa há 15 anos um ERP central com SAP e banco de dados Oracle, executado em alguns servidores IBM antigos com máquinas virtuais. Esse sistema não pode ser alterado.

No ano passado, porém, a empresa iniciou uma transformação digital e precisava desenvolver um novo sistema para a cadeia de suprimentos. O diretor de TI tomou uma decisão inteligente: manteve o ERP central como estava e adotou uma arquitetura de microsserviços Docker em todos os novos serviços.

A arquitetura atual ficou assim:

• ERP antigo: máquinas virtuais em 5 servidores, com máxima estabilidade
• Novo sistema da cadeia de suprimentos: Docker + K8s em 3 servidores, com mais de 70 contêineres
• Integração entre os dois lados por um gateway de API

Essa solução manteve a estabilidade do sistema central, do qual centenas de pessoas dependem para trabalhar, e deu agilidade ao novo negócio. É um exemplo típico de TI bimodal.

Caso 3: isolamento de segurança em um provedor de nuvem

Um pequeno provedor de nuvem oferece hospedagem virtual para empresas. Cada cliente precisa de um ambiente de execução independente.

No início, a equipe pensou em usar Docker para reduzir custos, mas o diretor técnico rejeitou a ideia: os clientes precisavam ficar fortemente isolados. Se o site de um deles fosse comprometido, isso não poderia afetar os demais. Como o Docker compartilha o kernel, o risco era alto demais.

A escolha final foi usar máquinas virtuais KVM. Cada cliente recebe uma VM com kernel isolado. O custo é maior, mas a segurança fica garantida. Os clientes também valorizam esse detalhe: o contrato especifica “servidor virtual independente”, não um contêiner.

Esse é um cenário típico em que a segurança tem prioridade sobre o custo.

Caso 4: boas práticas em uma arquitetura de nuvem híbrida

Uma empresa de internet que trabalha com jogos precisa manter o banco de dados central em um datacenter próprio por exigências de segurança, mas os servidores de jogo precisam escalar rapidamente durante eventos com picos de tráfego.

A solução adotada foi:

• Datacenter próprio: banco principal MySQL em uma máquina virtual, priorizando a estabilidade
• Nuvem: todos os serviços de jogo em Docker, conectados ao K8s para escalar automaticamente durante os picos
• Durante um evento: expansão de 10 para 100 contêineres em 10 minutos
• Após o evento: redução automática para 20 contêineres, economizando recursos

Essa arquitetura equilibra estabilidade, elasticidade e custo. Os sistemas centrais usam VMs; os serviços de borda usam Docker. Cada tecnologia é aplicada onde funciona melhor.

Depois de analisar esses casos, fica claro que não existe uma escolha absolutamente certa ou errada. Existe a opção mais adequada para cada cenário.

Conclusão

No fim das contas, Docker e máquinas virtuais não são opções mutuamente exclusivas, mas ferramentas com vantagens diferentes.

Se você está desenvolvendo um projeto novo, busca ciclos rápidos de melhoria e quer ambientes consistentes, o Docker é a melhor escolha. Ele inicia rapidamente, consome poucos recursos e se adapta perfeitamente a arquiteturas de microsserviços e processos de DevOps. Pessoalmente, começo quase todos os meus projetos novos com Docker e gosto muito da praticidade.

Se você mantém um sistema legado, precisa de isolamento forte ou executa vários sistemas operacionais, uma máquina virtual é mais adequada. Ela oferece estabilidade e segurança; quando o cenário exigir, não hesite em usá-la.

Na verdade, muitas empresas combinam as duas soluções. Usam máquinas virtuais em sistemas centrais, nos quais a estabilidade é prioridade, e Docker em serviços periféricos, nos quais a velocidade é mais importante. Não é preciso ser dogmático: o melhor é ser pragmático.

Para terminar, aqui vão três sugestões práticas:

1. Avalie seu projeto: siga a árvore de decisão acima e dedique 5 minutos para identificar a opção mais adequada ao projeto atual.
2. Teste em pequena escala: se decidir usar Docker, comece por um serviço não essencial. Não tente colocar tudo em contêineres de uma só vez.
3. Continue aprendendo: a tecnologia de contêineres evolui rapidamente. Kubernetes, Serverless e edge computing continuam avançando, então mantenha a curiosidade.

Aliás, se você se interessa por Docker, no próximo artigo vou publicar “Docker para iniciantes: da instalação ao primeiro contêiner”, com um passo a passo para começar.

Escolher a ferramenta certa economiza tempo e esforço. Espero que este artigo ajude você a tomar a melhor decisão.