GitHub

Serverless é fácil de explicar no abstrato e difícil de visualizar na prática. A maioria das introduções fala de funções, eventos e escalabilidade automática, conceitos corretos, mas que não ajudam quem precisa decidir se aquilo serve para o problema que tem em mãos.

A melhor forma de entender serverless é ver onde ele realmente brilha. Quais problemas concretos ele resolve melhor do que as alternativas. Que padrões se repetem nas arquiteturas que dão certo.

Este texto troca a teoria por exemplos. Vamos olhar arquiteturas reais, do tipo que aparece todos os dias em produtos digitais, e entender por que serverless faz sentido em cada uma. Não para vender a tecnologia, mas para que você reconheça quando ela é a escolha certa.

O padrão por trás de quase todo bom uso de serverless

Antes dos exemplos, vale notar uma coisa. As melhores aplicações de serverless compartilham uma característica: são tarefas que acontecem em resposta a um evento e não precisam estar rodando o tempo todo.

Algo acontece, um arquivo chega, um usuário clica, um horário é atingido, uma mensagem é recebida, e uma função desperta, faz seu trabalho e dorme de novo. Você paga só pelo instante de execução. Não há máquina parada esperando.

Quando você internaliza esse padrão, passa a enxergar oportunidades de serverless em todo lugar. E também passa a reconhecer onde ele não se encaixa.

Exemplo 1: processamento de uploads

Imagine um produto onde usuários enviam imagens, documentos, fotos de perfil, comprovantes. Cada upload precisa ser processado: redimensionado, validado, talvez analisado.

Numa arquitetura tradicional, você manteria servidores prontos para esse processamento, ociosos na maior parte do tempo e sobrecarregados nos picos. Em serverless, o fluxo é diferente. O arquivo chega ao armazenamento, esse evento dispara uma função, a função processa a imagem e termina.

Se chegarem mil uploads simultâneos, a plataforma roda mil execuções em paralelo. Se não chegar nenhum, você não paga nada. O encaixe é perfeito porque o trabalho é por evento e intermitente, exatamente o terreno onde serverless vence.

Exemplo 2: APIs com tráfego irregular

Pense em uma API de backend para um aplicativo que tem horários de pico bem definidos. Um app de transporte usado de manhã e à noite. Um sistema de agendamento de consultas com rajadas no início do mês.

Manter servidores dimensionados para o pico significa pagar por capacidade ociosa nos vales. Dimensionar para o vale significa não aguentar o pico. É um dilema clássico.

Uma API serverless resolve isso elegantemente. Cada requisição aciona uma execução, e a plataforma escala conforme o tráfego. No pico, escala; no vale, recolhe. Você acompanha a curva real de uso em vez de provisionar para o pior caso. Para tráfego irregular, esse é um dos casos de uso mais eficientes em custo.

Exemplo 3: automações e tarefas agendadas

Muitas organizações vivem de pequenas automações. Gerar um relatório toda madrugada. Enviar lembretes em horários específicos. Sincronizar dados entre sistemas periodicamente. Limpar registros antigos.

Tradicionalmente, essas tarefas exigiam um servidor ligado o tempo todo só para rodar alguns minutos por dia. Um desperdício. Em serverless, você define o gatilho, um horário, por exemplo, e a função executa só naquele momento.

Para um governo municipal, isso pode significar consolidar dados de atendimento toda noite ou disparar notificações de vencimento de tributos sem manter infraestrutura dedicada. Tarefas administrativas que rodam sozinhas, custando apenas os segundos que ocupam.

Exemplo 4: arquitetura orientada a eventos entre serviços

O exemplo mais sofisticado é também o mais poderoso. Aplicações modernas frequentemente são compostas por várias partes que precisam reagir umas às outras.

Um pedido é feito. Isso precisa atualizar o estoque, notificar o cliente, registrar a transação, talvez acionar a logística. Em vez de um sistema monolítico fazendo tudo de forma acoplada, cada uma dessas reações pode ser uma função independente, acionada pelo evento "pedido feito".

Essa arquitetura orientada a eventos é naturalmente serverless. Cada peça é pequena, independente e escala por conta própria. Se um componente falha, os outros continuam. A flexibilidade é enorme, embora, como veremos, traga sua própria complexidade.

A tese: serverless é sobre encaixe, não sobre superioridade

O que esses exemplos revelam é a minha posição central. Serverless não é melhor nem pior que arquiteturas tradicionais. É diferente, e seu valor depende inteiramente do encaixe com o problema.

Onde o trabalho é por evento, intermitente e variável, serverless costuma ser uma escolha excelente. Onde o trabalho é constante, previsível e sensível a latência, outras abordagens podem servir melhor.

A maturidade técnica não está em adotar serverless por moda, mas em reconhecer o formato do problema e escolher a ferramenta que se encaixa. Os exemplos acima compartilham uma assinatura comum, e é essa assinatura que você deve aprender a identificar.

Os erros que aparecem na prática

O primeiro erro é forçar serverless onde ele não cabe. Aplicações com processamento longo e contínuo, ou que dependem de baixa latência constante, sofrem com as limitações da abordagem. Encaixar à força gera frustração e custo.

O segundo é subestimar a complexidade distribuída. Arquiteturas orientadas a eventos, com dezenas de funções, podem virar um emaranhado difícil de entender e depurar. Mais flexibilidade significa mais peças se comunicando, e isso exige disciplina de design.

O terceiro é ignorar custo em escala extrema. Para volumes muito altos e constantes, o modelo de pagar por execução pode acabar mais caro que máquinas dedicadas. Vale fazer a conta, não presumir economia.

Reconhecer o padrão é o que importa

Depois desses exemplos, a lição prática é simples. Aprenda a reconhecer o formato de problema que serverless resolve bem: eventos, intermitência, variabilidade, independência entre peças.

Quando você enxerga esse padrão, a decisão fica natural. E quando não o enxerga, você economiza o desgaste de adotar uma arquitetura que não combina com o que precisa fazer.

Boa arquitetura não é escolher a tecnologia mais nova. É escolher a que se encaixa no problema como uma peça que sempre esteve faltando.

Se você está desenhando uma arquitetura e quer discutir onde serverless realmente cabe no seu caso, vale conversar. Tenho outros artigos no blog sobre serverless na prática e no dia a dia, com foco em execução e operação, para quem já decidiu seguir esse caminho.

Serverless para aplicativos: arquitetura com exemplos reais