{"id":1509,"date":"2025-04-18T15:58:32","date_gmt":"2025-04-18T15:58:32","guid":{"rendered":"https:\/\/mugnos-it.com\/?p=1509"},"modified":"2025-06-03T00:50:03","modified_gmt":"2025-06-03T00:50:03","slug":"containers-no-design-de-sistemas-sao-sempre-a-melhor-escolha","status":"publish","type":"post","link":"https:\/\/mugnos-it.com\/pt\/containers-no-design-de-sistemas-sao-sempre-a-melhor-escolha\/","title":{"rendered":"Containers no Design de Sistemas: S\u00e3o Sempre a Melhor Escolha ?"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n

Fala, galera! beleza ?! \ud83d\udc4b
<\/p>\n\n\n\n

Nos dias de hoje, quando se fala em arquitetura de software, parece que containers s\u00e3o obrigat\u00f3rios<\/strong>, n\u00e9? Principalmente em empresas de m\u00e9dio e grande porte, a ideia de “precisamos containerizar tudo” se espalha rapidamente. Isso acontece muito no meu dia a dia, e com voc\u00ea? Acho que n\u00e3o sou o \u00fanico “sortudo\u201d<\/em> aqui n\u00e3o \ud83d\udc40 \u2026 Mas ser\u00e1 que essa \u00e9 sempre a melhor escolha? \ud83e\udd14
<\/p>\n\n\n\n

A verdade \u00e9 que a decis\u00e3o de usar containers deve ser baseada em necessidades reais, e n\u00e3o apenas seguir a hype. Por\u00e9m, confesso que em m\u00e9dias\/grandes organiza\u00e7\u00f5es, seguir a hype \u00e0s vezes pode ser at\u00e9 estrat\u00e9gico e fazer sentido. Por isso, quero compartilhar alguns pontos que justificam esse desejo t\u00e3o grande por containers e, claro, levantar algumas reflex\u00f5es sobre quando essa escolha realmente vale a pena (ou n\u00e3o).<\/p>\n\n\n\n

Dimens\u00f5es a Considerar no Uso de Containers \ud83d\udea2<\/h2>\n\n\n\n

\u2705 Portabilidade<\/h3>\n\n\n\n

Um dos maiores argumentos para containers \u00e9 a portabilidade. A capacidade de rodar um software em qualquer lugar \u2014 seja na m\u00e1quina do dev, no servidor de staging ou na nuvem \u2014 \u00e9 incr\u00edvel. Imagine uma aplica\u00e7\u00e3o que precisa ser testada em ambientes diversos antes do deploy final: com containers, voc\u00ea garante que a aplica\u00e7\u00e3o se comportar\u00e1 de forma id\u00eantica em cada um deles.<\/p>\n\n\n\n

Agora, pense em um cen\u00e1rio onde uma empresa decide migrar sua infraestrutura de um provedor de nuvem para outro (ex: Google Cloud para AWS<\/strong>, ou vice-versa), ou at\u00e9 mesmo sair de um ambiente on-premise<\/strong> para a nuvem. Sem containers, essa migra\u00e7\u00e3o pode ser mais complexa, exigindo ajustes na configura\u00e7\u00e3o de servidores, depend\u00eancias e at\u00e9 reescrita de partes da aplica\u00e7\u00e3o. Com containers, essa transi\u00e7\u00e3o se torna muito mais tranquila: basta garantir que a nova infraestrutura suporte a orquestra\u00e7\u00e3o e o runtime de containers, e a aplica\u00e7\u00e3o roda sem grandes dores de cabe\u00e7a.<\/p>\n\n\n\n

(Claro, d\u00e1 pra fazer app ruim<\/strong> em qualquer lugar, mas seguir os princ\u00edpios do 12-Factor App<\/strong> ajuda muito a criar aplica\u00e7\u00f5es realmente port\u00e1teis dentro de containers. Por isso, sempre falo sobre o 12-Factor App<\/strong> na Comunidade de Arquitetura Descomplicada<\/strong>, porque ele \u00e9 um \u00f3timo guia para quem quer aproveitar containers do jeito certo!)
<\/p>\n\n\n\n

\u2705 Escalabilidade<\/h3>\n\n\n\n

Containers permitem escalabilidade eficiente, pois possibilitam rodar v\u00e1rias inst\u00e2ncias sem grande complexidade. Por exemplo, em um e-commerce que precisa lidar com picos de acesso na Black Friday<\/strong>, subir novos containers de um servi\u00e7o espec\u00edfico \u00e9 muito mais r\u00e1pido do que configurar novas m\u00e1quinas do zero.<\/p>\n\n\n\n

MASSS CLARO<\/strong> que n\u00e3o \u00e9 t\u00e3o simples assim, n\u00e9?! Apesar de voc\u00ea realmente ter a capacidade \u00fanica de subir inst\u00e2ncias de containers em n\u00f3s compartilhados, ainda assim h\u00e1 um overhead operacional<\/strong>. Al\u00e9m disso, em alguns casos, faz sentido se perguntar: por que usar HPA (Horizontal Pod Autoscaler) e KEDA para escalar containers, se um servidor f\u00edsico parrudo poderia atender toda a demanda?<\/strong> Parece loucura, mas n\u00e3o deixa de ser um trade-off<\/strong> v\u00e1lido!<\/p>\n\n\n\n

E outra, a romantiza\u00e7\u00e3o da escalabilidade \u00e9 linda\u2026 tudo cresce, tudo escala\u2026 mas n\u00e3o \u00e9 s\u00f3 sobre % de CPU n\u00e3o, hein!<\/strong> POD n\u00e3o nasce do nada\u2014ele precisa de nodes<\/strong>, e nodes precisam ser iniciados, o que pode adicionar lat\u00eancia na escalabilidade autom\u00e1tica. Ou seja, n\u00e3o \u00e9 m\u00e1gica, tem custo e tempo envolvido. \ud83d\ude06
<\/p>\n\n\n\n

\u2705 Deployment<\/h3>\n\n\n\n

Com containers, voc\u00ea pode usar estrat\u00e9gias como Blue\/Green Deployment<\/strong> ou Canary Releases<\/strong>, reduzindo riscos ao atualizar sistemas em produ\u00e7\u00e3o. Isso permite validar novas vers\u00f5es com um grupo pequeno de usu\u00e1rios antes de expandir para toda a base.
<\/p>\n\n\n\n

Mas a real vantagem dos containers quando falamos de deployment<\/strong> vai al\u00e9m disso. A capacidade de gerenciar atualiza\u00e7\u00f5es, roteamento de tr\u00e1fego e rollback<\/strong> apenas alterando manifests<\/strong> (YAML no Kubernetes, por exemplo) simplifica absurdamente o processo. Com apenas algumas configura\u00e7\u00f5es, voc\u00ea pode espelhar tr\u00e1fego real para testar a nova vers\u00e3o sem impactar usu\u00e1rios, alterar rotas dinamicamente via Service Mesh sem modificar c\u00f3digo, definir regras autom\u00e1ticas de rollback caso algo d\u00ea errado e liberar novas vers\u00f5es de forma progressiva e controlada<\/strong>.<\/p>\n\n\n\n

Ou seja, containers n\u00e3o s\u00f3 tornam o deploy mais seguro<\/strong>, mas tamb\u00e9m muito mais din\u00e2mico e program\u00e1vel<\/strong>, permitindo que todo esse gerenciamento seja feito como c\u00f3digo. Isso reduz riscos e torna o processo mais previs\u00edvel e f\u00e1cil de automatizar.<\/p>\n\n\n\n

\u2705 Testes<\/h3>\n\n\n\n

Containers tornam a automa\u00e7\u00e3o de testes muito mais simples e eficiente. Com um pipeline bem estruturado, voc\u00ea consegue validar cada mudan\u00e7a antes que ela chegue \u00e0 produ\u00e7\u00e3o, garantindo qualidade sem surpresas. \u00c9 f\u00e1cil configurar um fluxo onde o c\u00f3digo passa por testes unit\u00e1rios, integra\u00e7\u00e3o, carga e end-to-end<\/strong> nos ambientes de desenvolvimento (dev), homologa\u00e7\u00e3o (homo) e produ\u00e7\u00e3o (prod)<\/strong>, tudo de forma automatizada.<\/p>\n\n\n\n

Al\u00e9m disso, containers permitem rodar testes isolados e paralelos<\/strong>, criando inst\u00e2ncias ef\u00eameras sob demanda, sem impactar o ambiente principal. No caso de testes de carga<\/strong>, \u00e9 poss\u00edvel simular m\u00faltiplas r\u00e9plicas do sistema para validar como ele se comporta sob alto volume de requisi\u00e7\u00f5es, garantindo que esteja preparado para escalar quando necess\u00e1rio.<\/p>\n\n\n\n

Se algo der errado, rollback<\/strong> \u00e9 imediato: basta reverter a imagem do container para a vers\u00e3o anterior e restaurar o estado desejado.<\/p>\n\n\n\n

Com isso, o processo de testes se torna mais previs\u00edvel, seguro e \u00e1gil<\/strong>, reduzindo erros em produ\u00e7\u00e3o e acelerando entregas com confian\u00e7a.<\/p>\n\n\n\n

\u2705 Infraestrutura<\/h3>\n\n\n\n

Containers otimizam recursos ao isolar aplica\u00e7\u00f5es sem a necessidade de uma VM para cada servi\u00e7o, reduzindo consumo de hardware e melhorando a efici\u00eancia da infraestrutura. Mas, claro<\/strong>, para gerenciar isso de forma eficiente, voc\u00ea precisa de um orquestrador<\/strong>. N\u00e3o \u00e9 s\u00f3 sobre rodar containers; \u00e9 sobre gerenci\u00e1-los em escala com orquestradores como ECS, Kubernetes (K8s) e EKS.<\/strong><\/p>\n\n\n\n

\u2705Observabilidade<\/h3>\n\n\n\n

Containers facilitam a padroniza\u00e7\u00e3o de logs e m\u00e9tricas<\/strong>, garantindo que aplica\u00e7\u00f5es diferentes sigam um mesmo formato de sa\u00edda (stdout\/stderr<\/strong>). Com isso, fica muito mais simples coletar, monitorar e analisar logs de servi\u00e7os distribu\u00eddos sem depender de configura\u00e7\u00f5es individuais para cada aplica\u00e7\u00e3o.<\/p>\n\n\n\n

Al\u00e9m disso, a instrumenta\u00e7\u00e3o pode ser feita de forma automatizada e consistente<\/strong> com agentes provisionados como DaemonSets<\/strong> no Kubernetes, garantindo que todos os containers enviem logs e m\u00e9tricas de maneira uniforme. Isso permite ingerir os dados em ferramentas especializadas, como ELK Stack (Elasticsearch, Logstash, Kibana), Loki, Datadog ou New Relic<\/strong>, mantendo um padr\u00e3o centralizado e facilitando a an\u00e1lise e troubleshooting.<\/p>\n\n\n\n

T\u00e1, t\u00e1, t\u00e1\u2026 at\u00e9 entendo que voc\u00ea pode conseguir algo pr\u00f3ximo disso sem containers, mas oloco<\/strong>, atualizar agentes de monitora\u00e7\u00e3o manualmente em v\u00e1rias m\u00e1quinas simplesmente n\u00e3o faz sentido nenhum<\/strong>. Com Kubernetes e containers, isso se resolve \u201cfacilmente\u201d<\/em> (ps: com um pouco de suor, vai…<\/strong>), garantindo que toda a stack de observabilidade seja gerenciada de forma unificada e sem dor de cabe\u00e7a.
<\/p>\n\n\n\n

\u2705 Resili\u00eancia
<\/h3>\n\n\n\n

Containers aumentam a resili\u00eancia<\/strong> dos sistemas ao permitir reinicializa\u00e7\u00e3o autom\u00e1tica<\/strong> de servi\u00e7os em caso de falhas. J\u00e1 viu aquele cen\u00e1rio onde uma API para de responder e precisa ser reiniciada manualmente? Com containers e um orquestrador<\/strong> como Kubernetes<\/strong>, isso \u00e9 resolvido automaticamente, garantindo que as aplica\u00e7\u00f5es sempre estejam rodando corretamente.<\/p>\n\n\n\n

Al\u00e9m disso, a resili\u00eancia vai al\u00e9m de simplesmente reiniciar servi\u00e7os. Com ReplicaSets<\/strong>, \u00e9 f\u00e1cil manter m\u00faltiplas inst\u00e2ncias de uma aplica\u00e7\u00e3o distribu\u00eddas para evitar downtime. O pr\u00f3prio orquestrador aplica mecanismos de reconcilia\u00e7\u00e3o<\/strong>, garantindo que o estado desejado da aplica\u00e7\u00e3o seja mantido \u2014 se um n\u00f3 cair, os pods s\u00e3o recriados em outro n\u00f3 automaticamente.<\/p>\n\n\n\n

Comparado a uma infraestrutura tradicional baseada em VMs<\/strong>, onde a alta disponibilidade depende de configura\u00e7\u00f5es manuais e balanceadores de carga externos, containers tornam todo esse processo muito mais simples e eficiente.<\/p>\n\n\n\n

\u2705 Operacional<\/h3>\n\n\n\n

Apesar de padronizar, operacionalizar um orquestrador de containers<\/strong> pode ser algo tranquilo ou uma verdadeira dor de cabe\u00e7a. No Kubernetes<\/strong>, por exemplo, a quantidade de addons, funcionalidades, integra\u00e7\u00f5es, atualiza\u00e7\u00f5es e patches<\/strong> pode parecer simples no come\u00e7o, mas logo voc\u00ea percebe que s\u00e3o muitas vari\u00e1veis para gerenciar.<\/p>\n\n\n\n

Ainda assim, eu acho o overhead operacional<\/strong> de containers menor comparado a cen\u00e1rios onde voc\u00ea depende de diferentes equipes especializadas<\/strong> para provisionar desde uma VM at\u00e9 a aplica\u00e7\u00e3o<\/strong>. Com containers e um orquestrador bem configurado, infraestrutura e aplica\u00e7\u00e3o se aproximam<\/strong>, reduzindo burocracias e acelerando entregas.<\/p>\n\n\n\n

\u2705 Infra as Code (IaC)<\/h3>\n\n\n\n

Containers se integram perfeitamente com IaC<\/strong> (como Terraform, Ansible, Crossplane<\/strong>), permitindo que toda a infraestrutura seja definida como c\u00f3digo. Isso facilita automa\u00e7\u00e3o, reprodutibilidade e versionamento<\/strong>, garantindo que ambientes possam ser provisionados e atualizados de forma consistente.<\/p>\n\n\n\n

Al\u00e9m disso, com GitOps<\/strong> e ferramentas como ArgoCD e Flux<\/strong>, \u00e9 poss\u00edvel gerenciar deploys e infraestrutura de forma declarativa, trazendo ainda mais controle e seguran\u00e7a para as opera\u00e7\u00f5es.
<\/p>\n\n\n\n

\u2705 Custo<\/h3>\n\n\n\n

Dependendo do uso, containers podem reduzir custos ao otimizar o uso de hardware. Ao consolidar m\u00faltiplas aplica\u00e7\u00f5es em um \u00fanico cluster e permitir escalabilidade din\u00e2mica, voc\u00ea evita desperd\u00edcio de recursos com servidores subutilizados.<\/p>\n\n\n\n

Mas cuidado<\/strong>: se mal planejado, o uso de containers pode elevar complexidade e custos desnecessariamente. Por exemplo, migrar uma aplica\u00e7\u00e3o monol\u00edtica diretamente para Kubernetes<\/strong> sem refatora\u00e7\u00e3o pode resultar em um consumo excessivo de recursos, pois cada inst\u00e2ncia da aplica\u00e7\u00e3o precisaria de containers completos e possivelmente replica\u00e7\u00e3o de depend\u00eancias. Em alguns casos, manter uma infraestrutura mais simples, como VMs bem ajustadas, pode ser mais eficiente financeiramente.<\/p>\n\n\n\n

\n\n\n\n

Conclus\u00e3o<\/h2>\n\n\n\n

Sim, containers trazem muitos benef\u00edcios e valem o investimento<\/strong> em muitos casos. Mas nem sempre s\u00e3o a melhor escolha! Em algumas situa\u00e7\u00f5es, outras solu\u00e7\u00f5es mais simples podem atender aos mesmos objetivos de neg\u00f3cio sem adicionar complexidade desnecess\u00e1ria.<\/p>\n\n\n\n

\u00c9 verdade que containers podem aumentar custos e adicionar overhead operacional<\/strong>, mas como descrevi nos pontos acima, os benef\u00edcios muitas vezes compensam esse custo\u2014principalmente para empresas m\u00e9dias\/grandes<\/strong>. Quando bem utilizados, eles trazem agilidade no desenvolvimento, padroniza\u00e7\u00e3o de infraestrutura e facilidade na escalabilidade<\/strong>, permitindo que times entreguem novas funcionalidades com mais rapidez e seguran\u00e7a. E isso, n\u00e3o tem valor para um neg\u00f3cio maduro.<\/p>\n\n\n\n

Al\u00e9m disso, o custo dos containers vale o pre\u00e7o<\/strong>, mesmo que, em alguns cen\u00e1rios, rodar uma aplica\u00e7\u00e3o diretamente em uma VM tradicional pare\u00e7a mais barato<\/strong>. O ganho em flexibilidade, automa\u00e7\u00e3o, resili\u00eancia e efici\u00eancia operacional<\/strong> justifica o investimento, pois reduz depend\u00eancias, acelera ciclos de entrega e melhora a confiabilidade dos sistemas.<\/p>\n\n\n\n

No fim das contas, arquitetura n\u00e3o \u00e9 sobre seguir tend\u00eancias, e sim sobre escolher o que faz mais sentido para seu contexto<\/strong>. Como sempre digo na CaD<\/strong>, criar aplica\u00e7\u00f5es resilientes n\u00e3o \u00e9 s\u00f3 sobre design da aplica\u00e7\u00e3o enquanto ela est\u00e1 rodando, mas tamb\u00e9m garantir que ela seja resiliente inclusive durante o deployment!<\/strong> \ud83d\udcaa\ud83d\ude80<\/p>\n\n\n\n

Exemplo? Imagine um sistema banc\u00e1rio onde a disponibilidade \u00e9 cr\u00edtica. Se voc\u00ea puder fazer um deployment gradativo sem downtime, utilizando containers e feature flags, o impacto para os usu\u00e1rios \u00e9 minimizado, garantindo uma experi\u00eancia mais est\u00e1vel e segura.<\/p>\n\n\n\n

E voc\u00ea, como tem utilizado containers em seus projetos?<\/p>\n\n\n\n

Abra\u00e7os,<\/p>\n\n\n\n

Douglas Mugnos<\/p>\n\n\n\n

MUGNOS-IT<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"

Fala, galera! beleza ?! \ud83d\udc4b Nos dias de hoje, quando se fala em arquitetura de software, parece que containers s\u00e3o obrigat\u00f3rios, n\u00e9? Principalmente em empresas de m\u00e9dio e grande porte, a ideia de “precisamos containerizar tudo” se espalha rapidamente. Isso acontece muito no meu dia a dia, e com voc\u00ea? Acho que n\u00e3o sou o […]<\/p>","protected":false},"author":3,"featured_media":1899,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1509","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/mugnos-it.com\/wp-content\/uploads\/2025\/04\/07.-containers-3.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/1509","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/comments?post=1509"}],"version-history":[{"count":4,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/1509\/revisions"}],"predecessor-version":[{"id":2034,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/1509\/revisions\/2034"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media\/1899"}],"wp:attachment":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media?parent=1509"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/categories?post=1509"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/tags?post=1509"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}