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

Serverless é uma forma de correr código em que não configuras nem geres servidores. Entregas o teu código a um fornecedor de cloud, que o corre apenas quando algo o dispara — um pedido web, um ficheiro carregado, uma notificação de pagamento — e depois para. Normalmente pagas pelo tempo em que o teu código efetivamente corre, e não por uma máquina parada à espera.

Porque é que a serverless importa quando crias com IA

Quando crias uma app com IA e olhas para opções de alojamento ou para código, vais encontrar «funções serverless», «edge functions» ou «cloud functions». Muitas plataformas de alojamento oferecem-nas, e alguns criadores com IA publicam backends desta forma. Perceber o modelo ajuda-te com três questões práticas:

• Custo. A tua app vai custar dinheiro enquanto ninguém a usa?
• Velocidade. Porque é que o primeiro pedido depois de um período calmo é mais lento?
• Limites. Porque é que uma tarefa longa — gerar um relatório grande, processar um vídeo — excedeu o tempo limite?

Ajuda também saber o que a serverless não é: não é a ausência de backend. Continuas a ter código do lado do servidor; só que outra pessoa gere as máquinas. Para as bases, vê o que é um servidor.

Uma analogia do dia a dia

Um servidor tradicional é como ter um carro. Está sempre ali, pronto a andar de imediato, mas pagas por ele — seguro, estacionamento, manutenção — quer o uses, quer não.

A serverless é como chamar um táxi. Pagas apenas as viagens que fazes, e se cem pessoas precisarem de boleia ao mesmo tempo, chegam cem táxis. Mas pode haver uma pequena espera até o carro chegar (um cold start), cada viagem tem um comprimento máximo, e o motorista não se lembra de ti da última vez (as funções são sem estado, ou stateless).

Como funcionam as funções serverless

Na forma mais comum, chamada functions as a service:

1. Escreves uma função — um pequeno pedaço de código que trata um tipo de evento, como «tratar um POST para /api/bookings».
2. Fazes o deploy. O fornecedor guarda-a e liga-a a um gatilho: um URL, um agendamento, um novo ficheiro no armazenamento, uma mensagem numa fila.
3. Chega um evento. O fornecedor arranca uma cópia da tua função (ou reutiliza uma já quente), corre-a e devolve o resultado.
4. Escala sozinha. Se chegarem mil pedidos ao mesmo tempo, o fornecedor corre muitas cópias em paralelo, até aos limites da tua conta.
5. Fica inativa. Quando o tráfego para, as cópias são desligadas. Sem nada a correr, não pagas computação.

Uma função serverless minúscula em JavaScript pode ter este aspeto:

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

Não há código para arrancar um servidor, abrir uma porta ou manter um processo a correr. A plataforma trata de tudo isso.

«Serverless» também é usado de forma mais solta para outros serviços geridos que escalam automaticamente e cobram por utilização — por exemplo, as bases de dados serverless, que entram em pausa quando estão inativas.

Termos-chave

Um exemplo prático: um pequeno site de marcações

O site de marcações de um estúdio de yoga recebe uma enxurrada de visitas todos os domingos ao fim da tarde, quando sobe o novo horário, e muito pouco no resto da semana.

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

Os compromissos também aparecem. A primeira pessoa a abrir o site na terça-feira de manhã pode esperar um pouco mais por causa de um arranque a frio. A base de dados tem de lidar com muitas ligações de curta duração vindas de muitas cópias das funções, o que pode exigir um pool de ligações. E se o estúdio quiser depois uma tarefa «gerar o PDF anual de presenças de todos», pode exceder o tempo limite da função e ter de correr noutro sítio.

Quando a serverless encaixa — e quando não

Erros comuns e ideias erradas

• «Serverless quer dizer que não há backend.» Quer dizer que não há servidores para gerir. Continuas a escrever e a proteger código de backend.
• «Serverless é sempre mais barata.» É barata com pouco volume, mas a cobrança por pedido pode somar-se com volume alto e constante.
• «Serverless escala infinitamente.» As plataformas têm limites de concorrência, e a tua base de dados pode tornar-se o estrangulamento muito antes das funções.
• «Os ficheiros guardados numa função estarão lá da próxima vez.» O armazenamento local é temporário. Usa uma base de dados ou armazenamento de ficheiros.
• «Escalar até zero é o mesmo que serverless.» Relacionados, mas não idênticos. Algumas plataformas correm a tua app como um servidor normal que adormece quando está inativo e acorda no pedido seguinte — poupanças semelhantes e um atraso semelhante no primeiro pedido, mas sem os limites de tempo por pedido das funções.

O que pedir ao teu criador de apps com IA

• «Este backend vai correr como funções serverless, ou como um servidor sempre ligado ou que adormece? O que isso significa para o custo?»
• «Alguma tarefa vai provavelmente demorar mais do que o limite de tempo da plataforma? Se sim, como a tratamos?»
• «Guarda tudo o que tem de persistir na base de dados ou no armazenamento de ficheiros, não na memória ou em ficheiros locais.»
• «Como devem ser geridas as ligações à base de dados se muitas cópias correrem ao mesmo tempo?»
• «Qual é o atraso no primeiro pedido depois de a app ter estado inativa?»

Como a Mythex aloja as apps

A Mythex não descreve o seu alojamento como funções serverless. Quando publicas, a tua app corre como uma aplicação web normal ou um contentor que a Mythex gere por ti — não há alojamento para configurar. É scale-to-zero: as apps publicadas e as respetivas bases de dados adormecem quando estão inativas e acordam na visita seguinte; uma app a dormir não gasta nada em computação, e máquinas extra só arrancam quando o tráfego é intenso (o Pro permite até 3 por serviço). A base de dados Postgres associada também adormece após 5 minutos inativos e é faturada pelo tempo em que esteve acordada. Assim, obtés grande parte do benefício de «pagar pelo que usas», com o mesmo tipo de atraso no primeiro pedido após um período calmo. Vê limites de alojamento na documentação e os nossos guias sobre o que é alojamento web e como reduzir os custos de alojamento.

Perguntas