Fala, galera! beleza ?! 👋
Nos dias de hoje, quando se fala em arquitetura de software, parece que containers são obrigatórios, né? Principalmente em empresas de médio e grande porte, a ideia de “precisamos containerizar tudo” se espalha rapidamente. Isso acontece muito no meu dia a dia, e com você? Acho que não sou o único “sortudo” aqui não 👀 … Mas será que essa é sempre a melhor escolha? 🤔
A verdade é que a decisão de usar containers deve ser baseada em necessidades reais, e não apenas seguir a hype. Porém, confesso que em médias/grandes organizações, seguir a hype às vezes pode ser até estratégico e fazer sentido. Por isso, quero compartilhar alguns pontos que justificam esse desejo tão grande por containers e, claro, levantar algumas reflexões sobre quando essa escolha realmente vale a pena (ou não).
Dimensões a Considerar no Uso de Containers 🚢
✅ Portabilidade
Um dos maiores argumentos para containers é a portabilidade. A capacidade de rodar um software em qualquer lugar — seja na máquina do dev, no servidor de staging ou na nuvem — é incrível. Imagine uma aplicação que precisa ser testada em ambientes diversos antes do deploy final: com containers, você garante que a aplicação se comportará de forma idêntica em cada um deles.
Agora, pense em um cenário onde uma empresa decide migrar sua infraestrutura de um provedor de nuvem para outro (ex: Google Cloud para AWS, ou vice-versa), ou até mesmo sair de um ambiente on-premise para a nuvem. Sem containers, essa migração pode ser mais complexa, exigindo ajustes na configuração de servidores, dependências e até reescrita de partes da aplicação. Com containers, essa transição se torna muito mais tranquila: basta garantir que a nova infraestrutura suporte a orquestração e o runtime de containers, e a aplicação roda sem grandes dores de cabeça.
(Claro, dá pra fazer app ruim em qualquer lugar, mas seguir os princípios do 12-Factor App ajuda muito a criar aplicações realmente portáteis dentro de containers. Por isso, sempre falo sobre o 12-Factor App na Comunidade de Arquitetura Descomplicada, porque ele é um ótimo guia para quem quer aproveitar containers do jeito certo!)
✅ Escalabilidade
Containers permitem escalabilidade eficiente, pois possibilitam rodar várias instâncias sem grande complexidade. Por exemplo, em um e-commerce que precisa lidar com picos de acesso na Black Friday, subir novos containers de um serviço específico é muito mais rápido do que configurar novas máquinas do zero.
MASSS CLARO que não é tão simples assim, né?! Apesar de você realmente ter a capacidade única de subir instâncias de containers em nós compartilhados, ainda assim há um overhead operacional. Além disso, em alguns casos, faz sentido se perguntar: por que usar HPA (Horizontal Pod Autoscaler) e KEDA para escalar containers, se um servidor físico parrudo poderia atender toda a demanda? Parece loucura, mas não deixa de ser um trade-off válido!
E outra, a romantização da escalabilidade é linda… tudo cresce, tudo escala… mas não é só sobre % de CPU não, hein! POD não nasce do nada—ele precisa de nodes, e nodes precisam ser iniciados, o que pode adicionar latência na escalabilidade automática. Ou seja, não é mágica, tem custo e tempo envolvido. 😆
✅ Deployment
Com containers, você pode usar estratégias como Blue/Green Deployment ou Canary Releases, reduzindo riscos ao atualizar sistemas em produção. Isso permite validar novas versões com um grupo pequeno de usuários antes de expandir para toda a base.
Mas a real vantagem dos containers quando falamos de deployment vai além disso. A capacidade de gerenciar atualizações, roteamento de tráfego e rollback apenas alterando manifests (YAML no Kubernetes, por exemplo) simplifica absurdamente o processo. Com apenas algumas configurações, você pode espelhar tráfego real para testar a nova versão sem impactar usuários, alterar rotas dinamicamente via Service Mesh sem modificar código, definir regras automáticas de rollback caso algo dê errado e liberar novas versões de forma progressiva e controlada.
Ou seja, containers não só tornam o deploy mais seguro, mas também muito mais dinâmico e programável, permitindo que todo esse gerenciamento seja feito como código. Isso reduz riscos e torna o processo mais previsível e fácil de automatizar.
✅ Testes
Containers tornam a automação de testes muito mais simples e eficiente. Com um pipeline bem estruturado, você consegue validar cada mudança antes que ela chegue à produção, garantindo qualidade sem surpresas. É fácil configurar um fluxo onde o código passa por testes unitários, integração, carga e end-to-end nos ambientes de desenvolvimento (dev), homologação (homo) e produção (prod), tudo de forma automatizada.
Além disso, containers permitem rodar testes isolados e paralelos, criando instâncias efêmeras sob demanda, sem impactar o ambiente principal. No caso de testes de carga, é possível simular múltiplas réplicas do sistema para validar como ele se comporta sob alto volume de requisições, garantindo que esteja preparado para escalar quando necessário.
Se algo der errado, rollback é imediato: basta reverter a imagem do container para a versão anterior e restaurar o estado desejado.
Com isso, o processo de testes se torna mais previsível, seguro e ágil, reduzindo erros em produção e acelerando entregas com confiança.
✅ Infraestrutura
Containers otimizam recursos ao isolar aplicações sem a necessidade de uma VM para cada serviço, reduzindo consumo de hardware e melhorando a eficiência da infraestrutura. Mas, claro, para gerenciar isso de forma eficiente, você precisa de um orquestrador. Não é só sobre rodar containers; é sobre gerenciá-los em escala com orquestradores como ECS, Kubernetes (K8s) e EKS.
✅Observabilidade
Containers facilitam a padronização de logs e métricas, garantindo que aplicações diferentes sigam um mesmo formato de saída (stdout/stderr). Com isso, fica muito mais simples coletar, monitorar e analisar logs de serviços distribuídos sem depender de configurações individuais para cada aplicação.
Além disso, a instrumentação pode ser feita de forma automatizada e consistente com agentes provisionados como DaemonSets no Kubernetes, garantindo que todos os containers enviem logs e métricas de maneira uniforme. Isso permite ingerir os dados em ferramentas especializadas, como ELK Stack (Elasticsearch, Logstash, Kibana), Loki, Datadog ou New Relic, mantendo um padrão centralizado e facilitando a análise e troubleshooting.
Tá, tá, tá… até entendo que você pode conseguir algo próximo disso sem containers, mas oloco, atualizar agentes de monitoração manualmente em várias máquinas simplesmente não faz sentido nenhum. Com Kubernetes e containers, isso se resolve “facilmente” (ps: com um pouco de suor, vai…), garantindo que toda a stack de observabilidade seja gerenciada de forma unificada e sem dor de cabeça.
✅ Resiliência
Containers aumentam a resiliência dos sistemas ao permitir reinicialização automática de serviços em caso de falhas. Já viu aquele cenário onde uma API para de responder e precisa ser reiniciada manualmente? Com containers e um orquestrador como Kubernetes, isso é resolvido automaticamente, garantindo que as aplicações sempre estejam rodando corretamente.
Além disso, a resiliência vai além de simplesmente reiniciar serviços. Com ReplicaSets, é fácil manter múltiplas instâncias de uma aplicação distribuídas para evitar downtime. O próprio orquestrador aplica mecanismos de reconciliação, garantindo que o estado desejado da aplicação seja mantido — se um nó cair, os pods são recriados em outro nó automaticamente.
Comparado a uma infraestrutura tradicional baseada em VMs, onde a alta disponibilidade depende de configurações manuais e balanceadores de carga externos, containers tornam todo esse processo muito mais simples e eficiente.
✅ Operacional
Apesar de padronizar, operacionalizar um orquestrador de containers pode ser algo tranquilo ou uma verdadeira dor de cabeça. No Kubernetes, por exemplo, a quantidade de addons, funcionalidades, integrações, atualizações e patches pode parecer simples no começo, mas logo você percebe que são muitas variáveis para gerenciar.
Ainda assim, eu acho o overhead operacional de containers menor comparado a cenários onde você depende de diferentes equipes especializadas para provisionar desde uma VM até a aplicação. Com containers e um orquestrador bem configurado, infraestrutura e aplicação se aproximam, reduzindo burocracias e acelerando entregas.
✅ Infra as Code (IaC)
Containers se integram perfeitamente com IaC (como Terraform, Ansible, Crossplane), permitindo que toda a infraestrutura seja definida como código. Isso facilita automação, reprodutibilidade e versionamento, garantindo que ambientes possam ser provisionados e atualizados de forma consistente.
Além disso, com GitOps e ferramentas como ArgoCD e Flux, é possível gerenciar deploys e infraestrutura de forma declarativa, trazendo ainda mais controle e segurança para as operações.
✅ Custo
Dependendo do uso, containers podem reduzir custos ao otimizar o uso de hardware. Ao consolidar múltiplas aplicações em um único cluster e permitir escalabilidade dinâmica, você evita desperdício de recursos com servidores subutilizados.
Mas cuidado: se mal planejado, o uso de containers pode elevar complexidade e custos desnecessariamente. Por exemplo, migrar uma aplicação monolítica diretamente para Kubernetes sem refatoração pode resultar em um consumo excessivo de recursos, pois cada instância da aplicação precisaria de containers completos e possivelmente replicação de dependências. Em alguns casos, manter uma infraestrutura mais simples, como VMs bem ajustadas, pode ser mais eficiente financeiramente.
Conclusão
Sim, containers trazem muitos benefícios e valem o investimento em muitos casos. Mas nem sempre são a melhor escolha! Em algumas situações, outras soluções mais simples podem atender aos mesmos objetivos de negócio sem adicionar complexidade desnecessária.
É verdade que containers podem aumentar custos e adicionar overhead operacional, mas como descrevi nos pontos acima, os benefícios muitas vezes compensam esse custo—principalmente para empresas médias/grandes. Quando bem utilizados, eles trazem agilidade no desenvolvimento, padronização de infraestrutura e facilidade na escalabilidade, permitindo que times entreguem novas funcionalidades com mais rapidez e segurança. E isso, não tem valor para um negócio maduro.
Além disso, o custo dos containers vale o preço, mesmo que, em alguns cenários, rodar uma aplicação diretamente em uma VM tradicional pareça mais barato. O ganho em flexibilidade, automação, resiliência e eficiência operacional justifica o investimento, pois reduz dependências, acelera ciclos de entrega e melhora a confiabilidade dos sistemas.
No fim das contas, arquitetura não é sobre seguir tendências, e sim sobre escolher o que faz mais sentido para seu contexto. Como sempre digo na CaD, criar aplicações resilientes não é só sobre design da aplicação enquanto ela está rodando, mas também garantir que ela seja resiliente inclusive durante o deployment! 💪🚀
Exemplo? Imagine um sistema bancário onde a disponibilidade é crítica. Se você puder fazer um deployment gradativo sem downtime, utilizando containers e feature flags, o impacto para os usuários é minimizado, garantindo uma experiência mais estável e segura.
E você, como tem utilizado containers em seus projetos?
Abraços,
Douglas Mugnos
MUGNOS-IT
