Platform Engineering: DevEx als neuer Wettbewerbsvorteil
Entdecken Sie, wie platform engineering die Entwicklererfahrung revolutioniert und so den entscheidenden Wettbewerbsvorteil sichert.
Das Wichtigste in Kürze
- Platform Engineering baut interne Developer-Plattformen, die Komplexität abstrahieren.
- Internal Developer Portals (Backstage, Port) bieten Self-Service für Infrastruktur und Services.
- Golden Paths definieren den empfohlenen Weg für Standard-Aufgaben – ohne Freiheit einzuschränken.
- Teams mit guter Developer Experience deployen 4x häufiger und haben 3x weniger Incidents.
- Der Trend löst die „You Build It, You Run It“-Überlastung der DevOps-Bewegung.
DevOps hat ein Problem geschaffen, das es nicht lösen kann: Entwickler sollen Code schreiben, Infrastruktur managen, Pipelines bauen, Security-Scans konfigurieren und On-Call-Rotation übernehmen. Die kognitive Last explodiert. Platform Engineering ist die Antwort – eine dedizierte Disziplin, die interne Plattformen baut, auf denen Entwickler produktiv arbeiten können, ohne Cloud-Infrastruktur im Detail verstehen zu müssen.
Das DevOps-Paradox: Mehr Verantwortung, weniger Produktivität
„You Build It, You Run It“ war die richtige Idee zur falschen Zeit. Als Amazon das Prinzip einführte, hatten ihre Teams dedizierte Tooling-Teams, die Deployment-Pipelines und Monitoring-Infrastruktur bereitstellten. In den meisten Unternehmen wurde „You Run It“ ohne diese Unterstützung eingeführt – das Ergebnis: Entwickler verbringen 30-40% ihrer Zeit mit Infrastruktur statt mit Features.
Platform Engineering korrigiert dieses Ungleichgewicht. Ein dediziertes Platform-Team baut und betreibt die interne Developer-Plattform, die Entwicklern ermöglicht, produktiv zu sein, ohne Kubernetes-YAML, Terraform-Module oder CI/CD-Pipelines von Grund auf schreiben zu müssen.
Die Internal Developer Platform (IDP)
Eine IDP besteht aus vier Schichten: Infrastructure Orchestration (Terraform, Crossplane) provisioniert Cloud-Ressourcen. Container Orchestration (Kubernetes, ECS) betreibt Workloads. CI/CD (GitHub Actions, ArgoCD) automatisiert Deployment. Developer Portal (Backstage, Port) bietet die Self-Service-Oberfläche.
Das Portal ist der sichtbare Teil: Entwickler erstellen neue Services über Templates, sehen den Status ihrer Deployments, finden Dokumentation und können Infrastruktur-Ressourcen per Klick anfordern. Was dahinter passiert – Terraform Apply, Kubernetes Deployment, DNS-Konfiguration – ist abstrahiert.
Golden Paths: Opinionated, nicht restriktiv
Golden Paths sind der empfohlene Weg für Standard-Aufgaben: „So baust du einen neuen Microservice“, „So deployest du in Production“, „So richtest du Monitoring ein“. Sie sind opinionated – es gibt eine klare Empfehlung – aber nicht restriktiv. Teams können vom Golden Path abweichen, wenn sie einen guten Grund haben.
Konkret bedeutet das: Ein Service-Template in Backstage generiert ein Repository mit CI/CD-Pipeline, Dockerfile, Kubernetes-Manifesten, Monitoring-Konfiguration und Dokumentation. Der Entwickler ändert den Business-Code – alles andere ist vorkonfiguriert. Von Code-Commit bis Production-Deployment in 15 Minuten statt 3 Tagen.
Backstage als De-facto-Standard
Spotify hat Backstage 2020 als Open Source veröffentlicht, und es hat sich zum De-facto-Standard für Internal Developer Portals entwickelt. Der Plugin-Ökosystem umfasst über 150 Plugins: Kubernetes-Monitoring, CI/CD-Integration, API-Dokumentation, Cost Management, Security-Scans.
Die Stärke von Backstage liegt im Software Catalog: Ein zentrales Register aller Services, APIs, Libraries und Teams mit Ownership-Information. Wer betreibt diesen Service? Wo ist die Dokumentation? Welche APIs stellt er bereit? Diese Fragen beantwortet der Catalog – statt Slack-Threads und Confluence-Suche.
ROI von Platform Engineering
Die Daten sind konsistent: Teams mit guter Developer Experience deployen 4x häufiger, haben 3x weniger Change-Failure-Rate und onboarden neue Entwickler 50% schneller. Die Produktivitätssteigerung rechtfertigt das Investment in ein Platform-Team (typisch 3-5 Engineers für 50-200 Entwickler).
Der versteckte ROI liegt in der Retention: Entwickler, die mit modernen Tools und Plattformen arbeiten, bleiben länger. In Zeiten des Fachkräftemangels ist das ein relevanter Faktor. Wer Entwicklern zumutet, mit veralteten Tools und manuellen Prozessen zu arbeiten, verliert sie an Unternehmen, die in Developer Experience investieren.
Häufige Fragen
Was ist der Unterschied zwischen Platform Engineering und DevOps?
DevOps ist eine Kultur und Methodik – die Zusammenarbeit von Entwicklung und Betrieb. Platform Engineering ist eine Disziplin – ein Team, das eine interne Plattform baut. Platform Engineering setzt DevOps-Prinzipien um, aber in einer Form, die Entwickler nicht überfordert. Es ist die produktive Evolution von DevOps.
Wie groß muss ein Platform-Team sein?
Als Faustregel: 1 Platform Engineer pro 15-25 Entwickler. Ein Startup mit 20 Entwicklern braucht kein dediziertes Platform-Team – hier reichen Shared Responsibilities und gute Templates. Ab 50 Entwicklern wird ein dediziertes Team (3-5 Personen) sinnvoll, ab 200 Entwicklern ist es unverzichtbar.
Braucht man Backstage oder reichen CI/CD-Tools?
CI/CD ist eine Komponente der Platform, nicht die Platform selbst. Backstage oder Alternativen (Port, Cortex) bieten den Self-Service-Layer, der CI/CD, Infrastruktur, Monitoring und Dokumentation zusammenbringt. Für kleine Teams kann ein gut konfiguriertes GitHub mit Actions und Templates ausreichen.
Wie misst man Developer Experience?
Die SPACE-Metriken (Satisfaction, Performance, Activity, Communication, Efficiency) bieten einen Rahmen. Pragmatischer: Developer Surveys (vierteljährlich), Time-to-First-Commit (Onboarding), Deployment Frequency, Lead Time for Changes und die Anzahl der Self-Service-Requests vs. Tickets an das Platform-Team.
Kann man Platform Engineering schrittweise einführen?
Ja, und das ist der empfohlene Weg. Start mit dem höchsten Pain Point – oft CI/CD oder Kubernetes-Deployment. Einen Golden Path für den häufigsten Use Case bauen, Feedback sammeln, iterieren. Backstage kann minimal starten (Software Catalog) und schrittweise um Plugins erweitert werden.
Quelle des Titelbildes: Pexels / Markus Spiske
Lesetipps der Redaktion
cloudmagazinLenovo ThinkCentre M75q Tiny Gen 5: Enterprise-Mini-PC mit AMD PRO und 5 Watt Idle für Edge und KioskcloudmagazinServerless KI ist überbewertet – hier ist was stattdessen zähltcloudmagazinQNAP TS-464: 4-Bay-NAS mit Docker, HDMI und PCIe-Slot – was Synology in dieser Klasse nicht bietet
