Case Study: IDP für Enterprise mit 500+ Entwicklern
Skalierung, Organisation, Portal, Golden Paths — kompletter Walkthrough.
Lernziele
Nach dieser Lektion kannst du ein System-Design für eine Internal Developer Platform mit 500+ Entwicklern end-to-end durchspielen — inklusive Organisationsmodell, Portal, Golden Paths und Skalierungsentscheidungen. Du verstehst, warum Enterprise-IDP mehr ist als Kubernetes plus Backstage, und kannst Trade-offs zwischen Zentralisierung, Team-Autonomie und Betriebskapazität benennen. Du kennst typische Interviewer-Einwände zu „Plattform als Produkt” und kannst einen realistischen Rollout über 24 Monate skizzieren.
Das Szenario
„Du leitest das Platform-Engineering in einem Konzern: 500 Entwickler in 120 Stream-Teams, verteilt auf drei Business Units. Jede Unit hat eigene Prioritäten. Baue eine IDP, die Time-to-Production senkt, Compliance sichert und von den Teams adoptiert wird. Platform-Team: 25 Personen, wachsend auf 35.”
Wieder: zuerst klären, nicht skizzieren.
Phase 1: Anforderungsklärung (Minuten 0–12)
Deine Fragen und typische Antworten:
Organisation: 120 Teams, ~2 000 Services, drei BUs (Retail, Logistics, Finance). Finance hat PCI.
Aktueller Zustand: 40 % der Teams nutzen bereits K8s (wild gewachsen), 30 % VM/Jenkins, 30 % Serverless. Kein einheitliches Portal.
Schmerzpunkte: Onboarding 6 Wochen; 12 verschiedene CI-Systeme; Audit findet jedes Jahr neue Lücken; Entwickler beschweren sich über „Plattform-Bürokratie”.
Compliance: SOC 2, PCI in Finance-BU, ISO 27001 konzernweit.
Constraints: AWS + Azure (Legacy-Akquisition), EU-Data-Residency. Kein Big-Bang — laufender Betrieb.
Erfolgskriterium: 80 % der neuen Services über Golden Path in 12 Monaten; Lead Time von Commit to Prod unter 24 Stunden (Median).
Zusammenfassung: „Enterprise-Brownfield, PCI-Split nötig, Multi-Cloud light, Erfolg = Adoption + Lead Time + Audit.”
Phase 2: Organisationsmodell — wer baut was?
Bei 500 Entwicklern scheitert IDP ohne klare Team Topologies (Lektion 3):
| Team-Typ | Aufgabe | Größe |
|---|---|---|
| Platform-Team (Enabling) | Golden Paths, Portal, Policy, Provisioning | 25→35 |
| Stream-Teams | Produkte bauen, Golden Path nutzen | 120 Teams |
| Complicated-Subsystem (optional) | Payment, Identity — eigene Pfade | 2–3 Teams |
Interviewer-Einwand: „25 Leute für 500 Entwickler — reicht das?”
Antwort: „Nur wenn die Plattform wirklich Self-Service ist und nicht Ticket-Factory. Ratio 1:15 ist branchenüblich für reife IDPs — aber nur mit Golden Paths, die 80 % der Fälle abdecken. Der Rest geht über dokumentierte Escape Hatches mit Eigenverantwortung. Wenn Adoption unter 60 % fällt, brauchen wir mehr Platform-Kapacity oder schmalere Scope.”
Phase 3: Architektur — Control Plane at Scale
Management-Ebene (Multi-Cloud, aber schlank):
- Portal (Backstage o. ä.) — ein Einstieg: Catalog, Scaffolder, TechDocs, API-Docs. Nicht selbst bauen, wenn 500 Devs warten (Lektion 11: Adopt).
- Software Templates — 5–7 Golden Paths (Web-Service, Worker, CronJob, Terraform-Module, …), nicht 50.
- GitOps-Hub — Argo CD ApplicationSets; Team-Repos oder BU-Monorepos mit klarer Ownership.
- Policy-as-Code — zentrale Policy-Library; PCI-Cluster bekommen strengere Bundle.
- Identity — OIDC-Konfiguration zentral; RBAC-Mapping aus IdP-Gruppen (Lektion 45).
Data Plane — Cluster-Topologie:
| Cluster | Inhalt | Teams |
|---|---|---|
| Mgmt | Control Plane | Platform only |
| Non-Prod (Shared) | Dev, Staging | Alle BUs |
| Prod Standard (Shared) | Retail, Logistics | ~90 Teams |
| Prod PCI (Dedicated) | Finance Payment | ~15 Teams |
| Prod Azure (Legacy) | Migrierte Workloads | Übergang, 24 Mon |
Warum nicht ein Cluster pro Team? 120 Cluster = Betriebsalbtraum. Warum PCI separat? Compliance und Audit — Shared Cluster mit Finance-PCI ist ein Showstopper.
Interviewer-Einwand: „Backstage skaliert nicht — zu langsam bei 500 Usern.”
Antwort: „Backstage ist ein Framework, kein fertiges Portal — Performance hängt an Catalog-Backend und Caching. Alternativen: Port (getmanaged.io), Cortex, oder schlankes Custom-Portal nur für Scaffolder + Links. Entscheidung: Adopt Backstage mit dediziertem Catalog-Team und Performance-Budget; bei MVP reicht Scaffolder + minimale Catalog-Integration. Trade-off: Time-to-Value vs. Vollständigkeit.”
Phase 4: Golden Paths — das eigentliche Produkt
Die IDP ist kein Cluster. Sie ist curated experience:
- Scaffolder — Team wählt Template → Repo + CI + Argo App + NS in einem Flow.
- CI-Vorlage — Build, Test, Scan, SBOM, cosign-Sign (Lektion 44), Push to Registry.
- Standard-Chart — Deployment, Service, Ingress, NetworkPolicy, ServiceMonitor — Security by Default.
- Observability-Paket — Dashboards und Alerts vorkonfiguriert.
- Dokumentation — TechDocs im Repo, nicht im Wiki.
Metriken (Lektion 17): Golden-Path-Adoption, Lead Time, Deployment-Frequency, Platform-NPS.
Interviewer-Einwand: „Teams wollen Flexibilität — sie umgehen den Golden Path.”
Antwort: „Escape Hatch ja, aber teurer: Eigenes CI, eigenes Compliance-Nachweis-Paket, kein Platform-Support-SLA. 80 % nutzen den Path, weil er schneller ist — nicht weil er Zwang ist. Platform-Team investiert in DX der Paths, nicht in Polizei.”
Phase 5: Rollout und Risiken (Minuten 35–45)
| Phase | Monate | Ziel |
|---|---|---|
| 0 — TVP | 1–4 | 2 Golden Paths, 10 Pilot-Teams, Non-Prod |
| 1 — Adoption | 5–10 | Portal live, 5 Paths, 50 Teams, Prod Standard |
| 2 — Compliance | 11–16 | PCI-Cluster, SOC-2-Evidenz automatisiert |
| 3 — Scale | 17–24 | 80 % neue Services auf Path, Azure-Migration läuft |
Risiko: Plattform wird ignoriert. Gegenmaßnahme: Executive Sponsor, Lead Time öffentlich messen, Pilot-Teams als Champions.
Risiko: Platform-Team wird Bottleneck. Gegenmaßnahme: Self-Service first; jede manuelle Anfrage wird Ticket für Automatisierung.
Risiko: Multi-Cloud-Komplexität. Gegenmaßnahme: Abstraktion nur wo nötig (Identity, Policy); nicht „ein Terraform für AWS und Azure” am Tag eins.
Praxis
Schreibe eine ADR-Zusammenfassung (Lektion 12) für eine Entscheidung aus dem Case: „Warum PCI-Dedicated-Cluster statt Namespace-Isolation?” — Kontext, Optionen, Entscheidung, Konsequenzen. Maximal eine Seite.
Variante: Interviewer sagt „Budget halbiert — was streichst du?” Priorisiere: Golden Path + GitOps + Policy behalten; Portal-Customization und Multi-Cloud-Abstraktion verschieben.
Typische Stolperfallen
IDP = Tool-Liste. Backstage, Argo, Prometheus — ohne Adoption-Strategie wertlos.
500 Devs = 500 Custom Paths. Standardisierung ist Feature, nicht Bug.
Platform-Team ohne Product Owner. Ohne Roadmap und Metriken wird es Infrastruktur-IT.
PCI und Standard mischen. Audit-Finding garantiert.
Interview-Vorbereitung
30-Sekunden-Pitch: „Enterprise-IDP = Golden Paths als Produkt, getrennte PCI-Zone, Portal für Discovery und Scaffolding, GitOps + Policy für Compliance-Evidenz, phasenweise Adoption mit gemessener Lead Time.”
Follow-ups:
- „Build or buy Portal?” — Adopt mit Anpassung; Build nur für Differenzierung.
- „Wie messen Erfolg?” — Adoption, Lead Time, Incidents, NPS — nicht Cluster-Anzahl.
Zusammenfassung
Eine IDP für 500+ Entwickler ist ein Organisations- und Produktproblem: Golden Paths, Self-Service, klare Team Topologies und ein Platform-Team, das wie ein Produktteam arbeitet. Technisch: getrennte Control Plane, Shared Cluster für Standard-Workloads, dedizierter PCI-Cluster, Policy und Supply Chain im Path eingebaut. Erfolg misst du an Adoption und Lead Time — nicht an deployten Komponenten. Nächster Case: nicht Greenfield, sondern Legacy-Migration.