Ein mittelgroßes Softwareunternehmen hatte vor zwei Jahren konsequent DevOps eingeführt. Jedes Produktteam war für seine eigene CI/CD-Pipeline verantwortlich, betrieb seine eigene Kubernetes-Infrastruktur, wählte seine eigenen Monitoring-Tools. Das war die Idee: Autonomie, schnelle Entscheidungen, keine zentralen Engpässe.
Zwölf Monate später sah die Realität anders aus. Jedes Team hatte seine Pipelines etwas anders gebaut. Ein Sicherheits-Update musste an elf verschiedenen Stellen eingespielt werden. Neue Entwickler brauchten Wochen, um produktiv zu werden, weil jede Umgebung anders war. Und die Senior Engineers, die eigentlich an Produktfeatures arbeiten sollten, verbrachten einen erheblichen Teil ihrer Zeit damit, Infrastruktur zu warten.
Das ist kein Einzelfall. Es ist das klassische Skalierungsproblem von DevOps-Autonomie – und Platform Engineering ist die Antwort darauf.
Platform Engineering bezeichnet die Praxis, eine interne Entwicklungsplattform zu bauen, die Produktentwicklungsteams als Self-Service-Infrastruktur nutzen können. Die Plattform nimmt Teams die Komplexität von Infrastruktur ab, ohne ihnen Autonomie zu nehmen.
Das Ergebnis heißt Internal Developer Platform (IDP) oder Internal Developer Portal – je nach Umsetzungsgrad. Es ist kein Toolset, das man kaufen und ausrollen kann. Es ist ein Produkt, das ein spezialisiertes Team entwickelt und pflegt – für interne Kunden, also andere Entwicklungsteams.
Platform Engineering ist damit die logische Konsequenz aus dem Skalierungsproblem verteilter DevOps-Verantwortung: Wenn jedes Team seine eigene Infrastruktur baut, entstehen Duplikation, Inkonsistenz und ein Wartungsaufwand, der mit der Teamanzahl exponentiell wächst.
Der Unterschied zu klassischem DevOps
In klassischen DevOps-Setups gibt es zwei Extreme: Entweder ein zentrales Ops-Team, das alles managed und zum Engpass wird. Oder vollständige Autonomie der Produktteams, bei der jedes Team seine eigene Infrastruktur erfinden muss.
Platform Engineering beschreibt einen mittleren Weg: “You build it, you run it” – aber auf einer Grundlage, die zentral bereitgestellt wird. Das Plattform-Team baut und betreibt die Infrastruktur-Schicht. Produktteams nutzen sie über standardisierte Schnittstellen, ohne die Interna verstehen zu müssen.
Der entscheidende Unterschied: Das Plattform-Team denkt in Produktmanagement-Kategorien. Es hat Nutzer – andere Entwickler – und ihre Developer Experience ist das eigentliche Produkt. Schlechte Usability, fehlende Dokumentation oder zu lange Deployment-Zeiten werden genauso ernst genommen wie Bugs in einer Nutzeranwendung.
Golden Paths statt Freiheit in jede Richtung
Ein zentrales Konzept im Platform Engineering ist der Golden Path – ein vordefinierter, gut unterstützter Weg, eine Anwendung zu deployen, zu monitoren und zu betreiben. Er ist nicht der einzig mögliche Weg, aber er ist der, für den das Plattform-Team Support, Automatisierung und Dokumentation bietet.
Teams können davon abweichen – aber sie übernehmen dann die Verantwortung für den Mehraufwand. Das ist ein eleganter Mechanismus: Er zwingt niemanden, gibt aber einen starken Anreiz, den Standard zu nutzen.
In der Praxis bedeutet das: Wer ein neues Microservice-Projekt startet, klickt sich durch ein Portal, wählt den Technologie-Stack, gibt Projektnamen und Team ein – und bekommt in wenigen Minuten eine vollständig konfigurierte Repository-Struktur, eine CI/CD-Pipeline, ein Monitoring-Dashboard und eine Staging-Umgebung. Alles nach einem Standard, der einmal definiert und zentral gepflegt wird.
Die ehrliche Antwort: nicht immer. Ein Team von zwanzig Entwicklern braucht keine Internal Developer Platform. Die Komplexität, eine solche Plattform zu bauen und zu betreiben, lohnt sich erst ab einer gewissen Teamgröße und Infrastrukturkomplexität.
Als grobe Richtlinie: Sobald mehr als vier bis fünf autonome Entwicklungsteams existieren, die alle ähnliche Infrastrukturprobleme lösen, lohnt sich die Frage, ob ein dediziertes Plattform-Team diese Probleme einmal gut lösen kann – statt dass jedes Team sie schlecht und mehrfach löst.
Das zweite Indiz: Wenn Senior Engineers signifikante Zeit mit Infrastrukturwartung verbringen, die nicht direkt zu Produktfeatures beiträgt.
Ein häufiger Fehler: Das Plattform-Team wird als zentrales Ops-Team umgelabelt. Alte Strukturen, neues Etikett.
Der Unterschied ist fundamental. Ein klassisches Ops-Team ist ein Dienstleister, der auf Anfragen reagiert. Ein Plattform-Team ist ein Produktteam, das proaktiv in die Bedürfnisse seiner Nutzer investiert, Feedback einholt und die Plattform kontinuierlich verbessert. Es hat einen eigenen Backlog, eigene Metriken – typischerweise Developer Experience-Metriken wie Time-to-Deploy oder DORA-Metriken der nutzenden Teams – und eine eigene Produktvision.
Wenn diese Produktperspektive fehlt, wird aus einem Plattform-Team schnell wieder ein Bottleneck – diesmal mit Kubernetes statt Ticketsystem.