# Serverless e serverful: 5 critérios para escolher

> Published 2026-09-28T01:08:13.175Z on https://www.crazystack.com.br/pt/p/serverless-e-serverful-5-criterios-para-escolher/
> Source video: https://www.youtube.com/watch?v=g9N1ki7v_aE

A escolha entre serverless e serverful depende de tráfego, custo e criticidade, não da linguagem do seu backend. Serverful aluga uma máquina dedicada que roda 24 horas por dia; serverless executa blocos de código só sob demanda, cobrando por invocação. Saber quando usar cada arquitetura evita contas de nuvem surpreendentes e gargalos de performance.

## Serverless e serverful: qual é a diferença?

A diferença entre serverless e serverful está em quem controla o servidor e quando ele roda. No modelo serverful, você aluga uma máquina dedicada — uma VPS da [Hostinger](https://www.hostinger.com.br), um [Amazon EC2](https://aws.amazon.com/ec2/) ou uma VM na Oracle — que fica disponível 24 horas por dia. No modelo serverless, você envia apenas um bloco de código, e o provedor provisiona infraestrutura somente quando alguém aciona esse código.

O nome entrega a lógica: serverless significa "sem servidor" para você, porque o gerenciamento do sistema operacional, memória, disco e escalonamento fica com o provedor. Serverful é o "servidor completo", sob seu controle. A cobrança também muda: no serverful, você paga pelo uptime, mesmo sem tráfego; no serverless, paga por demanda e não gasta nada se a função nunca for invocada.

| Dimensão | Serverful | Serverless |
| --- | --- | --- |
| Unidade de deploy | Aplicação completa | Função isolada |
| Disponibilidade | 24/7, sempre em memória | Só executa sob demanda |
| Cobrança | Uptime fixo | Por invocação e tempo de execução |
| Controle de infraestrutura | SO, CPU, RAM e disco escolhidos por você | Só o runtime da linguagem |
| Cold start | Zero | Existe, varia por runtime |
| Escalonamento | Você configura | Gerenciado pelo provedor |

## Como funciona o modelo serverful na prática

No modelo serverful, você provisiona uma máquina virtual e coloca sua aplicação para rodar dentro dela. Ao criar uma instância no [Amazon EC2](https://aws.amazon.com/ec2/), você escolhe o sistema operacional, a quantidade de núcleos de CPU e a memória. Depois, conecta via SSH, copia o build da aplicação e executa o comando de start — um `npm run start` em Node ou o boot de uma aplicação Spring em Java.

Com a aplicação carregada em memória, a máquina responde requisições o tempo todo, seja pelo IP direto ou por um domínio configurado. Isso traz previsibilidade: o tempo de resposta é estável e você pode manter cache em memória, além de persistir o connection pool com o banco de dados, o que otimiza cada requisição subsequente.

O contraponto é o custo fixo. Mesmo sem uma única requisição, a fatura continua chegando. E, para tarefas pequenas, como um endpoint que encurta URLs, alocar uma VPS inteira é usar uma bazuca para matar uma mosca. O canal Dev Doido do canal do youtube abordouesse tema em uma live longa de live code, mostrando os dois modelos na AWS na prática.

## Como funciona o serverless e o que é cold start

No serverless, você não faz deploy de uma aplicação inteira, apenas de uma função. No [AWS Lambda](https://aws.amazon.com/lambda/), por exemplo, você escolhe somente o runtime — Node 20, Java 17, .NET — e o provedor cuida de todo o resto. O serviço gera uma URL de função e, a cada chamada HTTP, provisiona a infraestrutura necessária, executa o handler e retorna a resposta.

Como não existe servidor dedicado, a primeira invocação após um período de inatividade sofre o cold start, o "início frio": o provedor precisa subir infraestrutura, instalar o runtime e só então rodar seu código. Em runtimes leves como Node, isso costuma ficar na casa de dezenas a centenas de milissegundos, quase imperceptível. Em runtimes como a JVM, o tempo sobe, porque subir uma JVM é mais pesado.

Além do [AWS Lambda](https://aws.amazon.com/lambda/), existem as [Cloud Functions do Google Cloud](https://cloud.google.com/functions), as [Azure Functions](https://azure.microsoft.com/products/functions) da Microsoft e as funções de provedores como Vercel e Netlify. O conceito é o mesmo; o que muda é o provedor por trás e quais serviços dele podem funcionar como gatilhos de execução.

## Prós e contras de cada arquitetura

Cada modelo brilha em um cenário e sofre no outro. Serverful oferece estabilidade, cache em memória e conexões persistentes com o banco, mas cobra mesmo ocioso e desacomplada de pouco serve quando você precisa escalar apenas uma parte do sistema. Serverless zera o custo base e escala automaticamente, mas herda o cold start e abre uma nova conexão com o banco a cada invocação.

Esse detalhe do banco de dados merece atenção. Uma função serverless que faz muita leitura e escrita cria conexões novas a cada execução, o que pode estourar o limite de conexões do banco e degradar a performance. Se sua função depende intensamente do banco, talvez o serverful seja a escolha mais sensata.

## Quando usar serverless ou serverful: casos de uso reais

Webhooks são o caso clássico de serverless. Imagine integrar com a API do Google Calendar para receber um evento a cada reunião agendada e disparar um e-mail ao gestor. Criar um servidor dedicado para isso é exagero; uma função serverless acionada pelo webhook resolve com custo quase zero, já que as execuções são curtas e pouco frequentes.

O outro extremo também justifica serverless: alto volume de requisições rápidas. Se 500 mil entregadores enviam coordenadas a cada segundo, você precisa escalar apenas esse endpoint, sem arrastar o resto da aplicação. Pagar por tempo de execução mínimo em requisições do tipo ping é mais eficiente que escalar o monolito inteiro. Já se a requisição demora muito ou exige conexão constante com o banco, o serverful tende a vencer.

Outro caso comum é processamento de arquivos. Toda vez que um restaurante sobe uma imagem de produto, uma função serverless pode comprimi-la e salvar a versão otimizada. Isso desacopla uma operação pesada de memória da aplicação principal, evitando que um bug no algoritmo de compressão derrube o backend de pedidos.

## Edge functions: serverless com uma diferença importante

Edge functions são funções serverless deployadas em CDNs, ou seja, executam no ponto de presença mais próximo do usuário, reduzindo latência. O [Supabase](https://supabase.com/docs/guides/functions) oferece edge functions com runtime Deno sobre a engine V8, que rodam JavaScript e TypeScript. Lambda e Cloud Functions, por outro lado, executam em regiões fixas do data center, como a us-east-1 da AWS em North Virginia.

Essa diferença de arquitetura traz limitações. Segundo o que a live técnica explorou com apoio de IA, edge functions têm timeout menor que Lambdas — o limite de execução do [AWS Lambda](https://aws.amazon.com/lambda/) é de até 15 minutos, enquanto edge functions costumam rodar por poucos minutos —, não se conectam a uma VPC privada, não processam arquivos pesados como PDFs e suportam poucas dependências nativas. A acionamento também muda: só via HTTP ou SDK, sem gatilhos de serviços da nuvem.

O melhor cenário para edge functions é lógica leve na borda, como validar um token de autenticação antes de a requisição seguir para o servidor. Retornar um erro de token no ponto mais próximo do usuário economiza ida e volta até a região da nuvem. Para tarefas que exigem rede privada, conexão direta com banco ou execução longa, a Lambda regional continua sendo a escolha adequada. Cloud Functions do [Firebase](https://firebase.google.com/docs/functions), por exemplo, são functions regionais, não edge.

## Case iFood: serverless orientado a eventos em produção

Um caso real publicado no blog técnico da AWS mostra como arquitetura serverless e orientada a eventos funcionam juntas. A plataforma financeira interna do iFood, chamada Digital by You, era um monolito com cerca de 100 mil usuários: componentes fortemente acoplados elevavam a taxa de falhas e o mean time to recover, porque um endpoint com problema derrubava todos os outros.

Com apoio do time AWS Professional Services e do método working backwards, o iFood identificou três domínios de negócio e decompôs o monolito em três microsserviços, que se comunicam pelo [Amazon EventBridge](https://aws.amazon.com/eventbridge/), um barramento de eventos serverless. Em vez de um serviço chamar outro via HTTP, um emite um evento e o outro consome quando estiver disponível. Se o consumidor cair, o evento não se perde e pode ser reprocessado, com dead-letter queues e políticas de retry.

Segundo o case, o tempo de desenvolvimento de novas funcionalidades caiu de um mês para uma semana após a decomposição em microsserviços por domínio. Times ganharam autonomia para deployar de forma independente, e falhas em um serviço deixaram de impactar os demais. O artigo completo está no [AWS Blog](https://aws.amazon.com/blogs/), que vale acompanhar para ver decisões de arquitetura documentadas em produção.

## Por que algumas empresas voltaram do serverless ao serverful

Houve uma onda de migrações reversas, do serverless de volta ao serverful, e a maioria dos relatos aponta custo como motivo. Durante o hype, muitos times quebraram aplicações inteiras em endpoints e jogaram cada um numa função, sem um caso de uso que justificasse a quebra. Um clique no frontend disparava cinco requisições, e cada invocação virava uma cobrança separada; em um monolito serverful, essas cinco chamadas caberiam dentro do custo fixo e da largura de banda já pagos.

Estratégias de polling agravam o problema: um frontend que consulta o banco a cada segundo transforma milhares de "pings" em milhares de execuções cobradas, cada uma abrindo uma conexão nova com o banco de dados. Para tráfego constante e previsível, uma VPS ou um EC2 dedicado sai mais barato. Serverless não é bala de prata; serve para funções específicas, curtas e esporádicas, não para substituir todo backend por hype.

A lição prática: analise o padrão de tráfego antes de decidir. Projetos com poucos acessos, como o site de uma barbearia com 200 clientes em serverless, atendem bem e custam quase nada. Sistemas críticos que transacionam dados sensíveis pedem rede privada, então provedores de nuvem com VPC fazem mais sentido. MVPs simples vivem bem na [Vercel](https://vercel.com) ou numa VPS barata.

## Perguntas frequentes sobre serverless e serverful

- **Serverless significa que não existe servidor?**

Existe servidor, sim, mas ele não é seu. O provedor gerencia sistema operacional, hardware e escalonamento, e você só envia o código da função. Por isso o nome é "sem servidor para você", não "sem servidor de verdade".

- **Cold start é um problema grave em serverless?**

Depende do runtime. Em Node, o início frio costuma ficar em torno de 100 ms e é quase imperceptível. Em runtimes como a JVM, sobe a JVM demora mais, então o impacto é maior em funções Java.

- **Posso usar função serverless que acessa banco de dados?**

Sim, mas com cuidado. Cada invocação abre uma conexão nova, o que pode estourar o limite de conexões do banco e deixar as consultas lentas em alto volume. Para funções com muita leitura e escrita, considere um servidor dedicado com connection pool persistente.

- **Edge functions substituem a AWS Lambda?**

Não. Edge functions são mais rápidas na borda, ideais para autenticação e lógica leve, mas têm timeout menor, não se conectam a VPC e não processam arquivos pesados. Lambda aceita até 15 minutos de execução e conexão com rede privada.

## Transforme lives técnicas em artigos

Essa comparação entre serverless e serverful nasceu de uma live de quase duas horas, cheia de demonstrações, cases e perguntas do chat — conteúdo valioso que ficaria preso em um vídeo. Se você também ensina em lives, entrevistas ou tutoriais no YouTube, existe uma forma simples de dar vida escrita a esse material.

Com o [Skala Blog](https://skalablog.com), você cola a URL do vídeo, gera a transcrição e transforma tudo em um artigo estruturado, pronto para revisão e publicação. Assim, o conhecimento que já gravou passa a alcançar quem pesquisa o assunto no Google.

[Source video](https://www.youtube.com/watch?v=g9N1ki7v_aE)