Cloud-Servicemodelle im Vergleich: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS und SaaS

Das Spektrum der Cloud-Servicemodelle ist eine Leiter aus IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS und SaaS, geordnet danach, wie viel der Anbieter für Sie betreibt. Jedes “aaS” beantwortet dieselbe Frage mit einer anderen Trennlinie: Oberhalb dieser Linie bauen Sie, unterhalb betreiben wir. Die meisten Erklärungen enden beim klassischen Trio, das die NIST-Definition festgeschrieben hat — IaaS, PaaS, SaaS — und überspringen genau die Sprossen, auf denen moderne Produkte tatsächlich laufen. Dieser Leitfaden behandelt alle sieben, definiert jedes Modell sauber und vergleicht dann die Paare, die tatsächlich verwechselt werden. Mit der Wahl der Sprosse legen Sie fest, womit Ihr Team seine Zeit in der Wartung verbringt.

Das Wichtigste in Kürze

Was “das Backend starten” auf jeder Sprosse bedeutet

# Dieselbe Aufgabe — ein Backend, das Anfragen bedient — Sprosse für Sprosse
# IaaS — Sie bekommen Maschinen:
$ ssh admin@vm-01              # dann: installieren, konfigurieren, patchen, skalieren, überwachen…
# CaaS — Sie bekommen Orchestrierung:
$ docker push registry/api:v1  # Ihre Container; deren Scheduler, Netzwerk, Skalierung
# PaaS — Sie bekommen eine Plattform:
$ git push platform main       # Ihr App-Code; deren Server, Runtime, Skalierung
# FaaS — Sie bekommen eine Runtime pro Ereignis:
$ deploy functions/api.js      # Ihre Funktionen; laufen bei Bedarf, skalieren auf null
# BaaS / mBaaS — Sie bekommen das Backend selbst:
#   nichts zu deployen — Authentifizierung, Datenbank und APIs laufen bereits
# SaaS — Sie bekommen das fertige Produkt:
#   nichts zu bauen — anmelden und nutzen

Die BaaS-Sprosse verdient einen Beleg, denn “nichts zu deployen” klingt nach Marketing. Eine Bestellung in einem Produktions-Backend zu speichern — Schema, API, Zugriffskontrolle und Skalierung liegen komplett beim Anbieter — ist ein einziger clientseitiger Aufruf:

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

Die sieben Modelle auf einer Leiter

Die NIST-Definition von Cloud Computing hat 2011 die drei klassischen Sprossen festgeschrieben — IaaS (Rechenleistung, Speicher und Netzwerke bereitstellen), PaaS (vom Kunden erstellte Anwendungen mit vom Anbieter unterstützten Werkzeugen deployen), SaaS (die Anwendungen des Anbieters nutzen) —, bevor CaaS, FaaS und BaaS als Kategorien existierten. Die neueren Sprossen füllen die Lücken, die NIST gelassen hat: CaaS zwischen IaaS und PaaS, FaaS und BaaS zwischen PaaS und SaaS — weiterhin programmierbar, aber mit einem immer kleineren Anteil des Programms, der Ihnen gehört.

Wer verwaltet was: die Verantwortungsmatrix

Das gesamte Thema in einer Tabelle. Lesen Sie eine Spalte von oben nach unten, um zu sehen, was ein Modell bei Ihnen belässt:

Zwei Dinge macht die Matrix sichtbar, die Fließtext meist verbirgt: Die unterste Zeile wandert nie ab — Ihre Daten und Ihre Identitätspraktiken bleiben auf jeder Sprosse Ihre Sache, selbst bei SaaS —, und der Name jedes Modells ist schlicht die höchste Schicht, ab der “Anbieter” beginnt.

Was ist IaaS (Infrastructure-as-a-Service)?

IaaS vermietet virtualisierte Infrastruktur — Maschinen, Block-Storage, Netzwerke — stundenweise. Alles oberhalb des Hypervisors gehört Ihnen: Betriebssystem, Patches, Runtime, Skalierungslogik und der Pager um drei Uhr nachts. Es ist die Sprosse mit maximaler Kontrolle und maximaler Betriebsfläche, ausführlich behandelt im IaaS-Eintrag.

Der ehrliche Test dieser Sprosse ist der Alltag nach dem Launch. Auf IaaS heißt das: Patch-Fenster für das Betriebssystem, Kernel-Upgrades, Speicherplatz-Alarme, Audits der Security Groups, Kapazitätsplanung und der Aufbau des Monitorings, das jede höhere Sprosse ohne Aufpreis mitbringt. Nichts davon ist Ihr Produkt. Die Sprosse lohnt sich in genau drei Situationen: Hardware oder Runtimes, die keine Plattform anbietet, Compliance-Vorgaben, die Kontrolle über die Infrastruktur verlangen, und dauerhafte Last, die groß genug ist, dass der reine Stückpreis die Margen verwalteter Angebote schlägt — nachdem Sie das Team eingerechnet haben, das alles betreibt. Diese Hürde liegt weit höher, als die meisten Teams annehmen.

Was ist CaaS (Containers-as-a-Service)?

CaaS vermietet die Schicht, die die meisten Erklärungen überspringen: Sie paketieren Dienste als Container — jede Sprache, jeder Stack —, und der Anbieter betreibt den Scheduler, das Service-Networking und die Skalierungsmechanik, typischerweise Kubernetes oder ein Äquivalent. CaaS liegt bewusst zwischen IaaS und PaaS: abstrakter als Maschinen, weniger vorgegeben als eine Plattform. Damit ist es das natürliche Zuhause für Microservices und polyglotte Landschaften, die sich an PaaS-Konventionen reiben würden.

Die Feinheit, die CaaS von einem gehosteten Kubernetes-Tutorial unterscheidet: Abgegeben wird die Control Plane — Scheduler, etcd, API-Server, Node-Health —, während alles, was sich in Images und Manifesten ausdrückt, bei Ihnen bleibt: Hygiene der Basis-Images, Resource Requests, Liveness Probes, Deployment-Strategie, Service-Topologie. Das ist eine echte Disziplin, und genau deshalb existiert die Sprosse als eigenes Angebot: für Teams, die diese Ausdrucksstärke brauchen, aber keine Lust haben, die Maschinerie darunter zu betreiben. Der Container selbst ist das Portabilitätsargument — dasselbe Image läuft auf jedem konformen Orchestrator, was CaaS zu einer der Sprossen mit dem geringsten Lock-in macht.

Was ist PaaS (Platform-as-a-Service)?

PaaS vermietet eine verwaltete Anwendungsplattform: Sie pushen Code, der Anbieter stellt Runtime, Skalierung und Betriebssystem darunter bereit. Der Tausch lautet Konvention gegen Zeremoniell — unterstützte Sprachen und Plattform-Idiome im Gegenzug für Deployments per git push. Was PaaS entscheidend nicht abnimmt: Sie schreiben und verantworten weiterhin die gesamte Backend-Anwendung — Authentifizierung, Endpoints, Validierung, alles —, eine Unterscheidung, die der Eintrag PaaS vs. BaaS im Detail zerlegt.

Der PaaS-Vertrag hat eine Generation guter Gewohnheiten geprägt — Twelve-Factor-Apps, Konfiguration in der Umgebung, zustandslose Prozesse, Logs als Streams —, weil die Plattform erzwingt, was vorher nur Empfehlung war. Ebenso aufschlussreich ist ihre Grenze: Die Plattform führt Ihre Anwendung aus, weiß aber nichts über deren Inhalt. Jedes Backend-Thema — Sessions, Berechtigungen, Migrationen, Rate Limits — bleibt Code, den Sie schreiben, testen und patchen. Daran erkennen Sie, dass Sie auf der falschen Sprosse stehen: Wenn der Großteil Ihrer auf PaaS gehosteten Codebasis Benutzer, CRUD und Datei-Uploads neu implementiert, bauen Sie die nächsthöhere Sprosse von Hand nach.

Was ist FaaS (Functions-as-a-Service)?

FaaS vermietet Rechenleistung pro Ereignis: Sie deployen einzelne Funktionen, der Anbieter führt jeden Aufruf bei Bedarf aus und skaliert dazwischen auf null. Es ist die reinste Form von Serverless-Computing — nichts läuft und nichts wird abgerechnet, solange nichts passiert. Der Preis ist architektonisch: Cold Starts, Ausführungslimits und eine Zustandslosigkeit, die jede Persistenz nach außen verlagert. Wie Funktionen im Vergleich zu einer eigenen Flotte von Diensten abschneiden, ist die Frage Funktionen vs. Microservices.

Zustandslosigkeit ist die tragende Einschränkung: Eine Funktion kann nach jedem Aufruf zerstört werden, also muss alles Dauerhafte — Sessions, Dateien, Queues, Daten — in Diensten rund um die Funktion liegen. Konsequent zu Ende gedacht, setzt diese Einschränkung stillschweigend ein BaaS zusammen: Funktionen für die Logik, verwaltete Dienste für alles mit Zustand. Deshalb sind die beiden Sprossen in der Praxis zusammengewachsen, und deshalb gibt es Open-Source-Runtimes (Knative, OpenFaaS) für Teams, die das ereignisbasierte Modell auf ihrer eigenen Orchestrierung wollen. Die Preise folgen derselben ereignisgetriebenen Logik: Kostenloser Leerlauf ist bei schwankendem Traffic unschlagbar und bei gleichmäßiger Last eine Strafe — die Umkehrung, die jede FaaS-Rechnung irgendwann lehrt.

Was ist BaaS (Backend-as-a-Service)?

BaaS vermietet das Backend selbst. Datenbank, Authentifizierung, Dateispeicher, automatisch generierte APIs und Push-Benachrichtigungen sind fertig und verwaltet und werden über Client-SDKs genutzt — für Standard-Features ist überhaupt kein serverseitiger Code nötig, wie das Codebeispiel oben zeigt. Eigene Logik läuft in eingebetteten Cloud-Funktionen, weshalb ausgereifte BaaS-Plattformen die FaaS-Sprosse enthalten, statt mit ihr zu konkurrieren. Die Make-or-Buy-Variante dieser Entscheidung hat einen eigenen Eintrag, und die Lock-in-Frage — die ehrliche Schwäche dieser Sprosse — hängt davon ab, ob die Plattform Open Source oder proprietär ist.

BaaS nimmt Ihnen Infrastruktur und Boilerplate-Code ab, nicht das Engineering: Ihr Datenmodell, Ihre Sicherheitsregeln und Ihre Geschäftslogik bleiben Entscheidungen, die Ihnen keine Plattform abnimmt. Die Wirtschaftlichkeit dieser Sprosse ist die schärfste auf der Leiter — Minuten bis zum funktionierenden Backend, nahezu keine Vorabkosten —, und ebenso ihr strukturelles Risiko: Auf einer proprietären Plattform liegen Datenschema, Authentifizierung und Funktionen in herstellerspezifischer Form vor, was BaaS zum stärksten Lock-in unter den programmierbaren Sprossen macht. Die Open-Source-Variante löst genau das auf: Wenn sich dieselbe Plattform selbst hosten lässt, bedeutet ein Wechsel Umziehen statt Neuschreiben. Das KI-Zeitalter hat zudem das Publikum dieser Sprosse erweitert — generierte Frontends brauchen schnell echte Backends, und ein fertiges Backend mit Berechtigungsmodell ist genau die passende Form.

Was ist mBaaS (Mobile Backend-as-a-Service)?

Mit mBaaS begann die BaaS-Kategorie: ein fertiges Backend speziell für mobile Apps, mit Push-Benachrichtigungen, gerätebezogenen SDKs und Offline-Synchronisation als vollwertigen Features statt als Add-ons. Als auch Single-Page-Web-Apps clientzentriert wurden, verallgemeinerte sich das Modell, und das m fiel stillschweigend weg — heute bedient jede ernstzunehmende Plattform Web und Mobile aus demselben Backend. Wann die Unterscheidung noch zählt und wann sie nur historischer Rest ist, behandelt der Eintrag mBaaS vs. BaaS.

An drei Stellen verdient sich das m seinen Buchstaben noch. Push-Benachrichtigungen sind kein API-Aufruf, sondern eine Beziehung zu den Gateways der Plattformen (APNs, FCM) — Token-Registrierung, Geräte-Targeting, Zustellsemantik —, die eine Plattform auf mBaaS-Niveau durchgängig verwaltet. Offline-First-Sync bedeutet, dass das SDK eine Zustandsmaschine ist und kein dünner HTTP-Wrapper: lokale Persistenz, eingereihte Schreibvorgänge, Konfliktbehandlung, sobald die Verbindung zurückkehrt. Und der Gerätezustand (Installationen, Kanäle, Segmente) ist ein Datenmodell, das Web-Apps schlicht nicht haben. Wenn diese drei Punkte Ihr Produkt beschreiben, zählt die mobile Herkunft Ihrer Plattform; wenn nicht, sind BaaS und mBaaS derselbe Kauf.

Was ist SaaS (Software-as-a-Service)?

SaaS vermietet fertige Software — anmelden und nutzen. Es ist die einzige Sprosse der Leiter, die Sie nutzen, statt darauf zu bauen, weshalb der Vergleich mit den anderen einen Kategorienwechsel bedeutet: Die ersten sechs Modelle beantworten die Frage “Wie viel vom Stack meines Produkts betreibe ich selbst?”, SaaS dagegen die Frage “Sollte das überhaupt mein Produkt sein?”. Ihr CRM, Ihr E-Mail-Dienst und Ihre Analytics sind SaaS. Sobald ein Tool Ihre eigene Logik in sich braucht, sind Sie von der SaaS-Sprosse gefallen und brauchen eine darunter.

Für diesen Vergleich zählt SaaS vor allem als Grenze: Es definiert, wie “vollständig verwaltet” aussieht, wenn nichts mehr zu programmieren bleibt — die Richtung, in die jede andere Sprosse seit zwei Jahrzehnten klettert. Es setzt auch die Obergrenze für das Versprechen der Bau-Sprossen: Je näher ein BaaS an “das Backend Ihres Produkts fühlt sich vom ersten Tag an wie SaaS an” herankommt, desto mehr ist das verbleibende Engineering genau der Teil, der Sie unterscheidet. Der Preis ist Abhängigkeit: Roadmap, Preise und Datenportabilität liegen auf der Seite des Herstellers, und nur Ihre Daten und Zugriffsrichtlinien bleiben immer auf Ihrer Seite der Linie.

Wie die Leiter gewachsen ist

Das Muster über zwei Jahrzehnte verläuft in eine Richtung: Jedes neue Modell abstrahiert die Schicht weg, die das vorherige noch offenlegte, und jede Generation von Teams steigt höher ein als die vorige. Dass mBaaS vor dem allgemeinen BaaS kam, ist die schönste Anekdote der Leiter — die mobilen Rahmenbedingungen (kein Server-Team, App-Store-Release-Zyklen) erzwangen zuerst die höchste Abstraktion, und der Rest der Branche zog nach.

Die Pizza-Analogie, erweitert auf sieben Sprossen

Die klassische Lehranalogie (2014 vom Softwarearchitekten Albert Barron geprägt) überträgt das Trio aufs Abendessen: On-Prem heißt selbst kochen, IaaS ist die Pizza zum Fertigbacken, PaaS der Lieferdienst, SaaS das Restaurant. Die neueren Sprossen lassen sich natürlich ergänzen. CaaS heißt, eine Profiküche mit standardisierten Blechen zu mieten — Ihre Rezepte, nach Ihren Vorstellungen verpackt, gebacken auf deren Ausstattung. FaaS heißt, pro Stück zu bezahlen — keine Pizza existiert, bevor Sie Hunger haben, und für einen leeren Tisch zahlen Sie nie. BaaS ist die Kochbox, in der alles vorbereitet ist außer Ihrer persönlichen Note — Teig, Soße und Ofen sind erledigt; Sie geben den Belag dazu, der daraus Ihr Restaurant macht. Und mBaaS ist dieselbe Box im Format für den Foodtruck: Die Einschränkung (Mobile) hat die Box zuerst geformt, alle anderen haben sie danach übernommen.

IaaS vs. CaaS vs. PaaS vs. FaaS vs. BaaS vs. SaaS im Vergleich

Die Paare, die tatsächlich verglichen werden

IaaS vs. PaaS — “Wollen wir Maschinen betreiben oder einfach eine App ausliefern?” Wählen Sie IaaS nur, wenn die Kontrolle selbst die Anforderung ist; sonst nimmt Ihnen PaaS für dieselbe Anwendung alles ab dem Betriebssystem aufwärts ab.

IaaS vs. CaaS — dieselbe Frage eine Schicht höher: die eigene Orchestrierung auf gemieteten Maschinen betreiben oder die Orchestrierung gleich mitmieten? Sofern der Betrieb der Control Plane nicht Ihre Spezialität ist: CaaS.

CaaS vs. PaaS — die Einheit, die Sie übergeben: Container (jeder Stack, Ihre Paketierung, Kontrolle auf Orchestrierungsebene) vs. Anwendungscode (deren Runtimes, deren Konventionen, weniger Zeremoniell). Microservices und polyglotte Landschaften tendieren zu CaaS, eine einzelne Standard-App zu PaaS.

CaaS vs. FaaS — Dauerbetrieb vs. Ereignisse. Langlebige Dienste mit Traffic untereinander gehören in Container; sporadische, ereignisförmige Arbeit gehört in Funktionen, die auf null skalieren. Die meisten realen Systeme nutzen beides.

PaaS vs. BaaS — die tiefste Verwechslung auf der Leiter, mit einem eigenen Eintrag: PaaS hostet das Backend, das Sie noch schreiben müssen; BaaS streicht diesen Schritt für Standard-Features. Ein Backend schreiben oder eines haben.

FaaS vs. BaaS — der Umfang des Outsourcings, zerlegt in BaaS vs. Serverless: FaaS lagert die Runtime für Code aus, den Sie schreiben; BaaS lagert das Backend aus, sodass der größte Teil dieses Codes nie entsteht. Ausgereifte BaaS-Plattformen bringen FaaS mit, in der Praxis lassen sich die Sprossen also kombinieren.

BaaS vs. mBaaS — Geschichte vs. Gegenwart: dieselbe Sprosse, mit mobiler Herkunft. Lebt Ihr Produkt von Push, Offline-Fähigkeit und Gerätezustand, beschreibt das m weiterhin Ihre Anforderungen; die Plattformen sind ohnehin zusammengewachsen.

SaaS vs. alle anderen — der Kategorienwechsel: Auf jedem anderen Modell bauen Sie etwas auf; auf SaaS bauen Sie nichts auf. Kann eine Workload SaaS sein, ist das fast immer die günstigste ausreichende Sprosse — sie ist dann nur nicht mehr Ihre Software.

Wo “Serverless” hingehört

Serverless ist keine achte Sprosse, sondern der Oberbegriff über den beiden höchsten programmierbaren. Die maßgebliche Definition umfasst sowohl FaaS (Ihr Code, bei Bedarf ausgeführt) als auch BaaS (fertige Backend-Dienste): In beiden Fällen verwaltet niemand in Ihrem Team einen Server, die Kapazität skaliert automatisch, und die Kosten folgen der Nutzung. Wenn jemand sagt “Wir sind auf Serverless umgestiegen”, lautet die Frage mit Blick auf die Leiter: welche Sprosse? Selbst geschriebene Funktionen, ein Backend, das sie nicht geschrieben haben, oder — am häufigsten — die Kombination.

Typische Anwendungsfälle

• IaaS: Lift-and-Shift-Migrationen, spezielle Runtimes und Hardware, Compliance-Vorgaben, die Kontrolle über die Infrastruktur verlangen.
• CaaS: Microservice-Flotten, polyglotte Systeme, Teams, die Orchestrierung auf Kubernetes-Niveau wollen, ohne die Control Plane zu betreiben.
• PaaS: eigene Webanwendungen und APIs, bei denen die Backend-Logik das Produkt ist, betrieben von Teams, die deployen wollen, ohne Server zu betreiben.
• FaaS: Webhook-Handler, geplante Jobs, Bild- und Datenpipelines — ereignisgesteuerte Arbeit ohne vollständiges Backend drumherum.
• BaaS: komplette App-Backends mit Standardanforderungen — Benutzer, Daten, Dateien, Benachrichtigungen —, besonders für Frontend-orientierte Teams.
• mBaaS: dasselbe mit Mobile-First-Fokus — Produkte, die auf Push, Offline-Sync und Gerätezustand aufbauen.
• SaaS: alles, was Ihr Unternehmen nutzt, aber nicht baut — die Sprosse, die Sie nutzen, statt darauf zu entwickeln.

Welche Sprosse sollten Sie wählen? Eine Entscheidungsmatrix

Zwei ehrliche Regeln kommen hinzu: Wählen Sie standardmäßig die höchste Sprosse, die passt (jede Stufe nach unten holt Betriebsarbeit zurück), und bewerten Sie jede Workload einzeln neu — Unternehmen stehen bewusst auf mehreren Sprossen gleichzeitig.

Grenzen und Trade-offs

• IaaS: Der Stückpreis schmeichelt; die eigentliche Rechnung ist das Ops-Personal, das patcht, skaliert und absichert.
• CaaS: Ausgelagert ist die Control Plane, nicht die Komplexität — Images, Manifeste, Service Meshes und Deployment-Pipelines bleiben eine eigene Engineering-Disziplin.
• PaaS: Sie verantworten weiterhin eine komplette Anwendung — jedes Dependency-Upgrade und jeden Authentifizierungsfehler inklusive — plus plattformspezifische Konventionen.
• FaaS: Cold Starts, Ausführungslimits und eine Abrechnung pro Aufruf, die bei dauerhaft hoher Last teuer wird.
• BaaS / mBaaS: eine Anpassungsgrenze bei stark vom Standard abweichenden Anforderungen und der stärkste Lock-in auf der Leiter, sofern proprietär — genau deshalb sind Plattformen auf Open-Source-Basis wichtig: Sie halten den Ausstieg real.
• SaaS: totale Abhängigkeit — Roadmap, Preise und Datenportabilität hängen von den Entscheidungen anderer ab.
• Alle Modelle: Die Linie der geteilten Verantwortung verschiebt sich, aber nie über Ihre Daten, Ihre Zugriffsrichtlinien und Ihr Urteilsvermögen hinaus.

Die Servicemodell-Leiter mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Sie belegt die BaaS-Sprosse — vollständig im Sinne von mBaaS, mit Push und mobilen SDKs als vollwertigen Features — und sichert sich bewusst in beide Richtungen ab. Nach oben: Das Standard-Backend ist fertig, sodass sich Ihr eigenes Produkt vom ersten Tag an so unmittelbar anfühlt wie SaaS. Nach unten: Funktionen, Trigger und geplante Jobs in Cloud Code liefern Ihnen die FaaS-Sprosse innerhalb der Plattform, und dasselbe Unternehmen dokumentiert die CaaS-Sprosse für Workloads, die Container brauchen. Und weil der Stack Open Source ist, gibt es für den schlimmsten Fehlerfall der Leiter — Lock-in ganz oben — einen dokumentierten Weg nach unten: dasselbe Backend auf jeder tieferen Sprosse selbst hosten, ohne Neuschreiben.