Serverless validações: 9 checagens antes do deploy

Serverless resolve muita coisa, mas não resolve a falta de validação. Antes de subir a primeira função em produção, passamos por nove checagens que separam um deploy tranquilo de uma conta salgada e um incidente silencioso. Antes de implementar serverless, valide concorrência e limites da conta, cold start real da sua stack, custo por invocação, permissões IAM mínimas, observabilidade, estratégia de deploy, tamanho do pacote, tempo de execução e plano de rollback. Cada checagem evita um problema caro que só apareceria em produção.

Use este checklist quando o time já decidiu ir para serverless e está prestes a configurar a primeira função, ou quando herda uma stack existente e precisa entender o que está frágil. A ordem não é rígida, mas pular as três primeiras costuma sair caro.

Validações de arquitetura e limites

1. Concorrência e limites da conta

Cada conta de nuvem tem um teto de invocações simultâneas, e esse teto é compartilhado entre todas as funções da conta. Se uma função sobe para 800 concorrências num pico, as outras ficam na fila. Defina concorrência reservada para as funções críticas e teste o comportamento sob carga antes do lançamento.

2. Cold start da sua stack real

Cold start varia por runtime, tamanho do pacote e dependências. Um Node.js enxuto se comporta diferente de um Java com framework pesado. Meça o tempo de inicialização da sua função específica, não o número genérico que circula em blog. Se a latência da primeira chamada importa para o usuário, considere provisioned concurrency.

3. Timeout e limites de payload

Funções serverless têm timeout máximo e limite de tamanho de payload, tanto de entrada quanto de saída. Se sua API trafega arquivos grandes, o gargalo aparece rápido. Valide o maior caso real de uso, não a média.

Validações de custo e permissões

4. Custo por invocação em cenário real

O custo serverless é uma função de invocações, tempo de execução e memória alocada. Rode uma estimativa com o volume real esperado, incluindo picos. Uma função que roda 200 ms a 256 MB pode custar dez vezes mais que a mesma lógica a 128 MB. Ajuste memória com base em medição, não em chute.

5. Permissões IAM mínimas

Cada função deve ter apenas as permissões que precisa. Um papel com acesso amplo é o caminho mais curto para um incidente de segurança. Revise as políticas antes do deploy e prefira escopo por recurso, não por serviço inteiro.

6. Variáveis de ambiente e segredos

Segredos não entram no código nem no repositório. Use o serviço de gestão de segredos da sua nuvem e rotacione quando necessário. Verifique se as variáveis de ambiente estão definidas em todos os ambientes, não só em produção.

Validações de operação

7. Observabilidade desde o primeiro deploy

Logs, métricas e traces precisam estar configurados antes de a função subir. Sem isso, você descobre o problema pelo cliente. Defina o que será logado, em que nível e por quanto tempo. Um log sem contexto de decisão é só volume.

8. Estratégia de deploy e versionamento

Funções serverless versionam por alias ou por estágio. Escolha um modelo e documente. Deploy direto em produção sem versão anterior acessível é o caminho mais rápido para um rollback doloroso.

9. Plano de rollback testado

Ter uma versão anterior publicada não basta. Teste o rollback em ambiente de homologação. Se o processo depende de alguém lembrar o comando certo, ele vai falhar no momento errado.

O erro mais comum

O erro mais comum é validar tudo em ambiente de desenvolvimento e assumir que produção se comporta igual. Concorrência, cold start e custo só aparecem com tráfego real. Antes de considerar a implementação pronta, rode um teste de carga pequeno em produção controlada e compare os números com a estimativa. A diferença entre os dois costuma ser o primeiro problema que você vai resolver.

FAQ

O que é cold start em serverless?

Cold start é o tempo que a plataforma leva para inicializar uma função que estava ociosa. Envolve carregar o runtime, o código e as dependências. Em funções com muitas bibliotecas, esse tempo pode ser perceptível para o usuário. Medir o cold start da sua stack é mais útil que usar médias genéricas.

Serverless é sempre mais barato que servidor tradicional?

Não. Para cargas constantes e previsíveis, um servidor dedicado pode custar menos. Serverless tende a compensar em cargas variáveis, com picos e vales. Faça a estimativa com o volume real da sua aplicação antes de decidir.

Preciso configurar concorrência reservada em toda função?

Não. Reserve concorrência para funções críticas que não podem competir com o restante da conta. As demais podem usar o pool compartilhado. O importante é saber qual é o teto da conta e como as funções se comportam quando ele é atingido.

Como validar permissões IAM antes do deploy?

Revise a política de cada função e confira se ela só acessa os recursos necessários. Prefira escopo por recurso (um bucket específico, uma tabela específica) em vez de acesso amplo ao serviço. Teste em ambiente de homologação com as mesmas políticas de produção.

Qual a melhor forma de estimar custo serverless?

Combine três variáveis: número de invocações, tempo médio de execução e memória alocada. Rode a estimativa com o volume real esperado, incluindo picos. Depois, compare com a medição em produção controlada. A diferença entre estimativa e realidade é o ajuste que você precisa fazer.

O que logar em uma função serverless?

Loge o identificador da requisição, o resultado da operação e o tempo de execução. Evite logar dados sensíveis. O objetivo é responder rapidamente a três perguntas: o que aconteceu, quando e para quem. Se o log não ajuda a tomar uma decisão, ele é só volume.