SaaS, PaaS und IDPs sind Plattformprodukte

Die hilfreiche Unterscheidung ist nicht, ob etwas SaaS, PaaS, Control Plane oder Internal Developer Platform genannt wird. Hilfreich ist die Frage, ob die Plattform echte Nutzer, eine klare Schnittstelle, ein betreibbares Betriebsmodell und einen Weg zur Ownership nach dem Aufbau hat.

Darum behandle ich diese Systeme meistens als eine Familie von Plattformprodukten.

Was sich ändert, wenn die Plattform als Produkt gedacht wird

Ein Plattformprodukt braucht mehr als einen Cluster und eine Pipeline. Es braucht einen Vertrag zwischen den Menschen, die es nutzen, und dem Team, das es betreibt.

Bei einem kundenorientierten SaaS-Produkt zeigt sich dieser Vertrag zum Beispiel in Tenant-Isolation, Onboarding-Flows, Abrechnungsgrenzen, Audit-Trails und Release-Kanälen. Bei einer PaaS-Schicht geht es eher um Self-Service-Provisioning, Environment-Templates, Runtime-Policies und klare Serviceklassen. Bei einer Internal Developer Platform können es Golden Paths, GitOps-Workflows, vorbereitete Observability und Dokumentation sein, die Anwendungsteams ohne Wartezeit handlungsfähig macht.

Die Mechanik ist unterschiedlich, aber die Produktfragen sind ähnlich:

• Wer ist der Nutzer?
• Was muss diese Person erstellen oder verändern können?
• Welche Entscheidungen sollten Self-Service sein?
• Welche Entscheidungen müssen kontrolliert bleiben?
• Wie betreibt, debuggt und verbessert das Team die Plattform nach dem Launch?

Diese Fragen früh zu beantworten verhindert ein bekanntes Problem: eine technisch starke Plattform, die niemand ohne Abstimmungsrunde sicher nutzen kann.

Die Umsetzung liegt meistens zwischen Produkt und Infrastruktur

Der Aufbau berührt oft Kubernetes, Terraform, CI/CD, GitOps, Identity, Secrets, Observability und Automatisierung. Das heißt nicht, dass jedes Projekt vom ersten Tag an ein großes Plattformteam braucht. Es heißt, dass die Plattform um den ersten dauerhaft relevanten Workflow geschnitten werden sollte.

Beispiele:

• Eine mandantenfähige SaaS-Grundlage mit Tenant-Provisioning, Environment-Promotion und Betriebsrunbooks.
• Eine Kubernetes-Control-Plane mit Custom Resources, Reconciliation-Logik und klaren Lifecycle-Regeln.
• Ein PaaS-Workflow, mit dem Teams Services deployen, Environments anfragen und gemeinsame Fähigkeiten nutzen können.
• Eine Internal Developer Platform, die wiederkehrende Infrastrukturarbeit in dokumentierte, testbare Self-Service-Pfade überführt.

Das Ziel ist nicht, jede Komplexität zu verstecken. Das Ziel ist, Komplexität hinter die richtige Schnittstelle zu legen und dem nächsten Betreiber genug Kontext zum Betrieb zu geben.

Worauf ich optimiere

Meine Tendenz geht zu Plattformen, die in Produktion ruhig sind und bei der Übergabe explizit bleiben.

Das bedeutet kleinere erste Releases, klare Ownership-Grenzen, sichtbare Fehlermodi und Dokumentation als Teil des Builds. Es bedeutet auch, Plattformfeatures abzulehnen, die im Diagramm gut aussehen, aber keinen konkreten Produkt- oder Delivery-Workflow freischalten.

Bei SaaS, PaaS und internen Plattformen ist das dauerhafte Ergebnis gleich: Teams können die Plattform liefern, betreiben und weiterentwickeln, ohne bei jeder Änderung die ursprüngliche Designabsicht neu zu erraten.