Serviços cobrados por uso precisam de hard caps de gasto por padrão

A tese: limites rígidos de gasto como padrão

Simon Willison defende que serviços cobrados por uso e APIs devem oferecer, por padrão, hard budget caps - limites rígidos de gasto que, ao serem atingidos, cortam o serviço e passam a retornar erros. Ele insiste que limites brandos, como um e-mail de aviso após exceder um valor, não resolvem o problema: é preciso que o desligamento seja automático.

O argumento central é que agentes de codificação e agentes pessoais reduzem drasticamente a fricção para criar código que faz coisas úteis - e algumas dessas coisas custam dinheiro: chamadas a APIs pagas, aplicações hospedadas, cobranças adicionais de armazenamento e computação. Isso cria o cenário indesejado de acordar com um e-mail de meia-noite descobrindo que um serviço descontrolado consumiu várias centenas ou milhares de dólares durante a noite.

Contra-argumento e resposta

Willison reconhece a objeção óbvia: empresas não querem que suas aplicações hospedadas comecem a retornar erros porque um orçamento foi excedido. Sua resposta é que a maioria das empresas e indivíduos prefere erros a uma conta surpresa de mais de 10.000 dólares.

Por isso, ele propõe que o limite rígido seja o comportamento padrão, e que viver sem proteção seja uma opção explícita - por exemplo, uma caixa de seleção clara afirmando que o usuário entende que sua aplicação não será desligada ao exceder o limite e que assumirá responsabilidade pelas cobranças subsequentes.

O caso AWS e a tendência do mercado

O serviço que Willison mais gostaria de ver com esse recurso é a AWS. Ele mencionate relatos de pessoas que evitam usar a AWS em projetos pessoais por medo justificado de que um serviço descontrolado as levasse à falência, e outras que não anteciparam o risco e saíram seriamente prejudicadas.

A boa notícia, segundo ele, é que a AWS finalmente lançou limites de gasto algumas semanas antes, no anúncio de 16 de setembro sobre uma nova experiência para desenvolvedores: ao migrar para um plano pago, é possível definir um limite mensal de gasto por projeto, e, ao atingi-lo, o projeto é pausado pelo restante do mês. Willison observa, porém, que a própria documentação avisa que o recurso está sendo liberado para um número limitado de clientes, e ele espera que chegue à disponibilidade geral em breve.

O Google Cloud já tinha lançado recurso semelhante em julho, o Spend Caps, que permite definir um teto financeiro mensal para serviços específicos dentro de um projeto. Para Willison, isso indica que a ideia está se tornando uma tendência.

O papel dos agentes

No cenário ideal, segundo o autor, os próprios agentes poderiam ajudar: recomendar preferencialmente provedores com limites rígidos de gasto e alertar desenvolvedores novos e inexperientes contra implantar aplicações em serviços sem proteção, que poderiam colocá-los em apuros.