Was eine Internal Developer Platform ist
Eine Internal Developer Platform (IDP) ist eine integrierte Sammlung von Fähigkeiten, die ein Plattformteam für die Entwicklungsteams des eigenen Unternehmens bereitstellt und pflegt. So beschreibt es das Platforms Whitepaper der CNCF: Die Plattform bündelt Infrastruktur, Pipelines, Umgebungen und Betriebsaufgaben so, dass Teams sie ohne Einzelabsprachen nutzen können. Drei Bausteine tauchen dabei in fast jeder Umsetzung auf.
- Golden Paths: vorbereitete, dokumentierte Wege für wiederkehrende Aufgaben. Ein neues Service-Repository entsteht aus einem Template, bringt Pipeline, Deployment und Grundkonfiguration mit. Technische Vorgaben lassen sich darin vorbelegen und automatisiert prüfen; zusätzliche Anforderungen der Anwendung bleiben zu bewerten.
- Self-Service: Teams fordern Umgebungen, Datenbanken oder Berechtigungen über definierte Schnittstellen an, statt ein Ticket zu schreiben und zu warten.
- Portal: eine Oberfläche, die Services, Ownership, Dokumentation und Templates an einer Stelle sichtbar macht.
Das CNCF-Whitepaper begründet den Ansatz mit reduzierter kognitiver Last: Entwicklungsteams sollen sich mit ihrem Produkt beschäftigen, nicht mit der zwanzigsten Variante von Pipeline, Netzwerkfreigabe und Deployment. Damit das trägt, wird die Plattform selbst wie ein Produkt geführt, mit einem verantwortlichen Team, einer Roadmap und den Entwicklungsteams als Kunden, die man halten muss.
Wichtig ist die Reihenfolge dieser Aufzählung. Das Portal ist der sichtbarste Baustein, aber der letzte. Tragfähig wird eine IDP durch die Golden Paths und den Self-Service darunter, und die wiederum setzen eine belastbare Grundlage voraus: eine Landing Zone und Infrastruktur, die als Code vorliegt.
Woran Sie erkennen, dass sich eine IDP lohnt
Eine IDP ist eine Investition in ein internes Produkt, mit eigenem Team und laufender Pflege. Das CNCF-Reifegradmodell für Platform Engineering sagt dazu klar: Jede weitere Ausbaustufe kostet zusätzliches Geld und zusätzliche Zeit, und die höchste Stufe ist kein Ziel an sich. Die Frage ist also nicht, ob eine IDP grundsätzlich gut ist, sondern ob Ihre Situation den Aufwand rechtfertigt. Drei Signale sind belastbar.
Die Anzahl der Teams. Solange eine Handvoll Teams direkt miteinander spricht, lassen sich Konventionen in Absprachen und gemeinsamen Modulen halten. Je mehr Teams parallel liefern, desto öfter wird dieselbe Grundlage mehrfach gebaut und desto teurer wird jede Abweichung. Gemeinsam genutzte Wege können Aufwand über mehrere Teams verteilen. Mit zusätzlichen Nutzern können aber auch Support, Betriebsaufwand und Weiterentwicklung wachsen.
Ticket-Ops-Schmerz. Wenn neue Umgebungen, Zugänge oder Deployments regelmäßig über Tickets an ein zentrales Team laufen und dort liegen bleiben, ist der Betrieb zum Engpass geworden. Wartezeit auf Routineaufgaben ist das deutlichste Signal, dass Self-Service fehlt.
Wildwuchs. Jedes Team hat eine eigene Pipeline, ein eigenes Deployment-Muster und eine eigene Interpretation der Sicherheitsvorgaben. Onboarding dauert Wochen, weil nichts zweimal gleich aussieht, und Audits werden zur Archäologie. Golden Paths machen den erwünschten Weg zum bequemsten und räumen damit auf, ohne zu verbieten.
Eine Internal Developer Platform lohnt sich, wenn wiederkehrende Tickets und uneinheitliche Eigenbauten sichtbar mehr kosten als ein Plattformteam. Fehlen diese Signale, ist ein Portal eine Lösung auf der Suche nach einem Problem.
Was eine IDP nicht löst
Eine Plattform verstärkt den Zustand, den sie vorfindet. Ist die Cloud-Grundlage instabil oder liegt Infrastruktur nur teilweise als Code vor, automatisiert die IDP das Chaos lediglich schneller. Auch unklare Verantwortlichkeiten verschwinden nicht: Wer einen Service betreibt, wer für Kosten geradesteht und wer Vorgaben durchsetzt, muss vorher geklärt sein.
Die zweite Grenze ist die Nutzung. Das CNCF-Reifegradmodell unterscheidet eine durch Vorgaben angestoßene Nutzung von einer Nutzung aus eigenem Antrieb. Für nachhaltige Akzeptanz müssen Golden Paths den Alltag erleichtern; veraltete Templates und ungepflegte Dokumentation wirken dem entgegen.
Der minimale Start: Templates und Doku vor dem Portal
Der häufigste Fehler ist, mit der Portal-Beschaffung zu beginnen. Ein tragfähiger Einstieg braucht kein neues Produkt, sondern zwei Artefakte, die in jeder Git-Umgebung funktionieren:
- Ein oder zwei Templates für den häufigsten Anwendungsfall, etwa einen neuen Service mit Pipeline, Deployment und Basiskonfiguration. Gemeinsame Terraform-Module sind dafür oft der erste Golden Path, den ein Unternehmen ohnehin schon halb besitzt.
- Dokumentation, die den Weg von null auf laufenden Service beschreibt und von einem unbeteiligten Team nachvollzogen werden kann.
Werden diese Wege freiwillig genutzt und kommen Nachfragen nach dem nächsten Template, gibt es ein Plattform-Produkt, das ein Portal sinnvoll sichtbar machen kann. Bleibt die Nutzung aus, hat der Test wenig gekostet und viel gezeigt.
Dieses Vorgehen deckt sich mit dem CNCF-Reifegradmodell, das die unteren Stufen ausdrücklich als taktische Lösungen beschreibt: erst der punktuelle Nutzen, dann die Strategie. Wer den Weg umgekehrt geht und mit einer Portal-Ausschreibung startet, kauft eine Oberfläche für Inhalte, die es noch nicht gibt.
Backstage als Beispiel
Das bekannteste Open-Source-Werkzeug in diesem Feld ist Backstage, ein Framework für den Bau von Developer Portals. Es bringt einen Software-Katalog für Services und ihre Ownership mit, dazu Software Templates für neue Projekte, TechDocs für Dokumentation nach dem Docs-like-Code-Prinzip und ein Plugin-System für die Anbindung vorhandener Werkzeuge.
Backstage ist allerdings ein Framework, kein fertiges Produkt: Aufbau, Betrieb, Updates und Plugin-Pflege bleiben beim Plattformteam und erfordern eigene Entwicklungskapazität. Das ist kein Argument dagegen, aber ein Posten in der Rechnung. Wer die Signale aus den Abschnitten oben nicht wiedererkennt, fährt mit Templates und Dokumentation ohne Portal zunächst besser.
Was Sie danach entscheiden können
- Ob die drei Signale (viele parallel liefernde Teams, Ticket-Wartezeiten, Wildwuchs) in Ihrem Haus vorliegen oder nicht.
- Womit Sie starten: Templates und Dokumentation zuerst, das Portal erst nach nachgewiesener Nutzung.
- Woran Sie nach dem Start messen, ob die Golden Paths freiwillig genutzt werden.
Häufige Fragen
Ist Backstage die einzige Option?
Nein. Backstage ist das bekannteste Open-Source-Framework, daneben gibt es kommerzielle Portale. Wichtiger als das Produkt ist, dass Templates und Self-Service darunter existieren, bevor eine Oberfläche darüber entsteht.
Brauchen wir ein eigenes Plattformteam?
Für den minimalen Start nicht. Templates und Dokumentation kann ein bestehendes Team pflegen. Ein eigenes Team braucht die Plattform, sobald mehrere Teams von ihr abhängen und sie wie ein Produkt geführt werden muss.
Wie messen wir, ob die Plattform angenommen wird?
An der Nutzung: wie viele neue Services über ein Template entstehen, wie oft der Self-Service statt eines Tickets genutzt wird und ob Nachfragen nach weiteren Templates kommen. Verpflichtende Nutzung allein belegt den Nutzen noch nicht. Dazu gehören Rückmeldungen der Teams, kürzere Wartezeiten und weniger manuelle Umwege.
Quellen
- CNCF Platforms White Paper CNCF TAG App Delivery
- Platform Engineering Maturity Model CNCF TAG App Delivery
- What is Backstage? Backstage-Dokumentation
- What is platform engineering? platformengineering.org