Não se deixe enganar pelo serverless

• Texto de DHH, criador do RoR
• Fãs da nuvem dizem que tudo — custo, desempenho, complexidade etc. — se resolve magicamente ao migrar para "serverless"
• Cloud/VPS funciona segundo o princípio de comprar em grande volume e revender em unidades menores
  • Compra-se um servidor grande por $1000 e ele é alugado para 7 pessoas por $200 cada, gerando $400 de lucro por mês
  • Isso funciona bem se essas 7 pessoas não colocarem muita carga no servidor ou se o usarem em horários diferentes
  • Se você precisar da capacidade total do servidor, estará usando um computador de $1000 por $1400
  • Se fizer um contrato de 1 ano, pode até conseguir desconto para $1250 por mês (basicamente, um contrato de crédito com juros anuais de 25%)
• Serverless é parecido, mas permite fatiar o servidor de forma muito mais fina
  • Em vez de oferecer um servidor grande para 7 pessoas por $200 por mês, ele é oferecido por $20 por mês a 100 clientes que executam funções
  • Agora, em vez de $400 de lucro por mês, o ganho passa a ser de $1000
  • Não é surpresa que os provedores de nuvem gostem de serverless
• É bom se você só precisa de algumas funções executadas ocasionalmente (pelo menos no curto prazo)
• Mas é terrível se o seu nível de uso exige aproveitar toda a capacidade de um computador
• Porque você paga mais pelo mesmo clock e ainda fica muito mais preso ao fornecedor
• Quanto mais você usar serviços "cloud native" no serverless, mais difícil será sair depois

• "Não se deixe enganar pelo serverless. Não existe nenhuma mágica que mude o fato de que, se você precisa de todos os ciclos de computação de um computador, então precisa comprar esse computador. Se você começar com uma configuração proprietária de serverless, vai descobrir que não consegue escapar do lock-in."

• "A nuvem é para empresas com grandes variações de uso, como a Amazon, que tem demanda enorme na Black Friday/no Natal e muita capacidade ociosa no resto do ano,
  ou para empresas que ainda não são um negócio grande o bastante para justificar possuir computadores inteiros, ou startups em estágio inicial cujo gasto com nuvem é tão pequeno que isso não faz diferença. Serverless não muda isso."

[secret3056]

Também existe a diferença entre um serviço com burst time e um sem. No caso de apps de delivery, claramente há horários de pico, então uma nuvem que só faz scale-out nesses momentos é atraente. Mas, no lado de IoT, em que 99% do tráfego é fixo, pode ser melhor operar servidores físicos.

[ehlegeth]

Parece que, além da utilidade real de serverless, há também um aspecto em que isso está sendo hypeado demais, então acho que traz um ponto de vista que vale a pena considerar.

• Mesmo quando são necessários recursos equivalentes a mais de um computador, a solução serverless ainda oferece vantagens?
• O lock-in do serverless

Se refletir e decidir sobre esses dois pontos, acho que é difícil errar feio.

Pessoalmente, tenho curiosidade sobre se serverless é a abstração correta, mas acho que o tempo vai provar isso; já o problema de lock-in do serverless vai continuar sendo uma dor de cabeça, e penso que é uma questão que a indústria como um todo precisará resolver, embora não seja algo fácil de solucionar com sucesso.

[kyc1682]

Mesmo sem dinheiro, para startups que têm ainda menos gente e tempo, acho que serverless é uma opção extremamente atraente.

[gcback]

No fim das contas, como é uma área em que é possível fazer escolhas racionais com base em oferta e demanda, não me parece que seja uma questão de ser enganado ou enganar alguém.

No mercado, sempre haverá empresas e pessoas que precisam adequadamente de cloud, on-premise e serverless, dependendo do porte da empresa, do tipo de negócio e do tipo de serviço.
Se faz mais sentido usar um servidor por US$ 200 ou usar funções por US$ 20 é, no fim, algo que o CEO/CTO de cada empresa pode analisar e decidir de forma racional. Se o custo e o prazo apertam no momento, US$ 20 pode ser melhor; se houver mais folga, opções de US$ 200 ou US$ 1.000 podem ser a decisão mais racional. Pelo contrário, do ponto de vista de quem demanda, ter mais opções para diferentes situações não torna isso algo melhor? Além disso, não é uma tecnologia monopolista, e como é um mercado em que as grandes empresas competem ferozmente, os preços tendem a continuar caindo.

[iolothebard]

Parece que o limite é AWS Fargate ou GCP Cloud Run sem um engenheiro de infraestrutura dedicado (DevOps, SRE, platform engineer ou algo do tipo). container as a service.
Claro, mesmo isso também tem seus prós e contras...

[xguru]

Relacionado a isso, há também um texto criticando a AWS por cobrar tão caro pelo Lambda e, ainda assim, não melhorar o runtime de fato.
https://www.lastweekinaws.com/blog/aws-is-asleep-at-the-lambda-wheel/

• Dizem que, no re:Invent de 2020, o número de usuários do Lambda já tinha passado de 1 milhão..
• O Python 3.10 saiu em outubro de 2021 e, embora o 3.11.2 já exista hoje, o runtime do Lambda ainda usa 3.9. Até o Ubuntu LTS usa 3.10. A AWS está "trabalhando nisso" há mais de 1 ano
• O runtime de Go é tão antigo que não oferece suporte ao Graviton, e com o Ruby acontece algo parecido: o suporte é fraco

[ehlegeth]

Concordo.

Olhando para o ciclo de upgrade de plataforma do Lambda e de outros serviços da AWS, não dá a impressão de serem ágeis; passa muito mais a sensação de que agem de forma bastante conservadora ou de que não investem muitos recursos nisso. Como a adição de novas versões da plataforma provavelmente exige muitos testes e também aumenta bastante o custo de suporte, imagino que seja porque priorizam a estabilidade e mantêm o número de versões da plataforma dentro de um certo limite... mas isso é só uma suposição.

[xguru]

Como sempre, o DHH é alguém que costuma falar de forma um pouco forte. Leve isso em consideração ao ler, rs.