Eine Plattform ist ein Produkt, kein Wiki voller Links
Eine Internal Developer Platform (IDP) führt Werkzeuge, Templates und Dokumentation in einer einzigen Self-Service-Oberfläche zusammen. Das Schlüsselwort ist Produkt: Sie hat einen Owner, Nutzer — Entwickler — und eine Erfolgsmetrik: wie schnell ein Ingenieur eine Idee in Produktion bringt. Ein Portal, das niemand als Produkt betreibt, stirbt innerhalb eines halben Jahres — darauf komme ich zurück.
Der zentrale Schmerz, den eine IDP nimmt, ist die kognitive Last. Ein Entwickler an einem einzigen Microservice muss heute Kubernetes-Manifeste, Terraform, ArgoCD, Vault-Policies, Prometheus-Regeln und Kyverno-Policies gleichzeitig im Kopf behalten. Die Plattform verbirgt das hinter Self-Service: Knopf drücken, Umgebung bekommen.
Warum gerade jetzt: drei Treiber
1. DevOps ohne Struktur skaliert nicht. Das Modell „jedes Team ist sein eigenes DevOps“ funktioniert bei drei Teams und bricht bei dreißig: Jedes baut seinen eigenen Werkzeug-Zoo, und die Organisation versinkt in Fragmentierung. Eine Plattform stellt Konsistenz wieder her, ohne die Autonomie zu töten.
2. KI-Code überholt Governance. Agenten und Copilot schreiben Code schneller, als manuelles Code-Review ihn validieren kann. Die einzige skalierbare Antwort ist, die Kontrolle in automatisierte Guardrails zu verlagern: Policy-as-Code als Admission Control statt eines menschlichen Reviewers als Flaschenhals.
3. Die kognitive Last ist untragbar geworden. Das folgt aus den ersten beiden: Je mehr Werkzeuge und je schneller der Änderungsfluss, desto teurer ist es, alles im Kopf zu behalten. Eine IDP gibt dem Entwickler den Fokus auf seinen eigenen Service zurück.
Laut CNCF haben 28 % der Organisationen bereits ein Plattform-Team; Gartner prognostiziert 80 % der großen Enterprises bis Ende 2026. Das ist kein Hype — es ist eine strukturelle Antwort auf Komplexität.
Der kanonische Sechs-Schichten-Stack
Eine funktionierende Plattform auf Kubernetes setzt sich aus sechs Schichten zusammen. Ich halte mich an CNCF-native Defaults — nicht weil sie die einzig richtige Wahl wären, sondern weil sie zusammenpassen: Die Werkzeuge sind füreinander gebaut.
- 1. Developer Portal — Backstage: einheitliche UI, Katalog, Scaffolder.
- 2. GitOps & Deployment — ArgoCD oder Flux: deklarative Auslieferung.
- 3. Infrastructure Provisioning — Crossplane: Infrastruktur als K8s-Ressourcen.
- 4. Policy & Security — Kyverno und Trivy: Guardrails und Scanning.
- 5. Observability — Prometheus, Grafana, OpenTelemetry.
- 6. AI / DevEx — noch emerging: Assistenten und KI-gestützte Incident-Triage.
Sechs Schichten sind das Minimum. Reife Plattformen ergänzen hauseigene Admin-API-Services und KI-gestützte Triage. Doch ohne die ersten sechs ist der Überbau sinnlos. Ein wichtiger Vorbehalt: ein Portal ohne Golden Paths und Policy-Engine ist ein Katalog ohne Inhalt. Ein nacktes Backstage liefert keinen Wert; der Wert steckt in den Templates, die per Knopfdruck ein Repository mit CI/CD, Observability und Security-Baseline ausliefern — und in den Policies, die diese Baseline vor dem Verfall bewahren.
Die drei Säulen des Portals
- Software Catalog — eine einzige Source of Truth: Services, Owner, Abhängigkeiten, Runbooks, Dashboard-Links. Keine handgepflegte Tabelle, sondern automatische Discovery.
- Scaffolder — Golden Paths als Code: Knopf → fertiges Repository mit Pipeline, Monitoring und Security-Baseline.
- TechDocs — Docs-as-Code aus den Service-Repositories mit einheitlicher Suche.
Was man messen sollte
Eine Platform-as-a-Product verlangt Produktmetriken:
- Time-to-first-deploy — von der Repo-Erstellung bis zur Produktion (Ziel: unter einem Tag).
- Self-Service-Ratio — der Anteil der Aufgaben, die ohne das Plattform-Team gelöst werden.
- Template-Adoption — der Anteil neuer Services über den Scaffolder.
- Internal NPS — eine Entwicklerumfrage einmal pro Quartal.
Wenn die Adoption steigt, während der NPS fällt, haben Sie Zwang gebaut, keine Plattform.
Vier Wege, eine IDP zu töten
- Ein Portal ohne Owner-Team — niemand entwickelt es weiter, es stirbt in einem halben Jahr.
- Ein Scaffolder ohne Post-Create-Automation — er hat Boilerplate erzeugt, aber CI, Secrets und Monitoring nie verdrahtet; der Entwickler steht trotzdem beim Plattform-Team.
- Ein Katalog als handgepflegte Tabelle — ohne automatische Discovery veraltet er am Tag seiner Erstellung.
- Erzwungene Adoption — eine Plattform sollte der beste Weg sein, nicht der einzige.
Fazit
Eine IDP ist eine Investition in Geschwindigkeit und Konsistenz, die sich nur mit Produkt-Mindset auszahlt: Owner, Metriken und ein Weg, den man freiwillig wählt. Die sechs Schichten geben den Rahmen; die drei Treiber erklären, warum Aufschieben teuer ist; die vier Anti-Patterns zeigen, wo Plattformen sterben. Beginnen Sie nicht mit dem Portal — beginnen Sie mit einem Golden Path, der einem Entwickler wirklich einen Tag spart. Und die sechs Schichten müssen nicht auf einmal entstehen — bauen Sie sie inkrementell aus, sobald die vorige Schicht sich zu rentieren beginnt.