Conhecimento em engenharia
A3A Academy
Análise de risco
TONITRU Risk Assessment Compare VMs e containers: hypervisors, armazenamento, redes, segurança, disponibilidade, custos e critérios técnicos para definir a arquitetura.
Confira!
Virtualização e containers são técnicas diferentes para executar aplicações de forma isolada sobre uma infraestrutura computacional. A virtualização cria máquinas com sistema operacional próprio gerenciadas por um hypervisor; containers executam processos e dependências de uma aplicação compartilhando, em geral, o kernel do host. Na engenharia de infraestrutura corporativa, essas abordagens são frequentemente complementares: VMs hospedam serviços e sistemas, enquanto containers simplificam entrega, atualização e escala de aplicações.
A escolha depende de requisitos de compatibilidade, isolamento, disponibilidade, recuperação, segurança, custo e capacidade de operação. Não basta comparar a quantidade de RAM consumida por cada alternativa. É necessário considerar toda a cadeia: servidores, storage, rede, runtime, identidade, backup, monitoramento e equipe responsável.
O que distingue máquinas virtuais e containers?
Uma máquina virtual, ou VM, contém um sistema operacional convidado e recursos virtuais que são apresentados por um hypervisor. Esse componente abstrai CPU, memória, interfaces de rede e discos, permitindo consolidar múltiplos sistemas sobre um conjunto de hosts. O isolamento depende da plataforma de virtualização, da configuração dos convidados e das políticas de administração.
Um container é uma instância de aplicação que utiliza isolamento de processos, filesystem, usuários, rede e limites de recursos fornecidos pelo sistema operacional. Sua imagem reúne os arquivos necessários à execução. Como não exige iniciar um sistema operacional convidado completo em cada instância, pode apresentar menor overhead e provisionamento rápido.
| Aspecto | Máquina virtual | Container |
| Unidade de execução | Sistema operacional convidado | Processo ou conjunto de processos |
| Dependência do kernel | Kernel do sistema convidado | Em geral compartilha o kernel do host |
| Empacotamento | Template ou imagem de VM | Imagem versionada de aplicação |
| Persistência | Discos virtuais e storage | Volumes e serviços de dados externos |
| Atualização | SO, drivers e aplicação | Imagem, runtime, host e aplicação |
| Caso comum | Legados e diferentes sistemas operacionais | APIs, serviços modulares e pipelines |
Essa distinção não permite afirmar que um modelo seja universalmente superior. A VM costuma oferecer uma fronteira adequada quando aplicações exigem kernels ou sistemas distintos, enquanto containers facilitam padronização de ambientes. Ambos podem falhar por permissões inadequadas, configurações inconsistentes, dependências vulneráveis ou ausência de recuperação demonstrada.
Arquitetura de virtualização: hypervisor, hosts e recursos
Em ambientes corporativos, um cluster de hypervisors administra servidores físicos e apresenta recursos virtuais às VMs. A arquitetura pode incluir storage compartilhado ou distribuído, redes virtuais, balanceamento de capacidade, movimentação de workloads e mecanismos de recuperação após falha de host.
A análise precisa separar capacidade instalada, recursos alocados e demanda efetivamente medida. O total de vCPUs provisionadas não equivale à quantidade de núcleos físicos, e o uso de memória nominal não descreve a pressão de memória nos horários críticos. Os indicadores relevantes incluem percentis de uso, picos simultâneos, IOPS, latência de armazenamento, throughput e contenção de CPU.
A estratégia de overcommit pode melhorar utilização quando suportada por medições, mas também aumenta a chance de degradação se múltiplos sistemas atingirem picos no mesmo intervalo. Em projetos com disponibilidade elevada, é necessário dimensionar o cenário de perda de um host, e não apenas o funcionamento normal do cluster.
O diagrama representa uma configuração possível, na qual os containers operam dentro de VMs. Também é possível executar containers diretamente em servidores físicos. Em ambos os modelos, a fronteira de responsabilidade por patching, rede, backup e monitoramento deve constar nos documentos de projeto.
Para aprofundar a camada física e lógica, o conteúdo sobre hypervisors, alta disponibilidade e storage apresenta os critérios de seleção e dimensionamento dessa infraestrutura.
Containers: imagem, runtime, volumes e ciclo de vida
A imagem de container é o artefato de distribuição, construído a partir de instruções versionadas e dependências necessárias à aplicação. O runtime cria e executa instâncias a partir dessa imagem, sob políticas de recursos e isolamento. Alterar manualmente a instância em produção é uma prática frágil: a atualização deve ser reproduzível e gerar um novo artefato controlado.
Um container não equivale a uma solução completa de persistência. Aplicações stateless podem ser reconstruídas sem manter estado local; bancos de dados, arquivos e filas exigem volumes duráveis ou serviços externos, com consistência, backup e recuperação próprios. Excluir o container não pode significar perder informações de negócio.
O isolamento depende de mecanismos como namespaces, cgroups, controle de usuários e permissões, seccomp e políticas de rede. Executar processos privilegiados, montar diretórios sensíveis do host ou disponibilizar secrets sem proteção desfaz parte das vantagens esperadas. A exposição de portas e APIs também necessita análise de ameaças e aprovação de fluxos.
A construção da imagem faz parte do supply chain. Bibliotecas, imagens-base, tags mutáveis, vulnerabilidades conhecidas e ausência de rastreabilidade podem gerar riscos mesmo em serviços aparentemente simples. A operação deve incluir atualização de dependências, verificação de origem, imagens mínimas e registros de versão.
O conteúdo sobre Docker, imagens, volumes e redes detalha a tecnologia de execução. É importante distinguir essa função de uma plataforma de orquestração, que gerencia múltiplas instâncias, reconciliação de estado e distribuição entre nós.
Quando escolher cada arquitetura
O ponto de partida é inventariar workloads por função, criticidade, dependências e nível de serviço. Sistemas legados com drivers específicos, necessidade de outro sistema operacional ou licenciamento restritivo frequentemente permanecem mais adequados em VMs. APIs, serviços independentes e aplicações com entregas frequentes podem se beneficiar do empacotamento em containers.
| Workload | Caminho inicial a avaliar | Verificação obrigatória |
| ERP legado com dependência de SO | VM | Suporte, compatibilidade e licenças |
| API de integração corporativa | Container | Deploy, rollback, segurança e logs |
| Banco de dados crítico | VM ou container | Consistência, volumes, RPO e restore |
| Serviço de filial em edge | Solução simplificada | Resiliência a falha e conectividade |
| Ambiente com dezenas de equipes | Plataforma distribuída | Isolamento, quotas e governança |
| Aplicação industrial ou OT | Avaliação específica | Latência, determinismo e suporte |
A modernização não precisa ser uma migração total. Uma empresa pode manter o banco de dados e os componentes legados em VMs e distribuir novas APIs em containers. O desenho híbrido exige gestão de identidade, DNS, certificados, segmentação e observabilidade de ponta a ponta.
Migrar uma aplicação monolítica para containers não cria automaticamente modularidade. Dependências entre processos, sessões, escritas em disco local, jobs agendados e comunicação com sistemas externos precisam ser compreendidas antes do cutover. Em certas situações, preservar a arquitetura atual e corrigir gargalos gera menos risco e custo.
Da mesma forma, manter serviços simples em máquinas virtuais não é necessariamente errado. A equipe operacional pode possuir processos maduros de backup, patching e recuperação para VMs. Introduzir um novo runtime sem estabelecer competências, ferramentas e responsáveis pode reduzir a disponibilidade em vez de ampliá-la.
Rede, DNS e armazenamento na prática
Workloads virtualizados consomem rede em diferentes planos: tráfego de usuários, comunicação entre aplicações, gerenciamento, backup, replicação e storage. O projeto deve diferenciar essas necessidades e avaliar banda, latência, redundância, MTU, endereçamento, resolução de nomes e localização de firewalls.
Em containers distribuídos, redes overlay, service discovery e balanceamento acrescentam componentes e domínios de falha. Latência entre serviços que realizam muitas chamadas pode comprometer o tempo de resposta mesmo quando CPU e memória parecem adequadas. Por isso, a validação deve usar fluxos de produção representativos, e não somente testes isolados de conectividade.
O storage precisa atender a padrões distintos de acesso: bancos transacionais exigem latência e consistência; arquivos e backups exigem retenção e capacidade; camadas temporárias podem exigir throughput, mas dispensar persistência após reinício. Uma única classe de armazenamento para tudo raramente oferece boa relação custo-desempenho.
Snapshots e replicação não substituem backups independentes. A replicação pode copiar exclusões ou corrupção lógica; snapshots podem depender do próprio domínio de falha. O projeto deve definir RPO e RTO, retenção, integridade, local de guarda e ensaios de recuperação. Uma política de backup sem teste de restore é apenas uma hipótese.
Disponibilidade, failover e disaster recovery
Alta disponibilidade deve ser definida a partir de cenários de falha. Reiniciar uma VM em outro host não restaura automaticamente uma aplicação cujo banco de dados foi corrompido. Reiniciar um container não recupera uma fila de mensagens que foi perdida. Cada camada possui mecanismos próprios e limites de proteção.
O desenho deve identificar componentes únicos: controladores de storage, switches, DNS, sistemas de autenticação, certificados, registros de imagens, control plane e conectividade externa. Uma redundância aparente pode continuar dependente de um único serviço crítico.
A simulação de falhas oferece evidências concretas. Testes recomendados incluem perda de host, indisponibilidade de storage, degradação de enlace, falha de resolução DNS, expiração de certificado, interrupção de banco e indisponibilidade de registro de imagens. O resultado precisa registrar tempo de recuperação, comportamento das transações e impacto nos usuários.
O plano de disaster recovery deve especificar quem decide pela ativação, quais dados têm prioridade, onde a recuperação ocorrerá e como será validada. Sem critérios operacionais, a tecnologia permanece incapaz de demonstrar que cumpre a continuidade exigida pelo negócio.
Segurança e governança de mudanças
Em VMs, o hardening envolve templates de sistema operacional, gestão de patches, restrições administrativas, acesso remoto, logs, criptografia e proteção do hypervisor. Em containers, acrescenta-se controle de imagens, secrets, política de privilégios, identidade de workloads e segurança do runtime. Os dois modelos continuam sujeitos a ataques sobre aplicações e credenciais.
Uma fronteira de rede precisa seguir necessidade real de comunicação. VLANs e sub-redes ajudam a estruturar o ambiente, mas não substituem regras explícitas entre serviços. A segmentação de rede e a arquitetura de DMZ em TI e OT apoiam a definição desses limites.
A configuração declarativa deve passar por análise de mudança: autor, versão, revisão, testes, aprovação, implantação e plano de retorno. O mesmo vale para políticas de rede, volumes persistentes, permissões e templates de VM. Automatizar alterações sem controle apenas aumenta a velocidade de propagação dos erros.
Gestão de vulnerabilidades não pode parar na fase de implantação. A operação precisa estabelecer periodicidade de atualização, tratamento de exceções, inventário de dependências e indicadores de exposição. Em serviços críticos, avaliar vulnerabilidade significa ponderar explorabilidade, impacto e capacidade de mitigação com o menor risco operacional possível.
Custos e dimensionamento: o que medir
A comparação econômica deve incluir aquisição e renovação de hardware, licenças, energia, refrigeração, storage, conectividade, suporte, monitoramento, backup e horas de administração. Uma solução que consome menos memória pode custar mais se exigir equipe especializada, ferramentas e operação de cluster desproporcionais à necessidade.
Um plano de capacidade deve utilizar séries temporais e perfis de carga. Métricas de CPU de um único dia não justificam o dimensionamento anual. É preciso considerar sazonalidade, retenção crescente de dados, cargas simultâneas, margens para manutenção e contingência para falha de host.
| Indicador | Evidência operacional | Decisão que suporta |
| CPU e p95 de uso | Telemetria histórica | Número e perfil de hosts |
| Pressão de RAM | OOM, swap, memory working set | Reservas e limites |
| IOPS e latência | Métricas de storage por volume | Classe de armazenamento |
| Throughput de rede | Tráfego por fluxo e horário | Capacidade e segmentação |
| RTO e RPO | Relatórios de restore testado | Estratégia de continuidade |
| Mudanças malsucedidas | Incidentes e rollback | Maturidade de operação |
Licenciamento também altera resultados. Métricas por core, socket, host, usuário ou instância podem produzir custos distintos em arquiteturas virtuais e containerizadas. A hipótese de economia deve ser validada sobre os contratos reais e a política de suporte, não inferida do nome da tecnologia.
Containers em escala e a função do Kubernetes
Um runtime executa containers; um orquestrador gerencia workloads distribuídos e o estado desejado da plataforma. Kubernetes oferece recursos para agendar Pods, manter réplicas, publicar serviços, administrar configurações e coordenar mudanças, mas exige operação adequada de rede, storage, identidade e componentes de controle.
Nem todo ambiente precisa dessa complexidade. Um conjunto pequeno de serviços com baixa frequência de mudanças pode funcionar adequadamente em infraestrutura simples, desde que haja segurança, atualização, backup e documentação. Kubernetes se justifica melhor quando a escala, disponibilidade, diversidade de equipes e automação tornam a orquestração necessária.
Em qualquer plataforma, o sucesso depende de engenharia e governança de ciclo de vida. Registrar apenas o deploy bem-sucedido não comprova maturidade. É necessário demonstrar resposta a upgrades, falha de nós, indisponibilidade de volumes, expiração de certificados e recuperação de dados.
O critério não deve ser usar a ferramenta mais sofisticada. Deve ser entregar o nível de serviço requerido com responsabilidade, previsibilidade e custo justificável.
Projeto, homologação e critérios de aceite
O projeto básico deve registrar objetivos, sistemas, dependências, requisitos de desempenho, disponibilidade, segurança, integridade de dados e continuidade. O projeto executivo deve definir topologia, fluxos, endereçamento, recursos, políticas, matrizes de acesso, integração, automação e documentação necessária para operação.
O plano de implantação deve separar ambiente de homologação, transição de dados, janela de manutenção, rollback e testes de recuperação. Também precisa tratar versões de firmware, hypervisor, runtime e aplicações. Compatibilidade é requisito verificável, não premissa assumida.
A documentação mínima inclui inventário de workloads, arquitetura lógica e física, matriz de dependências, plano de capacidade, matriz de portas, estratégia de hardening, política de imagens, backup, disaster recovery, monitoramento e roteiro de testes. A entrega somente é completa quando operações e responsáveis aceitam esses artefatos.
Para plataformas críticas, o projeto de Data Center precisa compatibilizar infraestrutura computacional com energia, refrigeração, conectividade, continuidade e gestão de mudanças. Essa coordenação reduz a distância entre desenho de TI e condições reais de operação.
Erros recorrentes e limitações das abordagens
Os erros mais frequentes são escolher a ferramenta antes dos requisitos, confundir reinício automático com recuperação, ignorar persistência e backups, utilizar imagens sem rastreabilidade, conceder privilégios administrativos excessivos e deixar fluxos de rede sem documentação.
Há também risco de generalizações. Containers não eliminam necessidade de VMs, e VMs não dispensam modernização. Aplicações de baixa criticidade e alta cadência de mudança podem exigir práticas diferentes das aplicadas a ambientes industriais, bancos de dados e plataformas institucionais com exigências formais de auditoria.
A melhor arquitetura é a que pode ser mantida, evoluída e recuperada por uma equipe real, com responsabilidades e limites conhecidos. Complexidade sem capacidade de operação representa uma nova fonte de risco.
Estudo aplicado: modernização de uma infraestrutura corporativa
Imagine uma organização que mantém ERP legado, serviços de autenticação, banco de dados transacional e aplicações de integração utilizadas por vinte filiais. A substituição de toda a arquitetura por containers seria uma decisão precipitada. O primeiro trabalho de engenharia consiste em mapear serviços, proprietários, dependências, portas, versões, vínculos de licenciamento, requisitos de disponibilidade e fluxos de dados. A ausência desse inventário pode fazer uma migração aparentemente simples interromper processos de negócio que dependem de sistemas não documentados.
Em seguida, são coletadas métricas de CPU, memória, IOPS, latência de storage, volume de transações e tráfego de rede, considerando horários de pico e crescimento previsto. É necessário distinguir capacidade alocada, consumo real e reserva para falhas. A análise identifica, por exemplo, um sistema legado que exige ambiente operacional específico e serviços de integração que podem ser distribuídos como aplicações em containers. O diagnóstico também verifica quais equipes serão responsáveis por patches, runtime e restauração.
Uma opção tecnicamente consistente é manter o sistema legado e seu banco em máquinas virtuais com suporte conhecido, enquanto APIs e serviços independentes são containerizados gradualmente. O projeto detalha políticas de rede, autenticação mútua quando necessária, DNS, certificados, monitoramento e backup das diferentes camadas. Essas responsabilidades não desaparecem quando a equipe altera a tecnologia de execução.
A implementação deve seguir homologação, testes com carga representativa, ensaios de restauração, plano de cutover, rollback e operação assistida. A passagem de uma etapa à seguinte depende de evidências verificáveis. Se os testes revelarem falhas de dependência ou degradação de desempenho, a equipe corrige o desenho antes da entrada em produção. Esse procedimento preserva investimento existente e permite validar ganhos reais de modernização.
Como organizar uma matriz de decisão técnica
Para comparar VMs e containers, a matriz de decisão deve tratar compatibilidade, isolamento, disponibilidade, segurança, persistência de dados, custo de ciclo de vida e maturidade operacional. Cada critério exige evidência associada: medidas de desempenho, contratos de suporte, requisitos do negócio, arquitetura de rede ou resultado de testes. Uma pontuação sem justificativa apenas transforma preferência tecnológica em aparência de método.
A criticidade altera os pesos. Uma aplicação interna com poucas transações e tolerância a horas de parada pode operar com infraestrutura simples, desde que tenha backup e suporte. Uma plataforma corporativa que sustenta controle de acesso ou processamento de eventos precisa comprovar segregação, continuidade, integridade e resposta a falhas. Não é tecnicamente correto atribuir o mesmo nível de exigência a ambos os serviços.
Custos devem incluir licenciamento por core ou host, storage, energia, refrigeração, rede, horas de administração, ferramentas de observabilidade, proteção de dados e renovação tecnológica. Uma plataforma sem taxa de licença pode representar maior despesa caso necessite equipe especializada para controlar a complexidade. Em contrapartida, consolidar servidores subutilizados pode reduzir custos recorrentes. O cálculo precisa ser baseado em cenários mensuráveis, não em afirmações genéricas sobre economia.
A conclusão da matriz deve explicitar alternativas rejeitadas, riscos residuais, responsáveis por aceitá-los, limites de desempenho e situações que exigirão revisão futura. Com isso, a decisão torna-se auditável e pode acompanhar mudanças de escala, fornecedores e necessidades operacionais.
Comissionamento, testes de continuidade e operação assistida
O comissionamento de uma plataforma virtualizada não termina quando uma máquina virtual inicia ou quando o runtime exibe um container em execução. Um sistema pode estar tecnicamente ligado e ainda assim não conseguir concluir uma transação. Por isso, a homologação executa fluxos reais, verifica o acesso a bases de dados, mede tempo de resposta, avalia integridade de registros e documenta critérios objetivos de aceitação.
No ensaio de perda de host, mede-se a detecção da falha, a reação dos mecanismos de alta disponibilidade e o tempo até a aplicação retornar a uma condição operacional. No restore, uma cópia independente é recuperada em ambiente isolado, permitindo confirmar integridade de dados e atendimento a RPO e RTO. Um snapshot local não substitui esse ensaio, pois pode compartilhar o mesmo domínio de falha do sistema original.
A operação assistida acompanha capacidade, latência de storage, falhas de rede, erros das aplicações, vencimento de certificados, pressão de memória e alterações de configuração. Cada alerta precisa ter destinatário, prioridade, procedimento e critério de escalonamento. Sem uma cadeia de resposta, painéis sofisticados não asseguram recuperação mais rápida.
Na entrega, devem estar disponíveis os inventários, diagramas lógicos, matriz de portas, políticas de acesso, registros de versões, procedimentos de atualização, estratégias de backup, documentação as-built e evidências dos testes. A passagem para a operação exige treinamento, validação de credenciais e aceitação formal do suporte. O projeto só está completo quando a infraestrutura pode ser mantida sem dependência informal de seus implementadores.
Edge computing e aplicações em infraestrutura distribuída
Em ambientes de varejo, indústria, subestações e infraestrutura distribuída, a execução de workloads próximos à origem dos dados impõe restrições específicas. Nós de edge podem processar eventos de câmeras, consolidar informações de controle de acesso ou sustentar gateways de integração. O projeto precisa avaliar conectividade intermitente, armazenamento local, retomada de sincronização, temperatura, disponibilidade de energia e capacidade de manutenção remota.
Containers podem simplificar a distribuição de agentes e pipelines de dados, enquanto VMs podem atender a plataformas que requerem sistemas operacionais específicos. A avaliação deve considerar o hardware instalado e o desempenho de fluxos reais, especialmente em processamento de vídeo. Em sites com UPS limitado ou ambiente físico agressivo, energia e refrigeração influenciam mais a confiabilidade do que a diferença de overhead entre modelos de execução.
É fundamental definir quais funções permanecem disponíveis quando o link WAN cai, por quanto tempo eventos serão armazenados e como a sincronização acontecerá sem duplicidade ou perda de registros. A rede deve preservar limites entre sistemas administrativos, automação, videomonitoramento e acesso remoto, com identificação e registro das sessões autorizadas.
A resiliência deve ser demonstrada por cenários de falha combinados, incluindo queda de enlace, reinicialização do host e indisponibilidade de um serviço central. O resultado relevante é manter funções críticas e recuperar os dados dentro dos limites estabelecidos, não apenas reiniciar processos automaticamente. Uma arquitetura robusta é aquela cujo comportamento diante de falhas é conhecido, testado e documentado.
Considerações finais
Virtualização e containers são instrumentos complementares para organizar workloads e infraestrutura. A primeira pode favorecer compatibilidade e isolamento por sistema operacional; a segunda favorece padronização, distribuição e atualização das aplicações. Nenhuma delas substitui a engenharia de redes, storage, segurança, energia, governança e continuidade.
Projetos consistentes documentam requisitos, justificam escolhas, medem desempenho e validam recuperação. O resultado esperado não é apenas maior eficiência de servidores, mas serviços confiáveis, rastreáveis e capazes de sustentar a operação ao longo de seu ciclo de vida.
Referências técnicas
[1] Docker Inc.. What is a container? Containers versus virtual machines. Disponível em: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container.
[2] Kubernetes. Concepts — architecture and workloads. Disponível em: https://kubernetes.io/docs/concepts/.
[3] NIST. Application Container Security Guide, SP 800-190. Disponível em: https://csrc.nist.gov/pubs/sp/800/190/final.
[4] CNCF. Cloud Native Definition. Disponível em: https://github.com/cncf/toc/blob/main/DEFINITION.md.
Perguntas frequentes
Uma VM executa sistema operacional convidado; containers isolam aplicações e normalmente compartilham kernel com o host.
Não. Containers podem executar em VMs e muitas arquiteturas combinam as duas tecnologias.
Não. As duas abordagens exigem hardening, controle de acessos, atualização e análise de riscos.
Não. Docker é conhecido por ferramentas de containers; Kubernetes gerencia workloads distribuídos e estado desejado.
Não. A necessidade depende de escala, disponibilidade, autonomia e maturidade operacional.
Não. Backups independentes e testes de restauração são necessários para lidar com exclusão, corrupção e falhas.
É alocar recursos virtuais acima da capacidade física disponível, prática que exige monitoramento de contenção.
Sim, utilizando volumes ou serviços externos com estratégias de consistência e backup.
Use TCO, considerando hardware, licenças, operação, backup, segurança, suporte, energia e continuidade.
Capacidade, fluxo de rede, segurança, atualização, falhas de componentes, rollback e restauração testada.
