Cloud Service Models Compared: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS & SaaS

The cloud service-model spectrum is a ladder — IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS — ranked by how much the provider runs for you. Every “aaS” answers the same question with a different line: you build above this line; we run below it. Most explainers stop at the classic trio the NIST definition formalized — IaaS, PaaS, SaaS — and skip the rungs where modern products actually live. This guide covers all seven, defines each one properly, and then compares the pairs people genuinely confuse. Pick the rung, and you’ve picked what your team spends its life maintaining.

Key takeaways

What “launch the backend” means at each rung

# The same task — get a backend serving requests — one rung at a time
# IaaS — you get machines:
$ ssh admin@vm-01              # then: install, configure, patch, scale, monitor…
# CaaS — you get orchestration:
$ docker push registry/api:v1  # your containers; their scheduler, networking, scaling
# PaaS — you get a platform:
$ git push platform main       # your app code; their servers, runtime, scaling
# FaaS — you get a per-event runtime:
$ deploy functions/api.js      # your functions; run on demand, scale to zero
# BaaS / mBaaS — you get the backend itself:
#   nothing to deploy — auth, database, and APIs are already running
# SaaS — you get the finished product:
#   nothing to build — sign in and use it

The BaaS rung deserves proof, because “nothing to deploy” sounds like marketing. Saving an order to a production backend — schema, API, access control, and scaling all provider-side — is one client-side call:

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

The seven models on one ladder

The NIST definition of cloud computing formalized the classic three rungs in 2011 — IaaS (“provision processing, storage, networks”), PaaS (“deploy consumer-created applications using provider-supported tools”), SaaS (“use the provider’s applications”) — before CaaS, FaaS, and BaaS existed as categories. The newer rungs slot into the gaps NIST left: CaaS between IaaS and PaaS, FaaS and BaaS between PaaS and SaaS — still programmable, but with progressively less of the program being yours.

Who manages what: the responsibility matrix

The whole subject in one table. Read a column top to bottom to see what a model leaves on your plate:

Two things the matrix makes visible that prose usually hides: the bottom row never transfers — your data and identity practices are yours on every rung, even SaaS — and each model’s name is just the highest layer where “Provider” begins.

What is IaaS (Infrastructure-as-a-Service)?

IaaS rents virtualized infrastructure — machines, block storage, networks — by the hour. Everything above the hypervisor is yours: operating system, patching, runtime, scaling logic, and the 3 a.m. pager. It is the rung of maximum control and maximum operational surface, covered in depth in the IaaS entry.

What day two looks like is the honest test of the rung. On IaaS, day two is OS patch windows, kernel upgrades, disk-space alarms, security-group audits, capacity planning, and building the monitoring that every higher rung includes for free. None of that is your product. The rung earns its keep in exactly three situations: hardware or runtimes no platform offers, compliance regimes that mandate infrastructure control, and sustained scale large enough that raw unit price beats managed margins after you price in the team that operates it — a bar far higher than most teams assume.

What is CaaS (Containers-as-a-Service)?

CaaS rents the layer most explainers skip: you package services as containers — any language, any stack — and the provider runs the scheduler, service networking, and scaling machinery, typically Kubernetes or an equivalent. It sits deliberately between IaaS and PaaS: more abstract than machines, less opinionated than a platform. That makes it the natural home for microservices and polyglot estates that would chafe against PaaS conventions.

The subtlety that separates CaaS from a hosted Kubernetes tutorial: what transfers is the control plane — schedulers, etcd, API servers, node health — while everything expressed in images and manifests stays yours: base-image hygiene, resource requests, liveness probes, deployment strategy, service topology. That’s a real discipline, which is precisely why the rung exists as a distinct offering: teams who need that expressiveness but have no appetite for operating the machinery underneath it. The container itself is the portability story — the same image runs on any conformant orchestrator, which keeps CaaS among the lowest-lock-in rungs on the ladder.

What is PaaS (Platform-as-a-Service)?

PaaS rents a managed application platform: you push code, the provider supplies the runtime, scaling, and operating system underneath. The trade is convention for ceremony — supported languages and platform idioms in exchange for git push deployment. The critical thing PaaS does not remove: you still write and own the entire backend application — auth, endpoints, validation, all of it — a distinction the PaaS vs. BaaS entry dissects.

The PaaS contract shaped a generation of good habits — twelve-factor apps, config in the environment, stateless processes, logs as streams — because the platform enforces what was previously just advice. Its boundary is equally instructive: the platform runs your application but knows nothing about what’s inside it, so every backend concern — sessions, permissions, migrations, rate limits — is still code you write, test, and patch. That’s the tell for when you’re on the wrong rung: if most of your PaaS-hosted codebase is re-implementing users, CRUD, and file uploads, you’re hand-building the rung above.

What is FaaS (Functions-as-a-Service)?

FaaS rents compute by the event: you deploy individual functions, the provider runs each invocation on demand and scales to zero between them. It is the purest expression of serverless compute — nothing runs, and nothing bills, until something happens. The costs are architectural: cold starts, execution limits, and statelessness that pushes all persistence elsewhere. How functions compare to running your own services fleet is the functions vs. microservices question.

Statelessness is the load-bearing constraint: a function may be destroyed after any invocation, so everything durable — sessions, files, queues, data — must live in services around the function. Followed to its conclusion, that constraint quietly assembles a BaaS: functions for logic, managed services for everything stateful. This is why the two rungs converged in practice, and why open-source runtimes (Knative, OpenFaaS) exist for teams that want the per-event model on their own orchestration. Pricing follows the same event-shaped logic — free when idle is unbeatable for spiky traffic and punishing for steady load, the inversion every FaaS bill eventually teaches.

What is BaaS (Backend-as-a-Service)?

BaaS rents the backend itself. The database, authentication, file storage, auto-generated APIs, and push notifications arrive pre-built and managed, consumed from client SDKs — for standard features there is no server-side code to write at all, as the code sample above demonstrates. Custom logic runs in embedded cloud functions, which is why mature BaaS platforms contain the FaaS rung rather than competing with it. The build-vs-buy version of this decision has its own entry, and the lock-in question — the rung’s honest weakness — turns on whether the platform is open source or proprietary.

What BaaS removes is infrastructure and boilerplate, not engineering: your data model, your security rules, and your business logic remain decisions no platform makes for you. The rung’s economics are the sharpest on the ladder — minutes to a working backend, near-zero upfront cost — and so is its structural risk: on a proprietary platform, data schema, auth, and functions all live in vendor-shaped form, making BaaS the strongest lock-in of the programmable rungs. The open-source variant dissolves exactly that: when the same platform self-hosts, leaving means relocating, not rewriting. The AI era has also widened the rung’s audience — generated frontends need real backends fast, and a pre-built, permissioned one is the shape that fits.

What is mBaaS (Mobile Backend-as-a-Service)?

mBaaS is where the BaaS category began: a pre-built backend aimed specifically at mobile apps, with push notifications, device-aware SDKs, and offline synchronization as first-class features rather than add-ons. As single-page web apps became client-first too, the model generalized and the m quietly dropped — today every serious platform serves web and mobile from the same backend. When the distinction still matters — and when it’s just historical residue — is the subject of the mBaaS vs. BaaS entry.

The m still earns its letter in three places. Push notifications are not an API call but a relationship with the platform gateways (APNs, FCM) — token registration, device targeting, delivery semantics — that an mBaaS-grade platform manages end to end. Offline-first sync means the SDK is a state machine, not a thin HTTP wrapper: local persistence, queued writes, conflict handling when connectivity returns. And per-device state (installations, channels, segments) is a data model web apps simply don’t have. If those three paragraphs describe your product, the mobile heritage of your platform matters; if not, BaaS and mBaaS are the same purchase.

What is SaaS (Software-as-a-Service)?

SaaS rents finished software — sign in and use it. It is the only rung on the ladder you consume rather than build on, which is why comparing it to the others is a category shift: the first six models answer “how much of my product’s stack do I run?”; SaaS answers “should this exist as my product at all?” Your CRM, email, and analytics are SaaS. The moment a tool needs your custom logic inside it, you’ve fallen off the SaaS rung and need one below.

SaaS matters to this comparison mostly as a boundary: it defines what “fully managed” looks like when there’s nothing left to program, which is the direction every other rung has been climbing toward for two decades. It also sets the ceiling for the builder rungs’ pitch — the closer a BaaS gets to “your product’s backend feels like SaaS from day one,” the more the remaining engineering is exactly the part that differentiates you. The dependence is the price: roadmap, pricing, and data portability sit on the vendor’s side of the line, with your data and access policy the only rows that never leave yours.

How the ladder grew

The pattern across two decades is one-directional: each new model abstracts the layer the previous one still exposed, and each generation of teams starts higher than the last. mBaaS arriving before general BaaS is the ladder’s best trivia — the mobile constraint (no server team, app-store release cycles) forced the highest abstraction first, and the rest of the industry caught up to it.

Pizza, extended to seven rungs

The classic teaching analogy (coined by software architect Albert Barron in 2014) maps the trio to dinner: on-prem is cooking at home, IaaS is take-and-bake, PaaS is delivery, SaaS is dining out. The newer rungs extend it naturally. CaaS is renting a commercial kitchen with standardized pans — your recipes, packed your way, cooked on their equipment. FaaS is paying per slice — no pie exists until you’re hungry, and you never pay for an empty table. BaaS is the meal kit with everything pre-made except your signature touch — dough, sauce, and oven handled; you add the topping that makes it your restaurant. And mBaaS is that same kit sized for a food truck: the constraint (mobile) shaped the kit first, and everyone else adopted it after.

IaaS vs. CaaS vs. PaaS vs. FaaS vs. BaaS vs. SaaS, compared

The pairs people actually compare

IaaS vs. PaaS — “do we want to operate machines or just ship an app?” Choose IaaS only when the control is the requirement; otherwise PaaS deletes the OS-and-up burden for the same application.

IaaS vs. CaaS — the same question one layer up: run your own orchestration on rented machines, or rent the orchestration too? Unless operating the control plane is your specialty, CaaS.

CaaS vs. PaaS — the unit you hand over: containers (any stack, your packaging, orchestration-level control) vs. application code (their runtimes, their conventions, less ceremony). Microservices and polyglot estates lean CaaS; one standard app leans PaaS.

CaaS vs. FaaS — persistence vs. events. Long-running services with inter-service traffic belong in containers; sporadic, event-shaped work belongs in functions that scale to zero. Most real systems run both.

PaaS vs. BaaS — the deepest confusion on the ladder, with a full entry: PaaS hosts the backend you still have to write; BaaS deletes that step for standard features. Write the backend, or have one.

FaaS vs. BaaS — scope of outsourcing, dissected in BaaS vs. Serverless: FaaS outsources the runtime for code you write; BaaS outsources the backend so most of that code never exists. Mature BaaS platforms embed FaaS, so in practice the rungs combine.

BaaS vs. mBaaS — history vs. present: same rung, mobile-first origin. If your product lives on push, offline, and device state, the m still describes your requirements; the platforms converged regardless.

SaaS vs. all of them — the category shift: every other model is something you build on; SaaS is something you build nothing on. If a workload can be SaaS, that’s almost always the cheapest sufficient rung — it just stops being your software.

Where “serverless” fits

Serverless is not an eighth rung — it’s the umbrella over the two highest programmable ones. The canonical definition covers both FaaS (your code, run on demand) and BaaS (pre-built backend services): in both, nobody in your team manages a server, capacity scales automatically, and cost tracks usage. When someone says “we went serverless,” the ladder question to ask is which rung: functions they wrote, a backend they didn’t, or — most commonly — the combination.

Common use cases

• IaaS: lift-and-shift migrations, specialized runtimes and hardware, compliance regimes that demand infrastructure control.
• CaaS: microservice fleets, polyglot systems, teams that want Kubernetes-grade orchestration without operating the control plane.
• PaaS: custom web applications and APIs where the backend logic is the product, run by teams that want deployment without server operations.
• FaaS: webhook handlers, scheduled jobs, image and data pipelines — event-driven work with no full backend around it.
• BaaS: complete app backends with standard needs — users, data, files, notifications — especially for frontend-first teams.
• mBaaS: the same, mobile-first — products built on push, offline sync, and per-device state.
• SaaS: everything your company uses but doesn’t build — the rung you consume rather than architect on.

Which rung should you choose? A decision matrix

Two honest rules stack on top: default to the highest rung that fits (each step down re-hires operational work), and re-evaluate per workload — companies live on several rungs at once, by design.

Limitations and trade-offs

• IaaS: the unit price flatters you; the ops headcount to patch, scale, and secure it is the real bill.
• CaaS: you’ve outsourced the control plane, not the complexity — images, manifests, service meshes, and deployment pipelines are still an engineering discipline.
• PaaS: you still own an entire application — every dependency upgrade and auth bug included — plus platform-shaped conventions.
• FaaS: cold starts, execution limits, and per-invocation pricing that turns hostile under sustained heavy load.
• BaaS / mBaaS: a customization ceiling for far-off-standard requirements, and the strongest lock-in on the ladder when proprietary — the reason open-source-based platforms matter: they keep the exit real.
• SaaS: total dependence — roadmap, pricing, and data portability all live on someone else’s decisions.
• All of them: the shared-responsibility line moves, but never past your data, your access policy, and your judgment.

Where Back4app sits on the ladder

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. It occupies the BaaS rung — mBaaS-complete, with push and mobile SDKs first-class — and hedges deliberately in both directions. Upward: the standard backend is pre-built, so day one feels SaaS-immediate for your own product. Downward: Cloud Code functions, triggers, and scheduled jobs give you the FaaS rung inside the platform, and the same company documents the CaaS rung for workloads that need containers. And because the stack is open source, the ladder’s worst failure mode — lock-in at the top — comes with a documented way down: self-host the same backend on any rung below, without a rewrite.