---
title: "Platform Engineering auf Kubernetes: Was es wirklich ist (und wie man die Plattform baut)"
description: "Platform Engineering auf Kubernetes, ohne Hype erklärt: was eine Internal Developer Platform wirklich ist, wie sie sich von DevOps und SRE unterscheidet, die Anatomie einer IDP, Golden Paths, eine Vergleichstabelle und eine ehrliche Antwort, ob du überhaupt eine brauchst."
author: Aleksei Aleinikov
date: 2026-07-23
lang: de
tags: [platform-engineering, platform-engineering-kubernetes, internal-developer-platform, golden-paths, gitops, kubernetes, devops]
canonical: https://www.alekseialeinikov.com/de/blog/topics/devops/platform-engineering-auf-kubernetes-2026
source: alekseialeinikov.com
---

# 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.

![Ein Diagramm, das zwei Entwickler gegenüberstellt. Links, „ohne Plattform", ist ein Entwickler von vielen Werkzeugen umgeben — Kubernetes, Helm, Terraform, CI/CD, Networking, Secrets, Security — beschriftet mit hoher kognitiver Last. Rechts, „mit Plattform", interagiert der Entwickler mit einer einzigen Self-Service-Schnittstelle, beschriftet als Golden Path, während die Plattform alle darunterliegenden Werkzeuge absorbiert.](https://www.alekseialeinikov.com/blog/platform-engineering-golden-path-2026.webp)

## 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** | **SRE** | **Platform Engineering** |
|---|---|---|---|
| **Was es ist** | Eine Kultur und Praxis | Eine Reliability-Engineering-Disziplin | Eine IDP als Produkt bauen |
| **Kernidee** | Dev/Ops-Wand einreißen — „you build it, you run it" | Zuverlässigkeit via SLOs und Error Budgets | Golden Paths und Self-Service im großen Maßstab |
| **Besitzt** | Wie Teams zusammenarbeiten | Uptime, Toil, Incident Response | Die Entwicklerplattform und ihre UX |
| **Scheitert, wenn** | Jedes Team muss allen Ops meistern | Als Umbenennung für Ops behandelt | Als Technik um ihrer selbst willen gebaut, nicht adoptiert |
| **Der Einzeiler** | Das *Ziel* | Hält es *zuverlässig* | Das *Produkt*, das beides skalieren lässt |

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:

![Ein geschichtetes Stack-Diagramm einer Internal Developer Platform auf Kubernetes. Von unten: Cloud-Infrastruktur (GKE, Compute, Netzwerk); Orchestrierung und Konfiguration (Kubernetes, Crossplane, Helm, Kustomize); Continuous Delivery (Argo CD, GitOps); und die Self-Service-Schnittstelle oben (Entwicklerportal wie Backstage, Templates, Plattform-CLI und -API). Zwei vertikale Balken spannen rechts über alle Ebenen: Leitplanken (Policy-as-Code, RBAC, Security) und Observability (Metriken, Logs, Traces).](https://www.alekseialeinikov.com/blog/platform-engineering-idp-layers-2026.webp)

- **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.

![Ein Entscheidungsbaum mit dem Titel „Brauchst du wirklich eine Plattform?". Erste Frage: Lösen mehrere Teams dieselben Infra-Probleme immer wieder? Zweite: Bremst kognitive Last die Delivery messbar? Dritte: Hast du genug Größe, um ein Plattform-Team zu finanzieren, das die Plattform als Produkt behandelt? Wenn die Antworten nein sind, lautet die Empfehlung: gute Templates plus eine README schlagen eine Plattform, die du nicht warten kannst. Wenn ja zu allen, bau eine IDP und betreib sie als Produkt.](https://www.alekseialeinikov.com/blog/platform-engineering-decision-2026.webp)

- **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](https://www.alekseialeinikov.com/de/blog/topics/devops/gitops-mit-argo-cd-automatisierte-kubernetes-deployments-2026) ist die Delivery-Schicht einer IDP, und [Secure-by-Default GKE](https://www.alekseialeinikov.com/de/blog/topics/architecture/secure-by-default-gke-referenzarchitektur-2026) ist die Leitplanken-Schicht, richtig gemacht.*