O que é computação serverless: guia do modelo FaaS

Computação serverless é um modelo de computação em nuvem em que você publica código acionado por eventos e o provedor provisiona, escala e mantém a infraestrutura. A cobrança costuma seguir execução e memória usadas, não servidor ocioso, porém cold start, limites de duração e a responsabilidade por identidade, dados e dependências permanecem com a equipe.

Imagine um formulário que recebe poucos envios no meio da noite e um pico quando uma campanha dispara. Se você mantém uma máquina ligada o dia inteiro, paga capacidade parada. Com uma função serverless, o código sobe quando o evento chega e pode voltar a zero quando o tráfego some. O alívio operacional é real, e o risco de projetar mal a cobrança ou a latência também.

Você sai deste verbete sabendo o mecanismo, os casos em que a arquitetura serverless ajuda, o que muda frente a IaaS e a containerização, e os cuidados de segurança que o provedor não assume por você. Além disso, o texto liga cada benefício ao custo correspondente, porque economia prometida sem medição vira surpresa na fatura.

Como a computação serverless executa o seu código?#

Ela executa unidades pequenas de lógica quando um gatilho dispara, sem que a equipe administre o sistema operacional do host. Segundo a visão de funções serverless da Microsoft Learn, o servidor continua existindo no datacenter do provedor, porém a responsabilidade de comprar, patchar e dimensionar essa camada deixa de ser da aplicação. O time entrega handlers, não inventário de máquinas.

Na prática o fluxo costuma ser este. Um evento chega por HTTP, fila, armazenamento de objetos ou agendamento. A plataforma instancia um ambiente, injeta o código e chama o handler. Em seguida, se a demanda cair, as instâncias podem ser reduzidas, inclusive a zero. Por isso o modelo combina com tarefas curtas, assíncronas e com carga irregular, como redimensionar imagem após upload, validar webhook ou enriquecer um registro que acabou de entrar num banco de dados.

Função como serviço e o papel do FaaS#

A forma mais citada de serverless de compute é a função como serviço, também chamada FaaS. A função tende a fazer uma operação bem delimitada e a responder a um evento, enquanto um microsserviço costuma expor várias operações de um domínio. Essa diferença importa no desenho, porque empilhar dezenas de regras num único handler cria um monólito disfarçado, com deploy difícil e permissões largas demais.

O provedor gerencia o runtime gerenciado, a escala e boa parte da disponibilidade da plataforma. Porém você continua dono do código, das bibliotecas, das variáveis de configuração e do contrato com serviços vizinhos. Ou seja, “sem servidor” nunca significa “sem operação”. Significa outra superfície operacional, centrada em eventos, identidade e observabilidade.

Quem chega de um servidor sempre ligado precisa mudar o hábito de estado. Funções costumam ser tratadas como sem estado entre invocações, e qualquer dado que precise sobreviver vai para armazenamento externo, cache gerenciado ou fila. Assim você evita depender de memória local que some quando a plataforma encolhe a frota.

Na prática, o que eu vejo com mais frequência é time tratando a função como um servidor miniatura e enchendo o handler de regras de domínio inteiras. O caminho mais saudável costuma ser funções curtas, contratos claros de evento e persistência fora do processo, mesmo quando isso exige mais componentes no desenho.

Em quais cenários a arquitetura serverless costuma ajudar?#

Ela costuma ajudar quando a carga varia, quando o trabalho é orientado a eventos e quando o custo de manter capacidade ociosa dói mais do que a complexidade de orquestrar funções. A documentação de arquiteturas serverless do Google for Developers descreve o modelo como adequado a microsserviços, processamento em tempo quase real, aplicações web com tráfego irregular e processamento de eventos, com a ressalva de avaliar latência, depuração e dependência do provedor no seu caso.

Um exemplo concreto ajuda a ancorar a decisão. Uma loja recebe 200 pedidos em dias comuns e 8 mil no horário de uma promoção. Com máquinas fixas, ou você sobra capacidade a maior parte do mês, ou falta capacidade no pico. Com funções acionadas por fila, a plataforma adiciona instâncias conforme a fila cresce e reduz depois. O ganho aparece na fatura e no tempo de resposta sob pressão, porém o desenho precisa aceitar retries, idempotência e mensagens duplicadas.

Quando outra opção costuma servir melhor#

Há casos em que serverless atrapalha mais do que ajuda. Processos longos que ultrapassam o tempo máximo de execução do plano escolhido pedem worker dedicado, orquestração com etapas ou outro modelo de hospedagem. Cargas estáveis e altas o tempo todo podem ficar mais previsíveis e até mais baratas em plano dedicado ou em contêineres com capacidade reservada. Além disso, requisitos rígidos de latência na primeira resposta sofrem com o cold start se a função ficar ociosa.

Também entra na conta a experiência da equipe. Depurar cadeias de eventos, correlacionar logs e reproduzir falhas intermitentes exige disciplina de rastreamento. Se o time ainda não tem observabilidade mínima, a arquitetura serverless amplia a superfície de “não sei onde quebrou” sem entregar o benefício esperado.

Se fosse comigo, eu começaria por um fluxo limitado, com métricas de duração, erros e custo por milhão de execuções, antes de migrar o núcleo transacional. Assim a decisão deixa de ser moda e vira evidência do próprio tráfego.

Serverless, IaaS e containers: o que muda na sua responsabilidade?#

Muda o quanto da pilha você administra e o quanto herda do provedor. O NIST SP 800-145 define computação em nuvem com elasticidade rápida e serviço medido, e separa IaaS, PaaS e SaaS pelo grau de controle do consumidor. Serverless de funções costuma se aproximar de uma plataforma gerenciada em que você controla o código e parte da configuração, não a máquina. O glossário da MDN sobre cloud computing reforça a mesma hierarquia de controle entre IaaS, PaaS e SaaS.

Em IaaS você escolhe imagem, rede, patch e escala, e por isso carrega mais operação. Em containers você empacota runtime e dependências com mais controle de portabilidade, porém ainda precisa de orquestração, política de rede e atualização de imagem base. Em FaaS o provedor abstrai boa parte disso, e o preço dessa abstração é menor controle fino de ambiente e maior acoplamento a gatilhos e limites da plataforma.

Como encaixar API, CDN e nuvem no mesmo desenho#

Muitos sistemas misturam camadas. Uma API pública pode autenticar na borda, servir estáticos por CDN e despachar trabalho pesado para uma função. A computação em nuvem continua sendo o guarda-chuva. Serverless é um jeito de consumir compute dentro desse guarda-chuva, não um substituto de toda a arquitetura.

A armadilha clássica é achar que migrar um monólito inteiro para funções resolve organização e dívida técnica. Sem fronteiras de domínio, você só espalha o monólito em dezenas de deploys. Por outro lado, extrair um ponto de integração barulhento, como geração de PDF ou notificação, costuma ser um primeiro passo com risco contido.

O erro que mais custa caro aqui é escolher o modelo pelo catálogo de marketing e só depois descobrir requisitos de rede privada, tempo de execução ou compliance. O critério útil é mapear o que você precisa controlar de fato e aceitar o restante como serviço gerenciado com limites explícitos.

Quanto custa e o que é cold start na prática?#

O custo típico combina execuções, memória provisionada pelo tempo ativo e, em alguns planos, instâncias sempre prontas. Na documentação de hospedagem e escala do Azure Functions, o modelo sob demanda cobra enquanto o código executa e pode escalar a partir de zero, enquanto instâncias always-ready reduzem atraso e passam a ter cobrança de baseline. Ou seja, a economia máxima e a latência mínima raramente andam juntas sem trade-off.

Cold start é a latência extra da primeira invocação depois que a plataforma reduziu as instâncias a zero ou criou uma nova. A página de escala orientada a eventos do Azure Functions descreve esse atraso e nota que dependências da aplicação influenciam o tempo, com impacto maior em operações síncronas como HTTP. Para o leitor, isso significa que um webhook ocasional pode demorar mais na primeira chamada do que nas seguintes, mesmo com código idêntico.

Como estimar sem se iludir com a fatura zero#

Faça a conta com premissas explícitas. Suponha 1 milhão de execuções no mês, 256 MB de memória e 200 ms de duração média. O custo de compute segue a tabela do provedor na data da consulta, e ainda entram transferência de dados, filas, armazenamento e observabilidade. Se a função dispara outras chamadas em cascata, a conta cresce fora do item “funções”. Assim, o número isolado de GB-segundo nunca conta a história completa.

Há também o efeito inverso. Funções muito chatas, com execuções curtas e frequentes, podem gerar muita cobrança por contagem de invocações. Nesses casos, agregar trabalho em lotes ou usar um worker contínuo pode sair mais barato, mesmo perdendo o charme do scale-to-zero. Além disso, planos com instâncias pré-aquecidas compram previsibilidade de latência com dinheiro e complexidade de capacidade mínima.

Muita gente acha que serverless elimina custo fixo, e quase sempre está enganada, porque monitoramento, rede, armazenamento e instâncias aquecidas reintroduzem piso de gasto. O hábito saudável é orçar o fluxo ponta a ponta e revisar a fatura com o mesmo rigor usado no código.

Quais cuidados de segurança a função como serviço exige?#

Ela reduz a superfície de patch de sistema operacional, porém concentra risco em identidade, entrada de eventos, segredos e dependências. O guia Serverless FaaS Security da OWASP lista ameaças centrais como funções com permissão excessiva, eventos não validados, vazamento de dados no cold start ou em armazenamento temporário, encadeamento abusivo entre funções e segredos embutidos na configuração.

O modelo de responsabilidade compartilhada continua valendo. O provedor cuida da infraestrutura física, do hipervisor e, em runtimes gerenciados, de parte das atualizações da plataforma. Você cuida do código, das bibliotecas, de quem pode invocar a função, do que a função pode acessar e de como logs e alertas revelam abuso. Por isso uma política com ação e recurso em curinga transforma um bug local em incidente amplo.

Controles mínimos antes de abrir a função para o mundo#

Comece por uma identidade por função, com o menor conjunto de ações necessárias. Valide todo payload de evento, não só o corpo HTTP, porque nome de arquivo em armazenamento ou mensagem de fila também carrega entrada hostil. Busque segredos em cofre em tempo de execução, em vez de gravá-los em variável de ambiente permanente. Além disso, limite saída de rede quando a função não precisa falar com a internet aberta.

Observabilidade entra como controle, não como enfeite. Sem correlação de invocação, você não distingue pico legítimo de abuso. Em equipes que já praticam DevOps, serverless pede o mesmo rigor de revisão de política e de dependência que qualquer outro serviço, só que com deploys mais granulares e mais papéis de acesso para auditar.

Quando reviso um desenho novo, eu priorizo inventário de gatilhos e papéis antes de discutir framework. Sem esse mapa, a equipe acelera o deploy e herda uma porta lateral barata de explorar.

Termos relacionados#

• computação em nuvem é o modelo amplo de recursos sob demanda no qual o serverless costuma rodar.
• IaaS entrega máquinas e rede virtuais com mais controle e mais operação do que o FaaS.
• containerização empacota runtime e app com portabilidade maior e orquestração própria.
• microsserviços organizam capacidades de negócio que às vezes são implementadas com funções.
• API é a porta de entrada HTTP que frequentemente aciona handlers serverless.
• latência é a métrica que o cold start pressiona em fluxos síncronos.

Perguntas frequentes sobre computação serverless#

As dúvidas abaixo cobrem definição curta, diferença para servidores tradicionais, preço, cold start e segurança. Use-as como atalho depois de ler o guia, ou como consulta rápida quando a decisão de arquitetura precisar de um critério objetivo sem abrir mão dos riscos.

O que é computação serverless em uma frase útil?#

É executar código sob demanda em infraestrutura gerenciada pelo provedor, em geral cobrando pela execução, enquanto a equipe permanece responsável por aplicação, dados, identidade e qualidade do evento. A frase ajuda no resumo, porém a decisão real depende de latência, duração do trabalho e previsibilidade de custo.

Serverless significa que não existem servidores?#

Não. Os servidores existem no provedor. O que muda é quem os administra no dia a dia. Você troca patch de máquina por disciplina de eventos, permissões e limites da plataforma.

Função como serviço e arquitetura serverless são a mesma coisa?#

Nem sempre. FaaS é o padrão mais comum de compute serverless, porém o rótulo arquitetura serverless também aparece em bancos, filas e fluxos gerenciados. Por isso convém nomear o serviço concreto, não só o slogan.

Cold start sempre inviabiliza uso em API pública?#

Não. Inviabiliza quando a primeira resposta precisa ser estável e a função fica ociosa com frequência. Em fluxos assíncronos o atraso costuma ser aceitável, e planos com instâncias aquecidas mitigam o problema com custo adicional.

Serverless fica sempre mais barato que máquina ligada?#

Não. Fica mais barato quando há ociosidade relevante e execuções bem dimensionadas. Em carga alta e constante, ou com muitas invocações mínimas, a conta pode superar a de capacidade reservada. Meça o fluxo completo antes de generalizar.

Quem cuida da segurança no FaaS?#

A responsabilidade se divide, porque o provedor endurece a base enquanto você endurece código, dependências, gatilhos e papéis. Sem validação de evento e sem menor privilégio, a superfície de ataque só muda de lugar.

Conclusão#

Para a maioria dos times que enfrenta picos irregulares e tarefas curtas acionadas por evento, computação serverless é um caminho sólido desde que o desenho aceite cold start, limites de duração e operação centrada em identidade. O benefício de escala automática e cobrança sob demanda só se sustenta com medição e com funções pequenas o bastante para auditar.

A resposta muda quando o trabalho é longo, a latência da primeira chamada é crítica sem orçamento para instâncias aquecidas, ou a equipe ainda não consegue observar cadeias de eventos. Nesses casos, IaaS, containers ou um serviço dedicado tendem a reduzir surpresa, mesmo com mais operação aparente.

O primeiro passo útil é escolher um fluxo real, escrever o handler com permissão mínima, definir orçamento e SLI de latência, e só então decidir se o FaaS escala para o restante do sistema. Sem esse piloto instrumentado, a conversa continua no slogan e não no resultado operacional.

Este verbete sobre computação serverless tem caráter informativo e educacional. Não é consultoria de arquitetura, segurança ou contratação de nuvem para o seu caso. Plataformas, preços, limites de execução e controles mudam com frequência. Confira a documentação oficial na data da sua decisão e, em sistemas com dado pessoal ou requisito regulatório, envolva profissionais responsáveis pela conformidade e pela segurança da informação.