--- term: 'Funções Serverless vs. Microsserviços' seoTitle: 'Funções Serverless vs. Microsserviços: Como Escolher' headline: 'Funções Serverless vs. Microsserviços: qual escolher?' slug: funcoes-serverless-vs-microsservicos category: backend-compute shortDefinition: '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.' relatedTerms: - cloud-code-serverless-functions - microservices-vs-monolith - serverless-architecture - event-driven-architecture contrastsWith: - microservices-vs-monolith aboutTerms: - 'Funções Serverless' - 'Microsserviços' faq: - question: 'Uma função serverless é um microsserviço?' answer: 'Não exatamente — a granularidade difere em uma ordem de magnitude. Um microsserviço é dono de uma capacidade de negócio: seu próprio processo, banco de dados, pipeline de deploy e superfície de API. Uma função é dona de uma operação. Um único microsserviço tipicamente se decompõe em várias funções, e é a plataforma, não o seu time, que fornece o processo, a escala e o runtime ao redor de cada uma.' - question: 'Funções serverless podem substituir microsserviços?' answer: 'Para muitos produtos, sim — especialmente quando os serviços fariam pouco mais que envolver um banco de dados com validação e um workflow leve. Funções em um BaaS herdam o banco, a autenticação e as APIs, sobrando só a lógica de negócio genuína para escrever. As exceções são reais: trabalho de longa duração, runtimes customizados, throughput pesado e sustentado e pisos rígidos de latência ainda favorecem um serviço operado por você.' - question: 'O que sai mais barato: funções ou microsserviços?' answer: 'Em volume baixo ou com picos, funções — você paga por execução e o custo ocioso é zero, enquanto uma frota de microsserviços fatura contêineres o dia inteiro, mais o tempo de engenharia para operá-los. Em volume pesado e sustentado, as curvas se cruzam: capacidade sempre ativa fica mais barata por request. Inclua o salário de ops na comparação; ele costuma dominar a linha de infraestrutura.' - question: 'Cold starts tornam as funções mais lentas que os microsserviços?' answer: 'Só na fração de invocações que cai numa instância ociosa — tipicamente de milissegundos a cerca de um segundo, contra a latência consistente de um serviço sempre warm. Tráfego constante mantém as instâncias das funções warm, e funções encadeadas são o caso a vigiar, já que cada salto pode adicionar seu próprio cold start. Para orçamentos rígidos de latência de cauda, um serviço sempre ativo ainda vence.' - question: 'Quando microsserviços customizados claramente vencem?' answer: 'Trabalho longo ou stateful que ultrapassa os timeouts das funções, runtimes customizados ou dependências de sistema que a plataforma não oferece, hardware especializado, throughput alto e sustentado em que capacidade sempre ativa sai mais barata e times que precisam de controle total da rede e da topologia de deploy. Se vários desses pontos valem para um componente, esse componente quer ser um serviço.' - question: 'Funções serverless podem manter estado?' answer: 'Não entre invocações — cada chamada de função parte do zero, e qualquer coisa que valha a pena guardar precisa viver no banco de dados ou num cache. Microsserviços podem manter estado em memória, ao preço de dificultar a escala e o failover. Na prática, as duas arquiteturas convergem para a mesma disciplina: externalize o estado, trate a computação como descartável.' - question: 'Dá para combinar funções e microsserviços?' answer: 'Sim, e sistemas maduros normalmente combinam. A divisão pragmática: funções cuidam da lógica de API request/response, dos triggers de banco de dados, dos jobs agendados e da cola entre eventos; serviços dedicados cuidam dos poucos componentes com carga pesada e constante ou com necessidades especiais de runtime. Começar com funções e extrair um serviço quando os números exigirem é mais barato que a migração inversa.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)' url: 'https://martinfowler.com/articles/serverless.html' - name: 'Microservices — Lewis & Fowler (martinfowler.com)' url: 'https://martinfowler.com/articles/microservices.html' - name: 'Microservices (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Microservices' - name: 'Back4app Cloud Code documentation' url: 'https://www.back4app.com/docs/get-started/cloud-functions' cta: title: 'A frota de funções, sem a frota' text: 'O Cloud Code no Back4app roda suas funções ao lado de banco de dados gerenciado, autenticação e APIs geradas automaticamente — as partes que uma frota de microsserviços existe para prover, já provisionadas. Escreva a lógica de negócio; pule a engenharia de plataforma.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-20' translationKey: serverless-functions-vs-microservices --- **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 | Pergunta | Resposta | | --- | --- | | A diferença central | Unidade de deploy: uma operação (função) vs. uma capacidade própria (serviço) | | Quem opera | Funções: a plataforma. Microsserviços: o seu time, por serviço | | Custo ocioso | Funções escalam a zero; uma frota de serviços fatura o dia inteiro | | O imposto das funções | Cold starts, limites de tempo de execução, ausência de estado | | O imposto dos serviços | Pipelines, orquestração, monitoramento, plantão — multiplicados por serviço | ## 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:** ```javascript // 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 // 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); } ``` **Swift:** ```swift // 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 ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Calling the function: one named endpoint, no service discovery val params = hashMapOf("cartId" to cartId) ParseCloud.callFunctionInBackground>( "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 | Dimensão | Funções serverless | Microsserviços customizados | | --- | --- | --- | | Unidade de deploy | Uma função | Um serviço (processo + API + dados) | | Infraestrutura que você opera | Nenhuma — gerenciada pela plataforma | Contêineres, orquestração e rede por serviço | | Escala | Automática, por invocação, até zero | Você configura; a capacidade roda mesmo ociosa | | Estado | Stateless por contrato; o estado vive no banco de dados | Pode manter estado em memória (a um preço) | | Perfil de latência | Chamadas warm são rápidas; instâncias ociosas pagam cold start | Consistente — o processo está sempre de pé | | Runtime | Fornecido pela plataforma (tipicamente um runtime JavaScript gerenciado) | Qualquer coisa que você consiga conteinerizar | | Trabalho de longa duração | Cortado pelos limites de tempo de execução | Ilimitado | | Formato do time | Só engenheiros de produto | Exige capacidade de plataforma/DevOps | | Curva de custo | Por execução; imbatível com picos, cruza em carga sustentada | Fixa; eficiente em volume alto e constante | A [literatura de microsserviços](https://martinfowler.com/articles/microservices.html) é 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](https://martinfowler.com/articles/serverless.html) 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 ```mermaid flowchart TB accTitle: Caminho de uma request por uma função serverless versus uma frota de microsserviços customizados accDescr: No modelo de funções, um cliente chama um endpoint gerenciado e a plataforma roda a função contra o banco de dados gerenciado, escalando instâncias automaticamente. No modelo de microsserviços, o cliente passa por um API gateway até um de vários serviços operados pelo time, cada um com seu próprio deploy de contêiner e seu próprio banco de dados. subgraph F ["Modelo de funções — operado pela plataforma"] C1["Cliente"] --> E["Endpoint gerenciado"] E --> FN["checkout()"] FN --> DB[("Banco de dados gerenciado")] end subgraph M ["Modelo de microsserviços — operado pelo time"] C2["Cliente"] --> G["API gateway"] G --> S1["Serviço de carrinho"] G --> S2["Serviço de pedidos"] S1 --> D1[("BD do carrinho")] S2 --> D2[("BD de pedidos")] S1 <--> S2 end ``` 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](/glossary/event-driven-architecture/) (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](/glossary/pt/cloud-code-funcoes-serverless/) 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](/glossary/microservices-vs-monolith/) 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 | Sua situação | Tendência | | --- | --- | | Time pequeno, lógica do produto é majoritariamente CRUD + regras | Funções em um BaaS — a frota adiciona custo, não capacidade | | Tráfego com picos, baixo ou imprevisível | Funções — escalar a zero é o argumento inteiro | | Um componente roda de minutos a horas por job | Microsserviço (ou um sistema de background jobs) — os timeouts descartam funções | | Throughput alto e sustentado num caminho quente | Microsserviço — a capacidade de preço fixo vence a curva de custo | | Orçamento rígido de latência de cauda em toda request | Microsserviço — sem variância de cold start | | Runtime customizado, dependências nativas, hardware especial | Microsserviço — plataformas rodam o que rodam | | Você não tem capacidade de ops dedicada | Funções — o imposto da frota chega tendo você orçado ou não | | Um hot spot dentro de um produto em formato de funções | Híbrido — extraia esse único serviço, mantenha o resto como funções | ## 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](https://www.back4app.com/docs/get-started/cloud-functions) 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.