Serverless não significa ausência de servidores. Significa que você não gerencia servidores. O código roda em infraestrutura do provedor que provisiona, escala e desaloca recursos automaticamente. Você entrega a função; o provedor cuida de tudo embaixo.
Como o serverless funciona: FaaS e event-driven
O modelo dominante de serverless é o FaaS (Function as a Service). O código é organizado em funções pequenas e independentes, cada uma com uma responsabilidade específica. As funções não ficam “rodando” permanentemente — elas são executadas em resposta a eventos.
O fluxo básico:
- Um evento ocorre: requisição HTTP, mensagem em fila, novo arquivo em object storage, mudança em banco de dados, timer agendado.
- O provedor recebe o evento e instancia um container efêmero com o código da função.
- A função executa, produz uma resposta ou dispara outro evento.
- O container é desalocado. Se nenhum outro evento chegar, não há custo.
Exemplos de plataformas FaaS:
- AWS Lambda
- Azure Functions
- Google Cloud Functions
- Cloudflare Workers (edge)
A escala é automática e transparente. Se chegam 10.000 requisições simultâneas, o provedor instancia 10.000 execuções paralelas da função — sem configuração de auto-scaling, sem grupos de instâncias, sem load balancer para gerenciar.
O modelo de cobrança é por execução: você paga pelo número de invocações e pelo tempo de CPU/memória consumido durante a execução. Se a função não é invocada, o custo é zero.
Casos de uso ideais
Serverless não é a resposta certa para tudo. Ele brilha em cenários com características específicas.
APIs de baixo a médio volume com tráfego irregular
Um endpoint que recebe poucas requisições por hora mas tem picos ocasionais. Com VMs, você paga pela capacidade ociosa entre os picos. Com serverless, paga apenas pelas execuções reais.
Processamento de eventos assíncronos
Redimensionar imagens quando fazem upload, processar arquivos CSV enviados por clientes, transcrever áudio após gravação, enviar notificações quando um registro é atualizado. Cada evento dispara uma função; o processamento escala com o volume de eventos.
Automações e integrações
Rotinas agendadas (substituindo cronjobs em servidores), webhooks de integração entre sistemas, transformações de dados em pipelines ETL leves.
Backends para aplicações mobile e web simples
Quando a lógica de negócio é simples e o tráfego não justifica manter um servidor dedicado.
Prototipação e MVPs
O tempo de setup é mínimo. Escreva a função, faça o deploy e o endpoint está disponível. Ideal para validar ideias sem infraestrutura.
Limitações reais que arquitetos precisam conhecer
Cold start
Quando uma função não foi invocada recentemente, o provedor precisa inicializar um novo container. Esse processo leva de algumas dezenas de milissegundos a alguns segundos, dependendo do runtime e do tamanho da função. Para APIs onde latência é crítica (< 100ms consistente), o cold start é um problema real. Soluções existem (provisioned concurrency, keep-alive pings), mas adicionam custo e complexidade.
Timeout máximo
Funções FaaS têm tempo máximo de execução. No AWS Lambda, o limite é 15 minutos. No Azure Functions, 10 minutos (no plano de consumo). Processos de longa duração — processamento de vídeo, relatórios pesados, migrações — não são adequados para FaaS.
Estado efêmero
Cada invocação é isolada. A função não pode armazenar estado local entre execuções. Qualquer dado que precisa persistir deve ir para um serviço externo (banco de dados, cache, object storage). Isso é uma restrição de design, não apenas uma limitação técnica.
Debugging e observabilidade difíceis
Rastrear o que aconteceu em uma execução de função que durou 200ms e produziu um erro é significativamente mais difícil que debugar um processo em servidor. Não há SSH para o container; logs são o principal instrumento. Ferramentas como AWS X-Ray ou Datadog APM ajudam, mas exigem instrumentação explícita.
Lock-in de provedor
O código da função pode ser portável. A integração com filas, bancos gerenciados, triggers de eventos e a configuração de permissões são profundamente atadas ao provedor. Migrar de AWS Lambda para Azure Functions não é simples.
Custo em alta escala contínua
Serverless é econômico para tráfego variável. Para cargas altas e constantes (muitas execuções por segundo, 24 horas por dia), uma VM ou container rodando permanentemente pode ser mais barato. Faça o cálculo antes de assumir que serverless é sempre mais econômico.
Serverless vs containers vs VMs: quando usar cada um
Não existe uma resposta universal. A escolha depende do perfil da carga de trabalho.
| Critério | Serverless (FaaS) | Containers (Kubernetes) | VMs |
|---|---|---|---|
| Gestão de infraestrutura | Nenhuma | Média (cluster) | Alta |
| Escala automática | Imediata, até zero | Configurável | Manual ou script |
| Latência de inicialização | Cold start (dezenas de ms a segundos) | Segundos (pod startup) | Minutos |
| Estado da aplicação | Efêmero (sem estado) | Stateless ou stateful | Stateful |
| Tempo máximo de execução | Minutos (limitado) | Ilimitado | Ilimitado |
| Debugging | Difícil | Moderado | Direto (SSH) |
| Custo em baixa carga | Mínimo (paga por execução) | Fixo (nós do cluster) | Fixo (VM ligada) |
| Custo em alta carga constante | Pode ser alto | Médio | Médio a baixo |
| Portabilidade | Baixa (lock-in) | Alta | Alta |
| Ideal para | Eventos, APIs variáveis, automações | Microsserviços, aplicações cloud native | Workloads legados, licenças por servidor, alta previsibilidade |
Regra prática:
- Processamento de eventos pontuais e escaláveis: serverless.
- Aplicação de longa duração com escala horizontal: containers.
- Workload com licença por servidor, estado complexo ou acesso direto ao SO: VM.
Arquiteturas modernas frequentemente combinam os três. Um sistema pode ter uma API em containers, processamento de eventos em serverless e um banco de dados legado em VM dedicada.
A Adentro oferece infraestrutura de Cloud Pública e Cloud Privada para hospedar workloads modernos, incluindo ambientes Kubernetes compatíveis com arquiteturas event-driven e serverless. Consulte um especialista.