---
term: 'IaaS vs. PaaS vs. CaaS vs. FaaS vs. BaaS vs. mBaaS vs. SaaS'
seoTitle: 'IaaS vs PaaS vs CaaS vs FaaS vs BaaS vs mBaaS vs SaaS: Guia Completo'
headline: 'Modelos de serviço em nuvem comparados: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS e SaaS'
slug: modelos-de-servico-em-nuvem
category: cloud-architecture
shortDefinition: 'Os modelos de serviço em nuvem são uma escada — IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS — ordenada por quanto o provedor executa por você.'
relatedTerms:
  - infrastructure-as-a-service
  - paas-vs-baas
  - baas-vs-serverless
  - mbaas-vs-baas
  - baas-vs-custom-backend
  - serverless-architecture
  - containerization
contrastsWith:
  - paas-vs-baas
aboutTerms:
  - 'Infrastructure-as-a-Service (IaaS)'
  - 'Containers-as-a-Service (CaaS)'
  - 'Platform-as-a-Service (PaaS)'
  - 'Functions-as-a-Service (FaaS)'
  - 'Backend-as-a-Service (BaaS)'
  - 'Mobile Backend-as-a-Service (mBaaS)'
  - 'Software-as-a-Service (SaaS)'
faq:
  - question: 'Qual a diferença entre IaaS, PaaS e SaaS?'
    answer: 'Quem gerencia o quê. IaaS aluga infraestrutura — máquinas virtuais, armazenamento, redes — e tudo do sistema operacional para cima é seu. PaaS aluga uma plataforma gerenciada: você traz código e dados, o provedor executa o resto. SaaS entrega software pronto que você simplesmente usa. Cada degrau acima troca controle por velocidade e menos carga operacional.'
  - question: 'Onde CaaS, FaaS e BaaS se encaixam entre IaaS e SaaS?'
    answer: 'Nos degraus que o trio clássico pula. CaaS fica entre IaaS e PaaS: você entrega containers, o provedor executa a orquestração. FaaS fica acima do PaaS: você entrega funções individuais que rodam por evento. BaaS vai mais longe sem deixar de ser programável: o backend em si — banco de dados, auth, armazenamento, APIs — já vem pronto, e as funcionalidades padrão dispensam qualquer código de servidor.'
  - question: 'BaaS significa Backend as a Service ou Backup as a Service?'
    answer: 'No desenvolvimento de aplicações, BaaS quase sempre significa Backend as a Service — um backend pronto consumido via SDKs. Alguns contextos de armazenamento corporativo usam a mesma sigla para Backup as a Service, que é outra coisa: backups gerenciados de dados. Se a conversa envolve apps mobile, APIs ou plataformas de aplicação, leia BaaS como backend. O contexto resolve; esta página cobre o significado de backend.'
  - question: 'Qual a diferença entre CaaS e PaaS?'
    answer: 'A unidade que você entrega ao provedor. No CaaS você entrega containers — qualquer linguagem, qualquer stack, empacotados do seu jeito — e mantém o controle das decisões de orquestração. No PaaS você entrega código de aplicação e aceita os runtimes e convenções da plataforma em troca de um fluxo de deploy mais simples. CaaS combina com microsserviços e stacks poliglotas; PaaS combina com apps padrão que querem o mínimo de cerimônia.'
  - question: 'FaaS é a mesma coisa que serverless?'
    answer: 'FaaS é metade do serverless, não um sinônimo. A definição canônica — de Mike Roberts no martinfowler.com — trata serverless como um guarda-chuva que cobre tanto FaaS (suas funções, executadas sob demanda) quanto BaaS (serviços de backend prontos). No dia a dia, "serverless" muitas vezes quer dizer só FaaS, e é daí que vem a confusão entre os termos.'
  - question: 'Qual a diferença entre BaaS e mBaaS?'
    answer: 'mBaaS é onde a categoria começou — um backend pronto voltado especificamente para apps mobile, com push notifications, SDKs cientes do dispositivo e sincronização offline como recursos de primeira classe. Quando os apps web também viraram client-first, o modelo se generalizou e o "m" caiu. Hoje todo mBaaS sério atende web igualmente, então os termos nomeiam praticamente as mesmas plataformas com ênfases diferentes.'
  - question: 'Qual modelo de serviço em nuvem é o mais barato?'
    answer: 'Depende do formato do workload, não do modelo. FaaS é o mais barato para tráfego esporádico ou baixo, porque o custo ocioso é zero, e caro sob carga alta sustentada. IaaS tem o melhor preço unitário bruto em grande escala estável, mas carrega o custo escondido do time de operações. CaaS, PaaS e BaaS ficam no meio, trocando a margem da plataforma por horas de engenharia eliminadas — que, para times pequenos, costumam ser o custo dominante.'
  - question: 'Dá para combinar vários modelos de serviço?'
    answer: 'Praticamente toda empresa real combina. Uma stack típica: SaaS para as ferramentas de negócio, BaaS ou PaaS para rodar o produto, FaaS para a cola orientada a eventos, CaaS para os serviços containerizados que precisam de controle de orquestração e IaaS para o raro workload especializado. Os modelos são degraus para posicionar cada workload individualmente — a habilidade prática é encontrar, para cada um, o degrau suficiente mais barato.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'The NIST Definition of Cloud Computing (SP 800-145)'
    url: 'https://csrc.nist.gov/pubs/sp/800/145/final'
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'As a service (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/As_a_service'
  - name: 'Kubernetes documentation — overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: 'Comece no topo da escada'
  text: 'O Back4app coloca você no degrau do BaaS desde o primeiro dia — banco de dados, auth, armazenamento e APIs prontos, com funções Cloud Code quando você também precisar do degrau FaaS. Construído sobre open source, para que descer a escada continue sempre possível.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-20'
translationKey: iaas-paas-baas-faas
---

**Os modelos de serviço em nuvem são uma escada — IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS — ordenada por quanto o provedor executa por você.** Todo "aaS" responde à mesma pergunta com uma linha diferente: *você constrói acima desta linha; nós operamos abaixo dela.* A maioria dos guias para no trio clássico que a definição do NIST formalizou — IaaS, PaaS, SaaS — e pula os degraus onde os produtos modernos realmente vivem. Este guia cobre os sete, define cada um com precisão e depois compara os pares que geram confusão de verdade. Escolha o degrau, e você terá escolhido no que o seu time vai passar a vida dando manutenção.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| A escada em uma linha | IaaS: alugue as máquinas · CaaS: alugue a orquestração · PaaS: alugue a plataforma · FaaS: alugue por execução de função · BaaS: alugue o backend · mBaaS: alugue o backend mobile · SaaS: alugue a aplicação pronta |
| A variável real | Onde fica a linha entre o que você gerencia e o que o provedor gerencia |
| A unidade de deploy | VM → container → aplicação → função → modelo de dados → nada |
| Serverless? | O guarda-chuva sobre FaaS *e* BaaS — não um degrau próprio |
| Qual é o melhor | Pergunta errada — combine cada workload com o degrau suficiente mais barato |
| A tendência | A cada ano, os times começam mais alto na escada |

## O que "subir o backend" significa em cada degrau

```bash
# A mesma tarefa — colocar um backend para responder requisições — degrau por degrau
# IaaS — você recebe máquinas:
$ ssh admin@vm-01              # depois: instalar, configurar, aplicar patches, escalar, monitorar…
# CaaS — você recebe a orquestração:
$ docker push registry/api:v1  # seus containers; o scheduler, a rede e o scaling são deles
# PaaS — você recebe uma plataforma:
$ git push platform main       # seu código; os servidores, o runtime e o scaling são deles
# FaaS — você recebe um runtime por evento:
$ deploy functions/api.js      # suas funções; rodam sob demanda, escalam a zero
# BaaS / mBaaS — você recebe o backend em si:
#   nada para implantar — auth, banco de dados e APIs já estão no ar
# SaaS — você recebe o produto pronto:
#   nada para construir — faça login e use
```

O degrau do BaaS merece prova, porque "nada para implantar" soa como marketing. Salvar um pedido em um backend de produção — schema, API, controle de acesso e scaling todos do lado do provedor — é uma única chamada no cliente:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const order = new Parse.Object('Order');
order.set('total', 129.9);
order.set('status', 'paid');
await order.save(); // schema, API, auth, scaling: all the rungs below you
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final order = ParseObject('Order')
  ..set('total', 129.9)
  ..set('status', 'paid');
await order.save(); // schema, API, auth, scaling handled below you
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var order = Order()
order.total = 129.9
order.status = "paid"
order.save { result in
  if case .success = result {
    print("saved — the platform ran every layer underneath")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val order = ParseObject("Order").apply {
  put("total", 129.9)
  put("status", "paid")
}
order.saveInBackground { e ->
  if (e == null) Log.d("Order", "saved — platform ran every layer underneath")
}
```

## Os sete modelos em uma escada

```mermaid
flowchart LR
  accTitle: A escada as-a-service com sete degraus
  accDescr: Oito passos do on-premises passando por IaaS, CaaS, PaaS, FaaS e BaaS com sua especialização mobile mBaaS, até SaaS — cada um alugando mais do provedor; as máquinas, a orquestração de containers, a plataforma, funções por execução, o backend e, por fim, a aplicação pronta.
  A["On-premises"] --> B["IaaS<br/>alugue as máquinas"]
  B --> C["CaaS<br/>alugue a orquestração"]
  C --> D["PaaS<br/>alugue a plataforma"]
  D --> E["FaaS<br/>alugue por execução de função"]
  E --> F["BaaS · mBaaS<br/>alugue o backend"]
  F --> G["SaaS<br/>alugue a aplicação pronta"]
```

A [definição de computação em nuvem do NIST](https://csrc.nist.gov/pubs/sp/800/145/final) formalizou os três degraus clássicos em 2011 — IaaS ("provisionar processamento, armazenamento, redes"), PaaS ("implantar aplicações criadas pelo consumidor usando ferramentas suportadas pelo provedor"), SaaS ("usar as aplicações do provedor") — antes de CaaS, FaaS e BaaS existirem como categorias. Os degraus mais novos se encaixam nas lacunas que o NIST deixou: CaaS entre IaaS e PaaS, FaaS e BaaS entre PaaS e SaaS — ainda programáveis, mas com cada vez menos do programa sendo seu.

## Quem gerencia o quê: a matriz de responsabilidade

O assunto inteiro em uma tabela. Leia uma coluna de cima a baixo para ver o que cada modelo deixa no seu prato:

| Camada | On-prem | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Lógica de negócio | Você | Você | Você | Você | Você (como funções) | Só a lógica custom | Provedor |
| Funcionalidades de backend (auth, CRUD, storage, push) | Você | Você | Você | Você | Você | **Provedor** | Provedor |
| Empacotamento e runtime da aplicação | Você | Você | Você (containers) | Provedor | Provedor | Provedor | Provedor |
| Orquestração e scaling | Você | Você | **Provedor** | Provedor | Provedor (a zero) | Provedor | Provedor |
| SO e patching | Você | Você | Provedor | Provedor | Provedor | Provedor | Provedor |
| Servidores, rede, hardware | Você | **Provedor** | Provedor | Provedor | Provedor | Provedor | Provedor |
| Seus dados e política de acesso | Você | Você | Você | Você | Você | Você | **Ainda você** |

Duas coisas que a matriz torna visíveis e a prosa costuma esconder: a última linha nunca é transferida — seus dados e suas práticas de identidade são seus em todos os degraus, até no SaaS — e o nome de cada modelo é apenas a camada mais alta onde o "Provedor" começa.

## O que é IaaS (Infrastructure-as-a-Service)?

IaaS aluga infraestrutura virtualizada — máquinas, armazenamento em bloco, redes — por hora. Tudo acima do hypervisor é seu: sistema operacional, patching, runtime, lógica de scaling e o plantão das 3 da manhã. É o degrau de máximo controle e máxima superfície operacional, coberto em profundidade no [verbete de IaaS](/glossary/infrastructure-as-a-service/).

| | Perfil do IaaS |
| --- | --- |
| Você implanta | Máquinas virtuais e tudo que roda nelas |
| O provedor executa | Hardware físico, virtualização, malha de rede |
| Formato de preço | Por recurso-hora, usado ou ocioso |
| Escolha quando | Hardware/runtimes especiais, controle estrito da infraestrutura, lift-and-shift |
| Abandone quando | O headcount de operações custa mais do que o controle vale |

Como é o dia dois é o teste honesto do degrau. No IaaS, o dia dois é janela de patch do SO, upgrade de kernel, alarme de disco cheio, auditoria de security groups, planejamento de capacidade e construir o monitoramento que todo degrau acima inclui de graça. Nada disso é o seu produto. O degrau se paga em exatamente três situações: hardware ou runtimes que nenhuma plataforma oferece, regimes de compliance que exigem controle da infraestrutura e escala sustentada grande o bastante para o preço unitário bruto vencer as margens gerenciadas *depois* de precificar o time que opera tudo — uma barra bem mais alta do que a maioria dos times imagina.

## O que é CaaS (Containers-as-a-Service)?

CaaS aluga a camada que a maioria dos guias pula: você empacota serviços como [containers](/glossary/containerization/) — qualquer linguagem, qualquer stack — e o provedor executa o scheduler, a rede entre serviços e a maquinaria de scaling, tipicamente [Kubernetes](/glossary/kubernetes/) ou um equivalente. Ele fica deliberadamente entre IaaS e PaaS: mais abstrato que máquinas, menos opinativo que uma plataforma. Isso o torna a casa natural de [microsserviços](/glossary/microservices-vs-monolith/) e parques poliglotas que sofreriam com as convenções de um PaaS.

| | Perfil do CaaS |
| --- | --- |
| Você implanta | Imagens de container, manifestos de deployment |
| O provedor executa | Control plane de orquestração, nós, rede |
| Formato de preço | Por nó/cluster ou por container em execução |
| Escolha quando | Microsserviços, stacks poliglotas, controle de orquestração sem operar o cluster |
| Abandone quando | Um app padrão — um PaaS ou BaaS é menos maquinaria para o mesmo resultado |

A sutileza que separa o CaaS de um tutorial de [Kubernetes](/glossary/kubernetes/) hospedado: o que se transfere é o *control plane* — schedulers, etcd, API servers, saúde dos nós — enquanto tudo que se expressa em imagens e manifestos continua seu: higiene de imagem base, resource requests, liveness probes, estratégia de deployment, topologia de serviços. Isso é uma disciplina de verdade, e é exatamente por isso que o degrau existe como oferta distinta: times que precisam dessa expressividade, mas não têm apetite para operar a maquinaria por baixo. O container em si é a história de portabilidade — a mesma imagem roda em qualquer orquestrador conformante, o que mantém o CaaS entre os degraus de menor lock-in da escada.

## O que é PaaS (Platform-as-a-Service)?

PaaS aluga uma plataforma de aplicação gerenciada: você faz push do código, e o provedor fornece o runtime, o scaling e o sistema operacional por baixo. A troca é convenção por cerimônia — linguagens suportadas e idiomas da plataforma em troca de deploy via `git push`. O ponto crítico é o que o PaaS *não* remove: você ainda escreve e mantém toda a aplicação de backend — auth, endpoints, validação, tudo — uma distinção que o [verbete PaaS vs. BaaS](/glossary/pt/paas-vs-baas/) disseca.

| | Perfil do PaaS |
| --- | --- |
| Você implanta | Código de aplicação |
| O provedor executa | Runtime, SO, servidores, scaling |
| Formato de preço | Por instância/tier |
| Escolha quando | Apps de servidor custom em que a lógica de backend é o produto |
| Abandone quando | Você está escrevendo funcionalidades padrão que um BaaS já entrega prontas |

O contrato do PaaS moldou uma geração de bons hábitos — apps twelve-factor, config no ambiente, processos stateless, logs como streams — porque a plataforma *impõe* o que antes era só conselho. Sua fronteira é igualmente instrutiva: a plataforma executa a sua aplicação, mas não sabe nada do que existe dentro dela, então toda preocupação de backend — [sessões](/glossary/session-management/), permissões, migrações, [rate limits](/glossary/api-rate-limiting-throttling/) — continua sendo código que você escreve, testa e corrige. Esse é o sinal de que você está no degrau errado: se a maior parte do código hospedado no seu PaaS reimplementa usuários, CRUD e upload de arquivos, você está construindo à mão o degrau de cima.

## O que é FaaS (Functions-as-a-Service)?

FaaS aluga computação por evento: você implanta funções individuais, e o provedor executa cada invocação sob demanda, escalando a zero entre elas. É a expressão mais pura da [computação serverless](/glossary/pt/arquitetura-serverless/) — nada roda, e nada é cobrado, até que algo aconteça. Os custos são arquiteturais: [cold starts](/glossary/serverless-cold-starts/), limites de execução e um stateless que empurra toda persistência para fora. Como as funções se comparam a operar sua própria frota de serviços é a pergunta de [funções vs. microsserviços](/glossary/serverless-functions-vs-microservices/).

| | Perfil do FaaS |
| --- | --- |
| Você implanta | Funções individuais |
| O provedor executa | Todo o resto, por invocação |
| Formato de preço | Por invocação + tempo de execução; ocioso = zero |
| Escolha quando | Trabalho orientado a eventos: webhooks, jobs, pipelines, cola |
| Abandone quando | Carga alta sustentada — o preço por invocação se inverte |

O stateless é a restrição estrutural: uma função pode ser destruída depois de qualquer invocação, então tudo que é durável — sessões, arquivos, filas, dados — precisa viver em serviços *ao redor* da função. Levada à conclusão, essa restrição monta silenciosamente um BaaS: funções para a lógica, serviços gerenciados para tudo que tem estado. É por isso que os dois degraus convergiram na prática, e por isso existem runtimes open source (Knative, OpenFaaS) para times que querem o modelo por evento na própria orquestração. O preço segue a mesma lógica em formato de evento — grátis quando ocioso é imbatível para tráfego esporádico e punitivo para carga constante, a inversão que toda fatura de FaaS acaba ensinando.

## O que é BaaS (Backend-as-a-Service)?

BaaS aluga o backend em si. O banco de dados, a [autenticação](/glossary/authentication-vs-authorization/), o armazenamento de arquivos, as [APIs geradas automaticamente](/glossary/pt/apis-geradas-automaticamente/) e as push notifications chegam prontos e gerenciados, consumidos por [SDKs de cliente](/glossary/backend-sdk/) — para funcionalidades padrão não há código de servidor a escrever, como o exemplo acima demonstra. A lógica custom roda em [funções de nuvem](/glossary/pt/cloud-code-funcoes-serverless/) embutidas, e é por isso que plataformas BaaS maduras contêm o degrau FaaS em vez de competir com ele. A versão construir-ou-comprar dessa decisão tem [verbete próprio](/glossary/pt/baas-vs-backend-proprio/), e a questão do lock-in — a fraqueza honesta do degrau — depende de a plataforma ser [open source ou proprietária](/glossary/pt/baas-open-source-vs-proprietario/).

| | Perfil do BaaS |
| --- | --- |
| Você implanta | Um modelo de dados, regras de segurança, funções custom — muitas vezes nada além |
| O provedor executa | Todo o backend padrão, atrás de SDKs e APIs |
| Formato de preço | Free tier + uso/planos |
| Escolha quando | Backends de app padrão — usuários, dados, arquivos — e velocidade importa |
| Abandone quando | A lógica de backend *é* o produto, ou os requisitos fogem muito do padrão |

O que o BaaS remove é *infraestrutura e boilerplate*, não engenharia: seu [modelo de dados](/glossary/data-modeling/), suas [regras de segurança](/glossary/access-control-lists-acl/) e sua lógica de negócio continuam sendo decisões que nenhuma plataforma toma por você. A economia do degrau é a mais afiada da escada — minutos até um backend funcionando, custo inicial próximo de zero — e o risco estrutural também: em uma plataforma proprietária, schema, auth e funções vivem em formato moldado pelo fornecedor, o que faz do BaaS o lock-in mais forte entre os degraus programáveis. A variante open source dissolve exatamente isso: quando a mesma plataforma se auto-hospeda, sair vira mudança de endereço, não reescrita. A era da IA também ampliou o público do degrau — frontends gerados precisam de backends reais rápido, e um backend pronto e com permissões é o formato que encaixa.

## O que é mBaaS (Mobile Backend-as-a-Service)?

mBaaS é onde a categoria BaaS começou: um backend pronto voltado especificamente para apps mobile, com [push notifications](/glossary/push-notifications-apns-fcm/), SDKs cientes do dispositivo e [sincronização offline](/glossary/offline-first-data-sync/) como recursos de primeira classe, não como acessórios. Quando as single-page apps da web também viraram client-first, o modelo se generalizou e o *m* caiu discretamente — hoje toda plataforma séria serve web e mobile do mesmo backend. Quando a distinção ainda importa — e quando é só resíduo histórico — é o assunto do [verbete mBaaS vs. BaaS](/glossary/pt/mbaas-vs-baas/).

| | Perfil do mBaaS |
| --- | --- |
| Você implanta | O mesmo que no BaaS, via SDKs nativos mobile |
| O provedor executa | O backend, mais o encanamento mobile: gateways de push, estado do dispositivo, sync |
| Formato de preço | Como o BaaS |
| Escolha quando | Produtos mobile-first que vivem de push, offline e estado por dispositivo |
| Abandone quando | Nunca separado do BaaS — é uma especialização, não um rival |

O *m* ainda faz por merecer a letra em três lugares. Push notifications não são uma chamada de API, e sim um relacionamento com os gateways das plataformas (APNs, FCM) — registro de tokens, direcionamento por dispositivo, semântica de entrega — que uma plataforma de nível mBaaS gerencia de ponta a ponta. Sincronização offline-first significa que o SDK é uma máquina de estados, não um wrapper fino de HTTP: persistência local, escritas enfileiradas, resolução de conflitos quando a conectividade volta. E o estado por dispositivo (installations, canais, segmentos) é um modelo de dados que apps web simplesmente não têm. Se esses três parágrafos descrevem o seu produto, a herança mobile da sua plataforma importa; se não, BaaS e mBaaS são a mesma compra.

## O que é SaaS (Software-as-a-Service)?

SaaS aluga software pronto — faça login e use. É o único degrau da escada que você *consome* em vez de *construir sobre*, e é por isso que compará-lo aos outros é uma mudança de categoria: os seis primeiros modelos respondem "quanto da stack do meu produto eu executo?"; o SaaS responde "isso deveria sequer existir como produto meu?". Seu CRM, seu e-mail e seu analytics são SaaS. No momento em que uma ferramenta precisa da sua lógica custom por dentro, você caiu do degrau SaaS e precisa de um abaixo.

| | Perfil do SaaS |
| --- | --- |
| Você implanta | Nada — você configura |
| O provedor executa | Tudo, exceto seus dados e sua política de acesso |
| Formato de preço | Por assento/mês |
| Escolha quando | O problema já foi produtizado e não é o seu diferencial |
| Abandone quando | Você precisa de um comportamento custom que o roadmap do fornecedor não compartilha |

O SaaS importa nesta comparação principalmente como *fronteira*: ele define como fica o "totalmente gerenciado" quando não sobra nada para programar — a direção para a qual todos os outros degraus vêm subindo há duas décadas. Ele também define o teto do discurso dos degraus de construção: quanto mais um BaaS chega perto de "o backend do seu produto parece SaaS desde o primeiro dia", mais a engenharia restante é exatamente a parte que diferencia você. A dependência é o preço: roadmap, preços e portabilidade de dados ficam do lado do fornecedor, com seus dados e sua política de acesso como as únicas linhas que nunca saem do seu.

## Como a escada cresceu

| Era | O que surgiu | O que passou a ser abstraído |
| --- | --- | --- |
| 2006–2009 | IaaS, depois PaaS | Comprar hardware; depois operar servidores |
| 2011 | NIST formaliza IaaS/PaaS/SaaS · mBaaS surge para apps mobile | As definições; depois o backend mobile |
| 2013–2014 | Containers viram mainstream → CaaS · primeiros runtimes FaaS | Imagens de máquina; depois o servidor sempre ligado |
| 2015–2020 | mBaaS se generaliza em BaaS · o guarda-chuva "serverless" é cunhado | O recorte mobile-only; depois o servidor como conceito |
| Hoje | Times adotam por padrão o degrau suficiente mais alto | O próximo candidato: o próprio boilerplate |

O padrão ao longo de duas décadas é unidirecional: cada novo modelo abstrai a camada que o anterior ainda expunha, e cada geração de times começa mais alto que a anterior. O mBaaS chegar *antes* do BaaS geral é a melhor curiosidade da escada — a restrição mobile (sem time de servidor, ciclos de release de app store) forçou primeiro a abstração mais alta, e o resto da indústria a alcançou depois.

## Pizza, estendida a sete degraus

A analogia clássica de ensino (cunhada pelo arquiteto de software Albert Barron em 2014) mapeia o trio para o jantar: on-prem é cozinhar em casa, IaaS é a pizza congelada para assar, PaaS é o delivery, SaaS é jantar fora. Os degraus mais novos a estendem naturalmente. **CaaS é alugar uma cozinha industrial com formas padronizadas** — suas receitas, embaladas do seu jeito, assadas no equipamento deles. **FaaS é pagar por fatia** — nenhuma pizza existe até você sentir fome, e você nunca paga por mesa vazia. **BaaS é o kit de refeição com tudo pronto, menos o seu toque de assinatura** — massa, molho e forno resolvidos; você adiciona a cobertura que faz o restaurante ser seu. E **mBaaS é o mesmo kit no tamanho de um food truck**: a restrição (mobile) moldou o kit primeiro, e todo mundo o adotou depois.

## IaaS vs. CaaS vs. PaaS vs. FaaS vs. BaaS vs. SaaS, comparados

| Dimensão | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- |
| Você gerencia | Do SO para cima | Containers + app | App + dados | Funções + dados | Lógica custom + dados | Configuração |
| Unidade de deploy | Máquina virtual | Container | Aplicação | Função | Muitas vezes nada (chamadas de SDK) | — |
| Scaling | Você configura | O provedor orquestra | A plataforma, por instância | Automático, a zero | Automático, atrás de APIs | Invisível |
| Formato de preço | Por recurso-hora | Por nó/container | Por instância/tier | Por invocação + tempo | Free tier + planos | Por assento/mês |
| Tempo até a primeira requisição | Dias | Horas | Horas | Minutos | **Minutos, com auth e dados incluídos** | Instantâneo |
| Pressão de lock-in | Baixa | Baixa-média | Média | Média-alta | Alta — a menos que open source | A mais alta |
| Melhor para | Controle total, workloads especiais | Microsserviços, stacks poliglotas | Apps de servidor custom | Computação orientada a eventos | Backends de app padrão | Consumir, não construir |

### Os pares que as pessoas realmente comparam

**IaaS vs. PaaS** — "queremos operar máquinas ou só entregar um app?" Escolha IaaS apenas quando o controle é o requisito; caso contrário, o PaaS apaga a carga do SO para cima pela mesma aplicação.

**IaaS vs. CaaS** — a mesma pergunta uma camada acima: rodar sua própria orquestração em máquinas alugadas, ou alugar a orquestração também? A menos que operar o control plane seja a sua especialidade, CaaS.

**CaaS vs. PaaS** — a unidade que você entrega: containers (qualquer stack, seu empacotamento, controle no nível da orquestração) vs. código de aplicação (os runtimes deles, as convenções deles, menos cerimônia). Microsserviços e parques poliglotas pendem para CaaS; um app padrão pende para PaaS.

**CaaS vs. FaaS** — persistência vs. eventos. Serviços de longa duração com tráfego entre serviços pertencem a containers; trabalho esporádico em formato de evento pertence a funções que escalam a zero. A maioria dos sistemas reais roda os dois.

**PaaS vs. BaaS** — a confusão mais profunda da escada, com [verbete completo](/glossary/pt/paas-vs-baas/): o PaaS hospeda o backend *que você ainda precisa escrever*; o BaaS apaga essa etapa para as funcionalidades padrão. Escrever o backend, ou ter um.

**FaaS vs. BaaS** — escopo da terceirização, dissecado em [BaaS vs. Serverless](/glossary/pt/baas-vs-serverless/): o FaaS terceiriza o runtime do código que você escreve; o BaaS terceiriza o backend para que a maior parte desse código nem exista. Plataformas BaaS maduras embutem FaaS, então na prática os degraus se combinam.

**BaaS vs. mBaaS** — [história vs. presente](/glossary/pt/mbaas-vs-baas/): o mesmo degrau, com origem mobile-first. Se o seu produto vive de push, offline e estado por dispositivo, o *m* ainda descreve os seus requisitos; as plataformas convergiram de qualquer forma.

**SaaS vs. todos os outros** — a mudança de categoria: todos os outros modelos são algo sobre o qual você constrói; o SaaS é algo sobre o qual você não constrói *nada*. Se um workload pode ser SaaS, esse é quase sempre o degrau suficiente mais barato — ele só deixa de ser software *seu*.

## Onde "serverless" se encaixa

Serverless não é um oitavo degrau — é o guarda-chuva sobre os dois degraus programáveis mais altos. A [definição canônica](https://martinfowler.com/articles/serverless.html) cobre tanto FaaS (seu código, executado sob demanda) quanto BaaS (serviços de backend prontos): em ambos, ninguém no seu time gerencia servidor, a capacidade escala sozinha e o custo acompanha o uso. Quando alguém diz "fomos de serverless", a pergunta da escada é *qual degrau*: funções que eles escreveram, um backend que não escreveram, ou — o mais comum — a combinação.

## Casos de uso comuns

- **IaaS:** migrações lift-and-shift, runtimes e hardware especializados, regimes de compliance que exigem controle da infraestrutura.
- **CaaS:** frotas de microsserviços, sistemas poliglotas, times que querem [orquestração de nível Kubernetes](/glossary/kubernetes/) sem operar o control plane.
- **PaaS:** aplicações web e APIs custom em que a lógica de backend *é* o produto, mantidas por times que querem deploy sem operação de servidores.
- **FaaS:** handlers de webhook, jobs agendados, pipelines de imagem e dados — trabalho orientado a eventos sem um backend completo ao redor.
- **BaaS:** backends de app completos com necessidades padrão — usuários, dados, arquivos, notificações — em especial para times frontend-first.
- **mBaaS:** o mesmo, mobile-first — produtos construídos sobre push, sync offline e estado por dispositivo.
- **SaaS:** tudo que a sua empresa usa mas não constrói — o degrau que você consome em vez de arquitetar sobre.

## Qual degrau você deveria escolher? Uma matriz de decisão

```mermaid
flowchart TD
  accTitle: Escolhendo um modelo de serviço em nuvem pelo que você implanta
  accDescr: Um fluxo de decisão. Se alguém já vende o produto, use SaaS. Se você está construindo e as necessidades de backend são padrão, use BaaS, ou mBaaS para produtos mobile-first. Se a lógica de backend é o produto, use PaaS para um app ou CaaS para microsserviços. Use FaaS para a cola orientada a eventos em qualquer caminho, e IaaS apenas quando o controle da infraestrutura é o próprio requisito.
  Q0{"O produto já existe<br/>pronto para comprar?"} -->|Sim| S["SaaS — consuma"]
  Q0 -->|"Não, estamos construindo"| Q1{"As necessidades de backend são padrão?<br/>(usuários, dados, arquivos, push)"}
  Q1 -->|Sim| B["BaaS — mBaaS se mobile-first"]
  Q1 -->|"Não — a lógica de backend É o produto"| Q2{"Um app ou muitos serviços?"}
  Q2 -->|Um app| P["PaaS"]
  Q2 -->|"Microsserviços / poliglota"| C["CaaS"]
  Q1 -.->|"Trabalho lateral orientado a eventos"| F["FaaS — em qualquer caminho"]
  Q2 -.->|"Controle da infraestrutura é o requisito"| I["IaaS"]
```

| Se você é… | Comece em | Porque |
| --- | --- | --- |
| Um time de frontend ou mobile entregando um produto | BaaS / mBaaS | O backend padrão existe no primeiro dia; escreva só o que é único |
| Um time de backend com um codebase de servidor custom | PaaS | Controle total do código, nenhuma máquina |
| Quem opera um parque de microsserviços ou poliglota | CaaS | Orquestração sem operar o control plane |
| Quem automatiza eventos, cola e trabalho agendado | FaaS | Pague só quando algo acontece |
| Quem roda sistemas legados ou hardware especial | IaaS | O controle dos degraus de baixo é o requisito |
| Quem resolve um problema que alguém já produtizou | SaaS | Construir isso é uma distração |

Duas regras honestas por cima: adote por padrão o degrau mais alto que servir (cada passo para baixo recontrata trabalho operacional) e reavalie por workload — empresas vivem em vários degraus ao mesmo tempo, de propósito.

## Limitações e trade-offs

- **IaaS:** o preço unitário lisonjeia; o headcount de operações para aplicar patches, escalar e proteger tudo é a fatura real.
- **CaaS:** você terceirizou o control plane, não a complexidade — imagens, manifestos, service meshes e pipelines de deployment continuam sendo uma disciplina de engenharia.
- **PaaS:** você ainda mantém uma aplicação inteira — cada upgrade de dependência e bug de auth incluídos — além das convenções no formato da plataforma.
- **FaaS:** cold starts, limites de execução e um preço por invocação que fica hostil sob carga alta sustentada.
- **BaaS / mBaaS:** um teto de customização para requisitos muito fora do padrão, e o [lock-in](/glossary/cloud-vendor-lock-in/) mais forte da escada *quando proprietário* — a razão pela qual plataformas baseadas em open source importam: elas mantêm a saída real.
- **SaaS:** dependência total — roadmap, preços e portabilidade de dados vivem nas decisões de outra pessoa.
- **Todos eles:** a linha de responsabilidade compartilhada se move, mas nunca passa dos seus dados, da sua política de acesso e do seu julgamento.

## Modelos de serviço em nuvem 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 ocupa o degrau do BaaS — completo como mBaaS, com push e SDKs mobile de primeira classe — e se resguarda deliberadamente nas duas direções. Para cima: o backend padrão já vem pronto, então o primeiro dia tem a imediatez de um SaaS para o seu próprio produto. Para baixo: as funções, os triggers e os jobs agendados do [Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions) dão a você o degrau FaaS dentro da plataforma, e a mesma empresa documenta o [degrau CaaS](https://blog.back4app.com/containers-as-a-service/) para workloads que precisam de containers. E como a stack é open source, o pior modo de falha da escada — lock-in no topo — vem com um caminho de descida documentado: auto-hospedar o mesmo backend em qualquer degrau abaixo, sem reescrita.