Casos assustadores da tecnologia serverless

Histórias de terror sobre serverless

• Histórias de terror sobre serverless é um blog simples que compartilha experiências terríveis ocorridas ao usar tecnologia serverless.
• Este blog foi criado por Andras, que está desenvolvendo o Coolify, uma alternativa ao Heroku / Netlify / Vercel que é open source e pode ser auto-hospedada.
• Pessoas que tenham histórias de terror com serverless podem enviar seus relatos para Andras ou compartilhar abrindo um PR no Github.

Casos de custos serverless que merecem atenção

• 27 de março de 2020: houve um caso em que alguém gastou 72.000 dólares testando Firebase e Cloud Run e quase foi à falência.
• 27 de fevereiro de 2024: alguém recebeu um e-mail da Netlify no fim de semana dizendo que havia uma fatura vencida de 104.500 dólares.
• 13 de fevereiro de 2024: houve um caso em que alguém enviou spam para a EchoFox, fazendo a fatura da Vercel disparar para 23.000 dólares e gerando mais de 56.000 contas e testes.
• 5 de abril de 2023: há um relato de experiência alertando usuários da Vercel para tomarem cuidado ao testar ou fazer deploy na plataforma.

Opinião do GN⁺

• A arquitetura serverless é atraente para desenvolvedores por causa da infraestrutura sem necessidade de gerenciamento, mas estes casos mostram que custos inesperados podem se tornar um grande problema.
• Esses exemplos reforçam a importância de um controle rigoroso de custos e de monitoramento ao usar serviços serverless.
• Antes de adotar tecnologia serverless, é recomendável usar ferramentas que ofereçam previsão de custos e configuração de limites.
• Mesmo ao usar outros produtos serverless, como o AWS Lambda, problemas semelhantes relacionados a custos podem ocorrer, então é importante escolher serviços considerando a eficiência de custos.
• Os benefícios dessa tecnologia incluem deploy rápido e escalabilidade, mas, se o uso real não puder ser previsto, existe o risco de estourar o orçamento.

[GN⁺]

Opiniões do Hacker News

• Resumo dos comentários sobre a Netlify:

  • Um usuário mencionou que hospedou um arquivo de áudio de 3,44 MB em seu site e, por causa disso, sofreu um ataque DDoS. Apesar de estar usando uma conta gratuita da Netlify, apontou que corria o risco de receber uma cobrança alta por causa dos custos excessivos de tráfego.
  • Outro usuário disse que essa situação é triste, afirmando que um arquivo de 3,44 MB não deveria ser um problema e que a solução de hospedá-lo em outro lugar não é adequada. Também enfatizou que “grátis” não existe de verdade e que são necessárias mais medidas para evitar esse tipo de situação.
  • Foi mencionado que um VPS (Virtual Private Server) é barato, fácil de gerenciar e já vem automaticamente com limitação de tráfego.

• Resumo dos comentários sobre o Coolify:

  • Um usuário mencionou Andres, que desenvolveu o Coolify, uma alternativa self-hosted semelhante ao Heroku/Netlify. Ele disse que vem usando o Coolify há alguns meses e elogiou o fato de a ferramenta tê-lo ajudado a hospedar vários serviços por conta própria.
  • Também comentou que a comunidade do Coolify está crescendo, com usuários adicionando novos templates e ajudando uns aos outros na depuração.
  • Como ponto negativo, apontou que podem ocorrer problemas quando falta espaço em disco, e opinou que seriam necessários alertas melhores ou medidas preventivas para isso.

• Resumo dos comentários sobre arquitetura serverless:

  • Foi argumentado que o problema ocorrido na Netlify não é causado pela arquitetura serverless. Embora existam vários problemas técnicos em arquiteturas serverless, explicou-se que uma cobrança enorme por tráfego é um problema independente de serverless.
  • Também foi mencionado que uma situação parecida pode acontecer mesmo ao colocar hardware próprio em um data center e pagar pelos custos de tráfego, se não houver proteção contra DDoS.
  • Enfatizou-se que o problema principal são os custos excessivos de tráfego e a ausência de mitigação contra DDoS.

• Resumo dos comentários sobre a decisão de sair da Netlify:

  • Um usuário disse que decidiu migrar seu site pessoal da Netlify para outro lugar. Segundo ele, a migração é basicamente uma atualização de DNS, e ele prefere gerar o HTML localmente e depois fazer o upload.
  • Também comentou que é estranho que a maioria das soluções populares não permita definir um limite de gastos.

• Resumo dos comentários sobre cobranças excessivas de fornecedores de nuvem:

  • Foi feita uma comparação dizendo que a cobrança excessiva dos fornecedores de nuvem é parecida com um mecânico de automóveis que fica trocando uma peça defeituosa em loop infinito e depois apresenta uma conta absurda.
  • Como usuário pequeno, ele disse que não consegue ler e entender completamente toda a documentação e que quer um recurso capaz de interromper o serviço ao atingir o limite de gastos.

• Resumo dos comentários sobre a chave de API da OpenAI:

  • Um usuário comentou que, ao cadastrar uma chave de API da OpenAI, o sistema adota por padrão uma cota e desativa a chave quando ela é excedida.
  • Ele disse se surpreender com o fato de mais empresas não adotarem esse modelo, já que seria uma forma de proteger todo mundo contra faturas inesperadas.

• Resumo dos comentários sobre os problemas dos serviços de nuvem:

  • Foi apontado que estamos aceitando que provedores de nuvem cobrem por tráfego entre zonas de disponibilidade (AZs) como forma de mitigar problemas potenciais da própria infraestrutura deles.

• Resumo dos comentários sobre a falta de resposta da Netlify:

  • Foi expressa decepção com o fato de a Netlify cobrar caro por largura de banda sem oferecer aos clientes ferramentas para responder a ataques fora do seu controle.
  • Também houve crítica de que a Netlify não demonstra interesse em resolver o problema, apesar de existirem várias formas de fazê-lo. Como exemplo, foram mencionadas as diversas opções oferecidas pelo CDN da bunny.net.

• Resumo dos comentários sobre a necessidade de definir limites de gastos:

  • Foi apontado que a possibilidade de definir um limite de gastos não é um problema de serverless, mas da nuvem.
  • Também foi mencionado que um pequeno servidor em nuvem pode cair ao sofrer um ataque e que, como na AWS, o ideal é pagar apenas pelo tráfego de saída.