Revivi a época em que eu não conseguia entender serverless e decidi perguntar tudo o que pude.

O servidor sumiu? A verdadeira identidade do mago

🧙‍♂️ Doutor — 🐣, hoje vamos aprender sobre serverless. Só de ouvir o nome parece uma “magia que faz o servidor sumir”, mas a verdade é mais discreta e ainda assim profunda.

🐣 Estudante — Servidor nenhum? Não me diga que o senhor, como se fosse o Harry Potter, lançou “Servidor, desapareça!” e ele sumiu mesmo?

🧙‍♂️ Doutor — Hahaha, essa ideia passa pela cabeça de nove entre dez pessoas. Mas não é que “não existam servidores”. Lá no fundo da nuvem eles trabalham duro. Apenas não precisamos ficar conscientes da existência deles.

🐣 Estudante — Então é propaganda enganosa. Tipo escrever “legumes orgânicos” e despejar agrotóxico escondido.

🧙‍♂️ Doutor — Comparação bem torta, mas acerta o ponto. O “less” em “serverless” significa “menos gestão”. Antes criávamos nossos próprios servidores, instalávamos o sistema, lidávamos com incidentes — era como cuidar de um hamster. Em serverless o provedor de nuvem assume tudo isso.

🐣 Estudante — Quando o hamster morre a gente chora, mas quando o servidor cai os clientes brigam, então é pior ainda.

🧙‍♂️ Doutor — E diferente do hamster, o servidor ainda te acorda às três da manhã com um “o banco de dados não responde”.

📌 Nota: Conceitos básicos de serverless Serverless não quer dizer “não existem servidores”, mas sim que a gestão dos servidores é delegada ao provedor de nuvem.

  • Modelo tradicional: comprar, instalar e administrar o servidor por conta própria
  • Serverless: o provedor gerencia toda a infraestrutura e você se concentra apenas no código

Como funciona o serverless: ninjas que só aparecem quando chamados

🐣 Estudante — Parece difícil de usar. Em que ele é diferente de um servidor comum?

🧙‍♂️ Doutor — Pois é. Em serverless o recurso ‘aparece’ apenas quando é chamado, executa o processamento e desaparece. Por isso os aplicativos precisam ser projetados como ‘velocistas’. Maratonistas não servem.

🐣 Estudante — Então alguém grita ‘calcule agora!’ e ele surge, e quando dizem ’terminou’ ele desaparece?

🧙‍♂️ Doutor — Exatamente! É como um ninja que só aparece quando é convocado. Como ele fica escondido na nuvem, você não paga aluguel quando não está fazendo nada.

🐣 Estudante — Mas ninjas aparecem de lugares diferentes. Como fica o endereço IP?

🧙‍♂️ Doutor — Boa pergunta! Eles não têm endereço fixo. Como o servidor muda a cada vez, a nuvem coloca uma API Gateway como ‘porteiro da vila dos ninjas’ para distribuir as requisições para o ninja certo.

🐣 Estudante — Entendi. Mas se o ninja muda toda hora, significa que ele não lembra do que aconteceu antes?

🧙‍♂️ Doutor — Isso mesmo. Por isso a arquitetura precisa ser stateless. Nada de conversas ‘continuando de ontem’. Cada execução começa como se fosse a primeira vez, memória de peixinho dourado.

🐣 Estudante — Não é inconveniente? Como ficam login e sessão?

🧙‍♂️ Doutor — Guardamos o estado fora. Banco de dados, Redis, essas coisas. O ninja não tem memória própria, mas deposita os pergaminhos importantes no ‘depósito de rolos’.

📌 Nota: Por que o design stateless é crucial Funções serverless iniciam em contêineres novos a cada execução, logo o estado local (variáveis, arquivos, sessão) não é preservado.

  • Armazenamento de estado: bancos externos, Redis, S3 etc.
  • Sessões: tokens JWT ou armazenamento externo
  • Arquivos: tudo que não for temporário precisa ir para um storage externo

Diferenças em relação a servidores tradicionais: bichinho de estimação vs. ninja

🐣 Estudante — Consegue dar uma ideia concreta?

🧙‍♂️ Doutor — Pensa em um fluxo de ‘gerar miniaturas quando uma imagem é enviada’. No modelo tradicional, um servidor 24 horas fica lá, “será que chega alguma coisa?”. Consome energia e ainda pode falhar.

🐣 Estudante — É como um porteiro parado na porta esperando alguém aparecer.

🧙‍♂️ Doutor — Isso! E às vezes o porteiro fica resfriado e cai. Já no serverless, quando toca o sino “imagem enviada!”, o ninja aparece, gera a miniatura rapidinho e some.

🐣 Estudante — Mas não demora para o ninja aparecer?

🧙‍♂️ Doutor — Aí entra o problema do cold start. Quando o ninja está dormindo, leva alguns segundos para acordar e se preparar. Com linguagens pesadas, como Java, é como se o ninja sonolento tivesse que abrir o tapete de ioga e preparar o café antes de trabalhar.

🐣 Estudante — Irritante. Então não serve para processamento em tempo real?

🧙‍♂️ Doutor — Há mecanismos de aquecimento, mas, em geral, ele brilha em processamento em lote ou assíncrono. Coisas do tipo “responda já!” não são o forte.

Entendendo com um exemplo: um app de compartilhamento de fotos

🐣 Estudante — Me explica com um exemplo. Digamos que quero criar um app de fotos?

🧙‍♂️ Doutor — Ótimo. No modelo tradicional seria assim:

Servidor tradicional:

Servidor web rodando 24 horas (¥5000 por mês)
↓
"Uma foto foi enviada"
↓
Processamento de miniatura dentro do servidor
↓
Salvar no banco de dados

🧙‍♂️ Doutor — Desse jeito você paga ¥5000 todo mês, mesmo que ninguém envie nada. É como manter uma loja pagando aluguel sem cliente.

🐣 Estudante — Que desperdício.

🧙‍♂️ Doutor — No serverless seria:

Versão serverless:

Imagem enviada ao S3
↓
Evento do S3 dispara uma função Lambda
↓
Função Lambda inicia (0,1 s)
↓
Gera a miniatura e grava em outro bucket S3
↓
Função Lambda termina
↓
Cobrança: apenas pelo tempo de execução (cerca de ¥0,001 por chamada)

🐣 Estudante — Então se ninguém usar, custa zero?

🧙‍♂️ Doutor — Exatamente! Você paga só pelo que usar. Mas se viralizar, a fatura viraliza junto. Se um vídeo bombar e disparar um milhão de execuções…

🐣 Estudante — A fatura chega a ¥1000!

🧙‍♂️ Doutor — O cálculo está certo, mas lembra que somamos tráfego, API Gateway, banco de dados. Não é raro chegar a dezenas de milhares de ienes. É a tragédia moderna de “viralizou e faliu”.

📌 Nota: Cobrança por uso — benefícios e armadilhas

Benefícios

  • Custo inicial quase zero
  • Escala automática conforme o uso
  • Dispensa a gestão de infraestrutura

Riscos

  • Cobranças inesperadas e altas (principalmente em virais)
  • Estruturas de preços complexas
  • Dificuldade para enxergar o custo combinado de vários serviços

Contramedidas

  • Configurar alertas de cobrança
  • Implementar limites de taxa
  • Fazer testes de carga e estimativas de custo com antecedência

Tipos de serverless: as especialidades dos ninjas

🐣 Estudante — Ouvi dizer que existem tipos diferentes de serverless?

🧙‍♂️ Doutor — São três grandes estilos: FaaS (Function as a Service), BaaS (Backend as a Service) e contêineres serverless.

🐣 Estudante — O que é FaaS?

🧙‍♂️ Doutor — É o serviço do tipo “cuido só da função”. AWS Lambda, Google Cloud Functions, Azure Functions. Você escreve a função e eles “executam apenas quando chamados e cobram por uso” — um negócio digno de um sushibar.

🐣 Estudante — E BaaS?

🧙‍♂️ Doutor — É o “deixo banco, autenticação e push comigo”. Firebase, Supabase, AWS Amplify. É como viver na casa dos pais, onde “a mãe resolve tudo”.

🐣 Estudante — Viver com os pais é fácil, mas tem que seguir as regras deles.

🧙‍♂️ Doutor — Exatamente. Daí surge o risco de vendor lock-in. Quando percebe, já está “viciado a ponto de não viver sem aquele serviço”.

O que o serverless faz bem — e o que não faz

🐣 Estudante — Então é só fazer esforço físico que dá certo? Para que usar serverless?

🧙‍♂️ Doutor — A graça é a velocidade. Você publica uma ideia rapidamente e, enquanto o uso é pequeno, o custo fica perto de zero. Dá para lançar hoje algo que imaginou ontem à noite.

🐣 Estudante — Mas não serve para tudo, né?

🧙‍♂️ Doutor — Claro. Ele tem pontos fortes e fracos bem claros.

Pontos fortes

  • Processamento de imagens (upload → geração de miniaturas)
  • Transformação de dados (converter CSV em JSON)
  • Envio de notificações (e-mail, push)
  • Jobs em lote regulares (relatórios diários)
  • APIs leves (busca de usuários, leitura de dados)

Pontos fracos

  • Processamento em tempo real (chat, games)
  • Tarefas de longa duração (transcodificação de vídeo, ML)
  • Aplicações que exigem gestão complexa de estado
  • Integrações fortemente acopladas a legados

🐣 Estudante — Então ele tem “explosão de velocidade mas pouca resistência”.

🧙‍♂️ Doutor — Isso mesmo! Excelente nos 100 metros, péssimo na maratona.

A armadilha das cobranças: ninjas pagos por hora

🐣 Estudante — Se gente forte não precisa e a fatura pode te matar, só vale para quem pensa bem?

🧙‍♂️ Doutor — Exato. Serverless é “ganha quem usa a cabeça, explode quem vacila”. Se você não entender a cobrança, vai ver o inferno.

🐣 Estudante — Que tipo de inferno?

🧙‍♂️ Doutor — Imagine escrever um código em loop infinito. Num servidor tradicional tudo fica lento. No serverless, “novos ninjas são convocados sem parar”.

🐣 Estudante — Um exército de ninjas trabalhando e cobrando por hora sem parar? Terror.

🧙‍♂️ Doutor — E você só percebe na fatura do fim do mês. “Como assim ¥1.000.000?” Casos de gente sendo cobrada centenas de milhares de ienes na AWS existem aos montes.

🐣 Estudante — Assustador. Tem como evitar?

🧙‍♂️ Doutor — Claro. Configura alerta de custo, limite de tempo de execução, limite de concorrência. É como redigir direito o “contrato de trabalho dos ninjas”.

Casos reais de fracasso: o medo do viral

🐣 Estudante — Já ouviu algum caso real de cobrança absurda?

🧙‍♂️ Doutor — Dezenas. Um famoso foi o “app de edição de fotos que estourou e recebeu uma fatura de ¥3.000.000”.

🐣 Estudante — Nossa… conta mais.

🧙‍♂️ Doutor — Uma startup criou um app que “embelezava fotos com IA”. Calculavam cerca de ¥0,1 por foto.

🐣 Estudante — E o que houve?

🧙‍♂️ Doutor — Bombou nas redes: 1.000.000 de fotos por dia. Cada foto demorava mais que o previsto e a conta real foi de ¥3 por foto.

🐣 Estudante — 1.000.000 × ¥3 = ¥3.000.000…

🧙‍♂️ Doutor — E isso por 30 dias. “Ficou famoso e quebrou”: a tragédia moderna.

🐣 Estudante — Não tinham prevenção?

🧙‍♂️ Doutor — Nenhum limite de cobrança. “Nunca pensamos que ia viralizar”. Hoje virou praxe definir um “teto para o sucesso”.

🐣 Estudante — Ironia: limitar o sucesso.

🧙‍♂️ Doutor — Pois é. “Gritos de alegria” viram gritos de dor na vida real.

Mudança na experiência de desenvolvimento: prazer mágico, dor das restrições

🐣 Estudante — E na hora de desenvolver? É diferente de programar normalmente?

🧙‍♂️ Doutor — No começo é divertido. Você escreve a função, aperta um botão e publica para o mundo. Parece até virar mago.

🐣 Estudante — Uau, parece divertido mesmo.

🧙‍♂️ Doutor — Mas com o tempo aparecem os espinhos. É difícil testar localmente, depurar é um saco. Quando pensa “por que não funciona?”, o ninja já sumiu e só restam logs.

🐣 Estudante — Tipo chegar à cena do crime depois, só com as evidências.

🧙‍♂️ Doutor — Exato. E os logs ficam espalhados em vários serviços: CloudWatch, X-Ray, CloudTrail. Vira brincadeira de detetive.

🐣 Estudante — Chato. Melhor montar o servidor logo.

🧙‍♂️ Doutor — Essa é a armadilha do serverless. No começo é magia fácil; depois, uma maldição complexa. Mas quem se acostuma não quer voltar a “cuidar do servidor”.

🐣 Estudante — Então vicia?

🧙‍♂️ Doutor — Sim. “Não se preocupar com servidor” é viciante. Mas no lugar disso vêm “preocupação com cobranças” e “limitações de design”.

Serverless vs. modelo tradicional: a realidade do custo

🐣 Estudante — No fim, qual sai mais barato?

🧙‍♂️ Doutor — Depende do uso e da previsibilidade. Pense num gráfico:

Servidor tradicional

  • Custo fixo: ¥50.000 por mês
  • Custo variável: quase zero
  • Modelo ‘restaurante de prato feito’

Serverless

  • Custo fixo: quase zero
  • Custo variável: depende do uso
  • Modelo ‘sushibar de esteira’

🐣 Estudante — Qual é mais barato depende do quanto você ‘come’.

🧙‍♂️ Doutor — Perfeito. Comer pouco → sushibar (serverless). Comer muito → prato feito (tradicional). Concretamente:

Até 1 milhão de requisições por mês: serverless vence com folga
Acima de 10 milhões de requisições por mês: servidor tradicional sai mais em conta
No meio: depende, considere também o custo operacional

🐣 Estudante — E se a previsão errar?

🧙‍♂️ Doutor — Vira jogo de azar. “Planejei devorar no prato feito e perdi o apetite” ou “Achei que ia comer pouco no sushibar e virou campeonato de glutões”.

Serverless vai vencer?

🐣 Estudante — Então serverless vai vencer ou fracassar?

🧙‍♂️ Doutor — Nem vitória absoluta, nem derrota certa. Servidores tradicionais, contêineres e serverless vão coexistir. “Precisamos de ninjas, cavaleiros e magos” no mesmo mundo.

🐣 Estudante — Entendi. Nenhuma tecnologia resolve tudo.

🧙‍♂️ Doutor — Isso. Não existe “bala de prata”. Mas usada no contexto certo, é uma ferramenta poderosíssima.

🐣 Estudante — Quem deveria usar?

🧙‍♂️ Doutor — Gente assim:

Perfil ideal para serverless

  • Quer colocar algo em pé rapidamente
  • Entende bem a estrutura de cobrança
  • Prefere gestão simplificada a controle total
  • Se empolga com tecnologias novas

Quem não combina com serverless

  • Artesãos que querem controlar tudo
  • Quem é ruim de planejar orçamento
  • Quem prioriza acima de tudo a operação estável
  • Quem não consegue se desvencilhar de legados

🐣 Estudante — Então é para “inovadores mão de vaca”.

🧙‍♂️ Doutor — Descrição excelente. Precisa juntar inovação com avareza.

Encerrando: viver no modo serverless

🐣 Estudante — No fim, o senhor recomenda serverless?

🧙‍♂️ Doutor — Não é questão de recomendar, e sim de “entender e saber usar”. É uma magia moderna em que você pesa a tentação da conveniência e o risco das cobranças.

🐣 Estudante — Magia… Se conjurar errado, volta contra o mago.

🧙‍♂️ Doutor — Isso. Por isso precisamos aprender a ‘pronúncia correta’. Serverless é “ganha quem usa a cabeça, explode quem se distrai”. Não serve para brutamontes, mas é arma poderosa para quem souber controlar.

🐣 Estudante — Então fica assim:

  • Operar servidor: inferno físico de resistência
  • Serverless: sobrevivência financeira com estratégia Certo?

🧙‍♂️ Doutor — Resumo perfeito. A escolha depende do contexto. Mas “não escolher nada” já não é opção. Engenheiros modernos precisam decidir se serão cavaleiros, ninjas ou magos.

🐣 Estudante — Entendido. Vou começar pelo básico e deixar o ninja para depois.

🧙‍♂️ Doutor — Com essa mentalidade você vira um grande ‘domador de ninjas’. Mas cuidado com a fatura.

🐣 Estudante — Sim! Vou configurar alerta de cobrança!

📌 Nota final: framework para decidir pelo serverless

Avalie em conjunto os pontos abaixo antes de adotar serverless:

Fatores técnicos

  • Natureza do processamento (lote vs. tempo real)
  • Frequência de execução (baixa vs. alta)
  • Necessidade de manter estado
  • Integração com sistemas legados

Fatores de negócio

  • Orçamento para investimento inicial
  • Habilidades do time de operação
  • Precisão na previsão de crescimento
  • Grau aceitável de vendor lock-in

Conclusão: serverless não é uma solução universal, e sim uma técnica especializada que rende muito quando usada no contexto certo. Com compreensão e preparo, vira uma arma poderosa; se adotada de forma leviana, custa caro.

Para engenheiros modernos, serverless é uma opção que precisa estar no radar — e uma tecnologia para aplicar onde fizer sentido.