„Ich brauche eine neue Umgebung.” Früher bedeutete das ein Ticket, zwei Wochen Wartezeit und einen frustrierten Entwickler. Heute bedeutet es einen Klick im Portal und innerhalb von 10 Minuten einen laufenden Kubernetes-Namespace mit Datenbank, Monitoring und CI/CD-Pipeline. So sieht unsere interne Developer Platform aus — und so haben wir sie aufgebaut.
Warum Platform Engineering¶
Mit 30+ Microservices und 5 Entwicklungsteams stießen wir an ein Skalierungsproblem. Kein technisches — ein organisatorisches. Jedes Team handhabte Deployments anders. Infrastruktur-Wissen war auf 2 Personen konzentriert. Das Onboarding eines neuen Entwicklers dauerte eine Woche allein für die Einrichtung der Umgebung.
Platform Engineering = ein dediziertes Team baut eine interne Plattform, die Infrastrukturkomplexität abstrahiert. Entwickler konzentrieren sich auf Business-Logik; die Plattform kümmert sich um Deployment, Monitoring, Scaling und Security.
Golden Paths — kein goldener Käfig¶
Ein Golden Path = der empfohlene Weg, Dinge zu tun. Neuer Service nötig? Hier ist ein Template (Spring Boot + Dockerfile + Helm Chart + CI-Pipeline). Datenbank nötig? Hier ist ein Provisioner (PostgreSQL auf Kubernetes mit Backup).
Der Schlüssel: Golden Paths sind Empfehlungen, keine Vorschriften. Ein Team kann vom Pfad abweichen, muss dann aber die Infrastruktur selbst handhaben. 95 % der Teams bleiben auf dem Golden Path, weil es einfacher ist.
Backstage — Developer Portal¶
Spotifys Backstage als Self-Service-Portal. Ein Katalog aller Services (Ownership, Abhängigkeiten, API-Docs, Runbooks). Templates zur Erstellung neuer Services (Cookiecutter + Backstage Scaffolder). Integration mit Kubernetes, ArgoCD, Grafana, PagerDuty.
Ein Entwickler sieht an einem Ort: seine Services, deren Zustand, Deployment-Historie, Metriken, offene Incidents. Kein Wechseln zwischen 10 Tools.
Self-Service-Infrastruktur¶
Crossplane für Infrastructure Provisioning über Kubernetes CRDs. Ein Entwickler erstellt ein YAML-Manifest — „Ich möchte eine PostgreSQL-Datenbank, 10 GB, im Staging-Namespace” → Crossplane provisioniert Azure Database for PostgreSQL → der Connection String erscheint in einem Kubernetes Secret.
Der gleiche Ansatz für Redis, Kafka Topics und Azure Blob Container. Das Infra-Team definiert das „Angebot” (was verfügbar ist und mit welchen Parametern); Entwickler konsumieren es per Self-Service.
CI/CD-Standardisierung¶
Gemeinsame GitHub Actions Workflows. Jeder Service hat eine .github/workflows/ci.yml, die einen Reusable Workflow aus dem platform-workflows-Repository aufruft. Build, Test, Scan (Trivy), Image pushen, Deploy via ArgoCD — Standard für alle Services. Custom Steps über erweiterbare Hooks.
Messung der Developer Experience¶
DORA-Metriken + Developer-Satisfaction-Survey (vierteljährlich):
- Time to First Deployment (neuer Service): von 5 Tagen auf 2 Stunden
- Onboarding neuer Entwickler: von 5 Tagen auf 1 Tag
- Cognitive Load Score (Survey): von 7,2 auf 4,1 (von 10)
- Developer Satisfaction: von 3,2 auf 4,1 (von 5)
Erkenntnisse¶
Die Plattform ist ein Produkt. Sie hat Kunden (Entwickler), einen Product Owner, eine Roadmap und eine Feedback-Schleife. Bauen Sie sie als Produkt, nicht als Projekt.
Klein anfangen. Bauen Sie nicht die gesamte Plattform auf einmal. Beginnen Sie mit dem, was am meisten schmerzt (bei uns: Environment Provisioning).
Dokumentation > Automatisierung. Manchmal reicht ein gutes Runbook statt voller Automatisierung. Automatisieren Sie erst, wenn der Prozess stabil ist.
Die Plattform als Multiplikator¶
Platform Engineering ist kein Overhead — es ist eine Investition in die Geschwindigkeit der gesamten Organisation. 3 Leute im Platform Team beschleunigen 30 Entwickler. Das ist ein Multiplikator, der sich auszahlt.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns