Serverless e serverful: 5 critérios para escolher

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, um Amazon 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, 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, 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, existem as Cloud Functions do Google Cloud, as Azure 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 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 é 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, 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, 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, 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 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, 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