Platform Engineering: Eine interne Entwicklerplattform, die Teams tatsächlich nutzen

Das Versprechen von Platform Engineering klingt überzeugend: Entwicklern Self-Service-Zugang zu Infrastruktur geben, die kognitive Last reduzieren und sie sich auf Geschäftslogik konzentrieren lassen, statt mit YAML zu kämpfen. Die Realität: Die meisten internen Entwicklerplattformen scheitern — nicht an der Technologie, sondern daran, dass sie für das Plattformteam gebaut werden, nicht für die Entwickler, die sie nutzen sollen.

So bauen Sie eine Internal Developer Platform (IDP), die Teams tatsächlich annehmen — basierend auf Mustern, die wir in Enterprise-Organisationen haben gelingen (und scheitern) sehen.

Warum die meisten internen Plattformen scheitern

Bevor Sie irgendetwas bauen, verstehen Sie die drei Arten, wie Plattformen scheitern:

Der „Bau es und sie werden kommen"-Trugschluss. Ein Self-Service-Portal ohne Dokumentation, ohne Onboarding und ohne Feedback-Schleife. Entwickler probieren es einmal, stoßen an eine Wand und kehren zum Jira-Ticket-Erstellen zurück.
Die „Trampelpfad pflastern"-Falle. Kaputte Prozesse automatisieren. Wenn das Deployment in die Produktion 14 manuelle Schritte erfordert, produziert die Automatisierung aller 14 Schritte eine fragile Pipeline, keine Plattform.
Das „Goldener Käfig"-Problem. Eigenwillige Plattformen ohne Ausstiegsmöglichkeiten. Wenn ein Team auf einen Edge Case trifft, den die Plattform nicht unterstützt, verlässt es die Plattform entweder komplett oder baut zunehmend kreative Workarounds.

Der gemeinsame Nenner: Alle drei priorisieren die Vision des Plattformteams über den tatsächlichen Workflow der Entwickler.

Mit Golden Paths starten, nicht mit goldenen Käfigen

Ein Golden Path ist ein opinionierter, gut gepflasterter Weg durch einen gängigen Workflow — einen neuen Service erstellen, in die Produktion deployen, eine Datenbank provisionieren. Es ist der empfohlene Weg, nicht der einzige.

Was einen guten Golden Path ausmacht:

Er deckt 80 % der Anwendungsfälle ohne Anpassung ab. Wenn die meisten Teams Node.js-Services auf Kubernetes deployen, sollte Ihr Golden Path genau das trivial einfach machen.
Er ist verlassbar. Teams mit nicht-standardmäßigen Anforderungen können den Pfad verlassen und Ressourcen direkt verwalten. Sie verlieren den Komfort, nicht die Fähigkeit.
Er ist mit Beispielen dokumentiert, nicht nur mit Referenzdokumentation. Ein funktionierendes Beispiel-Repository, das Entwickler klonen und anpassen können, ist mehr wert als eine 50-seitige Spezifikation.
Er entwickelt sich anhand von Feedback weiter. Golden Paths sind Produkte, keine Projekte. Sie brauchen kontinuierliche Iteration basierend auf Nutzungsdaten und Reibungsberichten.

Ein praktisches Beispiel:

Ein Golden Path für „neuen Microservice erstellen" könnte umfassen:

Ein Backstage Software Template, das ein Git-Repository mit Dockerfile, Helm-Chart, CI-Pipeline und Flux-GitOps-Manifesten scaffolded.
Automatische Erstellung einer Datenbank (via Crossplane), eines Key Vaults für Secrets und eines Service Principals mit Least-Privilege-Zugriff.
Eine vorkonfigurierte CI/CD-Pipeline, die ab dem ersten Commit baut, testet, scannt und in eine Dev-Umgebung deployed.

Der Entwickler füllt ein Formular aus (Service-Name, Sprache, Datenbanktyp), klickt auf Erstellen und hat in 15 Minuten einen laufenden Service. Das ist der Golden Path.

Der Technologie-Stack

Eine IDP ist kein Produkt, das man kauft — es ist eine Komposition von Tools. Hier ist ein bewährter Stack:

Backstage: Das Entwicklerportal

Backstage (ursprünglich von Spotify, jetzt ein CNCF-Projekt) liefert die entwicklernahe Schicht:

Software Catalog: Eine einzige Quelle der Wahrheit für alle Services, ihre Eigentümer, Dokumentation und Abhängigkeiten. Beseitigt das „Wem gehört dieser Service?"-Problem.
Software Templates: Scaffolding, das neue Projekte mit eingebauten Best Practices erstellt. Templates rufen APIs (GitHub, Azure, Crossplane) auf, um alles zu provisionieren, was ein Service braucht.
TechDocs: Documentation-as-Code, gerendert neben dem Service im Katalog. Entwickler müssen nicht in Confluence nach Dokumentation suchen.
Plugins: Kubernetes-Status, CI/CD-Pipeline-Status, Security-Scan-Ergebnisse, Kosten-Dashboards — alles in einem Portal gebündelt.

Praxisempfehlung: Starten Sie mit dem Software Catalog. Befüllen Sie ihn mit bestehenden Services durch Import aus Ihrem Git-Provider. Templates und Plugins kommen später, sobald der Katalog seinen Wert bewiesen hat.

Crossplane: Self-Service-Infrastruktur

Crossplane erweitert Kubernetes um Custom Resource Definitions (CRDs), die Cloud-Ressourcen provisionieren. Es verwandelt Infrastruktur-Anfragen in Kubernetes-Manifeste.

Ein Entwickler, der eine PostgreSQL-Datenbank benötigt, erstellt einen Claim:

YAML

apiVersion: database.platform.internal/v1alpha1
kind: PostgreSQLClaim
metadata:
  name: my-service-db
  namespace: my-service
spec:
  size: small
  version: "15"

Das Plattformteam definiert Compositions, die diesen einfachen Claim auf die tatsächlichen Azure-Ressourcen abbilden: einen Flexible Server, Firewall-Regeln, einen Private Endpoint, ein Key-Vault-Secret mit dem Connection String.

Warum Crossplane statt Terraform für Self-Service?

Crossplane ist deklarativ und wird kontinuierlich reconciliert — wenn jemand die Firewall-Regel im Portal löscht, erstellt Crossplane sie neu.
Crossplane-Claims sind Namespace-basiert — natürliche Multi-Tenancy. Teams können nur ihre eigenen Ressourcen sehen und verwalten.
Crossplane nutzt die Kubernetes-API — kein zusätzliches Tooling, keine separate Authentifizierung, kein State-Management.

Argo Workflows oder Tekton: Orchestrierung

Für Workflows, die über einfache Ressourcen-Provisionierung hinausgehen — Onboarding eines neuen Teams, Credential-Rotation, Compliance-Checks — verwenden Sie eine Workflow-Engine.

Argo Workflows für komplexe DAG-basierte Workflows mit visueller UI.
Tekton, wenn Sie vollständig Kubernetes-nativ bleiben und es bereits für CI/CD nutzen.

Developer Experience messen

Wenn Sie Adoption und Zufriedenheit nicht messen, fliegen Sie blind. Das sind die Metriken, die zählen:

Lead-Time-Metriken

Zeit vom Code-Commit bis zum Laufen in der Produktion. Das ist Ihre Nordstern-Metrik. Wenn die Plattform funktioniert, sinkt diese Zahl über die Zeit.
Zeit zur Provisionierung eines neuen Service. Von der Template-Nutzung bis zum ersten erfolgreichen Deployment. Ziel: unter 30 Minuten.
Zeit zum Onboarding eines neuen Entwicklers. Vom Laptop-Setup bis zum ersten deployed Commit. Ziel: unter einem Tag.

Adoptions-Metriken

Anteil der Services, die den Golden Path nutzen. Tracken Sie das nach Team und Service-Alter. Neue Services sollten nahe 100 % liegen. Legacy-Services werden hinterherhinken, und das ist in Ordnung.
Template-Nutzungshäufigkeit. Wie viele neue Services werden pro Monat über die Plattform erstellt versus manuell?
Self-Service-Quote. Welcher Anteil der Infrastruktur-Anfragen wird über die Plattform bedient versus manuelle Tickets? Ziel: 80 %+ Self-Service innerhalb von 12 Monaten.

Zufriedenheits-Metriken

Developer Net Promoter Score (NPS) für die Plattform, quartalsweise erhoben.
Friction Logs. Bitten Sie Entwickler, jeden Punkt zu dokumentieren, an dem die Plattform sie verlangsamt hat. Das ist Gold für die Priorisierung von Verbesserungen.
Support-Ticket-Volumen. Ein sinkender Trend zeigt, dass die Plattform selbsterklärender wird.

Kernaussage: Die wichtigste Metrik ist nicht, wie viele Features die Plattform hat. Es ist, wie viele Teams sie freiwillig nutzen. Wenn Sie Adoption anordnen müssen, hat Ihre Plattform ein Produktproblem.

Organisationsdesign

Technologie ist der einfache Teil. Der schwierige Teil ist, die Plattform als Produkt zu betreiben.

Das Plattformteam als Produktteam

Bestimmen Sie einen Product Owner, der Entwicklerbedürfnisse vertritt, nicht Infrastruktur-Präferenzen.
Führen Sie User Research durch — begleiten Sie Entwickler bei der Plattformnutzung, führen Sie Interviews, sichten Sie Friction Logs.
Pflegen Sie eine öffentliche Roadmap, die Entwickler sehen und beeinflussen können.
Behandeln Sie Plattform-Features wie Produkt-Features: Discovery, Design, Build, Measure, Iterate.

Das Inner-Source-Modell

Machen Sie Plattform-Code offen für Beiträge. Wenn ein Team ein neues Backstage-Plugin oder eine Crossplane-Composition braucht, sollte es diese bauen und einen PR einreichen können.
Das Plattformteam reviewt und pflegt den Kern, aber das Ökosystem wächst durch Contributions.
Veröffentlichen Sie Contribution Guidelines und halten Sie regelmäßige Office Hours für Teams, die die Plattform erweitern möchten.

Schrittweiser Rollout

Starten Sie mit 2-3 Early-Adopter-Teams, die motiviert und nachsichtig sind.
Iterieren Sie basierend auf deren Feedback, bis der Golden Path wirklich reibungslos funktioniert.
Erweitern Sie erst auf die nächste Welle, wenn Early Adopter erfolgreich sind und bereitwillig als Fürsprecher auftreten.
Ordnen Sie Plattform-Adoption niemals an, bevor die Plattform bereit ist. Teams auf eine halbfertige Plattform zu zwingen zerstört Vertrauen, das Jahre zum Wiederaufbau braucht.

Häufige Fallstricke

Bauen Sie keine UI, bevor Sie funktionierende APIs haben. Das Portal ist ein Frontend. Wenn die zugrunde liegende Automatisierung nicht zuverlässig funktioniert, macht eine hübsche Oberfläche Fehler nur sichtbarer.
Abstrahieren Sie nicht zu früh. Starten Sie mit konkreten Golden Paths für Ihren häufigsten Anwendungsfall. Abstrahieren Sie erst in eine generalisierte Plattform, wenn Sie drei oder mehr konkrete Pfade funktionierend haben.
Ignorieren Sie Ausstiegsmöglichkeiten nicht. Jeder Golden Path braucht einen dokumentierten Weg, um „off-road" zu gehen. Wenn Entwickler etwas nicht tun können, das die Plattform nicht unterstützt, verlassen sie sie komplett.
Konkurrieren Sie nicht mit dem Portal Ihres Cloud-Anbieters. Die Plattform sollte Azure/AWS ergänzen, nicht replizieren. Wenn ein Entwickler eine einmalige Ressource konfigurieren muss, lassen Sie ihn die Cloud-Konsole nutzen.

Der Weg nach vorn

Platform Engineering ist eine mehrjährige Investition, kein Quartalsprojekt. Starten Sie klein, messen Sie konsequent, und iterieren Sie basierend auf dem, was Entwickler tatsächlich brauchen — nicht was das Plattformteam glaubt, dass sie brauchen sollten.

Die Plattformen, die Erfolg haben, sind die, die von Teams gebaut werden, die wie Produktingenieure denken, nicht wie Infrastrukturingenieure.

Sie bauen eine interne Entwicklerplattform? Sprechen Sie mit unserem Team — wir helfen Unternehmen beim Design, Aufbau und Betrieb von IDPs, die echte Adoption erzielen.