Use um único servidor grande (2022)

• A essência do debate não é monólito vs. microsserviços, mas sim se sistemas distribuídos valem o custo em overhead de desenvolvimento/operação
• Um servidor único moderno tem dezenas a centenas de núcleos, memória na casa dos TB e I/O de dezenas a centenas de Gbps, com folga de desempenho suficiente para suportar a maioria dos serviços web
• Benchmarks reais mostram que um único servidor pode entregar Nginx 500 mil RPS, PostgreSQL 70 mil IOPS, NoSQL 1 milhão de IOPS, codificação 4K a 75 FPS e outros níveis de processamento de alto desempenho
• A nuvem oferece mais conveniência e disponibilidade, mas o prêmio de custo é considerável, então é preciso avaliar a eficiência do investimento
• Apenas quando o padrão de uso é extremamente variável arquiteturas cloud-native e serverless trazem vantagem financeira
• Porém, o prêmio de custo de serverless/micro-VMs é alto e, se a carga de trabalho for contínua/previsível, escalabilidade vertical é mais econômica
• Disponibilidade pode ser resolvida em grande parte com redundância primário/secundário (ou 2×2) e combinações de hardware diferentes, e faz sentido adotar uma estratégia em que apenas CDN e backups sejam distribuídos

---

Visão geral: o valor de “um único servidor grande” em vez de um sistema distribuído

• O ponto central do debate “monolítico vs. microsserviços” é julgar se vale a pena gastar tempo e dinheiro de desenvolvedores para adotar sistemas distribuídos
• O software moderno roda sobre virtualização de servidores e várias camadas de abstração; mesmo “serverless” ou “bare metal” no fim das contas são construídos sobre recursos de servidores físicos
• Os servidores de hoje têm uma eficiência de custo por desempenho muito maior do que normalmente imaginamos
  • Em comparação com o passado, as especificações de servidores evoluíram drasticamente em quantidade de núcleos, largura de banda de memória, pistas PCIe e armazenamento NVMe, e muitos serviços conseguem atingir o QPS desejado sem distribuição

O forte desempenho do hardware de servidor

• Um servidor de exemplo da Microsoft Azure usa 2 CPUs AMD de 3ª geração para servidores, totalizando 128 núcleos e 256 threads
• Um único servidor pode entregar algo em torno de 4 TFLOPs de capacidade computacional, superando supercomputadores do início dos anos 2000
• Com 16 slots de DDR4-3200 por soquete, há escalabilidade para até 8 TB de memória; mesmo em opções de compra mais práticas, 1 TB de RAM já é suportado
• São 128 pistas PCIe Gen4 no total, permitindo conectar até 30 SSDs NVMe e placas de rede de 50 a 100 Gbps para armazenamento e rede de alto desempenho

O que dá para fazer com um único servidor assim (citando benchmarks)

• É possível atingir 400–800 Gbps de transmissão de vídeo, NoSQL com 1 milhão de IOPS, PostgreSQL com 70 mil IOPS e Nginx com 500 mil RPS
• Em tarefas intensivas em CPU, memória e I/O, como compilar o kernel do Linux em 20 segundos ou codificar x264 4K a 75 FPS, o throughput também é alto

Comparação de custos de aluguel e compra de servidores

• OVHCloud: servidor com 128 núcleos / 512 GB de RAM pode ser alugado por cerca de US$ 1.318 por mês
• Hetzner: oferece servidor com 32 núcleos / 128 GB de RAM por €140 por mês, com variação de preço conforme o porte
• AWS m6a.metal: servidor com 96 núcleos físicos / 768 GB de RAM custa US$ 8,29 por hora, cerca de US$ 6.055 por mês, mostrando um grande prêmio de nuvem
• Comprando um servidor similar diretamente da Dell, o custo fica em torno de US$ 40.000, com retorno do investimento frente à nuvem em cerca de 8 meses
• Assumindo a mesma capacidade de processamento em serverless, estima-se um prêmio de custo de 5,5× em relação a instâncias e de 25× em relação a hospedagem barata

Por que sistemas distribuídos ganharam tanto destaque

• No passado (por volta de 2010), as limitações de CPU, memória e armazenamento exigiam combinar vários servidores para serviços de grande porte
• Mais recentemente, com grandes servidores únicos, SSDs NVMe e alta largura de banda de memória, o limite de processamento em um único nó subiu muito, mas VMs e contêineres ainda são projetados com base em recursos de servidores menores

Quando um único servidor grande é suficiente

• A maioria dos serviços web abaixo de 10k QPS cabe tranquilamente em uma única máquina, e serviços simples podem chegar à faixa de milhão de QPS
• Mesmo em streaming de vídeo, é realista manter o control plane em um único servidor, e benchmarks com tabelas de desempenho comuns permitem estimar o tamanho adequado do servidor
• Fora situações especiais, apenas uma configuração com servidor principal e servidor de backup já é suficiente para garantir disponibilidade

“Mais alto” em vez de “mais largo”: preferir poucos servidores grandes a muitos pequenos

• Mesmo quando um cluster é necessário, alguns servidores grandes têm menos overhead de coordenação (O(n)) do que muitos servidores pequenos
  • Ou seja, no longo prazo, costuma ser mais eficiente reduzir o número de servidores e aumentar suas especificações
• Em modelos baseados em serverless e contêineres efêmeros, a proporção de overhead fica ainda maior
• A desvantagem é o ponto único de falha, mas isso pode ser bastante mitigado com uma configuração primário/secundário (em DCs diferentes)
• Para mais robustez, uma configuração 2×2 (2 servidores no DC principal + 2 no DC secundário) e lotes diferentes de hardware/fabricantes distintos ajudam a evitar falhas correlacionadas
• Em locação, diversificar os modelos de servidor reduz o risco de falhas em cascata em discos ou SSDs do mesmo lote

Vantagens e limites do uso de nuvem

• A nuvem se destaca em disponibilidade, velocidade de recuperação e conveniência operacional, e há valor em pagar esse custo premium
  • É possível religar rapidamente sem indisponibilidade dentro do orçamento e aproveitar grandes pools de recursos gerenciados como uma grade
  • Provedores de servidores alugados têm preços menores, mas podem ficar atrás em qualidade, rede e suporte premium
• Ainda assim, a venda de nuvem costuma incentivar VMs com autoscaling, serverless e bancos HA gerenciados, ou seja, arquiteturas dependentes do fornecedor, então é preciso tomar cuidado com custos e complexidade
• Lidar com tráfego em larga escala por si só não é o principal motivo para optar por cloud-native, e há muitos casos em que um único servidor grande consegue atender milhões de usuários simultâneos

Custo de pico e critério para cargas em burst

• Alguém sempre precisa provisionar capacidade para o pico, então no fim o custo do pico será cobrado em algum ponto da cadeia de suprimentos
• Para tarefas temporárias e em burst (ex.: uma grande simulação pontual), serverless/autoscaling é econômico, mas para cargas contínuas e previsíveis, manter um servidor grande fixo é mais eficiente em custo
• Com compromissos anuais, instâncias spot e negociação comercial, o custo das instâncias pode cair ainda mais, ampliando o prêmio em relação ao serverless

Avaliação quantitativa do “prêmio de nuvem”

• Computação serverless, como o AWS Lambda, pode ter um prêmio de custo de 5 a 30 vezes em comparação com um servidor equivalente
• Exemplo: se um servidor de US$ 8,2944/hora entrega 1k QPS e 768 GB de RAM, substituir a mesma capacidade por Lambda custaria cerca de US$ 46/hora, um prêmio de 5,5×
• Em comparação com aluguel na OVH, estima-se um prêmio de 25×, e com apenas 5% de utilização, hospedagem barata já pode ser mais econômica que serverless
  • Com contratos de longo prazo e instâncias spot, essa diferença de prêmio pode aumentar ainda mais
• Mesmo que o QPS varie, ao converter por memória-tempo, o múltiplo de prêmio tende a ser parecido; o essencial é escalar o servidor de acordo com o tamanho da carga de trabalho

Objeções e mal-entendidos comuns

• “Na nuvem não é preciso equipe de operações”: na prática, só mudou o nome da função para Cloud Ops; ainda são necessárias habilidades de documentação, rastreamento de mudanças e resposta a deprecações, o que pode até aumentar o custo de pessoal
• “Na nuvem não precisa aplicar atualizações de segurança”: parte disso é terceirizada, mas só em áreas fáceis de automatizar; auditoria de bibliotecas e verificação de configuração continuam necessárias
• “A nuvem dá tranquilidade por ter alta disponibilidade”: o aumento da complexidade cria novas vulnerabilidades, e até redundância entre regiões ou provedores não elimina completamente falhas correlacionadas
• “Na nuvem o desenvolvimento é mais rápido”: a agilidade inicial é uma vantagem real, então vale usar, mas é preciso monitorar o ponto de inflexão de custo para fazer a migração na hora certa
• “Nosso tráfego é muito bursty”: nesse caso, serverless e autoscaling fazem sentido
• “E a CDN?”: redução de latência e de banda é um caso claro de distribuição que vale a pena comprar, e backups entram na mesma categoria

Monolítico vs. microsserviços e a estrutura do servidor

• Um “servidor grande” se associa naturalmente a uma arquitetura monolítica, mas também é possível montar microsserviços em vários contêineres dentro de uma única máquina
  • Porém, o overhead de comunicação entre processos, deploy e observabilidade continua pesando mesmo em um único host, reduzindo bastante o ganho prático de desempenho diante da complexidade adicional
• Em fase inicial ou em escala pequena e média, monólitos ou poucos serviços tendem a ser melhores em termos de simplicidade operacional

Conclusão

• Na maioria dos casos, escolher escalabilidade vertical (um único servidor grande) é mais simples e econômico do que apostar em escalabilidade horizontal ou em uma arquitetura centrada em nuvem
• Combinando redundância primário/secundário, hardware heterogêneo e terceirização de CDN/backups, é possível obter confiabilidade prática e vantagem em custo total de propriedade (TCO) em ambientes de carga contínua
• Desde que haja uma estratégia sólida de redundância de hardware, a abordagem de “um único servidor grande” pode ser uma escolha muito adequada para serviços reais

[GN⁺]

Comentários no Hacker News

• Um dos maiores problemas do "imposto da nuvem" é que ele acaba limitando artificialmente o leque de soluções que os engenheiros podem considerar. Por exemplo, pagando algo como US$ 200/mês na AWS você consegue um servidor com 4 vCPU e 16 GB de RAM, o que equivale mais ou menos a um notebook de desenvolvimento de 5 anos atrás. Já na Hetzner, pelo mesmo valor, dá para alugar um servidor com 48 cores e 128 GB de RAM. A diferença de capacidade de processamento é absurda. Métodos que funcionam muito bem quando você tem 10x mais capacidade simplesmente deixam de fazer sentido em nós pequenos. Às vezes isso também economiza tempo de engenharia que seria gasto construindo sistemas mais complexos. Claro, há outras considerações como durabilidade, mas por outro lado um servidor dedicado garante desempenho consistente sem preocupação com noisy neighbors
  • Em 2025, já dá para usar serviços como fly.io para casos gerais sem abrir mão de conveniência nem passar por processos complicados, e para certos frameworks existem opções como a Vercel, que são boas por serem especializadas em stacks específicas. Se precisar de mais que isso, dá para alugar máquinas realmente monstruosas por pouco em OVH/Hetzner/Latitude. Se for só para manter um blog, há VPSs de sobra. A nuvem tradicional hoje praticamente só serve para exigências regulatórias, processos internos ou ineficiência. Na minha visão, tanto a produtividade de desenvolvimento quanto o custo por máquina são zero. A menos que um time realmente sem restrições goste de sistemas de aprovação estilo DMV, nós Intel barulhentos, margens caras e suporte ruim, isso quase nunca faz sentido
  • Isso vai além disso — com servidores bare metal você não precisa se preocupar com latência de rede, latência/contenda de banda de memória de VM, estruturas de cache separadas etc.; por exemplo, basta dar muita RAM ao Postgres e usar só o cache de disco do Linux. Fica muito mais simples e rápido
  • Eu não entendo por que serviços pequenos precisam ir direto para AWS. Não sou tão extremo quanto você, mas um cliente usava uma combinação de app web pequeno em PHP + servidor AWS/SQS/S3 por US$ 100/mês. Reescrevi isso em Python/Django/PostgreSQL (SQLite no começo) e migrei para uma VPS de US$ 25/mês. OCR de PDFs, atualização de preços, busca de produtos faltando, atendimento do site, tudo roda bem com 4 cores e 6 GB de RAM. É um app interno que nunca vai passar muito de 100 usuários, então mesmo que cresça um dia, migrar vai ser muito fácil. No estágio atual, não há motivo para usar um servidor AWS de US$ 100 antes de escalar de verdade
  • Concordo totalmente. Usando um banco embarcado como sqlite e otimizando gravações em lote, dá para ir muito longe até na Hetzner. O argumento de "reservar capacidade demais e desperdiçar" não faz sentido fora da AWS, porque o custo-benefício é incomparável. Na verdade, quanto mais complexo o sistema, mais comum ele ser menos confiável e resiliente do que um nó único. Quase nunca só uma coisa falha de forma isolada
  • Eu penso o contrário. Gosto muito da Hetzner para sites pequenos, mas em projetos grandes a nuvem parece praticamente sem restrições. Se o projeto vale o meu tempo, tanto faz o custo de hospedagem ser US$ 200 ou US$ 2000. Também não vejo grande diferença no tempo de desenvolvimento entre AWS CDK/Terraform + GitHub Actions e Docker/K8s/Ansible + pipeline de CI. Nunca senti que a abordagem bare metal economizasse muito mais tempo de engenharia. IaC com Fargate + RDS também é conveniente. Se você realmente precisa separar, escalar e garantir durabilidade de armazenamento de arquivos, ou integrar vários serviços dedicados de infraestrutura como criação dinâmica de subdomínios, aí o esforço de aprender e integrar soluções novas pode ser ainda maior. Na verdade eu já fazia isso antes da era da nuvem, e se o projeto gera receita, vejo o custo da nuvem como um investimento que vale a pena. Se o custo pesa demais, então provavelmente é mais hobby do que negócio. Gerenciar RAID ou vários sistemas de arquivos em cluster não é algo com que eu queira lidar com os recursos de uma startup/empresa comum ou com o meu tempo. Para mim isso parece a diferença entre quem gosta de mexer em Arch + Emacs e quem está satisfeito com um MacBook. Se alguém quiser trocar o scheduler do kernel, eu diria para usar Arch; senão, recomendo um MacBook. Dito isso, quando o orçamento é realmente apertado e raw throughput importa, já vi servidor dedicado ser a escolha perfeita e economizar milhares de dólares. Se tivesse dado certo, provavelmente teríamos feito scale vertical depois; mas esse é um caso raro
• O HN (Hacker News) roda com 2 servidores: um de produção e um de backup. É um padrão útil porque permite failover imediato em caso de problema de hardware ou necessidade de upgrade. Só é preciso tomar cuidado para que os dois não sejam clones idênticos, senão podem falhar ao mesmo tempo
  • Não era tão crítico quanto SSD, mas houve também um erro curioso em CPUs AMD. Depois de cerca de 1044 dias, um determinado core simplesmente parava de vez. Caso de travamento de CPU AMD EPYC Rome
  • Fico curioso se existe alguma estatística sobre downtime do HN (Hacker News). Nos últimos 10 anos eu só lembro de ele ter caído uma ou duas vezes; na prática parece ter mais de 99,99% de uptime
• Uso há mais de 10 anos um modelo híbrido de colocation + nuvem pública, e a partir de certo porte isso sempre foi o melhor em custo-benefício. A eficiência do hardware também continua melhorando. Você precisa de um administrador de rede/infraestrutura, mas hoje em dia isso é muito fácil de gerenciar, e na prática você também precisa de um administrador de "nuvem", então quase não há economia de pessoal. Há várias opções de colocation, e os fornecedores vendem banda agregada. Já rodei 8 clusters Dell VRTX, SAN e mais de 500 VMs, de grandes instâncias de msSQL até kube; se isso estivesse em nuvem pública, mesmo com desconto de reserva, a fatura passaria de seis dígitos. Já o custo de colo era US$ 2.400/mês, principalmente por energia. E a lentidão significativa dos nós de nuvem pública sempre me surpreende, mesmo sendo a mesma geração de CPU/vCPU. É claro que você precisa entender bem ofertas de equipamento, atualizações, licenças e contratos de suporte, mas isso é administrável na vida real. E hoje também é fácil conectar nuvem e rede: basta receber uma fibra e ligar na VPC
  • Entendo colocation como comprar meu próprio hardware e alugar apenas energia/rack/link no datacenter; queria saber se é isso mesmo. Também queria entender que vantagens isso tem em relação a alugar um servidor bare metal comum
• Venho discutindo esse tema com amigos há anos. A maior desvantagem da infraestrutura local é que você precisa de pessoal especializado para operá-la direito. O texto foca na faixa superior, mas no mercado de baixo porte, se você já tiver algum equipamento, dá para atingir o ponto de equilíbrio em um ano com um rack pequeno ou alguma rede. Considerando o prêmio atual da nuvem, parece que mesmo contratando um administrador a infraestrutura local ainda sairia mais barata
• Em uma empresa que ajudei a fundar, construíamos um motor de automação enterprise, e o time queria lançar a solução como SaaS para maximizar receita. Na prática, um esquema de banco multi-tenant + VPS já bastaria, mas o time ficou obcecado em aprender kubernetes e uma stack cloud native, dedicando um ano inteiro à automação de ambiente de desenvolvimento e operação. No fim, a empresa quebrou pouco tempo depois
  • Mas os engenheiros pelo menos ganharam experiência com k8s no currículo e conseguiram buscar novos empregos com isso
  • Eu também tive uma experiência parecida — perdi tempo demais tentando resolver antecipadamente problemas que talvez só aparecessem 5 anos depois. A maioria dos projetos e startups em estágio inicial funciona bem só com PaaS ou algo como nginx + containers Docker. Quando surgir dor de verdade, aí você pensa nisso
  • Por isso eu gosto de PaaS até a conta começar a doer de verdade. Pago heroku/render/fly e foco em PMF (Product-Market Fit). Ou então existe a rota de torrar dinheiro de VC investindo em K8s como hobby de servidor e depois trocar de emprego de novo
• Muitos negócios nem são tão importantes assim. Muita gente se estressa com a possibilidade de interrupção operacional, mas na prática os serviços com que lidam não são tão críticos. Mesmo que o ambiente de produção suma no meio do dia, vai ser incômodo, mas o mundo não acaba. Empresas assim antes atendiam tranquilamente 250 pessoas com um simples servidor de escritório, e agora migram para a nuvem só para explodir o orçamento. A nuvem é excelente para tarefas específicas; no resto, muitas vezes é mais marketing exagerado. Mas muitos engenheiros ficam obcecados com "escalabilidade perfeita" e acabam buscando só a arquitetura ideal, em vez de uma solução boa o bastante
  • Um colega com quem trabalhei dizia sempre algo assim: "pelo menos ninguém vai morrer se a gente errar, então não precisa se desesperar". Ele já tinha trabalhado com coisas muito mais críticas, e essa mentalidade ajudava bastante em situações difíceis
• Quando você cria uma estrutura complexa para buscar 100% de uptime, acaba cometendo mais erros que reduzem a confiabilidade. A maioria dos negócios consegue tolerar, na prática, uma ou duas horas de indisponibilidade ocasional ou até alguma perda de dados. Se essa expectativa for alinhada antes, dá para fazer engenharia com estruturas muito mais simples e confiáveis
  • E o custo é bem menor. O problema é que esse tipo de expectativa costuma ser mais difícil de aceitar para executivos não técnicos, especialmente quando há perda de dados. O engenheiro diz que só administra o ambiente, mas na prática é difícil se blindar, e quando algo dá errado você pode parecer incompetente
• Artigo bem bom. Ao escalar dessa forma (fora da nuvem), também vale pensar em adicionar um CDN. Com CDN você ganha também WAF e failover de DNS. A única parte menos atraente da abordagem fora da nuvem é ter de operar o próprio banco de dados. Por isso vale considerar fornecedores que ofereçam banco em nuvem como opção, ou, em uma arquitetura ativo/passivo, operar o nó passivo de forma mais barata com VM em nuvem + autoscaling. Hoje alugar servidor está realmente barato: VPS de 4 GB por cerca de US$ 6, e bare metal quad-core com 32 GB por volta de US$ 90. Sites de comparação de preço como serversearcher.com ajudam bastante
  • Subi Postgres em um container Docker e apenas rodei backups periódicos; nunca tive problema. A operação também é simples, então não vejo muito inconveniente
  • Em máquina única, sqlite pode entregar desempenho bem superior e administração muito mais fácil do que Postgres/MySQL
• Eu também rodo meus serviços em VPS. Abandonei a nuvem já faz tempo. Quando meus projetos começarem a dar dinheiro, pretendo comprar equipamento e colocar em colo. A nuvem parecia um app de namoro: a diversão acabou, e agora quero fazer algo realmente produtivo
  • O próprio colo também está cheio de problemas. É muito comum hardware morrer por causa de queda de energia em datacenter. Paradoxalmente, a energia da minha casa é mais estável. A menos que alguns minutos de downtime afetem milhões em receita, para a maioria das coisas não há problema nenhum em rodar servidor no porão. Muita gente superestima absurdamente a necessidade de 99,999% de uptime ou de banda enorme. E colo também não é tão barato quanto parece. A eletricidade em datacenter muitas vezes é mais cara do que tarifas residenciais ou comerciais normais. O que fica realmente barato é internet/fibra, e hoje em muitos países já dá para ter 5~10 Gbit empresariais por 100 euros; antigamente cobravam mais de 2 mil euros até por 1 Gbit
• Independentemente da análise de custo ou capacidade, é difícil ir contra a tendência da indústria. Existe uma vantagem real em "não precisar pensar em hardware". Além disso, há uma mentalidade forte de que capex (despesa de capital) deve ser evitado a qualquer custo, porque hardware de servidor exige investimento inicial alto. E quando uma região da AWS cai, isso não parece "culpa nossa", mas quando um servidor interno falha, parece que é
  • Essa aversão extrema a capex é quase toda efeito da estrutura de investimento de VC — quando os investidores exigem só crescimento acelerado, fica logicamente impossível justificar investimento antecipado como compra de servidores. Já um negócio estável consegue absorver tranquilamente um capex pequeno todo ano
  • Não é obrigatório comprar hardware de servidor — alugar de empresas como a Hetzner já resolve bem. Eu gostaria de ouvir melhor o que exatamente significa essa vantagem de "não precisar se preocupar com hardware"
  • Essa mentalidade de evitar capex realmente existe. Qualquer pessoa que saiba usar uma calculadora percebe que hoje o custo do servidor em si é quase irrelevante para o negócio. O que de fato custa caro é o "espaço" ao redor do servidor; por isso, na maioria dos casos, você aluga o espaço (rack/energia), não o servidor
  • No fim das contas, o que as empresas realmente pagam é pela "abstração da responsabilidade". Executivos de grandes empresas ficam tranquilos quando escolhem soluções de gigantes como Microsoft ou AWS
  • Se você aluga um servidor bare metal, não precisa se preocupar com capex nem com manutenção