O que é serverless? Computação serverless explicada de forma simples

Serverless é uma forma de rodar código sem que você mesmo configure ou gerencie servidores. Você entrega o seu código a um provedor de nuvem, e ele roda esse código apenas quando algo o dispara, como uma requisição web, um arquivo enviado ou uma notificação de pagamento, e depois para. Normalmente você paga pelo tempo em que o seu código está de fato rodando, e não por uma máquina ociosa.

Por que serverless importa quando você cria com IA

Ao criar um app com IA e olhar opções de hospedagem ou código, você vai encontrar “funções serverless”, “edge functions” ou “cloud functions”. Muitas plataformas de hospedagem oferecem esses recursos, e alguns criadores com IA publicam backends dessa forma. Entender o modelo ajuda com três perguntas práticas:

• Custo. O seu app vai custar dinheiro enquanto ninguém o usa?
• Velocidade. Por que a primeira requisição depois de um período sem uso é mais lenta?
• Limites. Por que uma tarefa longa, como gerar um relatório grande ou processar um vídeo, excedeu o tempo limite?

Também ajuda saber o que serverless não é: não é a ausência de backend. Você continua tendo código do lado do servidor; só que outra pessoa roda as máquinas. Para o básico, veja o que é um servidor.

Uma analogia do dia a dia

Um servidor tradicional é como ter um carro próprio. Ele está sempre ali, pronto para sair na hora, mas você paga por ele — seguro, estacionamento, manutenção — quer você dirija ou não.

Serverless é como chamar um táxi. Você paga só pelas viagens que faz, e se cem pessoas precisam de carona ao mesmo tempo, cem táxis aparecem. Mas pode haver uma curta espera até o carro chegar (um cold start), cada viagem tem uma duração máxima, e o motorista não se lembra de você da corrida anterior (as funções são sem estado, ou stateless).

Como funcionam as funções serverless

Na forma mais comum, chamada functions as a service (funções como serviço):

1. Você escreve uma função: um pequeno trecho de código que trata um tipo de evento, como “tratar um POST em /api/bookings”.
2. Você a publica. O provedor armazena a função e a conecta a um gatilho: uma URL, um agendamento, um novo arquivo no armazenamento, uma mensagem em uma fila.
3. Um evento chega. O provedor inicia uma cópia da sua função (ou reaproveita uma já aquecida), executa e devolve o resultado.
4. Ela escala sozinha. Se mil requisições chegam ao mesmo tempo, o provedor roda muitas cópias em paralelo, até os limites da sua conta.
5. Ela fica ociosa. Quando o tráfego para, as cópias são desligadas. Sem nada rodando, você não paga computação.

Uma pequena função serverless em JavaScript pode ter esta aparência:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

Não há código para iniciar um servidor, abrir uma porta ou manter um processo rodando. A plataforma cuida de tudo isso.

“Serverless” também é usado de forma mais livre para outros serviços gerenciados que escalam automaticamente e cobram pelo uso, como bancos de dados serverless, que pausam quando ficam ociosos.

Termos principais

Um exemplo prático: um pequeno site de agendamento

O site de agendamento de um estúdio de yoga recebe uma explosão de acessos todo domingo à noite, quando a nova grade de horários é publicada, e muito pouco no resto da semana.

• Com um servidor sempre ligado, o estúdio paga por uma máquina 24 horas por dia, dimensionada para o pico de domingo à noite, e que fica quase ociosa no resto do tempo.
• Com funções serverless, GET /api/classes e POST /api/bookings são funções. A correria de domingo cria muitas cópias automaticamente; em uma terça-feira de manhã tranquila, quase nada roda e a conta fica perto de zero.

As compensações também aparecem. A primeira pessoa a abrir o site na terça-feira de manhã pode esperar um pouco a mais por causa de um cold start. O banco de dados precisa lidar com muitas conexões curtas vindas de muitas cópias de funções, o que pode exigir um pool de conexões. E se o estúdio quiser depois uma tarefa para “gerar o PDF anual de presença de todos”, ela pode exceder o limite de tempo da função e precisar rodar em outro lugar.

Quando serverless faz sentido, e quando não

Equívocos comuns

• “Serverless significa não ter backend.” Significa não ter servidores para gerenciar. Você ainda escreve e protege código de backend.
• “Serverless é sempre mais barato.” É barato em volume baixo, mas a cobrança por requisição pode somar muito em volume alto e constante.
• “Serverless escala infinitamente.” As plataformas têm limites de concorrência, e o seu banco de dados pode virar o gargalo muito antes das funções.
• “Arquivos salvos em uma função vão estar lá na próxima vez.” O armazenamento local é temporário. Use um banco de dados ou armazenamento de arquivos.
• “Escalar até zero é o mesmo que serverless.” Estão relacionados, mas não são idênticos. Algumas plataformas rodam o seu app como um servidor comum que entra em repouso quando ocioso e acorda na próxima requisição: economia e atraso na primeira requisição parecidos, mas sem os limites de tempo por requisição típicos das funções.

O que pedir ao seu criador de apps com IA

• “Este backend vai rodar como funções serverless ou como um servidor sempre ligado ou que entra em repouso? O que isso significa para o custo?”
• “Alguma tarefa provavelmente vai demorar mais que o limite de tempo da plataforma? Se sim, como devemos tratá-la?”
• “Guarde tudo o que precisa persistir no banco de dados ou no armazenamento de arquivos, e não na memória ou em arquivos locais.”
• “Como as conexões com o banco de dados devem ser gerenciadas se muitas cópias rodarem ao mesmo tempo?”
• “Qual é o atraso na primeira requisição depois de o app ficar ocioso?”

Como o Mythex hospeda apps

O Mythex não descreve a sua hospedagem como funções serverless. Quando você publica, o seu app roda como um app web ou container comum, gerenciado pelo Mythex para você; não há hospedagem para configurar. É scale-to-zero: os apps publicados e os seus bancos de dados entram em repouso quando ociosos e acordam na próxima visita, um app em repouso não gasta nada com computação, e máquinas extras só são iniciadas quando o tráfego está alto (o Pro permite até 3 por serviço). O banco Postgres anexado também entra em repouso após 5 minutos ociosos e é cobrado pelo tempo em que ficou acordado. Assim, você tem grande parte do benefício de “pagar pelo que usa”, com o mesmo tipo de atraso na primeira requisição depois de um período sem uso. Veja limites de hospedagem na documentação e nossos guias sobre hospedagem web e como reduzir custos de hospedagem.

Perguntas