Hoje (20/10/2025) eu estava tomando meu café da manhã, por volta das 7h, e o Slack parou de funcionar. Pouco depois, o Jira. Em seguida, notei que metade dos serviços de monitoramento que usamos na empresa estavam amarelos ou vermelhos. O que aconteceu? Simples: a AWS caiu. Mais uma vez, uma falha em uma única região de um único provedor levou junto metade da internet que usamos no dia a dia.

Eu trabalho com desenvolvimento de software há mais de 20 anos. Eu vi a bolha da internet estourar, vi a ascensão do PHP e do Ruby on Rails, vi o nascimento dos smartphones e, agora, vejo a consolidação da "nuvem". E olhando para o estado atual das coisas, não consigo deixar de pensar: nós complicamos tudo.

Recentemente, escrevi no meu blog sobre como o mundo da conteinerização, Docker e a própria AWS parecem ter servido mais para complicar a entrega de software do que para simplificá-la. O evento de hoje só reforça essa minha percepção, e é por isso que decidi escrever este texto.

A verdade, na minha opinião, é que 95% das empresas do mundo não precisam de AWS, GCP ou Azure.

Onde foi que nos perdemos? A promessa e a realidade

Vamos voltar no tempo. Quinze anos atrás, como subíamos uma aplicação? Naquela época, não existiam contêineres ou "pods". O processo era, em retrospecto, incrivelmente simples. Você contratava um servidor dedicado (ou uma VPS), acessava via SSH, instalava seu stack (LAMP, geralmente), subia seus arquivos via FTP ou (para os mais avançados) usava um git pull com um script de deploy.

E sabe o que? Funcionava. E funcionava muito bem.

Então, vieram os gigantes. Google, Amazon, Microsoft. Eles tinham problemas de escala que nós, meros mortais, mal podíamos conceber. Eles precisavam gerenciar dezenas de milhares de servidores, e para isso criaram ferramentas internas. A Amazon, com uma visão de negócios notável, decidiu alugar sua infraestrutura ociosa. Nascia a AWS.

A promessa era sedutora: pague apenas pelo que usar. Escalabilidade infinita. Não se preocupe mais com hardware. Parecia o fim de todos os nossos problemas de infraestrutura.

Avançamos para hoje. O que temos? Uma indústria inteira que sofre de um caso crônico de "Complexidade Induzida por Hype". Criamos estruturas tão complexas que profissões inteiras nasceram apenas para gerenciá-las. Temos engenheiros de SRE, especialistas em Kubernetes, arquitetos de nuvem. Tudo isso para... rodar um CRUD?

A grande ironia é que, ao abraçar essa suposta simplicidade de "não se preocupar com hardware", nós trocamos um conjunto de problemas (gerenciar hardware) por outro muito mais complexo e caro (gerenciar a AWS).

A ilusão do custo e o mito da performance

Um dos principais argumentos que sempre vejo é que essas superestruturas são "caras e com performance ruim". E minha experiência prática confirma isso todos os dias.

Vamos falar de custo. A nuvem vende a ideia de OPEX (despesa operacional) em vez de CAPEX (despesa de capital). "Não compre um servidor caro, alugue um pedacinho do nosso." O problema está no "pedacinho".

Quando você contrata uma instância t3.large na AWS, você não está recebendo uma máquina potente. Você está recebendo o direito de usar, por um tempo, uma fração de um processador que, francamente, costuma ser "merda". Você paga caro por "pouca RAM, pouco espaço de disco" e, o pior de tudo, paga por "tempo de máquina ligada".

E o tráfego? A maior armadilha da nuvem não é o processamento; é o  egress (transferência de dados para fora). A AWS cobra valores exorbitantes para você tirar seus próprios dados de lá.

Quando você soma tudo — instâncias, EBS (discos), balanceadores de carga, tráfego de saída, NAT Gateways — a conta no final do mês é assustadora. E você só está pagando mais caro por um poder computacional inferior.

Nunca devíamos ter abandonado o Bare Metal. Vamos comparar. Hoje, é possível alugar um servidor dedicado na Europa ou EUA (em empresas como Hetzner ou OVH) com 128GB de RAM, 2TB de SSD NVMe e um processador de 16 núcleos por menos de 100 dólares por mês.

Agora, tente montar uma configuração remotamente parecida na AWS. Um m5.4xlarge (16 vCPUs, 64GB RAM) custa, no momento em que escrevo, mais de 500 dólares por mês on-demand, e isso sem contar o disco e o tráfego. Estamos falando de um custo 5x a 10x maior para, muitas vezes, metade da performance, já que no "bare metal" você não tem a sobrecarga do hipervisor.

É um fato: servidores dedicados são "centenas de vezes mais potentes e baratos quando comparados ao mesmo poder computacional na AWS". Pode não ser "centenas", mas a diferença é, sim, de uma ordem de grandeza.

A epidemia do "Resume-Driven Development"

Se o "bare metal" é tão mais barato e potente, por que 95% das empresas caíram nesse conto?

A resposta, na minha opinião, é cultural. E se divide em duas partes: o "Cargo Cult" e o "Resume-Driven Development" (RDD).

Cargo Cult: Vemos empresas como o Mercado Livre, que faz "30.000 deploys diários", ou a Shopify, ou os grandes bancos que precisam de suportar dezenas de milhões de acessos simultâneos no 5º dia útil". Essas empresas, sim, são os 5% que talvez precisem dessa escala. Elas precisam de Kubernetes, microserviços e uma infraestrutura global elástica.

O problema é que a startup que tem 100 usuários simultâneos olha para o Mercado Livre e pensa: "Eu preciso fazer o que eles fazem". Não, você não precisa. Provavelmente sua empresa não está nesse recorte. Você está adotando a solução para um problema que você não tem.

Resume-Driven Development (RDD): Aqui entra o fator humano, que tanto discuto neste blog quando falo de cultura de trabalho. O engenheiro júnior ou pleno quer aprender Kubernetes. Por quê? Porque "Kubernetes" fica bonito no currículo. Porque o mercado pede. Então, ele propõe uma "modernização" da infraestrutura. O gestor, que também não quer parecer ultrapassado, aprova.

Seis meses depois, a aplicação que rodava perfeitamente em uma única VM agora está espalhada em 30 microserviços, rodando em um cluster EKS que ninguém entende direito, custando 8x mais e sendo objetivamente mais lento. Mas o time "aprendeu Kubernetes".

Nós, como engenheiros, temos a responsabilidade de questionar isso. Temos que parar de complicar nossos sistemas apenas para adicionar uma buzzword ao nosso LinkedIn.

Docker, Kubernetes e a complexidade como regra

O problema não é só a AWS. É todo esse mundo de conteinerização, docker e na estrutura de conteiners e pods.

Eu adoro o Docker. Como ferramenta de desenvolvimento, ele é fantástico. A capacidade de ter um ambiente de desenvolvimento idêntico ao de produção, de forma isolada, é uma revolução.

O problema é o que fizemos com ele em produção.

Transformamos o Docker, uma ferramenta de empacotamento, no pilar de um sistema de orquestração (Kubernetes) de complexidade absurda. Para subir uma aplicação web simples, o que antes era um git pull, hoje é um manifesto YAML de 100 linhas. Precisamos de deployments, services, ingresses, configmaps, secrets, persistent volumes...

Essa complexidade toda se justifica? Para os 5% como o Mercado Livre, sim. Para os outros 95%, é um tiro no pé.

Aqui no blog eu costumo escrever sobre Inteligência Artificial e dar dicas de programação. E eu vejo o mesmo padrão lá. Vejo pessoas tentando aplicar deep learning para problemas que uma simples regressão linear resolveria. É a mesma doença: a paixão pela ferramenta, e não pelo problema.

O DHH e a 37signals

Quando eu escrevi que todo programador deveria aprender com o DHH (David Heinemeier Hansson), o criador do Ruby on Rails eu falei sério. Ele tem sido uma voz quase isolada contra essa complexidade. Recentemente, a empresa dele, a 37signals (criadora do Basecamp e do HEY), fez o movimento contrário ao do mercado: eles saíram da nuvem.

Eles documentaram publicamente sua jornada de migração da AWS e GCP de volta para servidores dedicados. O resultado? Uma economia projetada de 7 milhões de dólares em cinco anos.

O que eles descobriram? Exatamente o que eu venho dizendo: eles estavam pagando um valor exorbitante por "pouca RAM", "pouco espaço de disco" e "processador merda". Ao comprar o próprio hardware (bare metal), eles conseguiram máquinas dezenas de vezes mais potentes por uma fração do custo de aluguel na nuvem.

Eles não abriram mão dos contêineres, mas simplificaram drasticamente. Eles criaram uma ferramenta chamada "Kamal" que faz deploy de contêineres Docker diretamente em servidores bare metal, via SSH, sem a camada de complexidade do Kubernetes.

Isso é um alinhamento perfeito com a ideia de "retomar a capacidade de entregar software de forma mais simples e sustentável", como disse DHH.

Então a nuvem é inútil?

Agora, sendo uma pessoa sensata que gosta de ver todos os lados, seria injusto dizer que a AWS, GCP e Azure são inúteis. Elas não são. Elas apenas são usadas para os problemas errados.

Onde a nuvem brilha?

  1. Elasticidade Real: Você é um e-commerce e sua Black Friday representa 50% do seu faturamento anual? Você precisa da nuvem. Você precisa da capacidade de escalar de 10 para 1000 servidores em minutos e depois desligar tudo. Os "grandes bancos" no "5º dia útil" são outro exemplo perfeito. Essa é a verdadeira elasticidade, e ela tem um preço.
  2. Serviços Gerenciados (O verdadeiro "lock-in"): O maior valor da AWS não está nas VMs (EC2). Está no S3 (armazenamento de objetos), no RDS (bancos de dados gerenciados), no SQS (filas) e nas funções Lambda (serverless). Gerenciar um cluster de banco de dados replicado, com backup e alta disponibilidade é difícil. Pagar a AWS para fazer isso (RDS) é, muitas vezes, uma decisão de negócios inteligente.
  3. CAPEX Zero (O paradoxo da Startup): Você está começando uma empresa hoje, do zero. Você não tem 10 mil reais para comprar um servidor. A nuvem é perfeita para você. Você sobe uma instância "free tier" e começa a validar sua ideia. O problema não é começar na nuvem. O problema é ficar nela quando você cresce, sem nunca reavaliar se o modelo de custos ainda faz sentido.
  4. Presença Global: Sua aplicação precisa estar em 15 países com baixa latência? Tentar fazer isso com bare metal é um pesadelo logístico. A nuvem resolve isso com alguns cliques.

O problema é que a maioria das empresas (os 95%) não tem nenhum desses problemas. Elas têm uma aplicação monolítica, que atende a um único país, com tráfego previsível, e que rodaria feliz em um ou dois servidores dedicados potentes.

Recuperando o controle

Nós, como indústria, abraçamos uma complexidade que não precisávamos. A queda de hoje da AWS é apenas um sintoma doloroso da nossa dependência de estruturas frágeis e caras.

Estamos pagando mais caro por performance pior, em nome de uma escalabilidade que nunca usamos, gerenciando uma complexidade de contêineres e pods que nos atrasa, tudo porque nos disseram que esse era "o jeito certo".

Como DHH, eu acredito que devemos "retomar a capacidade de entregar software de forma mais simples e sustentável".

Isso não significa voltar a usar FTP. Significa usar as ferramentas modernas de forma inteligente. Use Docker para empacotar. Use um servidor "bare metal" potente e barato. Use um deployer simples. Se você realmente precisar de um banco de dados gerenciado, use o RDS da AWS, mas rode sua aplicação fora dela.

Seja um engenheiro, não um seguidor de tendências. Entenda o "trade-off" de cada escolha.

A minha provocação final é: será que a sua empresa é realmente o Mercado Livre? Ou você está apenas pagando a conta da AWS para que o Jeff Bezos possa construir mais foguetes, enquanto sua aplicação simples poderia estar rodando 10x mais rápida e 10x mais barata em um bom e velho servidor dedicado?

Fica a reflexão.