Containers vs VMs: quando usar cada um (sem hype)

Máquinas virtuais e containers resolvem problemas diferentes usando abordagens diferentes de isolamento. VM é um sistema operacional completo rodando sobre hardware virtual, com isolamento total. Container é um processo isolado que compartilha o kernel do host, leve e efêmero. Entender essa diferença te poupa de decisões ruins — em ambas as direções.

O que cada um realmente é — sem abstrações

O setor de TI tem o péssimo hábito de tratar containers e VMs como se fossem apenas “versões diferentes da mesma coisa, um mais leve que o outro”. Essa simplificação leva a decisões ruins. Vamos ser precisos.

Uma máquina virtual é exatamente o que o nome diz: uma máquina completa, criada em software. Ela tem seu próprio kernel de sistema operacional, seus próprios drivers, sua própria pilha de rede, seu próprio sistema de arquivos — tudo independente do host e das outras VMs. Do ponto de vista de segurança, uma VM que é comprometida não tem acesso ao host nem às outras VMs. O isolamento é real e profundo.

Um container é diferente em fundamento. Um container não tem seu próprio kernel — ele compartilha o kernel do sistema operacional do host. O que o container tem são namespaces (que criam a ilusão de isolamento: o container enxerga apenas seus próprios processos, sua própria interface de rede, seu próprio sistema de arquivos) e cgroups (que limitam quanto de CPU, memória e I/O o container pode usar). É isolamento de processo, não isolamento de máquina.

Essa diferença de fundamento é o que define tudo mais: por que containers são mais leves, por que iniciam em milissegundos, por que têm isolamento de segurança menor, e por que só funcionam nativamente com o mesmo tipo de kernel do host.

Diferenças práticas que importam no dia a dia

Imagine que você precisa subir 50 instâncias do mesmo serviço de API para absorver um pico de tráfego. Com VMs, cada instância precisa de um sistema operacional completo — 1 a 2 GB de RAM só para o SO, mais o tempo de boot que pode levar de 30 segundos a alguns minutos. Com containers, cada instância é um processo: 10 a 50 MB de overhead, boot em milissegundos.

Para escalar horizontalmente serviços stateless, containers ganham sem discussão. A densidade é radicalmente diferente.

Agora imagine que você precisa rodar um sistema ERP legado com Windows Server 2019, que foi desenvolvido há 10 anos, tem dependências específicas do registro do Windows e comportamento não-documentado com chamadas de sistema. Containers? Não funciona — você precisaria de containers Windows, que existem mas têm suporte e ecossistema muito menores que containers Linux, e ainda assim não capturam o isolamento completo que a aplicação pode precisar. VM com Windows Server 2019 é a resposta certa — e vai funcionar exatamente como no ambiente original.

Quando VM é a escolha certa

A VM ganha quando você precisa de isolamento real e não tem alternativa:

Workloads legados. Aplicações que foram escritas para um SO específico, com drivers específicos, que assumem que são o único processo importante no sistema — VMs são o único caminho para rodar isso sem modificar o código.

Isolamento total obrigatório. Em ambientes regulados (financeiro, saúde, governo) onde isolamento entre tenants precisa ser garantido por hardware ou por hypervisor — não por namespaces de kernel — VMs são o padrão. Um bug de kernel que permita escape de container não existe no modelo de VM; um bug de hypervisor permitindo escape de VM é muito mais raro e difícil de explorar.

Sistemas operacionais diferentes no mesmo host. Se você precisa rodar Windows e Linux no mesmo servidor físico, você precisa de VMs. Containers Linux não rodam aplicações Windows nativas e vice-versa (sem emulação pesada).

Compliance e certificações. Muitas certificações de segurança e compliance (PCI-DSS, ISO 27001 em certos escopos) exigem isolamento a nível de hypervisor. Containers podem passar em outros escopos, mas VMs são a escolha mais comum quando o auditor não está familiarizado com a segurança de containers.

Quando containers ganham

Containers dominam em cenários onde leveza, velocidade e densidade são críticos:

Microserviços e APIs. Se sua arquitetura é decomposta em serviços independentes que precisam de deploy frequente, escala independente e resiliência — containers com Kubernetes são o padrão da indústria. A densidade (centenas de containers por host) e a velocidade de escala (segundos) são impossíveis de igualar com VMs.

Pipelines de CI/CD. Builds, testes automatizados e deploys em containers são mais rápidos, mais reproduzíveis e mais baratos. Um pipeline que roda em containers usa recursos por segundos; o equivalente em VMs levaria minutos e consumiria muito mais recurso.

Ambientes de desenvolvimento padronizados. “Funciona na minha máquina” é um problema que containers resolvem: o container carrega o ambiente de execução junto com o código. Todos os desenvolvedores do time executam exatamente o mesmo ambiente, independente do SO do notebook deles.

Como os dois coexistem — a realidade do mercado

O título deste artigo pergunta “quando usar cada um”, mas a resposta mais honesta é: na maioria dos ambientes modernos, você usa os dois.

Kubernetes — a plataforma de orquestração de containers dominante — tipicamente roda sobre VMs. Os nodes do seu cluster Kubernetes são VMs provisionadas numa cloud (pública ou privada). Os pods do Kubernetes são containers rodando dentro dessas VMs. Você tem os benefícios dos dois: isolamento de VM para os nodes do cluster (nenhum node compromete o hypervisor ou os outros nodes), e eficiência de container para as cargas de trabalho dentro dos nodes.

Esse padrão — Kubernetes sobre VMs — é como AWS, GCP e Azure entregam seus serviços gerenciados de Kubernetes (EKS, GKE, AKS). É como a maioria das empresas que adotam Kubernetes em cloud privada configuram seus ambientes.

Comparativo por critério

Precisa de infraestrutura para rodar Kubernetes em cloud privada com SLA 99,99%? Fale com os arquitetos da Adentro.