DEV Community: Kauê Matos

Instâncias AWS Graviton Instâncias AWS Graviton Arquitetura ARM na Nuvem

Kauê Matos — Sun, 13 Sep 2026 17:04:17 +0000

O AWS Graviton é uma família de processadores desenvolvidos pela própria AWS, baseados em arquitetura ARM (64-bit, Arm Neoverse), em vez da arquitetura x86 tradicional (Intel/AMD). Lançado inicialmente em 2018, o Graviton se tornou uma das principais estratégias da AWS para oferecer melhor custo-benefício e eficiência energética em instâncias EC2.

Hoje, praticamente todas as famílias de instância "de uso geral" da AWS (M, C, R, T e derivadas) possuem uma variante Graviton, identificada pelo sufixo g no nome (ex.: m7g, c7g, r7g, t4g).

Este artigo explica o que é o Graviton, como evoluiu ao longo das gerações, quando vale a pena adotar e quais são os principais cuidados de migração.

O que é o Graviton

Graviton é um System on Chip (SoC) projetado pela AWS Annapurna Labs (empresa israelense adquirida pela AWS em 2015), otimizado especificamente para rodar dentro da infraestrutura da própria AWS. Diferente de depender de fornecedores externos (Intel, AMD), a AWS controla o design do chip ponta a ponta — o que permite ajustar a arquitetura ao perfil real de uso dos seus data centers.

Principais vantagens declaradas pela AWS:

Melhor custo-benefício — em geral, 20% a 40% mais barato que instâncias x86 equivalentes.
Melhor performance por watt — até ~60% mais eficiente energeticamente, o que também contribui para metas de sustentabilidade (ESG) das empresas.
Performance competitiva ou superior em cargas de trabalho compatíveis, especialmente as que escalam horizontalmente.

Evolução das gerações

Graviton1 (2018)

Primeira geração, lançada com as instâncias a1. Voltada principalmente para cargas escaláveis horizontalmente e workloads que não exigiam alta performance de CPU por núcleo. Adoção limitada, mas serviu como prova de conceito.

Graviton2 (2019/2020)

Salto significativo de performance — baseado em núcleos Arm Neoverse N1. Introduziu as variantes g em famílias já conhecidas: m6g, c6g, r6g, t4g. Trouxe suporte a mais casos de uso de produção, com performance comparável a instâncias x86 de geração equivalente.

Graviton3 (2021/2022)

Presente em m7g, c7g, r7g, além de instâncias especializadas como c7gn (rede otimizada) e hpc7g (HPC). Trouxe ganhos relevantes em:

Performance de ponto flutuante (importante para HPC e ML)
Criptografia acelerada por hardware
Maior largura de banda de memória (DDR5)

Graviton4 (2023/2024)

Geração mais recente, presente em instâncias como r8g e m8g. Foco em maior número de núcleos, maior largura de banda de memória e melhorias de segurança, mantendo compatibilidade com o ecossistema ARM já validado nas gerações anteriores.

Famílias disponíveis com Graviton

Família x86 equivalente	Variante Graviton	Foco
M (uso geral)	m6g, m7g, m8g	Aplicações web, microsserviços
C (compute optimized)	c6g, c7g, c7gn	CPU intensiva, rede otimizada
R (memory optimized)	r6g, r7g, r8g	Bancos de dados, cache
T (burstable)	t4g	Cargas variáveis, dev/test
X (memória alta)	x2gd	In-memory databases
I (storage optimized)	i4g	NoSQL, alta taxa de I/O
Hpc	hpc7g	HPC fortemente acoplado

Quando vale a pena migrar para Graviton

Bons candidatos:

Aplicações stateless rodando em containers (Docker/Kubernetes) com imagens multi-arquitetura.
Linguagens/runtimes com suporte nativo e maduro a ARM: Java (JVM), Go, Python, Node.js, .NET.
Cargas de trabalho gerenciadas pela própria AWS que já oferecem variante Graviton nativamente: Amazon RDS, ElastiCache, OpenSearch, EMR.
Workloads horizontalmente escaláveis, onde trocar a arquitetura de um conjunto de instâncias idênticas é simples de validar.

Pontos de atenção antes de migrar:

Dependências binárias nativas (bibliotecas compiladas, extensões C/C++) precisam ter build para ARM64 disponível.
Imagens de container precisam ser multi-arquitetura (docker buildx com suporte a linux/arm64) ou reconstruídas especificamente para ARM.
Softwares proprietários de terceiros (agentes de monitoramento, APM, drivers específicos) precisam ter suporte oficial a ARM confirmado pelo fornecedor.
Testes de performance e carga são recomendados antes de migrar workloads críticas de produção, mesmo com boa compatibilidade declarada.

Estratégia de migração recomendada

Inventariar as aplicações e suas dependências, verificando compatibilidade com ARM64 (bibliotecas, imagens base de container, agentes de terceiros).
Começar pelo menos crítico — ambientes de desenvolvimento/homologação ou workloads stateless de baixo risco.
Rodar testes de carga comparativos entre a instância x86 atual e a equivalente Graviton, validando performance e custo real.
Migrar gradualmente ambientes de produção, aproveitando Auto Scaling Groups com múltiplos tipos de instância (mixed instance policy) durante a transição.
Consolidar o ganho de custo validado nas etapas anteriores em Savings Plans ou Reserved Instances específicas para a família Graviton escolhida.

Conclusão

O Graviton deixou de ser uma opção experimental e se tornou, hoje, a recomendação padrão da AWS para novas cargas de trabalho — quando a stack permite. A combinação de menor custo, menor consumo energético e performance competitiva faz da migração para ARM uma das otimizações de maior impacto disponíveis em uma conta AWS, especialmente quando combinada com outras estratégias de FinOps como Savings Plans e Spot Instances.

Antes de migrar qualquer workload crítica, o caminho mais seguro é sempre: validar compatibilidade, testar performance real e migrar de forma incremental — começando pelos ambientes de menor risco.

The Twelve-Factor App: o guia que todo sistema deveria seguir (mas poucos seguem)

Kauê Matos — Sat, 12 Sep 2026 22:29:40 +0000

Se você já trabalhou num sistema que funcionava perfeitamente no seu computador mas quebrava assim que ia pra produção, ou já se irritou com uma atualização que exigiu reconstruir tudo só porque mudou a senha do banco de dados, você já sentiu na pele o problema que o Twelve-Factor App tenta resolver.

Essa ideia surgiu por volta de 2010, dentro da empresa Heroku, com Adam Wiggins à frente. Na época, a empresa já hospedava centenas de milhares de sistemas de clientes diferentes na mesma plataforma, o que deu a eles uma visão privilegiada de tudo que costuma dar errado quando um time constrói software sem pensar em portabilidade, crescimento e manutenção. O resultado foi uma lista de doze práticas — nenhuma delas revolucionária sozinha, mas que juntas formam uma base sólida pra qualquer sistema que roda como serviço na internet.

O interessante é que, mesmo com toda a evolução das ferramentas desde então, essas doze práticas continuam extremamente válidas. Vamos passar por cada uma.

1. Um único código-fonte, várias versões em uso

Cada sistema deve viver em um único repositório de código com histórico de versões (como o Git), e a partir dele você gera quantas cópias precisar: uma pra testes, outra pra homologação, outra pra produção. Se você tem vários repositórios diferentes pra uma coisa que deveria ser "um sistema só", provavelmente não é mais um sistema — é vários sistemas conectados, e cada um deveria seguir essa regra separadamente.

2. Deixe claro do que o sistema depende

Nada de assumir que uma determinada ferramenta ou biblioteca já está instalada no computador ou servidor só porque "sempre esteve". Liste tudo isso de forma explícita, em um arquivo próprio do projeto, e mantenha isso separado do que já vem instalado no sistema operacional. É isso que garante que o sistema funcione do mesmo jeito em qualquer máquina, seja no notebook de quem está desenvolvendo, seja no servidor de produção.

3. Mantenha as configurações fora do código

Senhas de banco de dados, chaves de acesso a serviços externos, endereços de outros sistemas — nada disso deveria estar escrito dentro do código-fonte. Isso deve ficar guardado separadamente, em variáveis de ambiente do próprio servidor. Além de ser mais seguro (menos risco de vazar uma senha sem querer), isso permite trocar de ambiente sem precisar reconstruir o sistema do zero.

4. Trate serviços externos como peças substituíveis

Banco de dados, fila de mensagens, sistema de cache, serviço de envio de e-mail — tudo isso deveria ser tratado como uma peça que se conecta por meio de um endereço e uma credencial, sem diferença entre se está rodando no próprio computador ou em outro lugar. Trocar um banco de dados local por um banco hospedado por um provedor de nuvem não deveria exigir mudar uma linha do código, só a configuração.

5. Separe bem as etapas de construir, preparar e executar

Essas três etapas precisam ser bem distintas:

construir: transforma o código escrito em algo pronto pra rodar;
preparar: junta esse resultado com a configuração daquele ambiente específico;
executar: efetivamente coloca isso em funcionamento.

Cada versão preparada deveria ter uma identificação única, pra que, se algo der errado, seja possível voltar rapidamente pra versão anterior.

6. Não guarde informação importante dentro do próprio sistema em execução

O sistema deveria funcionar sem depender de guardar informações importantes na própria memória entre um pedido e outro. Qualquer coisa que precise ser lembrada deve ficar armazenada em um lugar próprio pra isso, como um banco de dados. Isso parece óbvio, mas é justamente o que permite aumentar a capacidade do sistema adicionando mais cópias dele rodando ao mesmo tempo, sem risco de perder informação ou gerar comportamento estranho.

7. O sistema deve se apresentar sozinho, sem depender de outro programa

O sistema deveria ser completo por si só e ficar disponível através de uma porta de comunicação própria, sem precisar que outro programa seja instalado por fora pra fazer essa ponte. A maioria das ferramentas modernas de desenvolvimento já vem com isso embutido — é só configurar em qual porta o sistema vai atender.

8. Aumente a capacidade dividindo o trabalho em partes

Divida o sistema em partes diferentes conforme o tipo de tarefa — uma parte pra atender pedidos que chegam pela internet, outra pra processar tarefas em segundo plano, outra pra rodar tarefas programadas — e aumente cada parte de forma independente conforme a necessidade. Assim, se o gargalo está no processamento em segundo plano, você aumenta só aquela parte, sem precisar mexer no resto.

9. Deixe o sistema pronto pra ligar e desligar rápido

Um sistema bem construído é aquele que consegue começar a funcionar rapidamente e também parar de forma organizada, terminando o que estava fazendo antes de desligar de vez. Isso é fundamental pra atualizações ágeis, pra aumentar ou diminuir a capacidade automaticamente conforme a demanda, e pra se recuperar rápido quando algo dá errado.

10. Mantenha o ambiente de testes parecido com o de produção

Esse é um dos pontos mais esquecidos na prática. A ideia é diminuir ao máximo a diferença entre o ambiente onde o sistema é desenvolvido e testado e aquele onde ele realmente atende os usuários — usar a mesma versão de banco de dados, atualizar com frequência, e ter as mesmas pessoas cuidando das duas pontas. É basicamente a receita pra nunca mais ouvir a frase "mas funcionava aqui". Ferramentas que automatizam a criação de ambientes ajudam bastante a diminuir essa distância.

11. Registros de atividade não devem ser um arquivo pra gerenciar

O sistema não deveria se preocupar em decidir onde guardar seus próprios registros de atividade (o famoso "log"). Ele apenas deveria escrevê-los de forma simples, e outra ferramenta, especializada nisso, deveria cuidar de coletar, organizar e guardar essas informações. Isso simplifica bastante o trabalho de quem constrói o sistema.

12. Tarefas administrativas rodam do mesmo jeito que o resto

Corrigir dados no banco, rodar um ajuste pontual, abrir uma sessão pra investigar um problema em produção — tudo isso deveria ser feito usando o mesmo ambiente, o mesmo código e a mesma configuração do sistema normal. Nada de manter um script separado, guardado em outro lugar, que só uma pessoa lembra de atualizar de vez em quando.

Usar contêineres não resolve isso sozinho

Vale desfazer um mal-entendido comum: muita gente pensa que, ao usar ferramentas modernas de empacotamento e orquestração de sistemas, essas doze práticas "vêm de graça" junto com elas. Não vêm. Essas ferramentas ajudam bastante em algumas partes — como isolar dependências e permitir que o sistema ligue e desligue rápido —, mas manter a configuração separada do código, evitar guardar informação importante dentro do sistema em execução e organizar bem as versões continua sendo trabalho de quem projeta o sistema, não da ferramenta.

No fim das contas

Essas doze práticas não são regras burocráticas de manual. São o tipo de coisa que a maioria das pessoas aprende depois de passar por um problema chato em produção, e que, depois de adotada, ninguém mais quer abrir mão. Seguir esses princípios é o que diferencia um sistema fácil de manter e fazer crescer de um que só continua funcionando porque alguém está sempre correndo atrás de apagar incêndio.

Baseado em 12factor.net

AWS Well-Architected Framework

Kauê Matos — Sat, 05 Sep 2026 18:12:41 +0000

Construir na nuvem é fácil. Construir bem na nuvem é outra história. É justamente para preencher essa lacuna que a AWS criou o Well-Architected Framework (WAF): um conjunto estruturado de princípios de design, boas práticas e perguntas orientadoras que ajudam arquitetos e engenheiros a avaliar workloads sob a ótica de seis pilares — Excelência Operacional, Segurança, Confiabilidade, Eficiência de Performance, Otimização de Custos e Sustentabilidade.

O framework não é uma checklist genérica de "boas práticas de nuvem". Ele é, na prática, uma metodologia de trade-offs conscientes: toda decisão arquitetural — usar um banco relacional ou NoSQL, multi-AZ ou multi-região, autoscaling agressivo ou conservador — implica abrir mão de algo em troca de outra coisa. O WAF força você a nomear esses trade-offs em vez de descobri-los tarde demais, em produção, sob incidente.

Um pouco de história

O framework nasceu em 2012 como um documento interno de arquitetos de soluções da AWS e virou whitepaper público em 2015. Em 2016 ganhou o pilar de Excelência Operacional; em 2017 chegaram os Lenses (recortes especializados por domínio) e, em 2018, a ferramenta gratuita AWS Well-Architected Tool, disponível direto no Console. O sexto pilar, Sustentabilidade, foi incorporado no fim de 2021, refletindo a pressão crescente por eficiência energética e redução de pegada de carbono em cargas de trabalho de nuvem.

De lá para cá, a AWS vem tornando o conteúdo cada vez mais prescritivo: cada boas práticas hoje tem página dedicada, com antipadrões comuns, nível de risco, passos de implementação e recursos relacionados — uma resposta direta ao feedback de que o framework antigo dizia "o que" fazer, mas pouco sobre "como".

Os princípios gerais de design

Antes de entrar pilar por pilar, vale destacar os princípios transversais que sustentam o framework:

Pare de adivinhar sua capacidade — use autoscaling e elasticidade em vez de dimensionar para o pico teórico.
Teste sistemas em produção (com segurança) — ambientes controlados de teste em escala real, não só em staging.
Automatize experimentações arquiteturais — infraestrutura como código torna barato testar variações de arquitetura.
Permita evolução arquitetural — desenhe para mudar, não para ser definitivo.
Direcione arquiteturas com dados — decisões baseadas em métricas reais de uso, não em intuição.
Melhore através de "game days" — simule falhas e eventos reais para validar respostas antes que aconteçam de verdade.

Os seis pilares

1. Excelência Operacional

Trata da capacidade de operar e monitorar sistemas para entregar valor de negócio, e de melhorar processos e procedimentos continuamente. Na prática, envolve:

Infraestrutura como código (Terraform, CloudFormation, CDK) para operações reproduzíveis e auditáveis.
Observabilidade real: métricas, logs e traces centralizados (CloudWatch, X-Ray) com alarmes acionáveis, não apenas dashboards bonitos.
Runbooks e playbooks versionados para resposta a incidentes.
Deploys pequenos, frequentes e reversíveis (blue/green, canary), reduzindo o "blast radius" de cada mudança.
Retrospectivas pós-incidente sem culpabilização, com ações de melhoria rastreadas.

2. Segurança

O pilar de Segurança foca em proteger informação, sistemas e ativos, mantendo o valor do negócio através de avaliação de risco e estratégias de mitigação. Pontos centrais:

Identidade forte como novo perímetro: IAM com privilégio mínimo, roles em vez de credenciais estáticas, MFA obrigatório para operações sensíveis.
Defesa em profundidade: VPCs segmentadas, security groups e NACLs, WAF e Shield contra ataques na borda.
Criptografia em repouso e em trânsito por padrão, com KMS gerenciando chaves e rotação.
Visibilidade contínua: GuardDuty para detecção de ameaças, Security Hub para consolidar postura de segurança, Config para compliance contínuo de configuração.
Automação de resposta a incidentes, para reduzir o tempo entre detecção e contenção.

A atualização mais recente do framework incorporou também uma área dedicada de AppSec (segurança de aplicação), reforçando que testes de segurança devem fazer parte do ciclo de desenvolvimento — SAST, DAST e dependency scanning como etapas normais de CI/CD, não como auditoria pontual.

3. Confiabilidade

Aqui o foco é a capacidade de um workload realizar sua função corretamente e de forma consistente, incluindo a habilidade de operar e testar o sistema durante todo o seu ciclo de vida. Boas práticas típicas:

Arquiteturas multi-AZ como padrão mínimo; multi-região para workloads críticos.
Recuperação automática de falhas (self-healing) via health checks e auto-replacement de instâncias.
Gestão de capacidade com margem de segurança e testes de carga regulares.
Estratégias de disaster recovery bem definidas (backup and restore, pilot light, warm standby, multi-site ativo-ativo), apoiadas por serviços como Elastic Disaster Recovery e Resilience Hub para medir e validar objetivos de RTO/RPO.
Circuit breakers e retries com backoff exponencial para conter falhas em cascata entre serviços distribuídos.

4. Eficiência de Performance

Trata do uso eficiente de recursos computacionais para atender requisitos e manter essa eficiência conforme a demanda muda e as tecnologias evoluem:

Escolha deliberada de tipo de computação (EC2, containers em ECS/EKS, serverless com Lambda) conforme o padrão de carga do workload.
Uso de cache em múltiplas camadas (CloudFront, ElastiCache) para reduzir latência e carga em backends.
Bancos de dados adequados ao padrão de acesso — relacional para transações complexas, NoSQL para escala horizontal e baixa latência, data warehouse para analytics.
Revisão periódica de novas famílias de instância e serviços gerenciados, já que "o melhor recurso hoje pode não ser o melhor em seis meses".
Testes de carga e benchmarking como parte do pipeline, não como evento isolado antes de um lançamento.

5. Otimização de Custos

Foca em evitar gastos desnecessários e obter o melhor retorno pelo dinheiro investido em nuvem:

Modelos de compra corretos: On-Demand para picos imprevisíveis, Savings Plans/Reserved Instances para baseline previsível, Spot para workloads tolerantes a interrupção.
Rightsizing constante com apoio do Compute Optimizer e Trusted Advisor, eliminando recursos superdimensionados ou ociosos.
Tagging consistente de recursos para permitir chargeback/showback real por time, produto ou ambiente.
Orçamentos e alertas proativos via AWS Budgets, evitando surpresas na fatura.
Cultura de FinOps: custo como métrica de engenharia, revisada com a mesma seriedade que performance e disponibilidade.

6. Sustentabilidade

O pilar mais recente do framework, focado em minimizar o impacto ambiental de workloads em nuvem:

Priorizar regiões com matriz energética mais limpa quando a latência permitir.
Maximizar utilização de recursos provisionados, evitando superprovisionamento "por segurança".
Preferir serviços gerenciados e serverless, que se beneficiam de ganhos de eficiência agregados da AWS em escala.
Adotar políticas de ciclo de vida de dados (arquivamento e exclusão automática) para reduzir armazenamento desnecessário.
Escolher arquiteturas e algoritmos eficientes, já que menos processamento também significa menos consumo energético.

A ferramenta e o processo de revisão

O AWS Well-Architected Tool, gratuito no Console, permite conduzir uma revisão estruturada de um workload: você responde a um conjunto de perguntas por pilar, e a ferramenta identifica riscos (baixo, médio ou alto) e sugere ações de remediação com base nas boas práticas atualizadas.

Na prática, uma revisão Well-Architected segue um fluxo simples:

Definir o workload e seu contexto de negócio (criticidade, SLAs, requisitos regulatórios).
Responder às perguntas de cada pilar com a equipe técnica responsável, documentando decisões e justificativas.
Identificar riscos altos (HRIs) — os itens que mais ameaçam o sucesso do workload.
Priorizar e planejar remediação, tratando os HRIs como itens de backlog com dono e prazo.
Repetir periodicamente, já que arquiteturas e boas práticas evoluem — uma revisão não é um evento único, é um hábito.

Lenses: recortes especializados

Além do framework geral, a AWS mantém Lenses — extensões que aplicam os seis pilares a domínios específicos. Existem lenses para arquiteturas serverless, machine learning, SaaS, IoT, containers, entre outros. A adição mais notável recentemente foi o Generative AI Lens, lançado em 2025, que aplica os seis pilares ao ciclo de vida completo de workloads de IA generativa — do escopo de impacto e seleção de modelo até customização, integração, deployment e iteração contínua, com atenção especial a temas como veracidade, explicabilidade e uso responsável de LLMs.

Como aplicar isso na prática, sem virar teatro corporativo

O maior risco de qualquer framework é ele virar um exercício de preenchimento de formulário. Algumas recomendações práticas para evitar isso:

Comece pequeno: revise um workload real e crítico antes de tentar aplicar o framework em toda a organização de uma vez.
Trate os pilares como lentes de discussão, não como categorias isoladas — a maioria das decisões arquiteturais toca vários pilares ao mesmo tempo.
Automatize o que for possível (Config Rules, Security Hub, Trusted Advisor) para que parte da revisão aconteça continuamente, não só numa reunião trimestral.
Conecte os riscos identificados a itens reais de backlog, com dono e prazo — um relatório de revisão que não vira ação é apenas um documento a mais.

Conclusão

O AWS Well-Architected Framework não é sobre seguir regras cegamente, é sobre tornar explícitos os trade-offs que toda arquitetura de nuvem já carrega implicitamente. Usado com disciplina — revisões periódicas, HRIs viram backlog, métricas acompanhadas ao longo do tempo — ele funciona como um mecanismo de melhoria contínua genuíno. Usado como checklist de auditoria pontual, vira só mais um documento arquivado. A diferença entre as duas coisas não está no framework, está no processo que você constrói ao redor dele.

Por que a Prime Video trocou microsserviços serverless por um monólito

Kauê Matos — Sat, 05 Sep 2026 17:48:34 +0000

Em março de 2023, a equipe de engenharia da Amazon Prime Video publicou um post técnico que causou bastante repercussão na comunidade de cloud: eles haviam redesenhado um de seus serviços internos, saindo de uma arquitetura distribuída baseada em serverless para uma aplicação monolítica rodando em containers — e reduziram o custo operacional em 90%.

O caso ficou conhecido de forma simplificada como "Prime Video abandona microsserviços", mas essa leitura esconde um detalhe importante: o problema não estava no conceito de microsserviços em si, e sim em como serverless (Step Functions e Lambda) havia sido usado para orquestrar um fluxo de altíssima frequência de eventos. Vale entender o caso com mais profundidade, porque as lições dele valem para qualquer arquiteto de cloud que precisa decidir entre desacoplar componentes ou simplificar a orquestração.

O serviço em questão: monitoramento de qualidade de áudio/vídeo

O time responsável era o de Video Quality Analysis (VQA), que mantém uma ferramenta capaz de detectar problemas de qualidade em streams de vídeo em tempo real — coisas como corrupção de blocos de imagem, congelamento de vídeo e dessincronização entre áudio e vídeo. Essa ferramenta já existia, mas não havia sido projetada para operar na escala de milhares de streams simultâneos, que é o volume real de tráfego da Prime Video.

A arquitetura original

A primeira versão do serviço foi construída como um sistema distribuído usando componentes serverless, o que fazia todo sentido do ponto de vista de velocidade de entrega. Em linhas gerais, o desenho contava com:

Media Converter: um componente responsável por quebrar os streams de áudio/vídeo em frames de imagem e buffers de áudio decodificados.
Defect Detectors: microsserviços que analisavam esses frames e buffers usando algoritmos de machine learning para identificar defeitos, executados via AWS Lambda.
Orquestração via AWS Step Functions: controlando as transições de estado entre as etapas do pipeline de análise.
Amazon S3: usado como armazenamento intermediário, guardando os frames de imagem entre uma etapa e outra do pipeline.
Amazon SNS: usado para notificar os resultados da análise.

Esse desenho tinha uma vantagem clara: escalabilidade horizontal teórica, já que cada componente poderia escalar de forma independente, e uma implementação rápida, aproveitando serviços gerenciados da AWS.

Onde a conta não fechou

O problema apareceu quando o serviço começou a operar em escala real. Dois gargalos concentraram praticamente todo o impacto negativo:

1. Step Functions como orquestrador de alta frequência. O fluxo realizava múltiplas transições de estado a cada segundo de stream analisado. Como o Step Functions cobra por transição de estado, e como existem limites de conta para volume de transições, o serviço atingiu limites de escala em torno de apenas 5% da carga esperada — bem abaixo do necessário para operar com todos os streams da plataforma.

2. Custo de chamadas de camada 1 ao S3. Passar frames de vídeo entre componentes usando S3 como intermediário gerava um volume enorme de chamadas de escrita e leitura (chamadas "tier-1", que são as mais caras no modelo de precificação do S3), o que tornava o custo de operação proibitivo em escala.

Em resumo: o desenho não estava "errado" em teoria, mas o padrão de uso — altíssima frequência de eventos pequenos, orquestrados por um serviço que cobra por evento, trocando dados por um armazenamento intermediário que cobra por chamada — é exatamente o cenário em que orquestração serverless tende a sair cara.

A nova arquitetura

A solução da equipe foi consolidar as etapas do pipeline (conversão de mídia e detecção de defeitos) em um único processo, eliminando a orquestração via Step Functions e a troca de dados via S3. Os frames passaram a ser transferidos em memória, dentro do mesmo processo, e não mais por chamadas de rede a um serviço de armazenamento.

Essa aplicação consolidada passou a rodar sobre EC2 e ECS, com uma camada leve de orquestração para distribuir as requisições dos clientes entre instâncias. Para lidar com o problema de escala vertical de um único processo, a equipe replicou o serviço em múltiplas tarefas ECS, cada uma com um subconjunto de detectores — ou seja, ainda existe distribuição de carga, só que em um nível de granularidade bem mais grosso do que antes.

O resultado

A mudança de arquitetura reduziu o custo operacional do serviço em 90% e resolveu o gargalo de escala, permitindo cobrir a totalidade dos streams monitorados. A lógica de negócio (os algoritmos de detecção de defeitos) permaneceu praticamente a mesma — o que mudou foi a camada de orquestração e transporte de dados entre etapas.

Uma ressalva importante: monólito ou só "menos serverless"?

O post original gerou um debate acalorado na comunidade técnica, incluindo críticas de arquitetos conhecidos do setor. O ponto central da discussão é que, tecnicamente, o novo desenho não é um monólito no sentido tradicional do termo: a Prime Video como um todo continua operando como um conjunto de serviços independentes (cobrança, catálogo, streaming, etc.), e mesmo o novo serviço de VQA ainda é replicado em múltiplas instâncias ECS.

O que de fato mudou foi a granularidade da orquestração: em vez de fragmentar cada etapa do processamento em funções Lambda separadas e coordená-las por um serviço de estado que cobra por transição, a equipe passou a executar todas as etapas de um mesmo stream dentro de um único processo. É mais preciso descrever isso como uma migração de serverless orientado a eventos para compute tradicional em containers, do que como "microsserviços versus monólito" — ainda que essa segunda formulação tenha sido a usada no post original e seja a que pegou popularmente.

Lições para quem projeta arquiteturas em cloud

Alguns pontos ficam claros ao analisar o caso:

O modelo de cobrança do serviço gerenciado importa tanto quanto sua elasticidade. Step Functions e Lambda são excelentes para orquestrar fluxos de baixa a média frequência ou eventos assíncronos, mas cobrar por transição de estado ou por invocação se torna um problema quando a frequência de eventos é da ordem de múltiplas vezes por segundo, por stream, multiplicado por milhares de streams simultâneos.
Armazenamento intermediário tem custo de chamada, não só de armazenamento. Usar S3 como "fila" ou buffer entre etapas de um pipeline parece simples, mas o custo por operação pode superar rapidamente o custo do armazenamento em si, especialmente em payloads pequenos e frequentes.
Desacoplamento tem um custo de rede e serialização que nem sempre se paga. Quando as etapas de um pipeline sempre são executadas juntas, para o mesmo item de trabalho, colocá-las no mesmo processo elimina overhead de rede sem necessariamente sacrificar a capacidade de escalar — desde que a unidade de escala (nesse caso, a instância ECS) seja bem dimensionada.
A escolha de arquitetura depende do padrão de acesso, não de uma regra geral. O próprio caso não é uma prova de que "monólitos são melhores que microsserviços" — é uma prova de que a granularidade da orquestração precisa ser compatível com a frequência e o volume dos eventos que ela processa.

Conclusão

O caso da Prime Video se tornou um símbolo do debate entre microsserviços e monólitos, mas seu valor real está em outro lugar: ele mostra como escolhas de orquestração e transporte de dados, tomadas cedo no design de um sistema, podem determinar se uma arquitetura escala de forma sustentável ou colide com limites de conta e custos inesperados assim que sai do piloto para a produção em escala real. Antes de escolher entre serverless, containers ou uma combinação dos dois, vale simular o padrão real de tráfego esperado e o modelo de cobrança de cada serviço envolvido — não só a elegância teórica do desenho distribuído.

Fontes

Prime Video Tech Blog — Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
InfoQ — Prime Video Switched from Serverless to EC2 and ECS to Save Costs
The New Stack — Amazon Prime Video's Microservices Move Doesn't Lead to a Monolith after All

Kiro: a IDE agêntica da AWS — o que é, como funciona e vale a pena usar?

Kauê Matos — Wed, 02 Sep 2026 15:41:07 +0000

Em julho de 2025, a AWS lançou o Kiro, uma IDE agêntica construída sobre a base open-source do VS Code (Code OSS), entrando em um mercado já disputado por ferramentas como Cursor, Windsurf, GitHub Copilot e Claude Code. O produto saiu do modo preview e alcançou disponibilidade geral no fim de 2025/início de 2026, e desde então vem se consolidando como a aposta oficial da AWS para desenvolvimento assistido por IA — a ponto de a própria empresa ter anunciado, em janeiro de 2026, o fim de novos cadastros no Amazon Q Developer (efetivo a partir de 15 de maio de 2026), direcionando explicitamente os usuários ao Kiro.

O que diferencia o Kiro do restante da concorrência não é o modelo de IA por trás dele (ele roda sobre modelos Claude via Amazon Bedrock, com roteamento também para a Amazon Nova), mas sim sua filosofia de trabalho: em vez de "chat primeiro, código depois", o Kiro é spec-first — a unidade de trabalho não é um prompt solto, e sim uma especificação estruturada que o agente usa para planejar, implementar, verificar e documentar uma funcionalidade de ponta a ponta.

O que é o Kiro, na prática

O Kiro está disponível em quatro superfícies que compartilham o mesmo agente e o mesmo histórico de créditos:

IDE desktop (macOS, Windows e Linux), com a interface familiar de quem já usa VS Code
CLI para quem prefere trabalhar via terminal
Interface web, incluída em todos os planos pagos, que ganhou suporte a GitLab e specs completos em meados de 2026
App mobile, para acompanhar e disparar tarefas em trânsito

Não é necessário ter conta AWS para começar: dá para entrar com GitHub ou Google, o que reduz a barreira de adoção — embora todo o poder de integração nativa com ambientes AWS só apareça para quem já usa a nuvem da Amazon.

O conceito central: desenvolvimento orientado por especificação (spec-driven)

Quando você inicia uma nova funcionalidade no Kiro, a ferramenta não parte direto para o código. Primeiro, ela gera três artefatos estruturados:

requirements.md — histórias de usuário e critérios de aceitação
design.md — desenho do sistema, decomposição de componentes e fluxo de dados
tasks.md — lista de tarefas sequenciadas e executáveis

Só depois que essas especificações são revisadas (e aprovadas) pelo desenvolvedor é que os agentes começam a implementar, rodando comandos e testes ao longo do caminho — inclusive em paralelo, quando o plano permite. Uma atualização de maio de 2026 reforçou esse fluxo em torno de TDD: o agente escreve primeiro os testes que devem falhar a partir da especificação, depois a implementação, e por fim roda a suíte de testes — uma forma de manter um agente autônomo "honesto" em mudanças que tocam vários arquivos.

Diferente de especificações tradicionais em cascata, que são escritas uma vez e esquecidas, as specs do Kiro evoluem junto com o código e continuam servindo de referência para onboarding, refatoração e novas funcionalidades.

Principais recursos

Specs: como descrito acima, o núcleo do produto
Hooks (ganchos de agente): automações que disparam em eventos do repositório — salvar um arquivo, criar um componente — para atualizar testes, documentação ou rodar varreduras de segurança automaticamente
Steering: arquivos markdown que guiam o comportamento do Kiro com regras e contexto específicos do projeto
Agentic Chat: conversa em linguagem natural que entende o contexto do projeto inteiro
MCP (Model Context Protocol): conexão com ferramentas e fontes de dados externas
Kiro Autonomous Agent: agente em segundo plano que pega tarefas, implementa e abre pull requests sem que o desenvolvedor precise acompanhar em tempo real
Memória persistente entre sessões e agentes que aprendem com cada interação
Verificação determinística, como testes baseados em propriedades, para checar se o código gerado realmente corresponde à especificação

Pontos positivos

Rastreabilidade e disciplina: quebrar o trabalho em specs e tarefas revisáveis torna o desenvolvimento assistido por IA mais previsível — você não está apostando que um "despejo" gigante de código vai funcionar de primeira.
Bom para produção, não só prototipagem: enquanto ferramentas como Cursor otimizam velocidade de iteração, o Kiro otimiza para projetos maiors, em equipe, onde documentação e trilha de decisões importam.
Integração nativa com AWS: para quem já é cliente AWS, o Kiro capta contexto do ambiente de nuvem sem configuração extra, o que economiza um trabalho real de "engenharia de contexto".
Suporte a GovCloud: coloca o Kiro na lista de opções viáveis para setores regulados, onde a maioria dos concorrentes de IA não pode operar.
Múltiplas superfícies com o mesmo agente: IDE, CLI, web e mobile compartilham a mesma lógica e o mesmo pool de créditos, sem métricas separadas para gerenciar.
Hooks como colaborador constante: automatizam tarefas repetitivas e viram, na prática, um "parceiro" que trabalha em segundo plano.
Guardrails de segurança reforçados após um incidente de destaque (ver seção de controvérsias abaixo), o que tornou o produto mais maduro para uso em ambientes de produção.

Pontos negativos

Modelo de preços por créditos é agressivo e difícil de prever: os planos vão de um tier gratuito (50 créditos/mês) a um Power de US$ 200/mês (cerca de 20.000 créditos), passando por Pro (US$ 20), Pro+ (US$ 40) e Pro Max (US$ 100). Uma construção completa de feature via spec custa, em média, de 15 a 25 créditos — ou seja, o tier gratuito só permite 2 ou 3 features completas por mês.
Overhead para tarefas simples: se o seu dia a dia é fazer pequenas edições pontuais em um único arquivo, a estrutura de specs adiciona etapas e reduz a sensação de velocidade — o Kiro "compensa" mais em features grandes e multi-etapas do que em ajustes rápidos.
Custo de add-ons: créditos extras saem a US$ 0,04 cada, e o consumo varia conforme o modelo escolhido (usar Claude Sonnet diretamente, por exemplo, consome cerca de 30% mais créditos do que o modo Auto de roteamento).
GovCloud custa ~20% a mais e não tem tier gratuito.
Produto ainda "jovem": alcançou disponibilidade geral só no fim de 2025/início de 2026, e usuários relatam lentidão e arestas na interface em threads de comunidades como o r/kiroIDE — problemas típicos de uma ferramenta recente.
Incidente de reputação em fevereiro de 2026: código gerado por um usuário do Kiro foi apontado, num primeiro momento, como possível causa de uma interrupção de serviço na AWS. A narrativa "o Kiro vibrou demais e derrubou a AWS" viralizou; a AWS negou oficialmente que o Kiro tivesse causado o problema, mas o episódio expôs um risco real: código gerado por IA que interage com infraestrutura de produção precisa de barreiras de segurança bem definidas.
Dependência de um ecossistema (Bedrock/Claude): por rodar sobre modelos de terceiros via Bedrock, o Kiro fica sujeito a mudanças de disponibilidade e custo desses modelos.

Preços (panorama de 2026)

Plano	Preço/mês	Créditos aproximados
Free	US$ 0	50
Pro	US$ 20	1.000
Pro+	US$ 40	~2.500
Pro Max	US$ 100	~7.000
Power	US$ 200	~20.000

Além disso, novos usuários costumam receber créditos-bônus por tempo limitado, e startups elegíveis (até Series B) podem se candidatar a até um ano do plano Pro+ gratuito. Times contam com planos equivalentes, faturamento consolidado, analytics de uso e SSO via AWS IAM Identity Center.

Kiro vs. concorrentes

Cursor / Windsurf: mais rápidos para começar e mais "leves" para quem trabalha sozinho e quer iteração ágil; o Kiro compensa quando o time precisa de planejamento repetível e rastreabilidade de implementação.
Claude Code: também terminal-first e forte em tarefas de codificação profundas, mas sem o andaime formal de specs (requirements/design/tasks) que o Kiro impõe por padrão.
GitHub Copilot: mais focado em autocomplete e sugestões inline do que em orquestrar uma feature inteira a partir de uma especificação.
Amazon Q Developer: era o assistente da AWS mais atrelado ao console e à infraestrutura AWS; a própria AWS está descontinuando novos cadastros nele, direcionando os usuários para o Kiro como sucessor para assistência de IA em IDE.

Para quem o Kiro faz sentido

Times que precisam que o código gerado por IA seja revisável, documentado e auditável — não apenas rápido.
Organizações que já compram serviços via AWS e querem aproveitar a relação de billing existente.
Equipes em setores regulados que dependem de GovCloud.
Desenvolvedores avaliando Cursor ou Windsurf, mas que querem uma alternativa com etapa de planejamento explícita e maior flexibilidade de modelos.

Já para prototipagem rápida, ajustes pontuais em um único arquivo ou projetos pessoais pequenos, o overhead do fluxo de specs pode não compensar — nesses casos, ferramentas mais leves e "chat-first" tendem a parecer mais ágeis no dia a dia.

Conclusão

O Kiro representa uma aposta filosófica clara da AWS: em vez de tratar a IA como um autocomplete mais rápido, ele tenta resolver o problema de raiz do "vibe coding" — a falta de planejamento antes da implementação. Isso o torna, para muitos, uma das opções mais sólidas para desenvolvimento de produção com IA em 2026, especialmente em times e em ambientes AWS. Por outro lado, o modelo de créditos exige atenção ao orçamento, a estrutura de specs pode ser overkill para tarefas simples, e o produto ainda carrega as arestas normais de uma ferramenta que amadureceu rápido demais para o holofote que recebeu — inclusive um episódio de reputação que, apesar de desmentido pela AWS, deixou claro o quanto guardrails de segurança são essenciais quando agentes de IA tocam infraestrutura real.

Na prática, a recomendação mais comum entre quem testou a ferramenta a fundo é: rodar o Kiro em paralelo com a ferramenta que você já usa, reservando-o para features maiores e mais estruturadas, e usar algo mais leve para o trabalho do dia a dia.

AWS Shared Responsibility Model Quem Cuida do Quê na Nuvem

Kauê Matos — Tue, 25 Aug 2026 01:52:01 +0000

Boa parte dos incidentes de segurança na nuvem não acontece porque a AWS falhou — acontece porque alguém assumiu, incorretamente, que a AWS cuidaria de algo que na verdade era responsabilidade do cliente. O Shared Responsibility Model (Modelo de Responsabilidade Compartilhada) é o framework que a AWS usa para deixar essa linha explícita, e é provavelmente o conceito de segurança mais citado — e mais mal compreendido — entre quem opera workloads na nuvem.

Este artigo detalha o modelo, como a linha de responsabilidade se desloca conforme o tipo de serviço usado, e onde estão os erros mais comuns na prática.

1. A frase que resume tudo

A AWS resume o modelo inteiro em uma única distinção:

AWS é responsável pela segurança DA nuvem (security of the cloud). O cliente é responsável pela segurança NA nuvem (security in the cloud).

Essa frase parece simples, mas o detalhe importante é que ela muda de posição dependendo de qual serviço você está usando. Não existe uma linha fixa e universal — existe uma linha que se desloca conforme o modelo de serviço (IaaS, PaaS, SaaS) e quanto da pilha técnica a AWS gerencia por baixo dele.

2. Segurança DA nuvem (responsabilidade da AWS)

Isso cobre a infraestrutura física e a camada de plataforma que sustenta todos os serviços AWS, independentemente do que o cliente escolhe rodar em cima dela:

Data centers físicos: segurança de acesso físico, vigilância, controles ambientais (energia, refrigeração).
Hardware: ciclo de vida de servidores, discos, equipamentos de rede — aquisição, manutenção e descarte seguro.
Virtualização: segurança do hypervisor que isola as cargas de trabalho de diferentes clientes rodando na mesma infraestrutura física subjacente.
Rede global: o backbone de fibra que conecta regiões, Availability Zones e edge locations, incluindo a isolação de tráfego entre regiões.
Patching da infraestrutura de serviços gerenciados: para serviços como RDS, DynamoDB ou S3, a AWS também cuida do patching do sistema operacional e do software subjacente da plataforma — não apenas do hardware.
Compliance da infraestrutura: auditorias regulares de terceiros (SOC 1/2/3, ISO 27001, PCI-DSS, entre outros) que certificam que a infraestrutura da AWS atende a padrões de segurança reconhecidos.

O cliente não tem acesso e não pode alterar nada dessa camada — e também não precisa se preocupar com ela: é inteiramente coberta pela AWS, com evidência de auditoria disponível via AWS Artifact.

3. Segurança NA nuvem (responsabilidade do cliente)

Isso cobre tudo que o cliente configura, insere ou constrói em cima da infraestrutura da AWS — e é onde a esmagadora maioria dos incidentes reais de segurança na nuvem acontece:

Dados: classificação, criptografia (em repouso e em trânsito), e decisão de quem pode acessá-los.
Identidade e acesso (IAM): usuários, roles, políticas de permissão, MFA — garantir que apenas identidades autorizadas acessem recursos, com o mínimo privilégio necessário.
Configuração de aplicação e sistema operacional: em serviços IaaS, isso inclui aplicar patches de SO, configurar firewall a nível de instância (security groups, NACLs) e proteger o código da aplicação.
Configuração de rede: VPCs, sub-redes, tabelas de rota, security groups — desenhar a segmentação de rede corretamente.
Gestão de credenciais: chaves de API, segredos de aplicação, rotação de credenciais.
Compliance da aplicação: garantir que a forma como os dados são tratados dentro da aplicação atende às regulações aplicáveis ao negócio (LGPD, HIPAA, PCI-DSS, conforme o caso).

A AWS fornece as ferramentas (IAM, KMS, Security Groups, GuardDuty, Config, entre outras) — mas usar essas ferramentas corretamente é responsabilidade do cliente. A AWS não pode, por exemplo, impedir que alguém configure um bucket S3 como público por engano — só pode fornecer os mecanismos (como o S3 Block Public Access, que passou a vir habilitado por padrão em buckets novos) para tornar esse erro menos provável.

4. Como a linha se desloca conforme o tipo de serviço

Esse é o ponto mais importante e mais frequentemente mal entendido do modelo: a divisão de responsabilidade não é a mesma para todo serviço da AWS. Ela varia de acordo com quanto da pilha técnica é gerenciado pela AWS por trás daquele serviço específico — na prática, o mesmo raciocínio de IaaS/PaaS/SaaS aplicado à segurança.

Infraestrutura (ex.: Amazon EC2)

Camada	Responsável
Data centers, hardware, virtualização, rede global	AWS
Sistema operacional convidado (patches, configuração)	Cliente
Firewall a nível de instância (Security Groups)	Cliente
Software instalado, configuração da aplicação	Cliente
Dados armazenados, criptografia de dados	Cliente
Gestão de identidade e acesso à instância	Cliente

Rodar uma instância EC2 é o cenário onde o cliente assume a maior fatia de responsabilidade — equivalente a um modelo IaaS: a AWS garante o hardware e o hypervisor, tudo a partir do SO para cima é por conta do cliente.

Containers gerenciados (ex.: Amazon ECS/EKS com Fargate)

Camada	Responsável
Infraestrutura, orquestração dos nós, patching do SO do nó	AWS
Imagem de container, dependências da aplicação	Cliente
Configuração de rede do cluster/task	Cliente
IAM roles atribuídas a tasks/pods	Cliente
Dados da aplicação	Cliente

A responsabilidade sobre o sistema operacional subjacente se desloca para a AWS quando se usa Fargate — o cliente continua responsável pelo que roda dentro do container.

Serviços gerenciados/PaaS (ex.: Amazon RDS)

Camada	Responsável
Infraestrutura, hypervisor, SO do banco, patching do motor do banco	AWS
Configuração de acesso ao banco (security groups, parâmetros)	Cliente
Gestão de usuários e permissões dentro do banco	Cliente
Backup (a AWS automatiza, mas a política de retenção é configurada pelo cliente)	Compartilhado
Dados armazenados no banco, criptografia	Cliente

Aqui a AWS assume o patching do sistema operacional e do motor do banco — algo que, no EC2, seria integralmente do cliente. Ainda assim, a configuração de acesso e os dados continuam sendo do cliente.

Serverless/orientado a evento (ex.: AWS Lambda, Amazon S3)

Camada	Responsável
Infraestrutura, runtime, escalonamento, patching completo da plataforma	AWS
Código da função / política de bucket	Cliente
IAM role/policy anexada à função ou ao bucket	Cliente
Dados armazenados ou processados	Cliente

Esse é o extremo oposto do EC2: a AWS absorve praticamente toda a pilha técnica. Mesmo assim, o cliente continua totalmente responsável pela configuração de acesso — e é exatamente aqui que estão os incidentes mais comuns e mais citados de segurança na nuvem: buckets S3 configurados como públicos por engano, ou funções Lambda com permissões IAM excessivamente amplas. A infraestrutura estar 100% protegida pela AWS não impede um vazamento de dados causado por uma política de acesso mal configurada pelo cliente.

5. O padrão que se repete: infraestrutura protegida não é dado protegido

O ponto central do modelo, resumido de forma direta: quanto mais gerenciado o serviço, menor a fatia de responsabilidade técnica do cliente — mas a responsabilidade sobre dados, identidade e configuração de acesso nunca desaparece, em nenhum modelo de serviço.

É por isso que a maioria dos incidentes de segurança envolvendo AWS (buckets S3 públicos expostos, credenciais vazadas em repositórios de código, políticas IAM excessivamente permissivas) não são falhas da AWS — são falhas do lado do cliente na fração de responsabilidade que sempre lhe pertence, independentemente de quão gerenciado seja o serviço escolhido.

6. Ferramentas da AWS que ajudam o cliente a cumprir sua parte

A AWS não pode atravessar a linha de responsabilidade — mas oferece serviços especificamente desenhados para reduzir a chance de erro do lado do cliente:

Ferramenta	Ajuda a cobrir
IAM + IAM Access Analyzer	Identidade e acesso — identifica permissões não utilizadas ou excessivamente amplas
AWS KMS	Criptografia de dados em repouso, gestão de chaves
Security Groups / NACLs	Segmentação e controle de tráfego de rede
S3 Block Public Access	Reduz o risco de exposição acidental de buckets (habilitado por padrão desde 2023)
Amazon GuardDuty	Detecção de ameaças e comportamento anômalo na conta
AWS Config	Auditoria contínua de configuração de recursos contra regras definidas
AWS Artifact	Acesso a relatórios de compliance e certificações da infraestrutura AWS

Nenhuma dessas ferramentas "terceiriza" a responsabilidade de volta para a AWS — elas apenas tornam mais fácil para o cliente cumprir a parte que já é dele.

7. Erros comuns de interpretação do modelo

"A AWS é responsável pela segurança, então meus dados estão seguros por padrão." Incorreto — a AWS protege a infraestrutura; a configuração de acesso aos dados é sempre do cliente, em qualquer serviço.
"Como uso um serviço gerenciado (RDS, Lambda, S3), não preciso pensar em segurança." Incorreto — a fatia de responsabilidade técnica diminui, mas identidade, dados e configuração de acesso continuam sendo do cliente mesmo no serviço mais gerenciado que existe.
"O modelo é o mesmo para todo serviço da AWS." Incorreto — a linha se desloca conforme o serviço (EC2 vs. Fargate vs. RDS vs. Lambda), e entender onde ela está para cada serviço específico usado é parte do trabalho de arquitetura.
"Backup automático da AWS significa que meus dados estão protegidos contra qualquer perda." Parcialmente incorreto — a AWS automatiza o mecanismo de backup em muitos serviços gerenciados, mas a política de retenção, os testes de restore e a estratégia de disaster recovery continuam sendo decisões e responsabilidades do cliente.

Conclusão

O Shared Responsibility Model não é uma cláusula de contrato para ler uma vez e esquecer — é um mapa que precisa ser consultado para cada serviço específico que entra na arquitetura, porque a fronteira entre "isso é problema da AWS" e "isso é problema meu" muda de lugar a cada camada de abstração que se sobe. Entender exatamente onde essa linha está para o EC2, para o RDS, para o Lambda e para o S3 — em vez de tratar "a AWS cuida da segurança" como uma frase genérica — é o que separa uma arquitetura de nuvem bem protegida de uma que só parece estar.

Estratégias de Deploy no Kubernetes: Rolling Update, Canary Deployment e Blue-Green

Kauê Matos — Thu, 20 Aug 2026 11:22:17 +0000

Realizar o deploy de uma nova versão de uma aplicação em produção é uma das etapas mais críticas de um processo de entrega de software. Mesmo quando uma aplicação possui testes automatizados, pipelines de CI/CD, ambientes de homologação e validações de qualidade, ainda existe um risco associado à execução da nova versão em produção.

Problemas de performance, incompatibilidades com serviços externos, falhas de integração, consumo excessivo de memória, aumento de latência e erros não previstos podem aparecer apenas quando a aplicação está submetida ao tráfego real.

Nesse contexto, estratégias de deployment são utilizadas para reduzir o risco de uma nova versão. Em vez de simplesmente desligar a aplicação antiga e iniciar a nova, podemos controlar como a nova versão será introduzida no ambiente produtivo.

No Kubernetes, existem estratégias nativas, principalmente o Rolling Update, e estratégias mais avançadas de Progressive Delivery, como Canary Deployment e Blue-Green Deployment, normalmente implementadas com ferramentas como o Argo Rollouts.

As três abordagens possuem objetivos semelhantes: disponibilizar novas versões de forma segura. Entretanto, cada uma controla de maneira diferente aspectos como:

Quantidade de usuários expostos à nova versão;
Velocidade do deployment;
Capacidade de rollback;
Consumo de infraestrutura;
Controle do tráfego;
Validação por métricas;
Impacto de uma falha em produção.

1. O que é uma estratégia de deployment?

Uma estratégia de deployment define como uma versão nova substitui a versão atualmente executada.

Imagine uma aplicação em produção na versão:

Aplicação v1

Uma nova versão é desenvolvida:

Aplicação v2

A principal questão passa a ser:

Como migrar os usuários da versão v1 para a versão v2 com o menor risco possível?

Existem diferentes respostas para esse problema.

Rolling Update

v1 → v1 + v2 → v2

Os Pods antigos são substituídos gradualmente.

Blue-Green

Blue (v1) → validação da Green (v2) → troca de tráfego → Green (v2)

As duas versões coexistem, mas normalmente apenas uma recebe o tráfego produtivo.

Canary

90% v1 + 10% v2
        ↓
70% v1 + 30% v2
        ↓
50% v1 + 50% v2
        ↓
0% v1 + 100% v2

A nova versão recebe uma pequena parcela do tráfego e sua exposição aumenta progressivamente após validação.

2. Rolling Update: a estratégia nativa do Kubernetes

O Rolling Update é a estratégia mais comum e padrão para objetos Deployment no Kubernetes.

O Kubernetes substitui gradualmente os Pods pertencentes à versão antiga pelos Pods da nova versão. Durante o processo, ambas as versões podem coexistir temporariamente. A estratégia RollingUpdate é o padrão do Deployment, enquanto a alternativa nativa é Recreate.

Imagine uma aplicação com cinco réplicas:

Versão atual:

Pod 1 - v1
Pod 2 - v1
Pod 3 - v1
Pod 4 - v1
Pod 5 - v1

Após iniciar o deployment da versão v2:

Pod 1 - v2
Pod 2 - v1
Pod 3 - v1
Pod 4 - v1
Pod 5 - v1

Depois:

Pod 1 - v2
Pod 2 - v2
Pod 3 - v1
Pod 4 - v1
Pod 5 - v1

O processo continua até:

Pod 1 - v2
Pod 2 - v2
Pod 3 - v2
Pod 4 - v2
Pod 5 - v2

A velocidade e o comportamento dessa substituição são controlados principalmente por:

maxSurge
maxUnavailable

2.1 maxSurge

O parâmetro maxSurge define quantos Pods adicionais podem ser criados temporariamente durante o deployment.

Considere:

replicas: 10

Com:

maxSurge: 2

O Kubernetes pode executar temporariamente até:

10 Pods desejados + 2 Pods extras = 12 Pods

Isso permite criar novos Pods antes de remover todos os Pods antigos.

Também é possível utilizar porcentagem:

maxSurge: 25%

A documentação do Kubernetes permite valores absolutos ou percentuais; percentuais para maxSurge são arredondados para cima. O padrão é 25%.

2.2 maxUnavailable

O parâmetro maxUnavailable define quantos Pods podem ficar indisponíveis durante a atualização.

Exemplo:

replicas: 10

maxUnavailable: 1

Durante o processo, o Kubernetes tentará garantir que no mínimo nove Pods permaneçam disponíveis.

Também é possível utilizar porcentagem:

maxUnavailable: 20%

Nesse caso, até 20% das réplicas desejadas podem estar indisponíveis durante a atualização. Para porcentagens, o Kubernetes arredonda maxUnavailable para baixo; o padrão também é 25%.

2.3 Exemplo de Rolling Update

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application
spec:
  replicas: 5

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

  selector:
    matchLabels:
      app: application

  template:
    metadata:
      labels:
        app: application

    spec:
      containers:
        - name: application
          image: my-application:2.0.0
          ports:
            - containerPort: 8080

          readinessProbe:
            httpGet:
              path: /health
              port: 8080

Com essa configuração:

Replicas desejadas: 5
maxSurge: 1
maxUnavailable: 0

O Kubernetes pode criar um Pod adicional temporariamente, chegando a seis Pods, enquanto busca manter os cinco Pods disponíveis.

Um fluxo simplificado seria:

[ v1 ][ v1 ][ v1 ][ v1 ][ v1 ]

        ↓

[ v1 ][ v1 ][ v1 ][ v1 ][ v1 ][ v2 ]

        ↓

[ v1 ][ v1 ][ v1 ][ v1 ][ v2 ]

        ↓

[ v1 ][ v1 ][ v1 ][ v2 ][ v2 ]

        ↓

[ v1 ][ v1 ][ v2 ][ v2 ][ v2 ]

        ↓

[ v1 ][ v2 ][ v2 ][ v2 ][ v2 ]

        ↓

[ v2 ][ v2 ][ v2 ][ v2 ][ v2 ]

2.4 Vantagens do Rolling Update

Simplicidade

Não exige necessariamente ferramentas adicionais.

O próprio Kubernetes gerencia o processo através do recurso Deployment.

Menor consumo de infraestrutura

Normalmente não é necessário manter duas versões completas da aplicação durante todo o deployment.

Ausência de downtime em configurações adequadas

Com probes, réplicas suficientes e valores corretos de maxSurge e maxUnavailable, é possível atualizar a aplicação gradualmente sem interromper o serviço.

Integração nativa

Funciona diretamente com:

Deployment
ReplicaSet
Service
Readiness Probe
Liveness Probe
HPA

2.5 Limitações do Rolling Update

O maior problema é que o Rolling Update não fornece controle preciso sobre qual percentual dos usuários recebe cada versão.

Por exemplo, se existem:

10 Pods

e durante o deployment temos:

9 Pods v1
1 Pod v2

isso não significa necessariamente que exatamente 10% dos usuários receberão a nova versão.

O tráfego dependerá de fatores como:

Balanceamento do Service;
Conexões persistentes;
Distribuição de requisições;
Número de réplicas;
Comportamento do cliente;
Ingress;
Service Mesh.

Além disso, o Kubernetes Deployment não realiza, por conta própria, análise de métricas de negócio para decidir se uma versão deve continuar ou sofrer rollback. Ferramentas de progressive delivery adicionam esse tipo de capacidade.

3. Canary Deployment

O Canary Deployment é uma estratégia na qual uma pequena parcela dos usuários recebe inicialmente a nova versão da aplicação.

O objetivo é limitar o chamado blast radius, ou seja, limitar o número de usuários potencialmente impactados caso exista um problema.

O conceito vem da ideia de validar uma mudança em pequena escala antes de expô-la completamente.

Imagine:

Versão estável: v1
Nova versão: v2

Em vez de migrar todos os usuários:

100% → v2

podemos fazer:

95% → v1
5%  → v2

Após análise:

90% → v1
10% → v2

Depois:

75% → v1
25% → v2

E assim sucessivamente:

50% → v1
50% → v2

↓

25% → v1
75% → v2

↓

0% → v1
100% → v2

O Argo Rollouts define Canary como uma estratégia em que a nova versão é liberada para uma pequena porcentagem do tráfego de produção e permite configurar etapas específicas para controlar essa progressão.

4. Canary Deployment com Argo Rollouts

O Kubernetes padrão não possui um objeto Deployment com Canary completo baseado em porcentagem de tráfego e análise progressiva de métricas.

Para esse cenário, uma solução comum é utilizar o Argo Rollouts, que adiciona um controlador e CRDs para estratégias como Canary e Blue-Green. Ele também pode integrar o rollout com Ingress Controllers, Service Meshes e provedores de métricas.

Em vez de:

kind: Deployment

podemos utilizar:

kind: Rollout

Exemplo:

apiVersion: argoproj.io/v1alpha1
kind: Rollout

metadata:
  name: application

spec:
  replicas: 10

  selector:
    matchLabels:
      app: application

  template:
    metadata:
      labels:
        app: application

    spec:
      containers:
        - name: application
          image: my-application:2.0.0
          ports:
            - containerPort: 8080

  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause:
            duration: 5m

        - setWeight: 25
        - pause:
            duration: 10m

        - setWeight: 50
        - pause:
            duration: 15m

        - setWeight: 100

Nesse cenário, a estratégia é:

Etapa 1
10% do tráfego → nova versão

        ↓

Aguardar 5 minutos

        ↓

Etapa 2
25% do tráfego → nova versão

        ↓

Aguardar 10 minutos

        ↓

Etapa 3
50% do tráfego → nova versão

        ↓

Aguardar 15 minutos

        ↓

Etapa final
100% → nova versão

O Argo Rollouts permite etapas como setWeight e pause, inclusive pausas manuais ou com duração configurada.

5. O papel do Traffic Routing no Canary

Existe uma diferença importante entre:

Quantidade de Pods

Quantidade de tráfego

Suponha que existam:

9 Pods v1
1 Pod v2

Podemos pensar inicialmente:

1 Pod de 10 = 10% do tráfego

Porém, isso é apenas uma aproximação.

Sem um mecanismo avançado de roteamento, a distribuição pode ser aproximada pela proporção de Pods. A própria documentação do Argo Rollouts destaca essa limitação e explica que, para um controle mais fino de pesos, é necessário utilizar um Ingress Controller ou Service Mesh com capacidade de traffic shaping.

Com um sistema de traffic routing, é possível definir:

95% → Stable
5%  → Canary

mesmo que a quantidade de Pods não represente exatamente essa mesma proporção.

Exemplo conceitual:

                   ┌──────────────────┐
Usuários ────────► │ Ingress / Gateway│
                   └────────┬─────────┘
                            │
                  ┌─────────┴─────────┐
                  │                   │
                90%                 10%
                  │                   │
                  ▼                   ▼
          ┌─────────────┐     ┌─────────────┐
          │ Stable v1   │     │ Canary v2   │
          └─────────────┘     └─────────────┘

Dependendo da arquitetura, o roteamento pode ser integrado com tecnologias como:

NGINX;
Istio;
Linkerd;
AWS ALB;
App Mesh;
SMI e outros provedores suportados.

O Argo Rollouts possui integrações específicas para diferentes mecanismos de traffic routing.

6. Canary baseado em métricas

Um dos maiores benefícios do Canary é a possibilidade de tomar decisões baseadas em dados reais.

Durante uma etapa:

90% Stable
10% Canary

podemos monitorar indicadores como:

Taxa de erro

HTTP 5xx
Exceptions
Falhas de API

Latência

p95
p99
Tempo médio de resposta

Consumo de recursos

CPU
Memória
Network

Métricas de negócio

Pedidos concluídos
Logins realizados
Pagamentos aprovados
Taxa de conversão

Suponha que a nova versão apresente:

v1
Error Rate: 0.2%
p95: 150ms

E o Canary:

v2
Error Rate: 4.8%
p95: 1200ms

O rollout pode ser interrompido antes que a nova versão seja entregue para toda a base de usuários.

O Argo Rollouts oferece integração com provedores de métricas e análise para apoiar promoções ou rollbacks automatizados.

7. Fluxo completo de um Canary Deployment

Um fluxo de produção pode funcionar assim:

                    CI/CD Pipeline
                          │
                          ▼
                    Build da imagem
                          │
                          ▼
                  Testes automatizados
                          │
                          ▼
                 Publicação no Registry
                          │
                          ▼
                   Atualização do Rollout
                          │
                          ▼
                Nova versão é criada
                          │
                          ▼
                   5% do tráfego
                          │
                          ▼
                  Análise de métricas
                     │            │
                  Sucesso       Falha
                     │            │
                     ▼            ▼
                10% tráfego    Rollback
                     │
                     ▼
                  25% tráfego
                     │
                     ▼
                  50% tráfego
                     │
                     ▼
                 100% tráfego
                     │
                     ▼
                 Deploy concluído

8. Blue-Green Deployment

O Blue-Green Deployment trabalha com dois ambientes ou duas versões da aplicação.

Tradicionalmente:

Blue  = versão atual
Green = nova versão

Exemplo:

BLUE
my-application:1.0.0

GREEN
my-application:2.0.0

Inicialmente:

Usuários
    │
    ▼
BLUE - v1

A nova versão é criada:

                 ┌──────────────┐
                 │ BLUE - v1    │
Usuários ───────►│ Produção     │
                 └──────────────┘

                 ┌──────────────┐
                 │ GREEN - v2   │
                 │ Preview/Test │
                 └──────────────┘

A versão Green pode ser validada antes de receber o tráfego principal.

Após a aprovação:

Antes:

Usuários → BLUE v1

Depois:

Usuários → GREEN v2

A troca pode ser muito rápida porque, em vez de substituir Pods progressivamente, o roteamento de produção passa a apontar para a nova versão.

A documentação do Argo Rollouts descreve Blue-Green como uma estratégia na qual a versão antiga e a nova podem coexistir, enquanto a nova é validada antes da troca do tráfego de produção.

9. Blue-Green no Kubernetes com Argo Rollouts

O Argo Rollouts pode utilizar dois Services:

Active Service
Preview Service

A arquitetura pode ser representada assim:

                         ┌──────────────────────┐
                         │      Usuários        │
                         └──────────┬───────────┘
                                    │
                                    ▼
                         ┌──────────────────────┐
                         │   Active Service     │
                         └──────────┬───────────┘
                                    │
                                    ▼
                         ┌──────────────────────┐
                         │      BLUE v1         │
                         │     Produção         │
                         └──────────────────────┘


                         ┌──────────────────────┐
                         │   Preview Service    │
                         └──────────┬───────────┘
                                    │
                                    ▼
                         ┌──────────────────────┐
                         │      GREEN v2        │
                         │      Preview         │
                         └──────────────────────┘

Exemplo:

apiVersion: argoproj.io/v1alpha1
kind: Rollout

metadata:
  name: application

spec:
  replicas: 5

  selector:
    matchLabels:
      app: application

  template:
    metadata:
      labels:
        app: application

    spec:
      containers:
        - name: application
          image: my-application:2.0.0

  strategy:
    blueGreen:
      activeService: application-active
      previewService: application-preview

      autoPromotionEnabled: false

      scaleDownDelaySeconds: 30

Nesse modelo, o activeService continua direcionando o tráfego normal para a versão atual, enquanto o previewService pode direcionar tráfego de validação para a nova versão. O Argo Rollouts permite pausar antes da promoção usando autoPromotionEnabled: false e possui configurações adicionais para análise antes ou depois da promoção.

10. Fluxo do Blue-Green Deployment

Podemos dividir o processo em etapas.

Etapa 1 — Produção

Active Service
       │
       ▼
BLUE - v1

A versão atual atende os usuários.

Etapa 2 — Criação da nova versão

Active Service                Preview Service
       │                             │
       ▼                             ▼
BLUE - v1                      GREEN - v2
Produção                       Nova versão

A nova versão é iniciada.

Etapa 3 — Validação

A equipe pode testar:

GREEN - v2

Por meio de:

Smoke tests;
Testes automatizados;
Testes de integração;
Testes manuais;
Testes de performance;
Análise de métricas.

Etapa 4 — Promoção

Após a aprovação:

Antes:

Active Service → BLUE v1

A promoção altera o direcionamento:

Depois:

Active Service → GREEN v2

O tráfego produtivo é transferido para a nova versão.

Etapa 5 — Período de segurança

A versão anterior pode continuar disponível temporariamente.

GREEN - v2 → Produção

BLUE - v1 → Mantida temporariamente

Isso facilita uma reversão rápida caso um problema seja identificado.

11. Rollback no Blue-Green

O Blue-Green possui uma característica muito importante: a versão anterior pode continuar pronta para uso.

Imagine:

BLUE = v1
GREEN = v2

Após a promoção:

Usuários → GREEN v2

Se for identificado um problema crítico:

Usuários → BLUE v1

O rollback pode ser baseado na reversão do roteamento, desde que a versão anterior ainda esteja disponível e compatível com o estado do sistema.

Porém, existe um ponto fundamental: rollback de aplicação não significa automaticamente rollback de banco de dados.

Imagine que a versão v2 execute uma migration:

ALTER TABLE users ADD COLUMN new_field;

Isso pode ser compatível com a versão antiga.

Mas imagine uma migration destrutiva:

ALTER TABLE users DROP COLUMN old_field;

Caso a versão v1 dependa dessa coluna:

Rollback da aplicação → v1
Banco de dados → incompatível

Portanto, estratégias de deployment devem ser combinadas com estratégias seguras de evolução de banco de dados.

Uma abordagem muito utilizada é:

Expand
   ↓
Deploy
   ↓
Migrate
   ↓
Contract

Por exemplo:

Expand

Adicionar a nova estrutura sem remover a antiga.

Banco v1 + novas estruturas

Deploy

Publicar a aplicação nova.

Aplicação v1 + Aplicação v2 compatíveis

Migrate

Migrar gradualmente dados ou comportamento.

Contract

Somente após a estabilização remover estruturas antigas.

12. Comparação entre Rolling Update, Canary e Blue-Green

Característica	Rolling Update	Canary	Blue-Green
Estratégia nativa no Kubernetes	Sim	Não de forma completa	Não de forma completa
Ferramenta adicional	Não necessariamente	Geralmente sim	Geralmente sim
Duas versões simultâneas	Temporariamente	Sim	Sim
Controle percentual de tráfego	Limitado	Excelente com traffic routing	Geralmente troca de ambiente
Validação gradual	Limitada	Excelente	Pré/pós-promoção
Rollback	Possível	Excelente	Muito rápido
Consumo de infraestrutura	Baixo/Médio	Médio	Alto
Complexidade	Baixa	Alta	Média
Ideal para	Aplicações comuns	Sistemas críticos e alto tráfego	Sistemas que exigem troca controlada

13. Comparação visual

Rolling Update

v1 v1 v1 v1 v1

↓ Deploy

v2 v1 v1 v1 v1

↓

v2 v2 v1 v1 v1

↓

v2 v2 v2 v1 v1

↓

v2 v2 v2 v2 v1

↓

v2 v2 v2 v2 v2

Canary

Produção

95% → v1
5%  → v2

↓

90% → v1
10% → v2

↓

75% → v1
25% → v2

↓

50% → v1
50% → v2

↓

0% → v1
100% → v2

Blue-Green

Fase inicial

100% → BLUE v1
0%   → GREEN v2


Validação

100% → BLUE v1
GREEN v2 → Preview/Test


Promoção

0%   → BLUE v1
100% → GREEN v2

14. Quando utilizar Rolling Update?

O Rolling Update é uma excelente escolha quando:

A aplicação possui múltiplas réplicas;
Existe uma boa estratégia de readiness probes;
As versões podem coexistir;
Não existe necessidade de controle preciso do tráfego;
O sistema possui risco moderado;
A equipe deseja simplicidade operacional.

Exemplo:

API interna
5 réplicas
Baixo risco
Boa cobertura de testes

Uma configuração como:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

pode ser suficiente.

O Kubernetes também permite acompanhar o andamento do rollout e detectar falta de progresso através de progressDeadlineSeconds; a documentação indica que o padrão é 600 segundos.

15. Quando utilizar Canary Deployment?

O Canary é recomendado quando:

A aplicação possui grande volume de usuários;
Uma falha pode causar grande impacto;
Existem métricas confiáveis;
A equipe possui observabilidade madura;
Existe necessidade de limitar o impacto de uma nova versão;
O sistema permite múltiplas versões executando simultaneamente.

Exemplo:

API de pagamentos
Milhões de requisições
SLA crítico
Prometheus + Grafana + Alerting

Uma estratégia possível:

1%
↓
5%
↓
10%
↓
25%
↓
50%
↓
100%

Entre cada etapa:

Analisar:
- Error rate
- p95
- p99
- CPU
- Memory
- Métricas de negócio

Se algo falhar:

Abortar
↓
Retornar tráfego para Stable
↓
Investigar

16. Quando utilizar Blue-Green?

O Blue-Green é recomendado quando:

É necessário validar a aplicação inteira antes da promoção;
A troca precisa ser rápida;
O rollback precisa ser simples;
A infraestrutura suporta temporariamente duas versões;
Não é necessário fazer uma liberação progressiva por percentual.

Exemplo:

Sistema corporativo crítico

Fluxo:

Produção → BLUE v1

Nova versão → GREEN v2

Testes → GREEN v2

Aprovação → troca Active Service

Produção → GREEN v2

Caso ocorra uma falha:

GREEN v2 → problema

↓

Retornar tráfego

↓

BLUE v1

17. O que é Progressive Delivery?

Progressive Delivery é um conceito que evolui a ideia de Continuous Delivery.

Em um pipeline tradicional:

Code
 ↓
Build
 ↓
Test
 ↓
Deploy
 ↓
Produção

No Progressive Delivery:

Code
 ↓
Build
 ↓
Test
 ↓
Deploy
 ↓
Pequena exposição
 ↓
Análise de métricas
 ↓
Aumentar exposição
 ↓
Nova análise
 ↓
Produção completa

A diferença fundamental é que o deployment deixa de ser apenas uma ação técnica e passa a ser um processo controlado por feedback real do ambiente de produção.

O Argo Rollouts descreve Progressive Delivery justamente como uma liberação controlada e gradual, com exposição limitada da nova versão, observação contínua e promoção ou rollback com base na validação.

18. A importância da observabilidade

Canary e Blue-Green ficam muito mais eficientes quando combinados com observabilidade.

Uma arquitetura pode ser:

                    ┌───────────────┐
                    │   Kubernetes  │
                    └───────┬───────┘
                            │
                 ┌──────────┴──────────┐
                 │                     │
                 ▼                     ▼
           Stable v1              Canary v2
                 │                     │
                 └──────────┬──────────┘
                            │
                            ▼
                      Prometheus
                            │
                            ▼
                       Grafana
                            │
                            ▼
                    Argo Rollouts
                            │
                  ┌─────────┴─────────┐
                  │                   │
                Sucesso             Falha
                  │                   │
                  ▼                   ▼
              Promover             Rollback

Métricas importantes incluem:

HTTP 5xx
Latency p95
Latency p99
CPU
Memory
Restarts
OOMKilled
Saturation
Request rate
Business KPIs

A pergunta não deve ser apenas:

Os Pods estão rodando?

Mas também:

A nova versão está funcionando melhor ou pelo menos dentro dos limites aceitáveis?

Um Pod pode estar:

Running

e ainda assim a aplicação pode estar apresentando:

Latência alta
Erros de negócio
Falhas de integração
Timeouts

Por isso, readiness probes são importantes, mas não substituem análise mais profunda de métricas. Essa é uma das diferenças importantes entre o Rolling Update tradicional e soluções de progressive delivery.

19. Readiness Probe e estratégias de deploy

Independentemente da estratégia escolhida, a aplicação deve informar corretamente quando está pronta para receber tráfego.

Exemplo:

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080

  initialDelaySeconds: 10
  periodSeconds: 5

Enquanto o Pod não estiver pronto:

Pod criado
   ↓
Aplicação iniciando
   ↓
Readiness = false
   ↓
Não recebe tráfego
   ↓
Aplicação pronta
   ↓
Readiness = true
   ↓
Pode receber tráfego

Isso é fundamental especialmente em Rolling Updates.

Uma estratégia segura não depende apenas do controller de deployment. Ela depende também da qualidade da configuração da aplicação.

20. Exemplo de estratégia para diferentes níveis de criticidade

Aplicação de baixo risco

Rolling Update

Configuração:

maxSurge: 1
maxUnavailable: 0

Aplicação de médio risco

Rolling Update
+
Readiness Probe
+
Liveness Probe
+
Observabilidade
+
Rollback automático ou manual via pipeline

Aplicação de alto risco

Canary
+
Traffic Routing
+
Prometheus
+
Grafana
+
Alerting
+
Análise automática
+
Rollback automático

Aplicação crítica com necessidade de reversão rápida

Blue-Green
+
Preview Environment
+
Smoke Tests
+
Pre-Promotion Analysis
+
Post-Promotion Monitoring

21. Arquitetura recomendada para Progressive Delivery

Uma arquitetura moderna pode utilizar:

Developer
    │
    ▼
Git Repository
    │
    ▼
CI Pipeline
    │
    ├── Testes
    ├── Lint
    ├── Security Scan
    └── Build Docker Image
    │
    ▼
Container Registry
    │
    ▼
GitOps Repository
    │
    ▼
Argo CD
    │
    ▼
Kubernetes
    │
    ▼
Argo Rollouts
    │
    ├── Canary
    │       │
    │       ▼
    │   Traffic Routing
    │       │
    │       ▼
    │   Métricas
    │       │
    │       ▼
    │   Promote/Rollback
    │
    └── Blue-Green
            │
            ▼
      Preview + Active

Nesse modelo:

CI constrói e valida o software;
Container Registry armazena a imagem;
GitOps controla o estado desejado;
Argo CD sincroniza o cluster;
Argo Rollouts controla a estratégia de entrega;
Prometheus/Grafana fornecem observabilidade.

22. Conclusão

Não existe uma única estratégia de deployment ideal para todas as aplicações.

O Rolling Update é simples, eficiente e faz parte do Kubernetes. É uma ótima escolha para aplicações que podem coexistir entre versões e não precisam de um controle detalhado sobre a distribuição do tráfego.

O Blue-Green Deployment é especialmente útil quando é necessário preparar e validar completamente uma nova versão antes de realizar uma troca rápida do tráfego. Sua principal vantagem é a simplicidade de promoção e a possibilidade de reversão rápida, embora normalmente exija mais recursos de infraestrutura.

O Canary Deployment oferece o maior nível de controle sobre a exposição da nova versão. Ele permite liberar a aplicação progressivamente para uma parcela dos usuários, analisar métricas reais e interromper o rollout antes que uma falha atinja toda a base de usuários.

Podemos resumir as estratégias da seguinte maneira:

Rolling Update
→ Simplicidade e eficiência
→ Atualização gradual de Pods
→ Estratégia nativa do Kubernetes

Blue-Green
→ Validação completa antes da promoção
→ Troca rápida entre versões
→ Excelente para rollback rápido

Canary
→ Exposição gradual ao tráfego
→ Redução do blast radius
→ Métricas e análise progressiva
→ Ideal para ambientes críticos

Para ambientes modernos de produção, especialmente aplicações de alto impacto, a evolução natural é sair de um modelo baseado apenas em:

Deploy → Torcer para funcionar

para um modelo de Progressive Delivery:

Deploy
   ↓
Expor parcialmente
   ↓
Medir
   ↓
Validar
   ↓
Promover
ou
Rollback

Dessa forma, o Kubernetes deixa de ser apenas uma plataforma para executar containers e passa a fazer parte de uma estratégia completa de entrega segura, automatizada, observável e resiliente.

Karpenter Redefinindo o Autoscaling de Clusters Kubernetes com Provisionamento Just-in-Time

Kauê Matos — Sat, 25 Apr 2026 18:51:37 +0000

A escalabilidade de clusters Kubernetes evoluiu de modelos baseados em grupos estáticos para arquiteturas dinâmicas e orientadas a eventos. O Karpenter, um orquestrador de infraestrutura de código aberto desenvolvido pela AWS, lidera essa transformação ao eliminar a necessidade de gerenciar grupos de auto-escalonamento (ASGs) e focar diretamente nos requisitos de recursos de cada Pod pendente. Este artigo analisa a arquitetura técnica do Karpenter, sua comparação com o Cluster Autoscaler tradicional e as melhores práticas para operação em ambientes de produção.

1. Arquitetura e o Paradigma Just-in-Time

Diferente do Cluster Autoscaler (CA), que atua ajustando o tamanho de grupos de nós pré-definidos, o Karpenter interage diretamente com as APIs de nuvem (como o Amazon EC2 Fleet) para lançar a instância exata necessária para um Pod.

Comparativo: Karpenter vs. Cluster Autoscaler

Característica	Cluster Autoscaler (CA)	Karpenter
Mecanismo	Ajusta capacidade de ASGs existentes.	Provisiona nós individuais via API direta.
Loop de Decisão	Baseado em varredura periódica (~10s).	Baseado em eventos (reação imediata).
Latência	Minutos (espera o ASG e o SO).	Segundos (45-60s para entrar online).
Flexibilidade	Limitada por tipos de instâncias fixas.	Heterogênea (qualquer tipo EC2 compatível).

Enquanto o CA depende de simulações de agendamento para grupos idênticos, o Karpenter utiliza algoritmos de bin-packing para consolidar múltiplos Pods em menos instâncias, ou em instâncias mais baratas, reduzindo a fragmentação de recursos no cluster.

2. A Evolução para v1: NodePools e EC2NodeClasses

Com o lançamento da versão 1.0, o Karpenter consolidou suas APIs de "beta" para "estável", simplificando o modelo de configuração em torno do conceito de nós. As APIs antigas foram substituídas:

Provisioner tornou-se NodePool: Define a lógica de agendamento, como tipos de instâncias permitidos (x86 vs ARM), zonas de disponibilidade e políticas de interrupção.
AWSNodeTemplate tornou-se EC2NodeClass: Foca em configurações específicas da AWS, como Subnets, Security Groups, AMIs e configurações de disco.

Uma mudança crítica na v1 foi a promoção do mecanismo de Drift para estável. O Drift detecta automaticamente quando o estado real de um nó diverge da definição no NodePool ou EC2NodeClass (por exemplo, após uma atualização de AMI), disparando a substituição segura do nó.

3. Estratégias de Disrupção e Eficiência Operacional

O Karpenter utiliza o "Disruption Controller" para manter o cluster saudável e financeiramente eficiente por meio de três métodos principais:

Consolidação: O Karpenter busca continuamente caminhos para reduzir custos, identificando nós vazios ou subutilizados. Ele pode remover um nó totalmente vazio ou substituir um nó caro por uma variante mais barata se os Pods puderem ser reacomodados.
Drift: Garante que os nós sigam a especificação mais recente do código de infraestrutura, facilitando upgrades de sistema operacional e patches de segurança sem intervenção manual.
Interrupção: Monitora sinais de saúde e notificações de instâncias Spot (2 minutos de aviso), provisionando proativamente a capacidade de substituição antes que o nó seja removido.

4. Otimização Econômica: O Poder das Instâncias Spot e Graviton

A maior vantagem financeira do Karpenter reside na sua capacidade de gerenciar frotas mistas de instâncias de forma inteligente. Ele prioriza as compras de computação seguindo uma hierarquia de ROI:

Capacity Reservations: Utiliza capacidade já paga e reservada.
Spot Instances: Oferece economias de até 90% em comparação ao preço sob demanda.
On-Demand: Utilizada como fallback quando a capacidade Spot é escassa.

Exemplo de Impacto em Custos

Considerando um cluster com 5 nós do tipo m5.large em operação contínua (30 dias):

Cluster Autoscaler (On-Demand): Aproximadamente $417,60/mês.
Karpenter (Spot Otimizado): Aproximadamente $210,30/mês.
Economia Direta: (Redução de ~50%).

5. Melhores Práticas para Produção

Para uma implementação de sucesso, a AWS recomenda as seguintes diretrizes:

Diversificação de Instâncias: Use seletores amplos no NodePool para permitir que o Karpenter escolha entre diversas famílias de instâncias, aumentando a resiliência à falta de capacidade Spot em zonas específicas.
Pod Disruption Budgets (PDBs): Sempre configure PDBs para suas aplicações. O Karpenter respeita rigorosamente essas regras, garantindo que a disponibilidade do serviço não seja comprometida durante as ações de consolidação.
Hybrid Node Groups: Mantenha um pequeno grupo de nós gerenciados (Managed Node Groups) para cargas de trabalho críticas do sistema (como o próprio controlador do Karpenter e o CoreDNS), permitindo que o Karpenter gerencie o restante dos workloads de aplicação.
Ajuste de Recursos (VPA): O Karpenter é tão eficiente quanto os dados que recebe. Se os Pods superestimarem o uso de CPU/Memória, o Karpenter irá provisionar nós maiores que o necessário.

Conclusão

O Karpenter representa o estado da arte para o autoscaling em Kubernetes, transformando a infraestrutura de uma barreira estática em um recurso dinâmico e reativo. Ao adotar a versão 1.0 e seus novos conceitos de NodePools e Disruption Budgets, as organizações não apenas reduzem drasticamente sua latência de escalonamento, mas também alcançam um nível de eficiência financeira e operacional que os métodos tradicionais de Provisionamento de Grupos não conseguem igualar.

kubectl: o guia completo de comandos utilitários do Kubernetes

Kauê Matos — Mon, 20 Apr 2026 00:51:16 +0000

kubectl: o guia completo de comandos utilitários do Kubernetes

O kubectl é a CLI oficial do Kubernetes — é através dele que você interage com qualquer cluster, seja local (kind, minikube) ou em produção (EKS, GKE, AKS). Dominar seus comandos é a diferença entre um operador que abre o dashboard e um que resolve problemas em segundos no terminal.

Veja o mapa mental das principais categorias de comandos antes de mergulhar em cada uma:---

1. Inspeção — entendendo o que está rodando

`kubectl get`

O comando mais usado do dia a dia. Lista recursos do cluster.

# Listar pods no namespace atual
kubectl get pods

# Listar pods de todos os namespaces
kubectl get pods -A

# Listar pods com mais detalhes (IP, nó, tempo)
kubectl get pods -o wide

# Listar em formato YAML (útil para exportar configurações)
kubectl get deployment minha-app -o yaml

# Listar em formato JSON e filtrar com jq
kubectl get pods -o json | jq '.items[].metadata.name'

# Assistir mudanças em tempo real
kubectl get pods -w

# Listar múltiplos recursos de uma vez
kubectl get pods,services,deployments

Recursos comuns que você vai usar com get: pods, services (ou svc), deployments (ou deploy), nodes, namespaces (ou ns), configmaps (ou cm), secrets, ingresses, persistentvolumeclaims (ou pvc).

`kubectl describe`

Mostra os detalhes completos de um recurso, incluindo eventos — essencial para diagnosticar problemas.

# Descrever um pod específico
kubectl describe pod meu-pod-abc123

# Descrever todos os pods de um deployment
kubectl describe pods -l app=minha-app

# Descrever um nó
kubectl describe node worker-1

# Descrever um service
kubectl describe svc meu-service

A seção Events no final do describe é onde ficam as mensagens de erro mais úteis — sempre role até lá quando um pod não sobe.

`kubectl logs`

# Ver logs de um pod
kubectl logs meu-pod

# Seguir logs em tempo real (equivalente ao -f do tail)
kubectl logs -f meu-pod

# Ver os últimos 100 logs
kubectl logs --tail=100 meu-pod

# Logs de um container específico (pods multi-container)
kubectl logs meu-pod -c meu-container

# Logs de um pod que já morreu (crashou)
kubectl logs meu-pod --previous

# Logs dos últimos 30 minutos
kubectl logs meu-pod --since=30m

# Logs de todos os pods de um deployment via label
kubectl logs -l app=minha-app --all-containers=true

`kubectl top`

Mostra consumo de CPU e memória em tempo real. Requer o Metrics Server instalado.

# Consumo dos nós
kubectl top nodes

# Consumo dos pods
kubectl top pods

# Consumo dos pods de um namespace específico
kubectl top pods -n producao

# Ordenar por consumo de CPU
kubectl top pods --sort-by=cpu

2. Criação e gerenciamento de recursos

`kubectl apply`

A forma declarativa de criar ou atualizar recursos. É o comando que você deve usar em produção.

# Aplicar um arquivo
kubectl apply -f deployment.yaml

# Aplicar todos os YAMLs de um diretório
kubectl apply -f ./k8s/

# Aplicar de uma URL remota
kubectl apply -f https://raw.githubusercontent.com/.../manifest.yaml

# Ver o que seria aplicado sem aplicar (dry-run)
kubectl apply -f deployment.yaml --dry-run=client

# Ver diff entre o que está no cluster e o que será aplicado
kubectl diff -f deployment.yaml

`kubectl create`

Forma imperativa, útil para criações rápidas e one-shot.

# Criar um namespace
kubectl create namespace staging

# Criar um deployment rapidamente
kubectl create deployment nginx --image=nginx:1.25

# Criar um secret a partir de variáveis literais
kubectl create secret generic db-creds \
  --from-literal=user=admin \
  --from-literal=password=s3cr3t

# Criar secret a partir de arquivo .env
kubectl create secret generic app-env --from-env-file=.env

# Criar configmap a partir de arquivo
kubectl create configmap app-config --from-file=config.yaml

# Expor um deployment como service
kubectl expose deployment minha-app --port=80 --target-port=8080 --type=ClusterIP

`kubectl delete`

# Deletar por arquivo
kubectl delete -f deployment.yaml

# Deletar por tipo e nome
kubectl delete pod meu-pod

# Deletar todos os pods de um namespace
kubectl delete pods --all -n staging

# Deletar por label
kubectl delete pods -l app=minha-app

# Forçar deleção imediata (cuidado em produção)
kubectl delete pod meu-pod --grace-period=0 --force

# Deletar namespace inteiro (e tudo dentro)
kubectl delete namespace staging

`kubectl edit`

Abre o recurso no editor padrão ($EDITOR) diretamente para edição ao vivo.

kubectl edit deployment minha-app
kubectl edit configmap app-config

Útil para ajustes rápidos, mas evite em produção — prefira apply com arquivos versionados no Git.

3. Execução e acesso a containers

`kubectl exec`

Executa comandos dentro de um container em execução.

# Abrir shell interativo em um pod
kubectl exec -it meu-pod -- /bin/bash

# Abrir shell em um container específico (pod multi-container)
kubectl exec -it meu-pod -c sidecar -- /bin/sh

# Executar um comando sem shell interativo
kubectl exec meu-pod -- env

# Checar conectividade de dentro do pod
kubectl exec -it meu-pod -- curl http://outro-service:8080/health

`kubectl port-forward`

Redireciona uma porta local para uma porta dentro do cluster. Indispensável em desenvolvimento.

# Forward da porta local 8080 para a porta 80 do pod
kubectl port-forward pod/meu-pod 8080:80

# Forward para um service
kubectl port-forward svc/meu-service 8080:80

# Forward para um deployment (escolhe um pod automaticamente)
kubectl port-forward deployment/minha-app 8080:8080

# Escutar em todos os endereços (não só localhost)
kubectl port-forward svc/meu-service 8080:80 --address=0.0.0.0

`kubectl run`

Cria um pod temporário — excelente para testes e diagnósticos.

# Pod temporário interativo com curl disponível
kubectl run debug --image=curlimages/curl -it --rm -- sh

# Pod temporário com busybox para troubleshooting de rede
kubectl run nettest --image=busybox -it --rm -- sh

# Testar DNS de dentro do cluster
kubectl run dns-test --image=busybox --rm -it -- nslookup meu-service

# Pod temporário que morre sozinho após o comando
kubectl run teste --image=alpine --rm --restart=Never -- echo "funciona"

O flag --rm garante que o pod seja deletado automaticamente ao terminar.

`kubectl cp`

Copia arquivos entre o host e um container.

# Copiar arquivo do pod para o host
kubectl cp meu-pod:/app/logs/app.log ./app.log

# Copiar arquivo do host para o pod
kubectl cp ./config.yaml meu-pod:/app/config.yaml

# Copiar de um container específico
kubectl cp meu-pod:/dados ./dados -c meu-container

4. Escalonamento e rollouts

`kubectl scale`

# Escalar um deployment para 5 réplicas
kubectl scale deployment minha-app --replicas=5

# Escalar para zero (suspende a aplicação)
kubectl scale deployment minha-app --replicas=0

# Escalar múltiplos deployments de uma vez
kubectl scale deployment app-a app-b --replicas=3

`kubectl rollout`

Gerencia o ciclo de vida de deployments — um dos comandos mais importantes para operação.

# Ver status de um rollout em andamento
kubectl rollout status deployment/minha-app

# Ver histórico de versões
kubectl rollout history deployment/minha-app

# Ver detalhes de uma revisão específica
kubectl rollout history deployment/minha-app --revision=3

# Fazer rollback para a versão anterior
kubectl rollout undo deployment/minha-app

# Fazer rollback para uma revisão específica
kubectl rollout undo deployment/minha-app --to-revision=2

# Pausar um rollout em andamento
kubectl rollout pause deployment/minha-app

# Retomar um rollout pausado
kubectl rollout resume deployment/minha-app

# Forçar um novo rollout sem mudar nada (útil para reiniciar pods)
kubectl rollout restart deployment/minha-app

O kubectl rollout restart é especialmente útil para forçar os pods a recarregarem ConfigMaps ou Secrets que foram atualizados.

`kubectl autoscale`

Cria um HorizontalPodAutoscaler (HPA) de forma imperativa.

# Escalar entre 2 e 10 réplicas baseado em CPU
kubectl autoscale deployment minha-app --min=2 --max=10 --cpu-percent=70

5. Debug e diagnóstico avançado

`kubectl debug`

Introduzido no Kubernetes 1.18, permite criar containers de debug efêmeros.

# Adicionar container de debug a um pod em execução
kubectl debug -it meu-pod --image=busybox --target=meu-container

# Criar cópia do pod com shell para debug
kubectl debug meu-pod -it --copy-to=meu-pod-debug --image=ubuntu

# Debug de um nó diretamente
kubectl debug node/worker-1 -it --image=ubuntu

`kubectl events`

Lista eventos do cluster — muito mais rápido que describe quando você quer ver tudo de uma vez.

# Ver todos os eventos do namespace atual
kubectl events

# Ver eventos de um namespace específico
kubectl events -n producao

# Ver eventos em ordem cronológica
kubectl events --sort-by=lastTimestamp

# Ver eventos de um recurso específico
kubectl events --for pod/meu-pod

# Ver apenas eventos de Warning
kubectl events --types=Warning

`kubectl diff`

Mostra exatamente o que mudaria antes de aplicar um manifest — fundamental em pipelines de CD.

kubectl diff -f deployment.yaml

6. Contextos e namespaces

Em ambientes reais você lida com múltiplos clusters e namespaces. Estes comandos evitam confusão e erros graves.

Gerenciando contextos

# Ver o contexto atual
kubectl config current-context

# Listar todos os contextos disponíveis
kubectl config get-contexts

# Trocar de contexto (mudar de cluster)
kubectl config use-context producao

# Renomear um contexto
kubectl config rename-context velho-nome novo-nome

# Deletar um contexto
kubectl config delete-context contexto-antigo

# Ver o kubeconfig completo
kubectl config view

Trabalhando com namespaces

# Listar todos os namespaces
kubectl get namespaces

# Executar comando em um namespace específico
kubectl get pods -n kube-system

# Mudar o namespace padrão do contexto atual
kubectl config set-context --current --namespace=staging

# Listar recursos em todos os namespaces
kubectl get pods --all-namespaces
# ou o shorthand:
kubectl get pods -A

Uma dica de ouro: use a ferramenta kubens (do pacote kubectx) para trocar de namespace com um simples kubens staging. Da mesma forma, kubectx producao troca de cluster. São as duas ferramentas de produtividade mais recomendadas para quem usa kubectl no dia a dia.

7. Comandos de produtividade

Labels e seletores

# Adicionar label a um pod
kubectl label pod meu-pod ambiente=producao

# Remover label
kubectl label pod meu-pod ambiente-

# Filtrar por label
kubectl get pods -l app=minha-app,ambiente=producao

# Filtrar com operadores de conjunto
kubectl get pods -l 'ambiente in (staging, dev)'

Anotações

# Adicionar anotação
kubectl annotate deployment minha-app \
  kubernetes.io/change-cause="Atualiza para v2.1.0"

# Anotações ficam no histórico do rollout
kubectl rollout history deployment/minha-app

`kubectl patch`

Atualiza um campo específico sem precisar editar o arquivo inteiro.

# Atualizar a imagem de um container via patch JSON
kubectl patch deployment minha-app \
  -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"minha-app:v2"}]}}}}'

# Patch com merge estratégico
kubectl patch deployment minha-app --type=merge \
  -p '{"spec":{"replicas":3}}'

Output e formatação

# Colunas customizadas com jsonpath
kubectl get pods -o jsonpath='{.items[*].metadata.name}'

# Formato de tabela customizado
kubectl get pods \
  -o custom-columns=NOME:.metadata.name,STATUS:.status.phase,IP:.status.podIP

# Exportar todos os deployments do namespace em YAML
kubectl get deployments -o yaml > backup-deployments.yaml

Aliases úteis para o `.bashrc` / `.zshrc`

alias k='kubectl'
alias kg='kubectl get'
alias kd='kubectl describe'
alias kl='kubectl logs'
alias kx='kubectl exec -it'
alias kns='kubectl config set-context --current --namespace'
alias kctx='kubectl config use-context'

Com alias k='kubectl', você pode usar simplesmente k get pods, k apply -f ., k logs -f meu-pod e ganhar muito tempo no dia a dia.

8. Referência rápida dos recursos e seus atalhos

Recurso completo	Abreviação
`pods`	`po`
`services`	`svc`
`deployments`	`deploy`
`replicasets`	`rs`
`statefulsets`	`sts`
`daemonsets`	`ds`
`configmaps`	`cm`
`namespaces`	`ns`
`nodes`	`no`
`persistentvolumes`	`pv`
`persistentvolumeclaims`	`pvc`
`horizontalpodautoscalers`	`hpa`
`ingresses`	`ing`
`serviceaccounts`	`sa`

Você pode ver todos os recursos disponíveis (incluindo CRDs instalados) com:

kubectl api-resources

9. O comando que todo mundo esquece: `kubectl explain`

Documentação inline, sem precisar abrir o browser.

# Explicar um recurso
kubectl explain pod

# Explicar um campo específico
kubectl explain pod.spec.containers

# Explicar de forma recursiva (mostra todos os campos)
kubectl explain pod.spec --recursive

# Explicar para uma versão específica da API
kubectl explain deployment.spec.strategy --api-version=apps/v1

kind: o jeito mais rápido de ter um cluster Kubernetes sem gastar um centavo de cloud

Kauê Matos — Mon, 20 Apr 2026 00:14:22 +0000

O que é o kind?

O kind (Kubernetes IN Docker) é uma ferramenta que permite executar clusters Kubernetes locais usando contêineres Docker como "nós" (nodes). Criado originalmente para testar o próprio Kubernetes, hoje é amplamente usado por desenvolvedores para desenvolvimento local, CI/CD e aprendizado.

Antes de mergulhar nos detalhes, veja como a arquitetura funciona:---

Por que usar o kind?

Antes do kind existia o Minikube, que usa máquinas virtuais para simular um cluster. O kind trocou VMs por contêineres Docker, o que trouxe vantagens concretas:

Velocidade: um cluster sobe em cerca de 60 segundos.
Leveza: sem overhead de VM, consome muito menos RAM e CPU.
Multi-nó: é possível criar clusters com vários nodes no mesmo laptop.
CI/CD nativo: por rodar em Docker, funciona perfeitamente em pipelines como GitHub Actions, GitLab CI, Jenkins etc.
Versão exata do Kubernetes: você escolhe exatamente qual versão do K8s usar via image tag.

Instalação

O kind é um binário único, sem dependências além do Docker.

macOS (Homebrew)

brew install kind

Linux (binário direto)

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

Windows (Chocolatey)

choco install kind

Go install

go install sigs.k8s.io/kind@v0.23.0

Você também precisará do kubectl instalado separadamente para interagir com o cluster.

Uso básico

Criar um cluster

# Cluster simples com nome padrão ("kind")
kind create cluster

# Cluster com nome personalizado
kind create cluster --name meu-cluster

O comando acima cria um cluster de nó único (control plane + worker no mesmo contêiner) e configura automaticamente o ~/.kube/config para que o kubectl aponte para ele.

Verificar o cluster

kubectl cluster-info --context kind-meu-cluster
kubectl get nodes

Listar e deletar clusters

kind get clusters
kind delete cluster --name meu-cluster

Configuração avançada com arquivo YAML

O kind aceita um arquivo de configuração para personalizar o cluster. É aqui que a ferramenta fica realmente poderosa.

Cluster multi-nó

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
  - role: worker

kind create cluster --config kind-config.yaml --name meu-cluster

Isso cria um control plane e três workers, cada um em seu próprio contêiner Docker.

Múltiplos control planes (alta disponibilidade)

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: control-plane
  - role: control-plane
  - role: worker
  - role: worker

Nesta configuração, o kind provisiona automaticamente um load balancer HAProxy para distribuir o tráfego entre os control planes.

Escolhendo a versão do Kubernetes

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    image: kindest/node:v1.29.2@sha256:...
  - role: worker
    image: kindest/node:v1.29.2@sha256:...

Cada versão do Kubernetes tem uma image tag correspondente em kindest/node. Você encontra todas as versões disponíveis no repositório oficial do kind.

Port mapping e acesso a serviços

Um ponto frequente de confusão é como acessar aplicações rodando dentro do cluster. Como os nós são contêineres Docker, você precisa fazer port mapping explícito.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30080
        hostPort: 8080
        protocol: TCP
      - containerPort: 30443
        hostPort: 8443
        protocol: TCP

Com isso, um Service do tipo NodePort usando a porta 30080 ficará acessível em localhost:8080 na sua máquina.

Montagem de volumes locais

Para montar diretórios do host dentro dos nós do kind:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraMounts:
      - hostPath: /home/user/dados
        containerPath: /mnt/dados

Isso é útil para persistência de dados durante desenvolvimento, especialmente com PersistentVolumes baseados em hostPath.

Carregando imagens Docker locais

Esta é uma das funcionalidades mais úteis do kind. Em vez de publicar uma imagem em um registry, você a carrega diretamente no cluster:

# Buildar a imagem normalmente
docker build -t minha-app:dev .

# Carregar no cluster kind
kind load docker-image minha-app:dev --name meu-cluster

Depois disso, nos seus manifests Kubernetes, defina imagePullPolicy: Never ou IfNotPresent para garantir que o Kubernetes use a imagem local e não tente fazer pull de um registry.

spec:
  containers:
    - name: minha-app
      image: minha-app:dev
      imagePullPolicy: Never

Configurações de rede

O kind usa o CNI kindnet por padrão, mas você pode desabilitá-lo para instalar outro, como Calico ou Cilium:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true       # Desabilita o kindnet
  podSubnet: "192.168.0.0/16"  # Subnet para os pods
  serviceSubnet: "10.96.0.0/12"
  apiServerAddress: "127.0.0.1"
  apiServerPort: 6443

Depois de criar o cluster sem CNI, você instala o de sua escolha:

# Exemplo com Calico
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Uso em pipelines de CI/CD

O kind é especialmente popular em pipelines de CI porque o ambiente já tem Docker disponível. Exemplo para GitHub Actions:

# .github/workflows/test.yml
name: Testes de integração

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Instalar kind e kubectl
        run: |
          curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64
          chmod +x ./kind && sudo mv ./kind /usr/local/bin/kind
          curl -LO "https://dl.k8s.io/release/$(curl -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
          chmod +x kubectl && sudo mv kubectl /usr/local/bin/

      - name: Criar cluster
        run: kind create cluster --name ci-cluster

      - name: Build e load da imagem
        run: |
          docker build -t minha-app:${{ github.sha }} .
          kind load docker-image minha-app:${{ github.sha }} --name ci-cluster

      - name: Deploy e testes
        run: |
          kubectl apply -f k8s/
          kubectl wait --for=condition=ready pod -l app=minha-app --timeout=120s
          # Rodar testes de integração aqui

      - name: Deletar cluster
        if: always()
        run: kind delete cluster --name ci-cluster

kind vs outras soluções locais

Característica	kind	Minikube	k3d	Docker Desktop K8s
Backend	Docker	VM / Docker	Docker (k3s)	Docker
Multi-nó	Sim	Limitado	Sim	Não
Velocidade de criação	~60s	~2-5min	~30s	~1min
Consumo de recursos	Baixo	Alto (VM)	Muito baixo	Médio
Kubernetes upstream	Sim	Sim	Não (k3s)	Sim
Ideal para CI/CD	Excelente	Ruim	Muito bom	Não recomendado
HA (multi-control-plane)	Sim	Não	Não	Não

O k3d é ligeiramente mais rápido por usar o k3s (Kubernetes simplificado), mas o kind usa Kubernetes puro (upstream), o que o torna mais fiel ao ambiente de produção — decisivo para testes confiáveis.

Comandos úteis de diagnóstico

# Ver logs de um nó específico
kind export logs --name meu-cluster /tmp/kind-logs

# Entrar dentro de um nó (contêiner Docker)
docker exec -it meu-cluster-control-plane bash

# Ver os contêineres Docker do cluster
docker ps --filter "label=io.x-k8s.kind.cluster=meu-cluster"

# Exportar o kubeconfig manualmente
kind get kubeconfig --name meu-cluster > ~/.kube/kind-config

Limitações do kind

O kind não substitui um cluster de produção e tem restrições importantes a considerar:

LoadBalancer não funciona nativamente. Services do tipo LoadBalancer ficam em estado <pending> porque não há cloud provider. A solução é usar o MetalLB ou o cloud-provider-kind (projeto experimental da SIG Cloud Provider), ou simplesmente usar NodePort com port mapping.

Persistent Volumes têm limitações. O armazenamento é baseado em hostPath dentro do contêiner Docker, portanto os dados somem ao deletar o cluster. Para persistência real em dev, use extraMounts ou um CSI driver compatível.

Não roda no Windows sem WSL2. No Windows, o kind exige WSL2 com Docker rodando dentro do subsistema Linux. Docker Desktop resolve isso automaticamente, mas é bom estar ciente.

Performance de I/O. Por ser aninhado (contêiner dentro de Docker), operações de disco intensivas são mais lentas do que em um cluster real.

Casos de uso ideais

O kind brilha em cenários bem definidos. É a escolha certa quando você precisa testar manifestos Kubernetes, Helm charts ou operators sem subir infraestrutura real. Em pipelines de CI, é imbatível pela velocidade e pelo isolamento — cada job cria seu próprio cluster do zero e o destrói ao final. Para aprender Kubernetes, o kind oferece clusters reais com todos os componentes upstream funcionando, sem o custo de cloud.

O que ele não é: um substituto para staging ou produção, nem uma ferramenta de desenvolvimento de aplicações simples onde Docker Compose seria suficiente. Se a sua aplicação não precisa de funcionalidades específicas do Kubernetes, o kind é overhead desnecessário.

Recursos oficiais

Documentação: kind.sigs.k8s.io
Repositório: github.com/kubernetes-sigs/kind
Imagens disponíveis: hub.docker.com/r/kindest/node/tags

Escalabilidade vertical X Escalabilidade horizontal

Kauê Matos — Fri, 03 Apr 2026 21:50:35 +0000

A escalabilidade em sistemas de computação moderna não é meramente uma métrica de desempenho, mas o alicerce sobre o qual a resiliência e a viabilidade comercial de qualquer plataforma digital são construídas. Em um ecossistema global onde o tráfego de usuários pode flutuar de centenas para milhões em intervalos de tempo imprevisíveis, a capacidade de uma infraestrutura de tecnologia da informação para expandir ou contrair seus recursos de forma eficiente define o sucesso ou o fracasso de uma operação. Tradicionalmente, o desafio da escalabilidade era resolvido através de ciclos de planejamento de hardware de longo prazo, muitas vezes resultando em superprovisionamento dispendioso ou subprovisionamento catastrófico. Com a maturidade da computação em nuvem e a introdução de paradigmas como microsserviços e arquiteturas sem estado (stateless), o debate entre escalonamento vertical e horizontal evoluiu de uma escolha binária para uma disciplina complexa de engenharia que exige uma compreensão profunda de latência, consistência de dados e economia de infraestrutura.

A escalabilidade é a capacidade intrínseca de um sistema para gerenciar uma quantidade crescente de trabalho de forma fluida, adicionando recursos conforme a demanda. Este conceito manifesta-se em todos os níveis da pilha tecnológica, desde a potência de processamento bruto e alocação de memória até a capacidade de entrada e saída de bancos de dados e a largura de banda de rede. Quando um sistema é verdadeiramente escalável, ele mantém o desempenho e a experiência do usuário estáveis, independentemente da pressão de carga, evitando gargalos que poderiam levar à instabilidade ou interrupções totais do serviço.

O Paradigma do Escalonamento Vertical: Potencializando o Nó Individual

O escalonamento vertical, tecnicamente referido como scaling up, fundamenta-se na premissa de aumentar a capacidade de computação de um único servidor ou recurso de TI existente. Este processo envolve a atualização de componentes de hardware fundamentais, como a substituição de uma Unidade Central de Processamento (CPU) por uma versão com maior contagem de núcleos e frequência de clock, a expansão da Memória de Acesso Aleatório (RAM) ou a melhoria da velocidade das interfaces de rede e dispositivos de armazenamento, como a transição de unidades de disco rígido tradicionais para SSDs NVMe de alta performance.

Em ambientes virtuais e de nuvem, o escalonamento vertical é frequentemente abstraído como a alteração do tipo de instância ou máquina virtual (VM). Por exemplo, a migração de uma instância t3.medium da Amazon Web Services (AWS) para uma t3.xlarge representa uma operação clássica de escalonamento vertical. A principal vantagem desta abordagem reside na sua simplicidade arquitetural. Como a aplicação continua a residir em um único sistema operacional ou contêiner, não há necessidade de reengenharia complexa para lidar com processamento distribuído ou protocolos de sincronização de rede. Isso torna o escalonamento vertical a escolha preferencial para aplicações legadas, monólitos e sistemas que dependem fortemente de estado local ou sessões mantidas em memória, onde a latência de comunicação entre servidores seria proibitiva.

Entretanto, o escalonamento vertical enfrenta limitações físicas e operacionais significativas. Cada servidor possui um "teto de hardware" — um limite máximo definido pela placa-mãe e pelo chipset quanto à quantidade de RAM e ao número de soquetes de CPU que podem ser instalados. Uma vez atingido este limite, a única forma de continuar escalando verticalmente é através de uma migração completa da carga de trabalho para um novo sistema de camada superior, o que inevitavelmente introduz questões sobre o destino do equipamento antigo e a complexidade da migração de dados. Além disso, o escalonamento vertical cria um ponto único de falha (Single Point of Failure - SPOF). Se o hardware do servidor falhar, todo o sistema fica indisponível. O processo de atualização física ou redimensionamento de instâncias virtuais também requer frequentemente a reinicialização do sistema, resultando em períodos de inatividade que podem não ser toleráveis em ambientes que exigem disponibilidade de 24 horas por dia, 7 dias por semana.

Característica	Detalhamento Técnico do Escalonamento Vertical
Definição Principal	Adição de recursos (CPU, RAM, Armazenamento) a um único nó.
Complexidade de Implementação	Baixa; exige pouca ou nenhuma alteração no código da aplicação.
Risco de Disponibilidade	Alto; representa um ponto único de falha.
Limitações Físicas	Restrito pela capacidade máxima de hardware do servidor.
Tempo de Inatividade	Geralmente necessário para atualizações de hardware ou reinicialização de VM.
Custo Inicial	Frequentemente mais baixo para pequenos incrementos de performance.

O Paradigma do Escalonamento Horizontal: A Força da Distribuição

O escalonamento horizontal, ou scaling out, opera sob uma filosofia radicalmente diferente: em vez de tornar um único servidor mais potente, adicionam-se mais servidores (nós) ao pool de recursos, distribuindo a carga de trabalho de forma lateral. Esta abordagem é o alicerce fundamental para sistemas modernos de hiperescala, como os utilizados por gigantes de tecnologia para gerenciar bilhões de requisições diárias. O escalonamento horizontal remove efetivamente o teto de crescimento da infraestrutura, permitindo uma expansão teoricamente ilimitada em ambientes de nuvem elástica.

A resiliência é um dos maiores trunfos do escalonamento horizontal. Em um cluster de dez servidores, a falha de um nó individual reduz a capacidade total do sistema em apenas 10%, enquanto os nove nós restantes continuam a processar o tráfego sem interrupção para o usuário final. Esta redundância inerente permite atualizações em estilo "rolling update", onde cada servidor é atualizado sequencialmente sem nunca comprometer a disponibilidade global do serviço. Do ponto de vista econômico, o escalonamento horizontal permite o uso de hardware comum de baixo custo (commodity hardware), que pode ser mais rentável do que investir em servidores de ponta extremamente caros, cujos custos de aquisição tendem a crescer exponencialmente em relação aos ganhos de performance.

Contudo, a transição para uma arquitetura escalável horizontalmente exige uma maturidade de design significativa. A aplicação deve ser capaz de operar em um ambiente distribuído, o que significa que o estado da aplicação e as sessões de usuário não podem residir localmente em um único servidor. O gerenciamento de estado deve ser externalizado para sistemas de cache distribuídos, como Redis ou Memcached, ou bancos de dados replicados. Além disso, o escalonamento horizontal introduz complexidade na comunicação entre processos e na consistência de dados. Garantir que todos os nós vejam a mesma versão da verdade em tempo real exige protocolos de consenso e redes de alta velocidade, além de uma infraestrutura robusta de balanceamento de carga para orquestrar o fluxo de tráfego.

Aspecto	Implicações do Escalonamento Horizontal
Metodologia	Adição de novos nós para distribuir a carga de trabalho.
Escalabilidade	Quase ilimitada; permite expansão contínua em nuvem.
Resiliência	Alta; falhas de nós individuais não causam queda total do sistema.
Exigência de Código	Alta; requer aplicações sem estado (stateless) e design distribuído.
Complexidade Operacional	Alta; exige balanceadores de carga e orquestradores como Kubernetes.
Eficiência de Custo	Alta a longo prazo; permite "pagar conforme o uso" e redução em horários ociosos.

Componentes Críticos da Infraestrutura Escalável

Para viabilizar o escalonamento horizontal, a infraestrutura deve incorporar componentes que abstraiam a complexidade da rede e garantam a distribuição equitativa de recursos. O mais fundamental desses componentes é o balanceador de carga (load balancer).

O Papel dos Balanceadores de Carga

O balanceador de carga atua como um gatekeeper inteligente, recebendo todo o tráfego de entrada e roteando-o para o servidor mais adequado dentro do cluster. Sua função vai além do simples redirecionamento; ele monitora continuamente a "saúde" de cada servidor através de verificações (health checks). Se um servidor deixar de responder ou apresentar erros acima de um limite definido, o balanceador de carga o remove automaticamente do pool de tráfego ativo até que ele seja reparado ou substituído.

Os balanceadores de carga modernos operam principalmente em duas camadas:

Camada 4 (Transporte): Baseia-se em informações de protocolo de baixo nível, como endereços IP e portas TCP/UDP. É extremamente eficiente e de baixa latência, pois não precisa descriptografar ou inspecionar o conteúdo da mensagem.
Camada 7 (Aplicação): Opera no nível do protocolo HTTP/HTTPS, permitindo decisões de roteamento baseadas em cookies, headers, URLs ou caminhos específicos (por exemplo, enviar requisições de /api para um cluster de servidores de alto desempenho e /static para um armazenamento de baixo custo).

Além do roteamento, o balanceador de carga desempenha papéis cruciais como a terminação SSL, retirando o fardo pesado de criptografia e descriptografia dos servidores de aplicação, e a persistência de sessão (sticky sessions), garantindo que um usuário permaneça conectado ao mesmo servidor durante sua jornada, se a aplicação assim exigir.

Algoritmos de Distribuição de Tráfego

A escolha do algoritmo de balanceamento impacta diretamente a eficiência do escalonamento horizontal. Algoritmos como o Round Robin distribuem as requisições de forma sequencial, o que é eficaz para servidores de capacidade idêntica. O algoritmo Least Connections é mais dinâmico, enviando o tráfego para o servidor com o menor número de conexões ativas, sendo ideal para aplicações onde o tempo de processamento de cada requisição varia significativamente. Em cenários onde os servidores possuem potências diferentes, o Weighted Round Robin permite atribuir pesos para que máquinas mais potentes recebam uma fatia proporcionalmente maior do tráfego.

A capacidade teórica de um cluster horizontalmente escalado com $n$ nós operando sob um balanceador de carga pode ser aproximada pela fórmula de rendimento total $T$:

$$T = \sum_{i=1}^{n} (C_i \times \eta_i)$$

Onde $C_i$ representa a capacidade bruta do nó $i$ e $\eta_i$ representa a eficiência de utilização, que pode ser afetada pela sobrecarga de coordenação do balanceador e latência de rede. Em arquiteturas otimizadas, $\eta$ tende a 1, permitindo um crescimento linear de performance com a adição de novos nós.

Escalabilidade em Camadas de Persistência: O Desafio dos Dados

Enquanto os servidores de aplicação podem ser facilmente escalados horizontalmente por serem frequentemente sem estado, os bancos de dados representam o desafio mais complexo devido à necessidade de manter a integridade, consistência e persistência dos dados.

Escalabilidade Vertical de Bancos de Dados

O método mais direto para escalar um sistema de gerenciamento de banco de dados (SGBD) é o escalonamento vertical. Aumentar a RAM permite que o banco de dados mantenha uma porção maior do conjunto de dados em cache, reduzindo drasticamente a necessidade de operações lentas de leitura em disco. Processadores mais rápidos aceleram a execução de consultas complexas e junções (joins). No entanto, bancos de dados monolíticos atingem rapidamente o limite de custo-benefício, onde o custo para dobrar a potência do servidor pode ser proibitivo.

Estratégias de Escalonamento Horizontal: Sharding e Replicação

Para superar as limitações de um único nó, as arquiteturas de dados utilizam duas técnicas principais:

Replicação de Leitura (Read Replicas): Envolve a criação de uma cópia mestre do banco de dados para todas as operações de escrita (INSERT, UPDATE, DELETE) e múltiplas cópias secundárias sincronizadas para operações de leitura (SELECT). Esta estratégia é altamente eficaz para aplicações "read-heavy", como redes sociais ou sites de notícias, mas não resolve o gargalo de escrita nem aumenta a capacidade total de armazenamento único, já que cada replica deve conter o conjunto completo de dados.
Fragmentação (Sharding): É o processo de dividir um grande banco de dados em pedaços menores e independentes chamados shards, que são distribuídos por vários servidores. Ao contrário da replicação, o sharding permite distribuir tanto as leituras quanto as escritas e o armazenamento total. A eficácia do sharding depende da escolha da shard key (chave de fragmentação). Uma chave baseada em intervalos (por exemplo, IDs de usuário de 1 a 1.000.000 no Nó A e de 1.000.001 a 2.000.000 no Nó B) é simples, mas pode criar "hotspots" se um intervalo for muito mais ativo que os outros. Já o sharding baseado em hash aplica uma função matemática à chave para distribuir os dados de forma uniforme e pseudo-aleatória, equilibrando a carga, mas dificultando consultas de intervalo.

Técnica de Dados	Objetivo Principal	Limitação Técnica
Vertical Scaling	Aumentar performance bruta de queries individuais.	Limite físico de hardware e custo exponencial.
Replicação	Escalar volume de leitura e alta disponibilidade.	Não escala volume de escrita nem tamanho do dataset.
Sharding	Escalar volume de escrita e capacidade de armazenamento.	Complexidade na gestão de consistência e roteamento.

O Caminho do Meio: Escalonamento Diagonal e Híbrido

O escalonamento diagonal representa uma abordagem pragmática e sofisticada que combina as vantagens do escalonamento vertical e horizontal. Em vez de escolher uma única filosofia, o sistema começa escalando verticalmente um servidor existente até que ele atinja um ponto ideal de eficiência ou um limite de custo predefinido. Quando este patamar é alcançado, a infraestrutura inicia o escalonamento horizontal, adicionando novos nós que também podem ser configurados com alta potência.

Esta estratégia híbrida é particularmente valiosa para empresas em crescimento acelerado. Ela permite adiar a complexidade do gerenciamento de centenas de instâncias pequenas (que podem sofrer com latência de rede entre nós) ao utilizar máquinas robustas que são replicadas apenas quando necessário. A escala diagonal também aborda workloads heterogêneos: uma aplicação pode ter instâncias de aplicação menores e mais numerosas (escala horizontal) enquanto mantém um banco de dados central poderoso e atualizado (escala vertical).

A agilidade da escala diagonal em ambientes modernos de nuvem é potencializada por tecnologias de contêineres e orquestração. O Kubernetes, por exemplo, pode gerenciar o redimensionamento de pods individuais (VPA - Vertical Pod Autoscaler) e o aumento do número de réplicas (HPA - Horizontal Pod Autoscaler) de forma simultânea e coordenada, garantindo que os recursos computacionais sejam otimizados tanto em "altura" quanto em "largura".

Paisagem Tecnológica de 2026: Provedores e Tendências

Em 2026, a distinção entre escalonamento vertical e horizontal tornou-se cada vez mais fluida devido às ofertas de serviços gerenciados e serverless dos grandes provedores de nuvem.

Inovações em AWS, Azure e Google Cloud

Na Amazon Web Services, o foco está na maturidade e na largura do catálogo. O serviço Amazon EC2 Auto Scaling agora suporta políticas de escalonamento preditivo que utilizam aprendizado de máquina para analisar padrões históricos de tráfego e provisionar capacidade antes mesmo que a demanda ocorra. Para bancos de dados, o Amazon Aurora Serverless abstrai completamente a decisão de escala, ajustando a capacidade de computação em tempo real (em unidades de capacidade Aurora - ACUs) sem interrupção das conexões.

A Microsoft Azure consolidou sua liderança em integração corporativa e sistemas SQL inteligentes. O Azure SQL Database Serverless é um marco de eficiência, oferecendo um recurso de "auto-pausa" que suspende o banco de dados durante períodos de inatividade, cobrando apenas pelo armazenamento e retomando automaticamente em milissegundos quando uma nova conexão chega. Esta funcionalidade pode reduzir custos em até 70% para ambientes de desenvolvimento ou cargas de trabalho intermitentes.

O Google Cloud Platform (GCP) diferencia-se pela qualidade de sua rede global e inovações em inteligência artificial. O GCP Managed Instance Groups (MIGs) oferece o escalonamento preditivo mais avançado do mercado, integrado nativamente ao Vertex AI, permitindo que a infraestrutura se adapte a picos de tráfego baseados em eventos globais detectados por sinais de Big Data do próprio ecossistema Google. Além disso, o GCP oferece "Custom Machine Types", permitindo um escalonamento vertical granular onde o engenheiro pode especificar a contagem exata de vCPUs e memória, evitando o desperdício comum nos tamanhos "pré-definidos" de outros provedores.

Provedor	Diferencial Competitivo em Escala (2026)	Recurso Chave
AWS	Maior catálogo de serviços e maturidade de ecossistema.	Amazon EC2 Auto Scaling Groups.
Azure	Melhor integração para licenciamento Microsoft e SQL serverless.	Azure SQL Database Serverless.
GCP	Excelência em rede, Kubernetes (GKE) e IA preditiva.	Managed Instance Groups com ML.

FinOps e a Economia da Escalabilidade

A escalabilidade não é apenas um desafio de engenharia, mas uma disciplina financeira fundamental sob o conceito de FinOps. A capacidade de escalar horizontalmente permite que as empresas transformem despesas de capital fixas (CapEx) em despesas operacionais variáveis (OpEx), pagando apenas pelo que consomem.

Análise de Custo-Benefício: Vertical vs. Horizontal

O escalonamento vertical tem um custo inicial menor e uma complexidade operacional reduzida para pequenos incrementos. No entanto, à medida que a carga aumenta, o custo de instâncias de alto desempenho na nuvem cresce de forma não linear. Por outro lado, o escalonamento horizontal, embora exija um investimento inicial maior em arquitetura e automação, oferece uma eficiência de custos superior em larga escala através do uso de "Spot Instances" (capacidade ociosa da nuvem com descontos de até 90%) e da capacidade de desligar recursos em horários de baixa demanda.

A métrica de Custo por Unidade de Transação ($C_u$) pode ser calculada como:

$$C_u = \frac{C_{fixo} + (C_{variável} \times t)}{T}$$

Onde $T$ é o número total de transações processadas. Em sistemas verticalmente escalados, o $C_{fixo}$ do servidor potente é alto, tornando o $C_u$ elevado para volumes baixos. Em sistemas horizontais elásticos, o $C_{variável}$ se ajusta à carga, tendendo a otimizar o $C_u$ tanto em picos quanto em vales de demanda.

Melhores Práticas para Implementação de Infraestruturas Escaláveis

Para que qualquer estratégia de escalonamento seja bem-sucedida, a arquitetura deve seguir princípios rigorosos que garantam a fluidez do tráfego e a integridade do estado.

Arquitetura Sem Estado (Statelessness)

A regra de ouro para o escalonamento horizontal é que os servidores de aplicação devem ser stateless. Isso significa que nenhuma informação do usuário (como dados de login, carrinho de compras ou estado de workflow) deve ser armazenada localmente no disco ou na memória RAM de um servidor específico. Ao externalizar o estado para um banco de dados de alta velocidade ou cache distribuído, qualquer servidor no cluster pode processar qualquer requisição de qualquer usuário a qualquer momento, facilitando a adição ou remoção de nós sem afetar a experiência do usuário.

Idempotência e Resiliência

Em sistemas distribuídos, falhas de rede são inevitáveis. Portanto, as operações devem ser projetadas para serem idempotentes — ou seja, realizar a mesma ação múltiplas vezes deve produzir o mesmo resultado que realizá-la uma única vez. Isso é crucial quando um balanceador de carga ou um cliente tenta reenviar uma requisição após um timeout. Além disso, o uso de filas de mensagens e padrões de "backpressure" garante que, se o sistema estiver operando próximo à sua capacidade máxima, as novas requisições sejam enfileiradas ou rejeitadas educadamente, em vez de causar um colapso em cascata em toda a infraestrutura.

Monitoramento e Observabilidade

A escalabilidade automatizada depende de sinais precisos. A infraestrutura deve implementar monitoramento de "saúde" profundo, indo além da simples verificação de CPU e RAM para incluir métricas de latência de aplicação, taxas de erro e profundidade de filas. A observabilidade moderna em 2026 exige o uso de pipelines de telemetria inteligente que utilizam IA para distinguir entre ruídos temporários e picos de demanda reais, evitando o fenômeno de "flapping" — onde o sistema escala e desescala recursos freneticamente devido a limites de gatilho mal configurados.

Conclusão: A Evolução da Escalabilidade como Vantagem Competitiva

O debate entre escalonamento vertical e horizontal não é mais sobre qual técnica é superior, mas sobre como orquestrar ambas de forma estratégica para atingir os objetivos de negócio. O escalonamento vertical oferece a simplicidade necessária para validação rápida e sistemas legados, enquanto o escalonamento horizontal fornece a resiliência e a expansão ilimitada exigidas pelo mercado global. A emergência do escalonamento diagonal e das tecnologias serverless e preditivas representa a maturidade final da infraestrutura de TI, onde a capacidade de computação torna-se um recurso fluido, invisível e perfeitamente alinhado à demanda em tempo real.

Para arquitetos e gestores de TI em 2026, o sucesso reside na construção de sistemas que assumam a falha como uma constante e a mudança como a única certeza. Ao projetar aplicações sem estado, implementar governança de custos através de FinOps e alavancar a inteligência preditiva dos provedores de nuvem, as organizações podem garantir que suas plataformas não apenas sobrevivam ao sucesso, mas prosperem nele, transformando a infraestrutura de um centro de custo em um motor dinâmico de inovação e crescimento.

Devin AI O Primeiro Engenheiro de Software com IA

Kauê Matos — Fri, 13 Mar 2026 00:25:00 +0000

O que é

Devin AI é uma inteligência artificial desenvolvida pela empresa Cognition AI (também chamada de Cognition Labs). O software ganhou destaque no mundo corporativo ao ser adotado por grandes empresas como Nubank e Goldman Sachs como um "engenheiro de softwares" virtual, capaz de atuar de forma autônoma na resolução de problemas complexos de programação. TechTudo

Quem criou

A Cognition Labs é uma startup composta por dez membros, incluindo o CEO Scott Wu e o CTO Steven Hao, com financiamento do fundo Founders Fund, de Peter Thiel. Vários dos membros participaram de competições de programação antes de fundar a empresa. O software foi desenvolvido combinando o treinamento de grandes modelos de linguagem com aspectos de aprendizado por reforço. Google Translate
A equipe inclui medalhistas de olimpíadas internacionais de informática e profissionais com experiência em empresas como Google DeepMind, Waymo e Scale AI. Vidu AI

O que ele faz

Devin é capaz de construir e implantar aplicativos de ponta a ponta, desde o código inicial até o deploy final. Ele também tem a capacidade de treinar e ajustar seus próprios modelos de IA, tornando-o independente e adaptável ao ambiente em que é empregado. DIO
Equipado com um ambiente de desenvolvimento que inclui editor de código, shell para testes e navegador para acessar documentação, o Devin pode escrever e testar seu próprio código, além de explorar novas áreas de desenvolvimento de maneira independente. Sua capacidade de trabalhar em tempo real, respondendo a solicitações em linguagem natural, permite que se integre perfeitamente no fluxo de trabalho de uma equipe. Data Hackers

Desempenho e benchmarks

Devin foi avaliado no SWE-bench, um benchmarking desafiador que pede aos agentes que resolvam problemas reais do GitHub encontrados em projetos de código aberto como Django e scikit-learn. O Devin conseguiu resolver corretamente 13,86% dos problemas de ponta a ponta, superando em muito as IAs anteriores que chegaram a apenas 1,96% de resolução. Faberhausplay

Versão 2.0 e preços

Com o lançamento do Devin 2.0, a Cognition AI trouxe uma queda significativa nos preços. O custo passou a ser de apenas US$ 20 por mês, uma redução drástica em comparação com os US$ 500 anteriores. O modelo de cobrança é baseado em "Agent Compute Units" (ACU), onde cada unidade custa US$ 2,25, permitindo que os usuários paguem de acordo com os recursos computacionais realmente utilizados. Data Hackers
Versões posteriores do Devin ganharam capacidade de operação multi-agente, onde um agente de IA delega tarefas a outros agentes de IA, além de avaliação de confiança, pedindo esclarecimentos quando não tem certeza suficiente para executar uma tarefa. Google Translate

Adoção corporativa

O Goldman Sachs anunciou planos de incorporar o Devin à sua operação de tecnologia. Diferente de ferramentas de apoio como o Copilot, o Devin realiza o trabalho completo de um especialista, criando aplicativos do zero, construindo bancos de dados e realizando correções e testes automáticos — tudo sem intervenção humana. O CTO do Goldman, Marco Argenti, afirmou que centenas de Devins seriam inicialmente contratados, podendo chegar a milhares. NeoFeed

Recepção e impacto

O CEO da Perplexity.ai, Aravind Srinivas, elogiou o Devin, afirmando que ele parecia ser "a primeira demonstração de qualquer agente que parece cruzar o limite da capacidade humana." Google Translate A ferramenta gerou tanto entusiasmo quanto debate sobre o futuro dos desenvolvedores humanos no mercado de trabalho.