serverless · cloud · arquitetura
O que é serverless, exatamente?
A palavra é um termo de marketing que ficou, e engana quase toda a gente à primeira. Serverless não quer dizer que não há servidor. Quer dizer que nunca vê nenhum: não escolhe o tamanho, não instala as atualizações, não decide quantos põe a correr. Isso faz-o outra pessoa, e a si cobra-se o que o seu código realmente fez.
O que retira de facto
Num VPS aluga uma máquina. Ela existe venha alguém ou não, escolhe-lhe a RAM e os vCPU, corrige-lhe o kernel e decide quando acrescentar uma segunda. Cada uma dessas decisões é sua, e cada hora da fatura também.
O serverless retira a máquina enquanto unidade de raciocínio. Entrega à plataforma um pedaço de código e um gatilho: um pedido HTTP, uma mensagem numa fila, um ficheiro que aterra no armazenamento. A plataforma trata de que esse código corra quando o gatilho dispara. Quantas cópias correm, e sobre o quê, não é problema seu nem decisão sua.
É toda a troca, dita sem rodeios: abdica do controlo do runtime em troca de nunca o operar.
As duas famílias
Function as a Service é a parte em que se pensa primeiro. Faz o deploy de uma função, a plataforma executa-a por evento, e ela desaparece. AWS Lambda, Google Cloud Functions e Azure Functions são os exemplos conhecidos.
Os serviços geridos serverless são a metade maior e menos comentada: bases de dados, filas, armazenamento de objetos e pesquisa, faturados por pedido ou por unidade de trabalho em vez de por instância aprovisionada. A maioria dos sistemas serverless reais é sobretudo isto, com uma quantidade modesta de código de função a segurar as peças.
A faturação, e porque o scale to zero é o título
Uma máquina alugada é faturada ao tempo de relógio. Custa o mesmo às três da manhã sem visitas e no pico. O serverless fatura por invocação mais os recursos que essa invocação consumiu enquanto corria.
A consequência é o scale to zero: sem tráfego não corre nada e não há nada a pagar. Para um projeto pessoal, uma ferramenta interna usada duas vezes por semana ou uma carga aos picos parada quase sempre, esta é a vantagem verdadeira, e é grande.
O mesmo mecanismo trabalha ao contrário sob carga. A plataforma arranca tantas cópias concorrentes quantas os eventos exigirem, sem que configure um autoscaler, e essa é a segunda vantagem real.
As restrições que o argumentário omite
Arranques a frio. Quando nenhuma cópia da sua função está quente, o primeiro pedido paga a inicialização do runtime e das suas dependências antes de o seu código sequer começar. Bundles mais pequenos e runtimes mais leves reduzem isso. Os fornecedores vendem capacidade pré-aquecida, que funciona e que desfaz em silêncio o scale to zero, porque pré-aquecido significa pago enquanto está parado.
Ausência de estado. Nada do que guarde em memória ou em disco local está garantido da próxima vez. Duas invocações podem cair em instâncias diferentes, e uma instância desaparece quando a plataforma decidir. O estado vai para uma base de dados ou um armazenamento de objetos, sempre.
Limites de execução. Uma invocação tem uma duração máxima e um teto de memória. Os processos por lotes longos e tudo o que mantenha uma ligação aberta durante horas encaixam mal, e atingir o limite não é um aviso mas uma falha.
Acoplamento. O corpo da função costuma ser portável. As formas dos eventos, o modelo de identidade e os serviços geridos à volta não são, e é aí que sair mais tarde custa a sério.
Onde a curva de custo se cruza
A faturação por invocação é barata quando a máquina teria estado parada e cara quando teria estado ocupada. Abaixo de certa carga estável, o serverless ganha com folga. Acima, paga um prémio por unidade de trabalho por uma elasticidade que já não usa, e um servidor sempre ligado, ainda que modesto, sai mais barato e mais previsível.
A regra honesta é olhar para a forma do tráfego e não para o seu volume. Aos picos, ocasional e imprevisível: vantagem serverless. Estável e contínuo: vantagem máquina alugada ao mês, e nesse ponto o trabalho de operação que retoma é um preço justo por uma fatura que deixa de surpreender.
Se a sua carga estiver do lado estável, um VPS é a resposta simples, e o Docker mais alguma disciplina devolve-lhe quase toda a reprodutibilidade que tornava o serverless atraente ao início.
Um servidor para o lado estável da curva
Quando o tráfego deixa de ser aos picos, a faturação por invocação custa mais do que uma máquina que ia estar ocupada de qualquer forma. A DigitalOcean oferece VPS e servidores cloud com controlo root completo, faturados ao mês e não por chamada.
Ver DigitalOcean Cloud →Link de afiliado - apoia estes guias gratuitos.
Em resumo
Serverless significa que os servidores são problema de outra pessoa, não que não existam. Ganha scale to zero, concorrência automática e zero correções. Aceita arranques a frio, ausência de estado, limites de execução e uma fatura que segue o uso em vez do tempo. Encaixa em trabalho aos picos e intermitente, e deixa de encaixar quando o tráfego se torna estável o suficiente para que uma máquina alugada estivesse ocupada de qualquer forma.