Uma AMI empacota um sistema operativo completo mais o seu software: é o modelo de uma máquina virtual inteira. Um contentor empacota apenas a sua aplicação e as dependências, partilhando o kernel do anfitrião. A diferença de tamanho e de modelo de isolamento explica quase tudo.
Não é uma batalha: na prática os contentores correm sobre máquinas virtuais que arrancam a partir de uma AMI. A pergunta útil não é qual ganha, mas que camada cada um resolve.
Comparação direta
| Dimensão | AMI (máquina virtual) | Contentor |
|---|---|---|
| O que inclui | SO completo mais software | App e dependências |
| Isolamento | Forte, por hipervisor | Ao nível do processo, kernel partilhado |
| Tamanho | Gigabytes | Megabytes |
| Arranque | Segundos a minutos | Milissegundos a segundos |
| Densidade | Menor: uma VM por instância | Alta: muitos por anfitrião |
| Portabilidade | Ligada à nuvem ou ao hipervisor | Muito alta: qualquer anfitrião com runtime |
| Manutenção do SO | Gere-a você | Herdada do anfitrião ou da imagem base |
| Caso ideal | Monólitos, anfitriões, VMs dedicadas | Microsserviços, escalamento rápido |
AMIs e contentores resolvem problemas diferentes em camadas diferentes.
Quando escolher uma AMI
- Isolamento forte obrigatório: cargas multi-inquilino ou requisitos regulatórios rigorosos em que o isolamento do hipervisor é um requisito.
- Software que espera uma máquina completa: bases de dados, aplicações legadas, appliances de rede ou de segurança.
- Controlo total do sistema operativo: quando precisa de módulos de kernel, controladores específicos ou de um ajuste fino do SO.
- Base dos seus nós: mesmo num mundo de contentores, os nós de Kubernetes arrancam a partir de uma AMI.
Quando escolher contentores
- Microsserviços que escalam e são implantados de forma independente.
- Ciclos de implantação rápidos com integração e entrega contínuas.
- Alta densidade para espremer o hardware com muitas cargas pequenas.
- Portabilidade entre desenvolvimento, testes e várias nuvens.
A resposta madura: combiná-los
As equipas avançadas não escolhem um ou outro, estratificam. Constroem uma golden AMI endurecida como base do anfitrião —atualizada, com hardening CIS e agentes de segurança— e sobre ela executam os contentores. Assim obtêm o melhor dos dois mundos: a segurança e o controlo do anfitrião ao nível da imagem de máquina, e a agilidade e densidade dos contentores ao nível da aplicação.
- Nós de Kubernetes ou ECS baseados numa AMI endurecida e versionada.
- Atualização do anfitrião por substituição de AMI (imutável), não por patch a quente.
- Contentores para o ciclo de vida rápido da aplicação.
MicroVMs: a fronteira esbate-se
Tecnologias como o Firecracker —a que está por trás do AWS Lambda e do Fargate— criam microVMs: o isolamento forte de uma máquina virtual com tempos de arranque na ordem dos milissegundos, quase como um contentor. É o sinal de que o futuro não é «VM ou contentor», mas um contínuo onde escolhe o ponto certo entre isolamento e agilidade para cada carga.
Perguntas frequentes
Os contentores tornam as AMIs obsoletas?
Não. Os contentores correm sobre máquinas que arrancam a partir de imagens. Uma AMI endurecida continua a ser a base ideal para os nós que executam os seus contentores.
O que é mais seguro, uma VM ou um contentor?
A VM oferece um isolamento mais forte por conceção. Os contentores partilham kernel, pelo que exigem controlos adicionais. Para cargas muito sensíveis, a combinação de VM e contentor endurecido é o habitual.
Posso migrar de AMIs para contentores facilmente?
Depende da aplicação. Os serviços sem estado e modulares migram bem; os monólitos com forte acoplamento ao SO exigem mais trabalho. Muitas vezes convém uma abordagem híbrida e gradual.
Na imaxe.cloud acreditamos na ferramenta certa para cada carga: por isso as nossas imagens servem tanto de anfitrião direto como de base endurecida para os seus contentores.
