O Que São Serverless e FaaS

O que é a computação serverless

A computação serverless é um modelo de computação na cloud em que o fornecedor de cloud gere automaticamente a infraestrutura. Ao contrário do alojamento web clássico, o escalonamento e a alocação de recursos são feitos por ele em vez de por si. Apesar do nome, os servidores continuam a existir, mas não tem de pensar neles nem de os configurar. Escreve o código, faz o deploy, e o fornecedor de cloud trata de tudo o resto, incluindo o sistema operativo, o ambiente de execução, o escalonamento e a alta disponibilidade. Paga apenas pelo tempo de execução do código, e não pelo tempo em que o servidor está à espera de pedidos.

O serverless é uma evolução a partir dos servidores físicos, passando pelas máquinas virtuais e contentores, até a um modelo de computação completamente abstraído. Cada passo desta evolução retira uma camada de responsabilidade ao programador e transfere-a para o fornecedor de cloud. No modelo serverless, o programador concentra-se exclusivamente na lógica de negócio, enquanto o fornecedor de cloud trata de tudo o resto, acelerando drasticamente o desenvolvimento e reduzindo os custos operacionais para muitos tipos de aplicações.

Functions as a Service (FaaS)

O FaaS é a forma mais reconhecível de computação serverless. No modelo FaaS, escreve pequenas funções autónomas que são executadas em resposta a eventos. Cada função tem uma responsabilidade claramente definida, recebe dados de entrada, executa a lógica e devolve um resultado. O fornecedor de cloud cria automaticamente uma instância para a execução da função, executa-a e encerra a instância quando termina. Se chegarem 1000 pedidos em simultâneo, o fornecedor cria automaticamente 1000 instâncias.

Principais fornecedores de FaaS

• AWS Lambda - primeiro e mais maduro serviço FaaS, lançado em 2014
• Google Cloud Functions - o FaaS da Google com boa integração com o Firebase
• Azure Functions - o FaaS da Microsoft com excelente suporte para .NET
• Cloudflare Workers - edge computing com distribuição global e isolamento V8
• Vercel Functions - otimizadas para Next.js e frameworks de frontend
• Netlify Functions - simples para sites Jamstack

Cada fornecedor tem especificidades quanto às linguagens de programação suportadas, ao tempo máximo de execução, aos limites de memória e aos métodos de acionamento (trigger). Para uma abordagem mais clássica, considere o serviço de alojamento na cloud. O AWS Lambda suporta Node.js, Python, Java, Go, .NET e Ruby, com um tempo máximo de execução de 15 minutos e até 10 GB de memória. Os Cloudflare Workers usam o runtime V8 com um limite de tempo de CPU de 50 ms (plano gratuito), mas com uma latência extremamente baixa, porque são executados em localizações de edge.

Como funcionam as funções serverless

Quando um evento aciona uma função serverless, o fornecedor de cloud passa por vários passos. Primeiro, verifica se existe uma instância "quente" já inicializada e pronta para execução. Caso contrário, é criada uma nova instância, designada por cold start. O cold start inclui o arranque do contentor, o carregamento do runtime, o carregamento do seu código e a execução da lógica de inicialização. Depois disso, a função handler é executada com os dados do evento.

O problema do cold start

O cold start é a fonte de latência mais comum na arquitetura serverless. Para funções Node.js, o cold start demora normalmente 100-500 ms, para Python 200-800 ms, e para Java pode demorar 1-5 segundos ou mais, devido à inicialização da JVM. Após a primeira execução, a instância mantém-se "quente" durante algum tempo (normalmente 5-15 minutos) e os pedidos seguintes executam muito mais depressa, porque saltam a inicialização.

As estratégias para reduzir o cold start incluem usar runtimes leves (Node.js e Python são mais rápidos do que Java), minimizar o tamanho do pacote de deploy, usar concorrência aprovisionada (pagar por instâncias pré-aquecidas) e evitar inicializações pesadas na função handler. O AWS Lambda SnapStart para Java e os Cloudflare Workers, que usam isolates V8 em vez de contentores, reduzem significativamente o cold start para um nível negligenciável na maioria das aplicações.

Casos de utilização do serverless

A arquitetura serverless é ideal para certos tipos de carga de trabalho, enquanto para outros pode ser dispendiosa ou impraticável. Compreender o caso de utilização correto é fundamental para aplicar com sucesso o modelo serverless na prática.

Cenários ideais

• Backends de API - APIs REST ou GraphQL que processam pedidos HTTP
• Processamento de eventos - reagir a upload de ficheiros, alteração na base de dados, mensagem de fila
• Tarefas agendadas - cron jobs executados periodicamente
• Processamento de imagem e vídeo - redimensionamento, compressão, transcodificação a pedido
• Chatbots e inferência de IA - processamento de mensagens de utilizadores e chamadas a modelos de IA
• Webhooks - receção e processamento de chamadas de webhook de serviços externos
• Processamento de dados de IoT - processamento de dados de sensores e dispositivos

Cenários menos adequados

O serverless não é ideal para processos de longa duração que ultrapassem os 15 minutos, para aplicações que exijam baixa latência constante (problema do cold start), para cargas de trabalho com tráfego constantemente elevado em que um servidor dedicado é mais barato, e para aplicações que exijam um sistema de ficheiros local ou ligações WebSocket de longa duração. Nesses casos, os contentores ou os servidores tradicionais são uma escolha melhor.

Modelo de preços

Uma das maiores vantagens do modelo serverless é o pagamento por utilização. Não paga pelo tempo em que o servidor está inativo, mas apenas pelo tempo em que o seu código está ativamente em execução. O AWS Lambda cobra por número de pedidos (0,17 € por milhão de pedidos) e por duração de execução medida em GB-segundos (a quantidade de memória que a função usa multiplicada pela duração da execução em segundos).

Comparação de custos

Para um site ou API pequeno com 100 000 pedidos por mês, em que cada pedido demora 200 ms com 256 MB de memória, o custo mensal no AWS Lambda seria inferior a um euro. O servidor EC2 equivalente t3.micro custa cerca de 7,30 € por mês, mesmo quando na maior parte do tempo não faz nada. Para este tipo de carga de trabalho, o serverless é drasticamente mais barato.

No entanto, o cálculo muda em larga escala. Para uma aplicação com 100 milhões de pedidos por mês, os custos do serverless podem ultrapassar os 170 € por mês, enquanto um servidor dedicado com capacidade semelhante custaria menos. O chamado serverless cost cliff surge quando a carga de trabalho excede um determinado limiar a partir do qual um servidor alugado de forma permanente se torna mais económico. Para cada aplicação, é importante fazer uma análise de custos para a carga de trabalho prevista antes de escolher um modelo.

Vantagens da arquitetura serverless

• Sem gestão de infraestrutura - não se preocupa com servidores, patches, escalonamento
• Escalonamento automático - de zero a milhões de pedidos sem qualquer configuração
• Pagamento por utilização - paga apenas pela execução, não pelo tempo inativo
• Desenvolvimento mais rápido - o foco no código em vez da infraestrutura acelera a entrega
• Alta disponibilidade - o fornecedor de cloud garante a disponibilidade sem o seu envolvimento
• Escalonamento até zero - sem custos quando não há tráfego

Desvantagens e desafios

A arquitetura serverless também traz desafios específicos. O vendor lock-in é real, porque cada fornecedor tem APIs, serviços e ferramentas específicos que dificultam a migração para outro fornecedor. A latência do cold start pode ser problemática para aplicações que exijam uma resposta consistentemente rápida. O debugging e a monitorização são mais complexos, porque as funções são executadas em ambientes efémeros sem acesso a ferramentas de diagnóstico tradicionais.

O desenvolvimento e os testes locais também representam um desafio, porque é difícil replicar o ambiente de cloud localmente. Ferramentas como AWS SAM, Serverless Framework e LocalStack ajudam, mas não conseguem simular totalmente o comportamento em produção. Os limites no tamanho do pacote de deploy, no tempo de execução e na memória podem exigir a refatoração de aplicações existentes. Por fim, para equipas sem experiência em serviços de cloud, a curva de aprendizagem pode ser acentuada.