GitHub

Entender serverless é uma coisa. Implementar bem é outra completamente diferente. Muita gente que abraçou o conceito descobriu, no caminho, que a facilidade prometida vinha acompanhada de decisões difíceis que ninguém tinha mencionado.

A distância entre o serverless dos slides e o serverless do código de produção é onde os times se machucam. Não porque a tecnologia seja ruim, mas porque ela exige um modo de pensar que poucos desenvolvem antes de já estarem com problemas no ar.

Este texto é para quem decidiu construir com serverless e quer fazer direito. Vamos falar das decisões reais de design, das armadilhas que aparecem na implementação e da disciplina que separa uma arquitetura sólida de um amontoado de funções difícil de manter.

A facilidade enganosa do começo

Serverless tem um início sedutor. Em poucos minutos você sobe sua primeira função, ela responde, e parece que tudo será assim de simples. É aí que mora a armadilha.

O problema não é escrever uma função. É escrever cinquenta funções que conversam entre si, compartilham lógica, dependem de dados e precisam ser entendidas por uma equipe seis meses depois. A complexidade não desaparece com serverless. Ela muda de lugar, sai da infraestrutura e vai para a arquitetura.

Quem não percebe isso constrói o que se chama de "monólito distribuído": todas as desvantagens de um sistema espalhado, sem nenhuma das vantagens de um design pensado. É o pior dos mundos, e é mais comum do que se imagina.

A tese: serverless exige mais design, não menos

Aqui está minha posição central. Serverless não dispensa arquitetura, exige mais dela.

Quando você gerencia servidores, parte da disciplina é imposta pela infraestrutura. Você é obrigado a pensar em como as peças se organizam. Serverless remove essa imposição e devolve a liberdade total. E liberdade sem disciplina vira caos.

Por isso, implementar serverless bem é um exercício de design consciente. Você precisa decidir, de propósito, como dividir responsabilidades, como funções se comunicam, onde mora o estado e como tudo se mantém compreensível. Quem trata serverless como "código rápido sem servidor" colhe dívida técnica em velocidade recorde.

Decisões de design que definem o resultado

Granularidade: quão pequena deve ser cada função

A primeira decisão difícil é o tamanho. Funções pequenas demais multiplicam a complexidade da comunicação. Funções grandes demais perdem os benefícios de modularidade e escalabilidade independente.

Uma boa regra é organizar funções em torno de responsabilidades de negócio claras, não de operações triviais. Cada função deve fazer algo coeso e compreensível. Resista à tentação de fragmentar tudo em micro-pedaços, a sedução do "extremamente granular" costuma terminar em ingovernabilidade.

Estado: onde os dados realmente vivem

Funções serverless são, por natureza, sem estado. Elas nascem, executam e morrem. Isso significa que todo estado precisa morar fora delas, em bancos de dados, caches, armazenamentos.

Essa é uma das maiores mudanças de mentalidade. Você não pode guardar nada na memória entre execuções. Toda persistência é explícita e externa. Projetar isso bem, escolhendo os armazenamentos certos para cada tipo de dado, é o que separa uma aplicação confiável de uma cheia de comportamentos imprevisíveis.

Comunicação: como as peças conversam

Em uma arquitetura serverless real, as funções precisam interagir. A decisão de como elas se comunicam, de forma síncrona, esperando resposta, ou assíncrona, via eventos e filas, molda toda a robustez do sistema.

Comunicação assíncrona, via eventos, costuma trazer mais resiliência: se uma peça falha, a mensagem espera. Mas adiciona complexidade de rastreamento. Comunicação síncrona é mais simples de entender, mas cria acoplamento e propaga falhas. Essa escolha não é técnica menor, é estrutural.

Um exemplo de implementação consciente

Imagine construir o backend de um app de delivery usando serverless. O fluxo de um pedido envolve várias etapas: validar, cobrar, notificar o restaurante, acompanhar a entrega.

A implementação ingênua faria uma função gigante tentando orquestrar tudo de forma síncrona. Resultado: lenta, frágil e impossível de depurar. Se a notificação falha, o pedido inteiro trava.

A implementação consciente separa responsabilidades. Uma função recebe e valida o pedido, registrando-o. Isso emite um evento que dispara, de forma independente, a cobrança, a notificação e o acompanhamento. Cada peça falha e se recupera sozinha. O estado do pedido vive num banco, acessível por todas.

A diferença entre as duas não é a tecnologia. É o cuidado com o design feito antes de escrever a primeira linha.

As armadilhas da implementação

A primeira armadilha é a depuração. Quando algo dá errado num sistema espalhado por dezenas de funções e eventos, descobrir a causa é difícil. Sem rastreamento adequado desde o início, você fica cego. Investir em observabilidade não é opcional, é condição de sobrevivência.

A segunda é a explosão de configuração. Cada função tem suas permissões, suas variáveis, seus gatilhos. Em escala, gerenciar isso manualmente vira fonte de erros. Tratar a infraestrutura como código, versionada e automatizada, deixa de ser refinamento e vira necessidade.

A terceira é a ilusão de isolamento. Funções parecem independentes, mas compartilham bancos, filas e limites do provedor. Uma função mal comportada pode afetar as outras. Pensar nessas dependências invisíveis é parte do trabalho.

Disciplina é a verdadeira infraestrutura

O que descobri, na prática, é que serverless não elimina o trabalho difícil, ele o desloca. Você deixa de cuidar de máquinas e passa a cuidar de design, comunicação e estado. Para quem aborda isso com disciplina, o resultado é poderoso: sistemas flexíveis, escaláveis e econômicos.

Para quem trata como atalho, o resultado é um emaranhado que ninguém entende e ninguém quer manter. A tecnologia é a mesma. O que muda é o rigor de quem a empunha.

Serverless não é mais fácil. É diferente. E a diferença é vencida com design, não com pressa.

Se você está implementando uma arquitetura serverless e quer evitar as armadilhas clássicas, vale trocar ideia. Tenho outros artigos no blog sobre o conceito de serverless, casos de uso e operação no dia a dia que complementam esta visão de implementação.

Serverless para aplicativos: arquitetura na prática