Serverless

O nome é enganoso. Serverless — sem servidor — não significa que não existe servidor. Significa que o desenvolvedor não precisa pensar no servidor. A infraestrutura existe, mas é completamente abstraída: você escreve o código da função, define quando ela deve executar, e o provedor cuida de tudo o mais — provisionamento, escalabilidade, patches, monitoramento de infraestrutura.

O modelo muda fundamentalmente a unidade de computação. Em infraestrutura tradicional, você aluga um servidor que fica rodando — e você paga por ele enquanto estiver ligado, independentemente de estar fazendo algo útil ou não. Em serverless, você paga por execução: cada vez que sua função é chamada, ela roda, processa, retorna o resultado e para. Você paga pelo tempo de processamento consumido, não pelo servidor ocioso.

Para certos padrões de uso — cargas intermitentes, picos imprevisíveis, tarefas event-driven — essa mudança é economicamente e operacionalmente significativa.

O modelo de computação serverless mais disseminado é o de Functions as a Service (FaaS): funções individuais que são invocadas por eventos — uma requisição HTTP, uma mensagem numa fila, upload de arquivo, mudança num banco de dados, agendamento de tempo.

O fluxo típico: um evento acontece (usuário faz upload de imagem), o provedor detecta o evento, instancia a função (inicia um container com o código), executa, retorna o resultado e encerra a instância. Se dez uploads acontecem simultaneamente, dez instâncias da função rodam em paralelo — o escalonamento é automático e instantâneo, sem configuração.

As principais plataformas: AWS Lambda (pioneiro, ainda dominante), Google Cloud Functions, Azure Functions, Cloudflare Workers (executa na borda da rede, latência mínima), Vercel Functions e Netlify Functions (voltados para aplicações web modernas).

Além de FaaS, serverless abrange outros serviços gerenciados onde o provedor abstrai completamente a infraestrutura: bancos de dados serverless (Aurora Serverless, PlanetScale, Neon), filas serverless (SQS), armazenamento (S3) e autenticação (Cognito, Auth0).

Cargas intermitentes e imprevisíveis: APIs que recebem pico de tráfego em horários específicos e ficam quase ociosas o resto do dia. Processamento de imagens que acontece quando usuário faz upload — pode ser zero ou mil por dia. Em servidores tradicionais, você dimensiona para o pico e paga pelo ocioso. Em serverless, paga apenas pelo que usa.

Tarefas event-driven: processamento de webhooks de terceiros (pagamento confirmado, e-mail enviado, commit no repositório), reação a eventos em filas, transformação de dados disparada por upload. Serverless é o modelo natural para esse padrão.

Backend para aplicações web e mobile modernas: APIs RESTful e GraphQL construídas como funções serverless, escalando automaticamente com o número de usuários. Para aplicações que não têm estado complexo no servidor, serverless elimina toda a gestão de infraestrutura.

Automações e tarefas agendadas: jobs noturnos de processamento de relatórios, sincronização de dados entre sistemas, limpeza de dados expirados. Em vez de manter servidor apenas para executar código de cinco minutos por dia, uma função serverless agendada custa fração do preço.

Startups e MVPs: tempo para mercado é mais importante que otimização de custo. Serverless permite lançar backend funcional sem configurar servidor, load balancer, auto-scaling — em horas, não dias.

Serverless não é solução universal. Há compensações reais que determinam quando o modelo funciona e quando não funciona.

Cold start: quando uma função não foi chamada por um período, o provedor libera sua instância. A próxima chamada precisa instanciar uma nova — processo que leva de dezenas de milissegundos a alguns segundos dependendo do runtime e do tamanho do código. Para funções chamadas frequentemente, cold start é irrelevante. Para funções que ficam ociosas e precisam de resposta imediata, é problema.

Timeout: funções serverless têm limite de tempo de execução (AWS Lambda: máximo 15 minutos). Processamentos longos — transcodificação de vídeo, treinamento de modelo, relatórios pesados — não cabem no modelo.

Estado: funções serverless são stateless por design — cada execução começa do zero, sem memória do que aconteceu antes. Estado precisa ser armazenado externamente (banco de dados, cache). Para arquiteturas que dependem de estado em memória, o modelo exige redesenho.

Debugging e observabilidade: depurar uma função que roda em infraestrutura completamente gerenciada, em instâncias efêmeras, é mais complexo do que depurar aplicação em servidor próprio. Ferramentas de observabilidade e logs distribuídos são necessidade, não opcional.

Custo em carga constante alta: para aplicações com tráfego constante e alto, servidor dedicado ou containers podem ser mais baratos que funções serverless. O modelo pay-per-execution favorece cargas intermitentes; para carga constante, a conta pode inverter.

Vendor lock-in: o código da função em si pode ser portátil, mas o ecossistema ao redor — triggers, integrações, segurança — frequentemente é proprietário do provedor. Migrar de AWS Lambda para Google Cloud Functions não é trivial se o sistema usa serviços específicos da AWS.

O surgimento de frameworks como Next.js, Remix e SvelteKit, combinado com plataformas como Vercel e Netlify, popularizou um padrão de aplicação web onde todo o backend é serverless por padrão.

Nesse modelo, as páginas estáticas são servidas de CDN (extremamente rápido e barato), e lógica dinâmica — autenticação, acesso a banco de dados, APIs — é executada em funções serverless invocadas por requisição. O resultado é uma aplicação que escala automaticamente, sem configuração de servidor, com custo próximo a zero em tráfego baixo.

Para empresas que desenvolvem aplicações web modernas, esse padrão está se tornando o default — não porque sempre é a melhor opção técnica, mas porque elimina uma classe inteira de preocupações de infraestrutura que não são o core do negócio.

Serverless é especialmente relevante para PMEs que desenvolvem software sem equipe de operações de infraestrutura dedicada. O ganho não é apenas custo — é foco. Desenvolvedores que não precisam gerenciar servidor, configurar auto-scaling ou aplicar patches de segurança de sistema operacional têm mais tempo para o que agrega valor: o produto em si.

A adoção mais natural para equipes que estão começando é usar serverless para funções auxiliares e automações — processamento de imagens, envio de e-mails, webhooks, tarefas agendadas — enquanto mantém o backend principal em infraestrutura mais convencional. Isso captura os benefícios do modelo para os casos onde ele brilha sem comprometer a aplicação core a restrições que podem não se encaixar.