---
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: Full Guide'
headline: 'Cloud Service Models Compared: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS & SaaS'
slug: iaas-paas-baas-faas
category: cloud-architecture
shortDefinition: 'The cloud service-model spectrum is a ladder — IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS — ranked by how much the provider runs for you.'
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: 'What is the main difference between IaaS, PaaS, and SaaS?'
    answer: 'Who manages what. IaaS rents infrastructure — virtual machines, storage, networks — and everything from the operating system up is yours. PaaS rents a managed platform: you bring application code and data, the provider runs the rest. SaaS delivers finished software you simply use. Each step up the ladder trades control for speed and lower operational burden.'
  - question: 'Where do CaaS, FaaS, and BaaS fit between IaaS and SaaS?'
    answer: 'On the rungs the classic trio skips. CaaS sits between IaaS and PaaS: you ship containers, the provider runs the orchestration. FaaS sits above PaaS: you ship individual functions that run per event. BaaS goes furthest while staying programmable: the backend itself — database, auth, storage, APIs — comes pre-built, so standard features need no server-side code at all.'
  - question: 'Does BaaS mean Backend-as-a-Service or Backup-as-a-Service?'
    answer: 'In application development, BaaS almost always means Backend-as-a-Service — a pre-built app backend consumed through SDKs. A minority of enterprise-storage contexts use the same acronym for Backup-as-a-Service, which is unrelated: managed data backups. If the discussion involves mobile apps, APIs, or app platforms, read BaaS as backend. Context resolves it; this page covers the backend meaning.'
  - question: 'What is the difference between CaaS and PaaS?'
    answer: 'The unit you hand the provider. On CaaS you hand containers — any language, any stack, packaged your way — and keep control of orchestration choices. On PaaS you hand application code and accept the platform''s supported runtimes and conventions in exchange for a simpler push-to-deploy workflow. CaaS fits microservices and polyglot stacks; PaaS fits standard apps that want the least ceremony.'
  - question: 'Is FaaS the same as serverless?'
    answer: 'FaaS is one half of serverless, not a synonym. The canonical definition — from Mike Roberts on martinfowler.com — treats serverless as an umbrella covering both FaaS (your functions, run on demand) and BaaS (pre-built backend services). Colloquially "serverless" often means just FaaS, which is why the terms get tangled.'
  - question: 'What is the difference between BaaS and mBaaS?'
    answer: 'mBaaS is where the category started — a pre-built backend aimed specifically at mobile apps, with push notifications, device-aware SDKs, and offline sync as first-class features. As web apps became client-first too, the model generalized and dropped the m. Today every serious mBaaS serves web equally, so the terms mostly name the same platforms with different emphasis.'
  - question: 'Which cloud service model is cheapest?'
    answer: 'It depends on workload shape, not the model. FaaS is cheapest for spiky or low traffic because idle cost is zero, and expensive at sustained heavy load. IaaS has the best raw unit price at large stable scale but carries the hidden cost of the ops team to run it. CaaS, PaaS, and BaaS sit between, trading a platform margin for eliminated engineering time — which for small teams is usually the dominant cost.'
  - question: 'Can you combine multiple service models?'
    answer: 'Almost every real company does. A typical stack: SaaS for business tools, BaaS or PaaS to run the product, FaaS for event-driven glue, CaaS for the containerized services that need orchestration control, and IaaS for the rare specialized workload. The models are rungs to place each workload on individually — the practical skill is matching each workload to its cheapest sufficient rung.'
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: 'Start at the top of the ladder'
  text: 'Back4app puts you on the BaaS rung from day one — database, auth, storage, and APIs pre-built, with Cloud Code functions when you need the FaaS rung too. Built on open source, so climbing back down stays possible.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-23'
modifiedDate: '2026-08-11'
translationKey: iaas-paas-baas-faas
---

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

| Question | Answer |
| --- | --- |
| One-line ladder | IaaS: rent machines · CaaS: rent orchestration · PaaS: rent the platform · FaaS: rent per function run · BaaS: rent the backend · mBaaS: rent the mobile backend · SaaS: rent the finished app |
| The real variable | Where the you-manage / provider-manages line sits |
| The unit you deploy | VM → container → application → function → data model → nothing |
| Serverless? | The umbrella over FaaS *and* BaaS — not a rung of its own |
| Which is best | Wrong question — match each workload to its cheapest sufficient rung |
| The trend | Teams start higher up the ladder every year |

## What "launch the backend" means at each rung

```bash
# 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:**

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

## The seven models on one ladder

```mermaid
flowchart LR
  accTitle: The as-a-service ladder with seven rungs
  accDescr: Eight steps from on-premises through IaaS, CaaS, PaaS, FaaS, and BaaS with its mobile specialization mBaaS, to SaaS — each renting more from the provider; the machines, the container orchestration, the platform, per-run functions, the backend, and finally the finished application.
  A["On-premises"] --> B["IaaS<br/>rent the machines"]
  B --> C["CaaS<br/>rent the orchestration"]
  C --> D["PaaS<br/>rent the platform"]
  D --> E["FaaS<br/>rent per function run"]
  E --> F["BaaS · mBaaS<br/>rent the backend"]
  F --> G["SaaS<br/>rent the finished app"]
```

The [NIST definition of cloud computing](https://csrc.nist.gov/pubs/sp/800/145/final) 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:

| Layer | On-prem | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Business logic | You | You | You | You | You (as functions) | Only custom logic | Provider |
| Backend features (auth, CRUD, storage, push) | You | You | You | You | You | **Provider** | Provider |
| App packaging & runtime | You | You | You (containers) | Provider | Provider | Provider | Provider |
| Orchestration & scaling | You | You | **Provider** | Provider | Provider (to zero) | Provider | Provider |
| OS & patching | You | You | Provider | Provider | Provider | Provider | Provider |
| Servers, network, hardware | You | **Provider** | Provider | Provider | Provider | Provider | Provider |
| Your data & access policy | You | You | You | You | You | You | **Still you** |

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](/glossary/infrastructure-as-a-service/).

| | IaaS profile |
| --- | --- |
| You deploy | Virtual machines and everything on them |
| Provider runs | Physical hardware, virtualization, network fabric |
| Pricing shape | Per resource-hour, whether used or idle |
| Choose it when | Special hardware/runtimes, strict infrastructure control, lift-and-shift |
| Walk away when | The ops headcount costs more than the control is worth |

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](/glossary/containerization/) — any language, any stack — and the provider runs the scheduler, service networking, and scaling machinery, typically [Kubernetes](/glossary/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](/glossary/microservices-vs-monolith/) and polyglot estates that would chafe against PaaS conventions.

| | CaaS profile |
| --- | --- |
| You deploy | Container images, deployment manifests |
| Provider runs | Orchestration control plane, nodes, networking |
| Pricing shape | Per node/cluster or per running container |
| Choose it when | Microservices, polyglot stacks, orchestration control without cluster ops |
| Walk away when | One standard app — a PaaS or BaaS is less machinery for the same result |

The subtlety that separates CaaS from a hosted [Kubernetes](/glossary/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](/glossary/paas-vs-baas/) dissects.

| | PaaS profile |
| --- | --- |
| You deploy | Application code |
| Provider runs | Runtime, OS, servers, scaling |
| Pricing shape | Per instance/tier |
| Choose it when | Custom server apps where backend logic is the product |
| Walk away when | You're writing standard backend features a BaaS already ships |

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](/glossary/session-management/), permissions, migrations, [rate limits](/glossary/api-rate-limiting-throttling/) — 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](/glossary/serverless-architecture/) — nothing runs, and nothing bills, until something happens. The costs are architectural: [cold starts](/glossary/serverless-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](/glossary/serverless-functions-vs-microservices/) question.

| | FaaS profile |
| --- | --- |
| You deploy | Individual functions |
| Provider runs | Everything else, per invocation |
| Pricing shape | Per invocation + execution time; idle = zero |
| Choose it when | Event-driven work: webhooks, jobs, pipelines, glue |
| Walk away when | Sustained heavy load — per-invocation pricing inverts |

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](/glossary/authentication-vs-authorization/), file storage, [auto-generated APIs](/glossary/auto-generated-database-apis/), and push notifications arrive pre-built and managed, consumed from [client SDKs](/glossary/backend-sdk/) — 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](/glossary/cloud-code-serverless-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](/glossary/baas-vs-custom-backend/), and the lock-in question — the rung's honest weakness — turns on whether the platform is [open source or proprietary](/glossary/open-source-vs-proprietary-baas/).

| | BaaS profile |
| --- | --- |
| You deploy | A data model, security rules, custom functions — often nothing else |
| Provider runs | The entire standard backend, behind SDKs and APIs |
| Pricing shape | Free tier + usage/plans |
| Choose it when | Standard app backends — users, data, files — and speed matters |
| Walk away when | The backend logic *is* the product, or requirements are far off-standard |

What BaaS removes is *infrastructure and boilerplate*, not engineering: your [data model](/glossary/data-modeling/), your [security rules](/glossary/access-control-lists-acl/), 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](/glossary/push-notifications-apns-fcm/), device-aware SDKs, and [offline synchronization](/glossary/offline-first-data-sync/) 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](/glossary/mbaas-vs-baas/).

| | mBaaS profile |
| --- | --- |
| You deploy | The same as BaaS, via mobile-native SDKs |
| Provider runs | The backend, plus mobile plumbing: push gateways, device state, sync |
| Pricing shape | As BaaS |
| Choose it when | Mobile-first products living on push, offline, and per-device state |
| Walk away when | Never separately from BaaS — it's a specialization, not a rival |

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 profile |
| --- | --- |
| You deploy | Nothing — you configure |
| Provider runs | Everything except your data and access policy |
| Pricing shape | Per seat/month |
| Choose it when | The problem is already productized and isn't your differentiator |
| Walk away when | You need custom behavior the vendor's roadmap doesn't share |

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

| Era | What appeared | What it abstracted away |
| --- | --- | --- |
| 2006–2009 | IaaS, then PaaS | Buying hardware; then operating servers |
| 2011 | NIST formalizes IaaS/PaaS/SaaS · mBaaS emerges for mobile apps | The definitions; then the mobile backend |
| 2013–2014 | Containers go mainstream → CaaS · first FaaS runtimes | Machine images; then the always-on server |
| 2015–2020 | mBaaS generalizes to BaaS · "serverless" umbrella coined | The mobile-only framing; then the server as a concept |
| Today | Teams default to the highest sufficient rung | The next candidate: the boilerplate itself |

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

| Dimension | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- |
| You manage | OS and up | Containers + app | App + data | Functions + data | Custom logic + data | Configuration |
| Unit of deployment | Virtual machine | Container | Application | Function | Often nothing (SDK calls) | — |
| Scaling | You configure | Provider orchestrates | Platform, per instance | Automatic, to zero | Automatic behind APIs | Invisible |
| Pricing shape | Per resource-hour | Per node/container | Per instance/tier | Per invocation + time | Free tier + plans | Per seat/month |
| Time to first request | Days | Hours | Hours | Minutes | **Minutes, with auth and data included** | Instant |
| Lock-in pressure | Low | Low-medium | Medium | Medium-high | High — unless open source | Highest |
| Best for | Full control, special workloads | Microservices, polyglot stacks | Custom server apps | Event-driven compute | Standard app backends | Consuming, not building |

### 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](/glossary/paas-vs-baas/): 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](/glossary/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](/glossary/mbaas-vs-baas/): 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](https://martinfowler.com/articles/serverless.html) 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](/glossary/kubernetes/) 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

```mermaid
flowchart TD
  accTitle: Choosing a cloud service model by what you deploy
  accDescr: A decision flow. If someone already sells the product, use SaaS. If you are building and your backend needs are standard, use BaaS or mBaaS for mobile-first products. If the backend logic is the product, use PaaS for one app or CaaS for microservices. Use FaaS for event-driven glue on any path, and IaaS only when infrastructure control is itself the requirement.
  Q0{"Does the product<br/>already exist to buy?"} -->|Yes| S["SaaS — consume it"]
  Q0 -->|No, we're building| Q1{"Are the backend needs standard?<br/>(users, data, files, push)"}
  Q1 -->|Yes| B["BaaS — mBaaS if mobile-first"]
  Q1 -->|"No — backend logic IS the product"| Q2{"One app or many services?"}
  Q2 -->|One app| P["PaaS"]
  Q2 -->|Microservices / polyglot| C["CaaS"]
  Q1 -.->|Event-driven side work| F["FaaS — on any path"]
  Q2 -.->|Infrastructure control is the requirement| I["IaaS"]
```

| If you are… | Start at | Because |
| --- | --- | --- |
| A frontend or mobile team shipping a product | BaaS / mBaaS | The standard backend exists on day one; write only what's unique |
| A backend team with one custom server codebase | PaaS | Full control of the code, none of the machines |
| Running a microservice or polyglot estate | CaaS | Orchestration without operating the control plane |
| Automating events, glue, and scheduled work | FaaS | Pay only when something happens |
| Running legacy systems or special hardware | IaaS | The lower rungs' control is the requirement |
| Solving a problem someone already productized | SaaS | Building it is a distraction |

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](/glossary/cloud-vendor-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](https://www.back4app.com/docs/get-started/cloud-functions) functions, triggers, and scheduled jobs give you the FaaS rung inside the platform, and the same company documents the [CaaS rung](https://blog.back4app.com/containers-as-a-service/) 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.