Em 2023, a glória estava a apenas 11 MB/s de distância

A verdade sobre os custos da nuvem

• Existe a percepção de que os serviços de nuvem são baratos, mas na prática os usuários podem acabar pagando custos excessivos.
• A AWS gera a maior parte dos lucros da Amazon, o que pode indicar que os serviços de nuvem são, na realidade, caros.

Cálculo a partir dos primeiros princípios

• Se você quisesse criar um dos 1.000 principais sites da web, como o businessinsider.com, precisaria de 200M de visitantes por mês e 400M de visualizações de página.
• Apenas os documentos HTML exigiriam 30 TB de largura de banda por mês, mas isso equivale a apenas 11 MB/s, um patamar muito baixo para o hardware moderno.

Entendendo a latência

• Considerando a velocidade da luz, uma viagem de ida e volta até o lado oposto da Terra exigiria cerca de 200 ms, mas na prática leva aproximadamente 300 ms.
• Se você usar um CDN para entregar JS, CSS e mídia, reduzir 300 ms no tempo de processamento do servidor pode ter o mesmo efeito que colocar o servidor ao lado do usuário.

Limites da tecnologia de edge

• A tecnologia de edge não resolve o problema do banco de dados, apesar dos avanços da segunda geração de tecnologias serverless.
• A maioria das páginas complexas exige consultas ao banco de dados, o que pode aumentar a latência.

Considerações sobre custo

• O Hetzner.com oferece custos de servidor e largura de banda muito mais baixos quando comparado ao AWS EC2.
• Os fornecedores de nuvem oferecem muita coisa de graça no início, mas os custos aumentam bastante quando há escala.

A realidade prática

• A menos que seja um caso de uso específico, a maioria dos sites ou SaaS pode rodar em um único servidor, o que é mais barato e mais simples de manter.
• É possível usar SQLite localmente, armazenar em cache CSS, JS e imagens via CDN, e melhorar o desempenho com renderização no servidor.
• Mesmo sem Docker complexo ou virtualização, ainda é possível escalar o suficiente, com gestão mais fácil e custo menor.

Opinião do GN⁺

• Este artigo desafia a crença generalizada na eficiência de custo dos serviços de nuvem e aponta que os usuários podem estar pagando mais do que realmente precisam.
• Ao comparar a estrutura de custos dos serviços de nuvem, ele mostra que a hospedagem tradicional em servidor único ainda pode ser uma alternativa válida.
• Destaca que tecnologias como serverless, Docker e escalabilidade horizontal não são necessárias em todas as situações e que, às vezes, uma abordagem mais simples pode trazer melhor desempenho e redução de custos.
• Enfatiza a importância da otimização do banco de dados e da implantação regional, sugerindo que isso pode alcançar desempenho igual ou melhor do que o oferecido pelos serviços de nuvem.
• Entre os pontos a considerar na escolha tecnológica estão avaliar o tráfego real e os requisitos de desempenho e, considerando a relação custo-benefício, optar por hospedagem tradicional em vez de nuvem.

[GN⁺]

Opinião do Hacker News

• Experiência no negócio de hospedagem

  • No passado, o negócio de hospedagem oferecia sistemas complexos de acordo com as exigências dos clientes.
  • Foi desenvolvida uma plataforma de hospedagem em nuvem baseada em API para competir com a AWS, mas a receita atingiu o pico em 2012.
  • Os clientes queriam soluções mais complexas baseadas na AWS e não confiavam em servidores simples.
  • A empresa era operada no modelo bootstrap e não entendia a necessidade de assumir o risco de custos da AWS.
  • A AWS é preferida por causa da “esperteza” profundamente enraizada na geração de desenvolvedores de software.

• Erros na análise de tráfego

  • O tráfego não é distribuído de forma uniforme, e a necessidade de largura de banda nos horários de pico é muito maior do que a média.
  • Em serviços reais, a configuração de conexões TCP e TLS exige várias idas e voltas, e o tempo de resposta para a experiência do usuário é importante.

• Erros de servidor e tráfego

  • 500 Internal Server Error indica que o servidor está lidando com mais tráfego do que o esperado.

• Abordagem para escalar serviços

  • É desejável evitar escalabilidade desnecessária e construir apenas quando for preciso.
  • Quando surgirem problemas de desempenho, é melhor reagir naquele momento.

• Vantagens da AWS

  • Usar a AWS oferece uma margem para justificativas em caso de indisponibilidade do serviço.

• Discussão sobre arquitetura de nuvem

  • Não se trata de um debate sobre a necessidade da arquitetura de nuvem, mas de um meio para apresentar alternativas.
  • Problemas de disponibilidade em caso de queda do servidor podem ser resolvidos de outras maneiras.

• SQLite e escalabilidade vertical

  • Em vez de SQLite, pode-se usar Postgres auto-hospedado, embora isso exija mais esforço de configuração.
  • É possível uma arquitetura que mantenha todo o estado global na memória e grave snapshots em disco.

• Combinação de API e banco de dados SQLite

  • O SQLite pode processar muitas consultas em uma única thread.
  • Do lado da API, é possível usar cache em memória e, para páginas estáticas, pular o banco de dados para melhorar o desempenho.

• Problemas de disponibilidade de um único servidor

  • Operar um serviço em um único servidor pode causar downtime não planejado.
  • É preciso considerar o tempo de recuperação dos dados e a quantidade de perda de dados.

• Migração para a nuvem e disponibilidade

  • A migração para a nuvem muitas vezes parece pressão dos colegas.
  • Em termos de disponibilidade, um único servidor pode ser arriscado, e é melhor usar uma combinação inteligente de CDN e nuvem.