Cloud-Grundbegriffe: IaaS, PaaS, SaaS

Cloud Computing bedeutet im Kern: IT-Ressourcen über das Internet beziehen, anstatt sie selbst zu betreiben. Statt einen eigenen Server zu kaufen, mietet man Rechenleistung beim Anbieter. Statt eine Datenbank zu administrieren, nutzt man sie als Service. Statt eine E-Mail-Lösung zu installieren, loggt man sich bei Microsoft 365 ein. Diese drei Beispiele sind kein Zufall: sie entsprechen genau den drei Hauptmodellen, die jede:r Fachinformatiker:in kennen muss: IaaS, PaaS und SaaS.

Die klassische Analogie ist die Pizza: Du kannst sie komplett selbst machen (Teig, Soße, Belag, Ofen — alles eigene Arbeit). Du kannst Teig kaufen und nur belegen. Du kannst eine Tiefkühlpizza nehmen und nur in den Ofen schieben. Oder du gehst essen — bezahlst, isst, fertig. Jede Stufe nimmt dir mehr Arbeit ab, kostet aber pro Mahlzeit mehr und gibt dir weniger Kontrolle über das Endergebnis. Eine zweite Analogie: ein Auto. Selbst eines bauen (On-Prem) — nie. Selber kaufen und fahren (IaaS) — verbreitet. Leasen mit Service (PaaS) — Sorgenfrei-Paket. Carsharing nutzen (SaaS) — kein Eigentum, du zahlst pro Nutzung. So funktioniert die Cloud.

1) Die Pizza-Analogie: vier Stufen der Verantwortung

Stell dir vor, du willst Pizza essen. Du hast vier Optionen — jede nimmt dir mehr Arbeit ab, aber du gibst auch ein Stück Kontrolle auf:

Pizza-Modell: was du selbst tust, was übernommen wird

🏠

On-Premises

Selbst gebacken
Mehl, Hefe, Soße, Belag, Ofen — alles selbst. Volle Kontrolle, viel Aufwand.

📦

IaaS

Teig gekauft
Du belegst und bäckst. Anbieter liefert die Basis (Hardware, Strom).

🍕

PaaS

TK-Pizza
Nur noch in den Ofen schieben. Du wählst den Belag (deine App), Rest läuft.

🍴

SaaS

Pizzeria
Du bestellst, isst, bezahlst. Keine eigene Küche, keine Reste, kein Abwasch.

Die Pizza-Analogie wurde 2014 von Albert Barron (IBM) populär gemacht und ist in der gesamten Cloud-Welt etabliert. Sie funktioniert für jede:n und macht auf einen Blick klar: Je weiter rechts, desto weniger Eigenleistung — aber auch desto weniger Anpassbarkeit.

2) Der Verantwortungs-Stack — wer macht was?

Konkreter wird es, wenn man die typische IT-Architektur in Schichten zerlegt: vom Strom über die Hardware, das Betriebssystem, die Middleware (Datenbank, Webserver), die Laufzeitumgebung bis hin zur eigentlichen Anwendung und den Daten. Bei jedem Cloud-Modell verschiebt sich die Grenze zwischen Kundenverantwortung (gelb) und Anbieterverantwortung (grün) — und damit auch, wofür du als Admin in die Haftung kommst. Klick durch die Modelle:

Verantwortungs-Stack pro Cloud-Modell

Wichtig fürs Shared Responsibility Model: was der Anbieter übernimmt, ist sein Risiko (Hardware-Defekt → er ersetzt). Was beim Kunden bleibt, bleibt sein Risiko (vergessenes Datenbank-Backup → sein Problem). Diese Grenze entscheidet im Schadensfall, wer haftet.

3) IaaS — Infrastructure as a Service

IaaS ist die rohste Form der Cloud: du mietest Rechenleistung, Speicher und Netzwerk — also virtuelle Maschinen, Festplatten, virtuelle Netzwerke. Was darauf läuft, ist deine Sache: Betriebssystem installieren, Patches einspielen, Datenbank konfigurieren, Backups einrichten. IaaS ähnelt am stärksten der eigenen Virtualisierung — nur dass der Hypervisor jemand anderem gehört.

Typische IaaS-Beispiele:

AWS EC2 (Elastic Compute Cloud) — virtuelle Server in vielen Größen
Azure Virtual Machines — Microsofts Pendant
Google Compute Engine — Googles VMs
Hetzner Cloud, IONOS, OVH — europäische Alternativen

IaaS ist die richtige Wahl, wenn du maximale Kontrolle brauchst — etwa für eine ältere Anwendung, die nicht in Container passt; für Datenbank-Server mit spezieller Konfiguration; oder für Linux-Server mit Custom-Software, die du selbst pflegen willst.

4) PaaS — Platform as a Service

Bei PaaS gibst du das Betriebssystem ab. Du bekommst eine vorkonfigurierte Plattform — eine Datenbank, einen Webserver, eine Container-Runtime — und dort wirfst du deinen Code rein. Wartung, Updates, Skalierung der Plattform übernimmt der Anbieter. Du musst dich nicht mehr darum kümmern, ob die zugrunde liegende VM mit einem Security-Patch versorgt wurde — das passiert im Hintergrund.

Typische PaaS-Beispiele:

AWS Elastic Beanstalk / Azure App Service / Google App Engine — du lädst deinen Code hoch, der Rest läuft
Heroku — der PaaS-Pionier für Webanwendungen
AWS RDS / Azure SQL / Cloud SQL — Managed Databases (MySQL, PostgreSQL etc.)
AWS Lambda / Azure Functions — Function-as-a-Service (FaaS), serverlos

PaaS lohnt sich, wenn du eigene Software entwickelst, aber kein Interesse hast, Linux zu administrieren. Der Tradeoff: weniger Flexibilität. Du musst dich an die unterstützten Sprachen/Frameworks halten, die der Anbieter vorgibt. Was nicht passt, läuft nicht.

5) SaaS — Software as a Service

Bei SaaS bekommst du die fertige Anwendung — komplett betrieben, gewartet, aktualisiert. Du loggst dich im Browser ein und nutzt sie. Code, Server, Datenbanken, Backups, Updates — alles unsichtbar. Du zahlst pro Nutzer:in oder pro Funktionsumfang.

SaaS ist mit Abstand die häufigste Form von Cloud — und die meisten Menschen nutzen täglich Dutzende davon, ohne es zu merken:

Microsoft 365, Google Workspace — Office-Suiten
Salesforce, HubSpot — CRM
Slack, Microsoft Teams, Zoom — Kommunikation
Dropbox, OneDrive, Google Drive — Dateiablage
Jira, Asana, Trello — Projektmanagement
GitHub, GitLab.com — Code-Hosting

SaaS bedeutet null Wartungsaufwand für die IT — und null Kontrolle über die Software. Mag der Anbieter morgen die Oberfläche ändern oder eine Funktion abkündigen, bleibt dir nur zustimmen oder migrieren.

6) Vergleich auf einen Blick

Die folgende Tabelle fasst zusammen, wofür welches Modell taugt und welcher administrative Aufwand bleibt:

Aspekt	On-Premises	IaaS	PaaS	SaaS
Hardware-Verantwortung	Kunde	Anbieter	Anbieter	Anbieter
OS-Patches	Kunde	Kunde	Anbieter	Anbieter
Anwendungs-Code	Kunde	Kunde	Kunde	Anbieter
Daten-Backup	Kunde	Kunde	variiert	Anbieter (meist)
Skalierung	manuell, langwierig	auf Knopfdruck	automatisch	unsichtbar
Initialkosten	hoch (CapEx)	niedrig (OpEx)	sehr niedrig	fast null
Lock-in-Risiko	kein	gering	mittel	hoch
Typische Beispiele	eigener Server-Raum	AWS EC2, Azure VMs	Heroku, App Engine, RDS	Microsoft 365, Salesforce

Eine wichtige Beobachtung: CapEx vs. OpEx. Eigene Hardware ist Capital Expenditure (Investitionsausgabe — einmaliges Geld in den Anlagen) und über Jahre abzuschreiben. Cloud ist Operational Expenditure (laufende Kosten — wie Miete oder Strom). Diese Verschiebung hat Konsequenzen für Steuer, Bilanz und TCO-Rechnung — und ist einer der wirtschaftlichen Hauptgründe, warum Unternehmen in die Cloud gehen.

7) Weitere "-aaS"-Varianten

Über die drei Hauptmodelle hinaus haben sich diverse Spezialformen etabliert. Du musst sie nicht alle auswendig kennen, aber die Begriffe sollten klingeln:

Abk.	Name	Was steckt dahinter
FaaS	Function as a Service	Serverlose Funktionen, die nur bei Aufruf laufen (AWS Lambda, Azure Functions)
DBaaS	Database as a Service	Verwaltete Datenbanken (AWS RDS, Azure SQL Database)
STaaS	Storage as a Service	Speicher-Service (AWS S3, Azure Blob Storage)
CaaS	Container as a Service	Verwaltete Container-Plattformen (AWS ECS, Azure Container Apps)
DaaS	Desktop as a Service	Virtuelle Desktops aus der Cloud (Azure Virtual Desktop)
BaaS	Backup as a Service	Verwaltete Backup-Lösungen
iPaaS	Integration Platform as a Service	Plattformen zur Integration verschiedener Systeme

Zusammenfassung

Cloud Computing bedeutet IT-Ressourcen über das Internet beziehen statt selbst betreiben. Drei Hauptmodelle: IaaS (Infrastructure — virtuelle Server, du verwaltest OS und alles drüber), PaaS (Platform — vorkonfigurierte Plattform für deinen Code), SaaS (Software — fertige Anwendung über den Browser). Die Verantwortungsgrenze zwischen Kunde und Anbieter verschiebt sich je nach Modell — von voll beim Kunden (On-Prem) bis voll beim Anbieter (SaaS). Vorteile der Cloud: keine Vorabinvestition (OpEx statt CapEx), schnelle Skalierung, weniger Wartung. Nachteile: laufende Kosten, Vendor-Lock-in-Risiko, weniger Kontrolle. Spezialformen: FaaS, DBaaS, STaaS, CaaS, DaaS, BaaS — alles Sonderfälle des PaaS-Prinzips.