Funções Serverless vs. Microsserviços: qual escolher?

Uma função serverless é uma unidade única de deploy de lógica de backend; um microsserviço é um serviço inteiro operado de forma independente. Essa única frase é a comparação inteira em miniatura — todo o resto (carga de ops, curvas de custo, cold starts, estado) decorre do que é a unidade de deploy: uma função que você entrega a uma plataforma, ou um serviço que você mesmo opera.

Principais pontos

A unidade de deploy, em código

Este é o deployable inteiro de uma operação de checkout — uma função, sem repositório por serviço, sem imagem de contêiner, sem pipeline:

// JavaScript / Node.js — the function is the whole deployable
// cloud/main.js — runs on the platform; there is no service to operate
Parse.Cloud.define('checkout', async (request) => {
  const cart = await new Parse.Query('Cart').get(request.params.cartId, {
    sessionToken: request.user.getSessionToken(),
  });
  // …price the cart, reserve stock, write the order…
  return { orderId: cart.id, status: 'confirmed' };
});

// Any client calls it by name — no gateway, container, or pipeline
const result = await Parse.Cloud.run('checkout', { cartId });

// Flutter / Dart — Back4app Flutter SDK
// Calling the function: one named endpoint, no service discovery
final checkout = ParseCloudFunction('checkout');
final response = await checkout.execute(
  parameters: {'cartId': cartId},
);
if (response.success) {
  print(response.result['status']); // confirmed
} else {
  print(response.error?.message);
}

// iOS / Swift — Back4app Swift SDK
// Calling the function: one named endpoint, no service discovery
struct Checkout: ParseCloudable {
    typealias ReturnType = [String: String]
    var functionName: String = "checkout"
    var cartId: String
}

let result = try await Checkout(cartId: cartId).runFunction()
print(result["status"] ?? "") // confirmed

// Android / Kotlin — Back4app Android SDK
// Calling the function: one named endpoint, no service discovery
val params = hashMapOf("cartId" to cartId)
ParseCloud.callFunctionInBackground<Map<String, String>>(
    "checkout", params
) { result, e ->
    if (e == null) {
        Log.i("Checkout", result["status"] ?: "")
    } else {
        Log.w("Checkout", "failed: ${e.code}")
    }
}

O equivalente em microsserviço desse snippet é um repositório: um servidor HTTP, um build de contêiner, manifestos de deploy, service discovery, health checks, um dashboard e uma escala de plantão — antes da primeira linha de lógica de checkout.

Funções serverless vs. microsserviços customizados

A literatura de microsserviços é explícita: os benefícios da arquitetura se compram com maturidade operacional séria — deploy automatizado, monitoramento sofisticado, design para falha. Funções terceirizam exatamente essa conta para a plataforma, e é por isso que a análise de serverless de Mike Roberts enquadra FaaS como a troca de controle por radicalmente menos ops. Nenhuma das trocas é gratuita; a pergunta é qual imposto o seu time consegue pagar.

O que realmente acontece com uma request

Repare no que a metade de baixo adiciona e a de cima não consegue expressar: chamadas serviço a serviço, bancos de dados por serviço e um gateway — a superfície de coordenação onde a complexidade dos microsserviços realmente mora. Transações distribuídas, retries e falhas parciais entre os serviços de carrinho e de pedidos são código seu; no modelo de funções, o mesmo workflow costuma ser uma função e um banco, e as peças orientadas a eventos (triggers, jobs agendados) penduram na plataforma, e não em filas que você opera.

Quando funções substituem uma frota de microsserviços — e quando não conseguem

A observação honesta por trás do padrão BaaS: a maioria dos microsserviços de um produto típico é fina. Eles validam entrada, aplicam uma regra, leem ou escrevem num banco e chamam um vizinho — a casca operacional em volta dessa lógica é 90% do peso. Funções de nuvem dentro de um BaaS deletam a casca: o banco de dados, a autenticação, o armazenamento de arquivos e as APIs são serviços da plataforma, então cada “serviço” colapsa num punhado de funções e triggers. Times de uma a dez pessoas entregando produtos CRUD-mais-lógica raramente precisam de mais.

O teto é igualmente honesto. Funções não conseguem hospedar um modelo de recomendação que precisa de hardware especializado, um transcodificador de vídeo que roda por uma hora, um motor de fan-out de WebSocket com tuning customizado, nem um componente cujo throughput sustentado torna o preço por invocação a opção cara. Quando um componente cruza essas linhas, extraia-o como um serviço de verdade e deixe-o interoperar com as funções — extrair um hot spot comprovado é uma migração muito mais barata do que decompor uma frota especulativa construída cedo demais, a mesma lição que o argumento monolith-first ensina um nível acima.

Casos de uso comuns

• Funções: backends de API e mobile. Lógica em formato de request sobre um banco gerenciado — o caso dominante, e o que as plataformas BaaS empacotam de ponta a ponta.
• Funções: triggers e cola. Validar no save, redimensionar no upload, sincronizar com uma API de terceiros, rodar jobs noturnos — reações curtas que fariam um serviço dedicado passar vergonha.
• Funções: tráfego com picos ou desconhecido. Lançamentos, campanhas, MVPs — escalar a zero absorve tanto o pico quanto o silêncio.
• Microsserviços: componentes pesados e constantes. Busca, feeds, motores de precificação — carga estável em que capacidade sempre ativa é mais barata e ajustável.
• Microsserviços: runtimes especiais. Linguagens fora do padrão, dependências nativas, GPUs, processos de longa duração.
• O híbrido. Funções para a superfície de API e os eventos; um ou dois serviços extraídos para os componentes cujos números exigem.

Você deveria construir funções ou microsserviços? Matriz de decisão

Limitações e trade-offs

• Funções: limites de execução são paredes duras. Trabalho longo precisa migrar para sistemas de jobs ou serviços — nenhuma esperteza estende um timeout com elegância.
• Funções: cold starts e cadeias. Raros por invocação, mas arquiteturas de função-chama-função os empilham; mantenha os caminhos quentes rasos.
• Funções: acoplamento à plataforma. O runtime e suas APIs são da plataforma — uma fundação open-source que você pode auto-hospedar é a proteção prática contra o lock-in.
• Microsserviços: a conta de ops é por serviço. Pipelines, monitoramento, contratos versionados e plantão se multiplicam com a frota; subestimar isso é o modo clássico de falha.
• Microsserviços: os problemas de sistemas distribuídos chegam no primeiro dia. Partições de rede, falhas parciais e consistência entre serviços são constantes arquiteturais, não casos de borda.
• Ambos: o estado é externalizado de qualquer jeito. Funções obrigam; serviços bem operados escolhem. É o banco de dados, não a computação, que acaba guardando a verdade nos dois designs.

Funções serverless e microsserviços 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. É o lado das funções desta comparação entregue por inteiro: o Cloud Code roda funções nomeadas como a checkout acima, além de triggers de banco de dados e jobs agendados, ao lado de tudo o que uma frota de microsserviços existe para prover — então a frota que a maioria dos produtos teria construído vira funções sobre serviços gerenciados. E como a fundação é open source e você pode auto-hospedar, o caminho de extração continua aberto: quando um componente supera o modelo de funções, ele pode se graduar em um serviço dedicado sem abandonar a plataforma ao redor.