Mudar da AWS para bare metal economizou US$ 230 mil por ano

Artigo original ↗ Discussão no Hacker News ↗

A alegação de que a migração de um serviço de monitoramento de uptime da AWS para servidores bare metal economizou cerca de US$ 230 mil por ano gerou uma análise mais ampla da economia entre infraestrutura em nuvem e infraestrutura própria. Os comentaristas divergem sobre se essa economia persiste quando se contabilizam esforço de migração, trabalho operacional contínuo e redundância, observando que a configuração anterior na AWS parecia superprovisionada e pouco otimizada. Muitos concluem que cargas de trabalho previsíveis e estáveis podem ser muito mais baratas em colo ou hardware dedicado, enquanto plataformas de nuvem ainda vencem em experimentação rápida, serviços gerenciados e demanda variável ou incerta.

Debate sobre Custos e Economia

  • Muitos concordam que bare metal / colo é inerentemente mais barato do que AWS para cargas de trabalho estáveis; alguns citam que a nuvem muitas vezes custa ~2–2,5× o custo on-prem.
  • Vários argumentam que a economia reportada de US$ 230 mil/ano está inflada porque:
    • Eles estavam em EC2 sob demanda, sem Reserved Instances ou Savings Plans (o que poderia economizar ~35%+).
    • Instâncias Spot e Graviton (m7g) poderiam ter reduzido o custo de computação ainda mais para cargas adequadas.
  • Contra-argumento: mesmo após otimizações razoáveis na AWS, comentaristas ainda esperam economias significativas com bare metal, especialmente em largura de banda e armazenamento.
  • Alguns observam que a economia equivale aproximadamente a 1 engenheiro americano de nível intermediário por ano; fora dos EUA isso poderia financiar vários engenheiros.

Custos Ocultos e Operacionais

  • Céticos enfatizam:
    • O esforço e o risco de migração não estão precificados.
    • Trabalho contínuo com hardware: falhas, planejamento de capacidade, prazos de aquisição, remote hands.
    • Complexidade de armazenamento HA (Ceph/Longhorn), rede (Cilium/eBPF), plano de controle do Kubernetes e setups sérios de banco de dados com backups testados e PITR.
  • Outros respondem que:
    • Estruturas na AWS também exigem especialistas (DevOps/SRE, finops, segurança, trabalho de YAML/IaC, gestão de fornecedores).
    • Para frotas pequenas (1–2 racks), a sobrecarga operacional pode ser modesta, especialmente com colocation e automação (PXE, Harvester, Proxmox, etc.).

Confiabilidade, HA e Arquitetura

  • Crítica forte de que uma configuração de um único rack / único DC é menos confiável do que a multi-AZ da AWS; “monitoramento de uptime em um rack” é visto como irônico.
  • Defensores observam que mantêm um cluster de failover na AWS que podem subir rapidamente, mas outros apontam que DNS, sincronização de dados e exercícios de failover não são triviais.
  • Debate sobre se multi-região/multi-cloud na AWS é “Cloud 101” e se on-prem pode igualar essa resiliência de forma realista.

Cloud vs Bare Metal: Quando Cada Um Faz Sentido

  • Argumentos pró-cloud:
    • Experimentação rápida com serviços gerenciados (Fargate, S3, Aurora, etc.).
    • Evita lidar com hardware físico, instalações, geradores, HVAC.
    • Permite escalonamento rápido e crescimento muito alto sem grande capex inicial.
  • Argumentos pró-bare-metal/colo:
    • Grandes economias em largura de banda e computação previsível.
    • Bom encaixe para batch/ML, cargas de longa duração e produtos maduros e estáveis.
    • Potencialmente melhor desempenho (NVMe direto, sem noisy neighbors) e menos lock-in de fornecedor se serviços específicos da nuvem forem evitados.

Meta e Ceticismo Sobre Este Caso

  • Alguns acham que a pegada original na AWS (K8s de 28 nós para um app de uptime) era obviamente superdimensionada.
  • Outros dizem que o blog é pouco detalhado em pontos-chave (volume de dados, desenho de HA, RTO/RPO, termos de colo), tornando difícil julgar a decisão por completo.
  • Vários observam que a nuvem ainda foi útil para validar o negócio rapidamente; sair dela depois é visto como uma otimização razoável de “fase dois”.