Modelos de serviço em nuvem comparados: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS e SaaS

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

O que “subir o backend” significa em cada degrau

# 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 / 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 — Back4app Flutter SDK
final order = ParseObject('Order')
  ..set('total', 129.9)
  ..set('status', 'paid');
await order.save(); // schema, API, auth, scaling handled below you

// 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")
  }
}

// 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

A definição de computação em nuvem do NIST 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:

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.

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 — qualquer linguagem, qualquer stack — e o provedor executa o scheduler, a rede entre serviços e a maquinaria de scaling, tipicamente 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 e parques poliglotas que sofreriam com as convenções de um PaaS.

A sutileza que separa o CaaS de um tutorial de 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 disseca.

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, permissões, migrações, rate limits — 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 — nada roda, e nada é cobrado, até que algo aconteça. Os custos são arquiteturais: 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.

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, o armazenamento de arquivos, as APIs geradas automaticamente e as push notifications chegam prontos e gerenciados, consumidos por SDKs de cliente — 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 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, e a questão do lock-in — a fraqueza honesta do degrau — depende de a plataforma ser open source ou proprietária.

O que o BaaS remove é infraestrutura e boilerplate, não engenharia: seu modelo de dados, suas regras de segurança 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, SDKs cientes do dispositivo e sincronização offline 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.

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.

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

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

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: 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: 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: 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 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 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

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 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 dão a você o degrau FaaS dentro da plataforma, e a mesma empresa documenta o degrau CaaS 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.