Platform Engineering auf Kubernetes: Was es wirklich ist (und wie man die Plattform baut)

Platform Engineering ist gerade der meistgesuchte und meistmissverstandene Begriff der Infrastruktur. Anbieter verkaufen „eine Internal Developer Platform aus der Box“, Konferenzvorträge versprechen, sie werde DevOps ersetzen, und die halbe Branche vermutet still, es sei nur Kubernetes mit einem hübscheren Logo.

Ist es nicht. Nimm das Marketing weg, und Platform Engineering ist eine wirklich nützliche, konkrete Idee — und auf Kubernetes hat sie eine greifbare Form. Hier ist, was es wirklich ist, woraus es besteht und die ehrliche Antwort, ob du eine bauen solltest.

Was Platform Engineering wirklich ist

Platform Engineering ist die Disziplin, eine Internal Developer Platform (IDP) als Produkt zu bauen — mit den eigenen Entwicklern als Kunden.

Diese Sichtweise ist das Ganze. Du baust nicht Infrastruktur um ihrer selbst willen; du baust ein Produkt, das andere Ingenieure wählen, weil es das Ausliefern von Software schneller und sicherer macht als von Hand. Das Plattform-Team betreibt sie wie jedes Produkt: mit Nutzern, Feedback, einer Roadmap und einer Erfolgsdefinition, die Entwickler-Adoption heißt, nicht Zeilen Terraform.

Der Mechanismus ist der Golden Path (oder „Paved Road“): ein meinungsstarker End-to-End-Weg für eine häufige Aufgabe — einen neuen Service hochziehen, eine Datenbank hinzufügen, in Produktion ausliefern — der standardmäßig das Richtige tut. Der einfache Weg wird zum sicheren, konformen, beobachtbaren.

Das gelöste Problem: kognitive Last

Hier ist, warum es das gibt. Um einen einzigen Service auf moderner cloud-nativer Infrastruktur auszuliefern, soll ein Entwickler implizit Kubernetes, Helm oder Kustomize, ein Ingress- und Networking-Modell, Terraform oder ein anderes IaC-Tool, ein CI/CD-System, Secrets-Management und einen Haufen Security-Controls verstehen. Und das, bevor er eine Zeile Geschäftslogik schreibt.

Das ist kognitive Last, und sie skaliert nicht. Jedes neue Team lernt entweder alles neu oder kopiert ein halb verstandenes Setup vom letzten Team. Eine Plattform nimmt diese Last ab: Der Entwickler arbeitet gegen eine saubere Self-Service-Schnittstelle, und die Plattform kümmert sich um die zwölf Werkzeuge darunter.

Es ist nicht DevOps 2.0 oder umbenanntes SRE

Die häufigste Verwechslung ist, Platform Engineering ersetze DevOps oder benenne SRE um. Es tut weder das eine noch das andere — die drei sind komplementäre Ebenen.

DevOps ist das Ziel — Teams, die ihre Software End-to-End besitzen. SRE hält es mit echter Engineering-Strenge zuverlässig. Platform Engineering ist das Produkt, das eine große Organisation beides erreichen lässt, ohne dass jedes Team dieselbe Infrastruktur neu erfindet. Du brauchst alle drei.

Die Anatomie einer IDP auf Kubernetes

Auf Kubernetes hat eine Internal Developer Platform einen wiedererkennbaren Stack. Von der Infrastruktur unten bis zum Entwickler oben:

• Cloud-Infrastruktur — das Compute-, Netzwerk- und Storage-Fundament. Auf Google Cloud ist das GKE plus die umgebenden Primitive.
• Orchestrierung & Konfiguration — Kubernetes als Control Plane, mit Crossplane, um Infrastruktur als APIs bereitzustellen, und Helm oder Kustomize, um Workloads zu templaten.
• Continuous Delivery — GitOps mit Argo CD: Git ist die Quelle der Wahrheit, und der Cluster gleicht sich kontinuierlich darauf ab.
• Self-Service-Schnittstelle — der Teil, den Entwickler tatsächlich anfassen: ein Portal wie Backstage, Service-Templates (die Golden Paths) und eine Plattform-CLI oder -API.

Zwei Dinge schneiden durch jede Ebene und sind nicht optional:

• Leitplanken — Policy-as-Code mit Kyverno oder OPA Gatekeeper, RBAC und Security-Controls, die den befestigten Weg automatisch konform machen.
• Observability — Metriken, Logs und Traces standardmäßig verdrahtet, sodass jeder Service in dem Moment beobachtbar ist, in dem er geboren wird.

Die Ebenen zählen weniger als das Prinzip: Der Entwickler sieht nur die Spitze, und alles darunter ist Aufgabe der Plattform.

Der Golden Path in Bewegung

Konkret: Das ersetzt ein Golden Path. Ohne Plattform bedeutet einen Service zu starten, dass ein Entwickler Kubernetes-Manifeste von Hand schreibt, eine Pipeline verdrahtet, Secrets anfordert, Networking um einen Ingress bittet und einen Security-Review bucht — oft über Tage und mehrere Tickets.

Mit Plattform führt der Entwickler eine Aktion aus — „Service erstellen“ aus einem Template im Portal — und die Plattform gerüstet das Repo, verdrahtet CI (Build, Test, Scan), committet die GitOps-Konfiguration, rollt über Argo CD auf GKE aus und hängt Leitplanken und Observability automatisch an. Keine Tickets, kein Ops-Flaschenhals. Das ist das gesamte Wertversprechen: Self-Service, mit den sicheren Defaults bereits eingebaut.

Brauchst du wirklich eine Plattform?

Hier zählt Ehrlichkeit, denn eine Plattform zu bauen, die niemand adoptiert, ist einer der teuersten Fehler der Infrastruktur. Mehr Plattform ist nicht automatisch besser.

• Kleines Team, eine Handvoll Services? Du brauchst keine Plattform. Gute Templates, eine solide README und eine saubere CI-Pipeline schlagen eine maßgeschneiderte Plattform, für deren Wartung dir die Leute fehlen.
• Mehrere Teams lösen dieselben Infra-Probleme, kognitive Last bremst die Delivery, und genug Größe, um ein Plattform-Team zu besetzen? Jetzt zahlt sich eine Plattform aus — bau die IDP und betreib sie als Produkt.

Der Auslöser ist bewiesener, wiederkehrender Schmerz, nicht der Trend. Wenn du den konkreten Toil, den die Plattform beseitigt, und die Teams, die sie am ersten Tag adoptieren, nicht benennen kannst, baust du Technik um ihrer selbst willen — genau der Fehlermodus aus der Vergleichstabelle.

Werkzeuge und die Google-Cloud-Zuordnung

Das Platform-Engineering-Toolkit 2026 auf Kubernetes ist weitgehend CNCF-nativ: Backstage fürs Portal, Crossplane für Infrastructure-as-APIs, Argo CD für GitOps-Delivery, Kyverno oder OPA Gatekeeper für Policy und Kubernetes unter allem.

Auf Google Cloud bilden sich die Ebenen auf verwaltete Bausteine ab: GKE für den Cluster, Config Connector (oder Config Controller), um GCP-Ressourcen als Kubernetes-Objekte zu verwalten, Cloud Deploy für Delivery-Pipelines und Cloud Build oder Artifact Registry für die Supply Chain — alle fügen sich sauber unter dieselbe Self-Service-Schnittstelle.

Das ehrliche Fazit

Platform Engineering ist nicht Kubernetes mit einem hübscheren Logo, und es ist kein Ersatz für DevOps oder SRE. Es ist die Disziplin, eine Internal Developer Platform als Produkt zu bauen: Golden Paths, die den einfachen Weg zum sicheren machen, eine Self-Service-Schnittstelle über der Infrastruktur und Leitplanken und Observability in jeder Ebene.

Bau sie, um echte, wiederkehrende kognitive Last zu beseitigen — und miss sie auf die einzige Weise, die zählt: ob deine Entwickler sie tatsächlich nutzen wollen. Eine Plattform, die niemand adoptiert, ist nur mehr Infrastruktur zum Warten. Eine, die sie lieben, ist die schnellste befestigte Straße zur Produktion, die du ihnen geben kannst.

Weiterführend: GitOps mit Argo CD ist die Delivery-Schicht einer IDP, und Secure-by-Default GKE ist die Leitplanken-Schicht, richtig gemacht.