O que é Arquitetura Serverless?

Arquitetura serverless é um modelo de execução em nuvem no qual o provedor roda seu código sob demanda — você nunca provisiona nem gerencia servidores. Os servidores continuam existindo — você só para de alugar, atualizar e escalar cada um deles. Você faz deploy de funções; a plataforma aloca computação quando um evento chega e cobra apenas pelo que roda.

Principais pontos

O problema que ela resolve

Num deployment tradicional, você aluga capacidade antes da demanda: dimensiona a instância, configura o autoscaling, paga pelo tempo ocioso, atualiza o sistema operacional. Erre para um lado e você queima dinheiro; para o outro, derruba requests no pico de tráfego.

No modelo serverless, esse ciclo inteiro desaparece. Você escreve uma função, e escalar de zero a milhares de execuções concorrentes é trabalho do provedor. Este é todo o código de backend necessário para calcular a nota média de um filme no servidor:

// cloud/main.js — uma função Cloud Code do Back4app
Parse.Cloud.define('averageStars', async (request) => {
  const query = new Parse.Query('Review');
  query.equalTo('movie', request.params.movie);
  const reviews = await query.find();
  const sum = reviews.reduce((acc, r) => acc + r.get('stars'), 0);
  return sum / reviews.length;
});

Não há um app Express em volta, nem Dockerfile, nem load balancer. A função é a unidade de deploy.

Chamando a função de qualquer cliente

Todo SDK de cliente invoca a mesma função pelo nome — transporte, auth e escala ficam por conta da plataforma:

// JavaScript / Node.js — Back4app JS SDK
const params = { movie: 'Inception' };
const rating = await Parse.Cloud.run('averageStars', params);
console.log(`Average rating: ${rating}`);

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('averageStars');
final params = <String, dynamic>{'movie': 'Inception'};
final response = await function.execute(parameters: params);
if (response.success) {
  print('Average rating: ${response.result}');
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("averageStars",
                        parameters: ["movie": "Inception"]) { result in
  switch result {
  case .success(let rating):
    print("Average rating: \(rating)")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("movie" to "Inception")
ParseCloud.callFunctionInBackground<Float>("averageStars", params) { rating, e ->
  if (e == null) {
    Log.d("Cloud", "Average rating: $rating")
  }
}

Como uma requisição serverless flui

O ramo a observar é o cold start. Quando não existe instância warm, a plataforma precisa provisionar um runtime antes de executar seu código — de alguns milissegundos a vários segundos, dependendo da linguagem, do tamanho do código e das dependências. Em produção, isso afeta só uma pequena fração das requests, já que uma função invocada com constância segue reutilizando instâncias warm — desprezível para a maioria das APIs, mas real em caminhos críticos de latência, e uma das razões pelas quais edge functions e estratégias de warm-up existem.

Serverless vs. contêineres vs. servidores tradicionais

FaaS e BaaS: as duas metades do serverless

“Serverless” cobre dois modelos complementares, uma distinção que o artigo canônico de Mike Roberts no martinfowler.com formalizou. A divisão tem data de nascimento: a computação comercial disparada por eventos foi lançada em 2014 e, em dois anos, serverless saiu de ideia de pesquisa para padrão de produção em trabalho orientado a eventos — por isso o vocabulário ainda parece mais novo que as ideias por trás dele. FaaS (Functions as a Service) significa que você ainda escreve lógica server-side, mas ela roda em computação stateless, disparada por eventos e totalmente gerenciada — o modelo das “cloud functions”. BaaS (Backend as a Service) vai além: o banco de dados, a autenticação, o armazenamento de arquivos e as APIs são, eles próprios, consumidos como serviços gerenciados, então a maior parte do código de backend que você escreveria desaparece por completo.

A maioria das aplicações reais precisa dos dois — funções para a lógica customizada, serviços gerenciados para todo o resto. Essa combinação é exatamente o que uma plataforma BaaS empacota. Para mergulhar nessa metade do modelo, leia nosso guia completo de Backend as a Service.

Casos de uso comuns do serverless

• APIs e backends mobile. O caso dominante: tráfego orientado a requests que dorme de madrugada e dispara no lançamento — exatamente o formato que o preço por execução recompensa.
• Processamento de eventos e dados. Redimensionar uma imagem no upload, validar um registro no save, sincronizar uma mudança com um sistema de terceiros — reações curtas a eventos.
• Jobs agendados. Relatórios noturnos, tarefas de limpeza e sincronizações recorrentes rodam como funções disparadas por cron, sem servidor esperando entre uma execução e outra.
• Recursos em tempo real. Chat, notificações e dashboards ao vivo combinam funções serverless com infraestrutura de tempo real gerenciada, em vez de servidores WebSocket feitos à mão.
• MVPs e protótipos. Ao validar uma ideia, gastar zero tempo com infraestrutura é o ponto inteiro — deploy de uma função, uma URL, produto no ar.
• Agentes de IA e webhooks. Código de cola entre LLMs, provedores de pagamento e APIs SaaS é naturalmente orientado a eventos e de vida curta — um encaixe perfeito para serverless.

Você deveria adotar serverless? Matriz de decisão

Sobre custo, âncoras concretas ajudam: plataformas serverless cobram por request mais o tempo de computação consumido (GB-segundos), sem compromisso antecipado — e o tier gratuito do Back4app inclui 25.000 requests de API por mês, o suficiente para rodar um MVP real a $0 antes de qualquer decisão de escala.

Limitações e trade-offs

• Cold starts. A primeira invocação de uma função ociosa paga uma penalidade de provisionamento (de menos de 100 ms a mais de um segundo). Mitigações: concorrência warm, bundles menores, runtimes de edge.
• Limites de tempo de execução. Funções foram feitas para trabalho curto; encoding de vídeo ou batches de uma hora pertencem a contêineres ou a sistemas de background jobs.
• Debugging e observabilidade mais difíceis. Não há servidor para acessar via SSH. Você depende dos logs, das métricas e do tracing da plataforma — avalie-os antes de se comprometer.
• Vendor lock-in. Funções escritas contra APIs proprietárias custam caro para migrar. Prefira plataformas construídas sobre open source — o Cloud Code do Back4app roda sobre uma base open-source que você pode auto-hospedar quando quiser.
• Custo em escala sustentada. Pagar por execução é imbatível em volume baixo e com picos, mas pode superar o preço fixo de servidor sob carga constante e pesada. Refaça a conta quando o tráfego estabilizar.
• Ausência de estado. Funções não guardam nada entre invocações; sessão e estado da aplicação precisam morar em banco ou cache — uma restrição de design se você está portando código stateful.

Arquitetura serverless no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Ele entrega as duas metades numa plataforma só. A metade FaaS é o Cloud Code: funções JavaScript como a averageStars acima, com deploy pelo dashboard ou pela CLI, além de triggers de banco de dados e jobs agendados — sem gateway, políticas de IAM ou infraestrutura para configurar. A metade BaaS vem provisionada com cada app do Back4app: o banco de dados, a autenticação de usuários, o armazenamento de arquivos e as APIs REST e GraphQL geradas automaticamente. E como o Back4app é construído sobre uma base open-source, as funções que você escreve são portáteis — dá para auto-hospedar a mesma stack depois, o que remove a objeção de lock-in que paira sobre plataformas serverless presas a um provedor.