Was ist PaaS? Platform as a Service vs IaaS, SaaS und Kubernetes

Platform as a Service (PaaS) ist ein Cloud-Modell, in dem du deine Anwendung als Quellcode oder Container-Image übergibst und der Anbieter sie betreibt. Die Plattform baut sie, deployt sie, skaliert sie und betreibt die Server, Betriebssysteme und Netze darunter. Du bleibst verantwortlich für die Anwendung, ihre Konfiguration und ihre Daten.

Die meistzitierte Definition kommt vom US National Institute of Standards and Technology (NIST SP 800-145). Mit einer PaaS deployest du deine eigenen Anwendungen auf die Infrastruktur des Anbieters, aber du „verwaltest oder kontrollierst die zugrunde liegende Cloud-Infrastruktur einschließlich Netz, Server, Betriebssysteme oder Storage nicht“. Du kontrollierst die deployed Anwendungen und, möglicherweise, Settings der Hosting-Umgebung.

Was eine PaaS übernimmt

Die genaue Liste unterscheidet sich je Anbieter, eine volle PaaS deckt aber das meiste davon ab:

• Builds: sie macht aus einem Git-Repository ein lauffähiges Image, entweder mit Buildpacks, die deine Sprache erkennen, oder aus einem Dockerfile, das du committest.
• Deploys: sie rollt neue Releases aus, oft bei jedem Push auf einen Branch, und hält eine History, was wann gelaufen ist.
• Scaling: mehr Replikas oder eine größere Größe ist eine Einstellung, kein neuer Server zum Installieren.
• TLS und Domains: jede App bekommt einen Hostnamen, und Zertifikate für deine eigenen Domains werden für dich ausgestellt und erneuert.
• Logs und Metriken: Runtime-Logs und CPU- und Memory-Charts, ohne einen eigenen Logging-Stack zu betreiben.
• Managed Databases: PostgreSQL, MySQL oder ein Cache neben der App, mit Replikas und Backups als Optionen.
• Server und Betriebssysteme: Hosts patchen, ausgefallene Hardware ersetzen und das Netz am Laufen halten.

Was bei dir bleibt

Eine PaaS nimmt die Infrastrukturarbeit weg, nicht die Verantwortung für dein Produkt. Du besitzt weiter:

• Deinen Code und seine Dependencies, inklusive Libraries aktualisieren, wenn eine Schwachstelle rauskommt.
• Konfiguration und Secrets: Umgebungsvariablen, API-Keys und wer in deinem Team sie sehen kann.
• Deine Daten: Schema, Migrationen, Backups einschalten und einen Restore testen.
• Größe und Kosten: wie viele Replikas du betreibst und welchen Plan, und die Rechnung, die folgt.
• Application Security: Authentifizierung, Input-Validierung und Zugriff auf das Dashboard.
• Standort: in welcher Region deine App und ihre Daten laufen.

PaaS vs IaaS vs SaaS vs Serverless vs Kubernetes

Die Modelle unterscheiden sich darin, was du abgibst und was du behältst. Ein grober Vergleich:

Modell	Du bringst	Der Anbieter betreibt	Du verwaltest weiter	Typisch für
IaaS	Virtuelle Maschinen, Disks, Netze	Hardware, Virtualisierung, Rechenzentren	Betriebssystem, Runtime, Deploys, Scaling, Patches	Volle Kontrolle, Legacy oder spezielle Software
PaaS	Quellcode oder ein Container-Image	Server, OS, Builds, Deploys, Routing, oft Datenbanken	Anwendung, Konfiguration, Daten	Web-Apps, APIs, Worker
SaaS	Nichts zu deployen	Die ganze Anwendung	Settings, User und deine Daten in der App	Standard-Business-Software
Serverless (FaaS)	Functions	Ausführung pro Event oder Request, Scaling mit Bedarf	Function-Code, Cold Starts, Zeit- und Größenlimits	Eventgetrieben, spitze Lasten
Kubernetes	Container-Images und Manifeste	Als Managed Service: die Control Plane	Nodes, Deployments, Ingress, Scaling-Setup, CI/CD, Logging	Große Setups mit Plattform-Team

IaaS gibt dir virtuelle Maschinen und lässt den Rest bei dir. NIST beschreibt es als Bereitstellung von „Processing, Storage, Networks und anderen grundlegenden Computing-Ressourcen“, auf denen du beliebige Software betreibst, inklusive Betriebssystem.

SaaS ist das andere Ende: du nutzt die fertige Anwendung des Anbieters im Browser oder über eine API und deployest nichts.

Serverless im Function-Sinn führt deinen Code als kleine Functions aus, ausgelöst durch Events oder HTTP-Requests, und rechnet nach tatsächlichem Bedarf ab. Das Serverless-Whitepaper der CNCF merkt an, dass die meisten Runtimes Größe oder Ausführungszeit jeder Function begrenzen und dass der Start nach Idle-Zeiten langsam sein kann. Eine PaaS betreibt deine App meist als immer laufenden Prozess.

Kubernetes ist ein Container-Orchestrierer, und die eigene Dokumentation sagt, Kubernetes „ist keine klassische, allumfassende PaaS“. Sie deployt keinen Quellcode, baut deine Anwendung nicht und enthält keine Datenbanken als eingebaute Services. Sie liefert Bausteine für Plattformen. Den längeren Vergleich findest du unter PaaS vs Kubernetes.

Wann eine PaaS passt

• Du baust Web-Apps, APIs oder Background-Worker in einer gängigen Sprache.
• In deinem Team hat niemand den Job, Server oder Cluster zu betreiben, und du willst dafür noch niemanden einstellen.
• Du willst eine neue Version wenige Minuten nach einem Merge live, mit Logs und Metriken schon an Bord.
• Du brauchst Datenbanken, Storage und die App an einem Ort, unter einer Rechnung.

Wann nicht

• Du brauchst einen eigenen Kernel, spezielle Hardware oder Low-Level-Kontrolle über das Netz. Eine virtuelle Maschine oder Bare Metal passt besser.
• Deine Software erwartet Root-Zugriff, ein volles Init-System oder Pakete, die mit Maintainer-Skripten installiert werden. Ein Dockerfile kann einen Teil davon abdecken; manche Software läuft nur auf einer VM gut.
• Du betreibst große, gleichmäßige Lasten und hast schon ein Plattform-Team. Eigene Infrastruktur kann sich dann lohnen.
• Dein Code läuft ein paar Sekunden am Tag als Reaktion auf Events. Eine Function-Plattform kann günstiger sein.
• Du hast eine rechtliche oder Compliance-Anforderung, die Regionen oder Zertifizierungen des Anbieters nicht erfüllen.

Wie du eine PaaS bewertest

Regionen und Datenstandort

Prüfe, wo App, Datenbank, Backups und Logs tatsächlich laufen und ob du das pro Service wählst. Prüfe außerdem, wo Control Plane und Accountdaten des Anbieters liegen und in welchem Land das Unternehmen sitzt. Bei personenbezogenen Daten von Menschen in der EU zählen beide Fragen.

Enthaltene Dienste

Schau, was mit der Plattform kommt und was einen Dritten braucht: Datenbanken, Object Storage, E-Mail, CDN, Logs und Metriken, Preview-Environments. Jedes Add-on eines anderen Anbieters ist ein Vertrag mehr, eine Rechnung mehr und ein Unterauftragsverarbeiter mehr.

Preismodell

Plattformen rechnen pro Instanz, pro Laufzeitsekunde, pro Request oder pro Seat ab, und manche messen zusätzlich Bandbreite, Build-Minuten oder Log-Volumen. Schätze einen Monat mit deinen echten Zahlen, inklusive Datenbank und einer zweiten Umgebung für Staging.

Portabilität

Lock-in steckt meist im Build und in der Konfiguration, nicht im Code. Bevorzuge eine Plattform, die Standard-Container-Images aus einem Dockerfile oder aus Cloud Native Buildpacks baut: der Buildpacks-Lifecycle exportiert ein OCI-Image, dasselbe Format, das andere Container-Plattformen betreiben. Halte Konfiguration in Umgebungsvariablen und nutze Standard-Datenbankengines, die du woanders dumpen und wiederherstellen kannst. Dann ist der Wegzug eine Migration, kein Rewrite.

Wo Nodion hineinpasst

Nodion ist eine PaaS der Nodion GmbH aus Stuttgart, Deutschland. Du deployest aus Git mit einem Dockerfile oder Nodions eigenen Cloud Native Buildpacks, oder aus einem vorgebauten Image. Jede App bekommt Prozesse, Logs, Metriken und Domains, Git-Apps können Preview-Environments öffnen, und Managed Postgres, MySQL, Valkey und ClickHouse hängst du im Environment-Tab der App an. Du wählst die Region pro Service, zum Beispiel EU Central in Frankfurt. Details stehen unter Applications.