Internal Developer Platform: Bau den Motor, nicht das Dashboard

Ein Softwareentwickler wird eingestellt, um ein Produkt zu bauen. In vielen Firmen verbringt er einen erheblichen Teil der Woche damit, es nicht zu bauen. Die Zeit geht für alles drumherum drauf: herausfinden, wie man einen neuen Dienst überhaupt zum Laufen bringt, welche Konfigurationsdateien zu ändern sind, welches Dashboard zeigt, ob das nächtliche Release wirklich durchgelaufen ist, und wen man fragt, wenn es das nicht getan hat. Nichts davon liefert ein Feature aus – und genau das ist das Problem, das eine Internal Developer Platform lösen soll.

Der Begriff klingt schwerer als die Idee dahinter. Eine Internal Developer Platform ist nichts weiter als ein Satz von Self-Service-Werkzeugen, die eine Firma für ihre eigenen Entwickler baut – damit sie vom geschriebenen Code zum laufenden Dienst kommen, ohne ein Ticket aufzumachen und tagelang darauf zu warten, dass ein anderes Team das einrichtet. Die Tätigkeit, diesen Werkzeugkasten zu bauen und zu betreiben, hat einen eigenen Namen: Platform Engineering. Der klarste Zugang zum ganzen Thema ist, diese beiden Dinge auseinanderzuhalten: Platform Engineering ist die Arbeit, die Plattform ist das, was die Arbeit hervorbringt. Ein Team, das ein Werkzeug kauft und dabei stehen bleibt, hat die Arbeit übersprungen.

Diese Unterscheidung ist die haltbare Idee, denn sie überlebt jede Mode im Werkzeugkasten. Die Plattform ist ein internes Produkt, dessen Nutzer die eigenen Entwickler sind – mit eigener Roadmap und eigenem Backlog, also einer eigenen Liste offener Aufgaben. Sie ist nie ein einmaliges Projekt, das man fertigstellt und dann liegen lässt. Genau dort, wo man sie für so eines hält, wird das meiste Geld verbrannt.

Das Dutzend Werkzeuge in einem Kopf

Um zu sehen, wogegen die Plattform ankämpft, lohnt ein Blick darauf, was ein einzelner Produktentwickler im Kopf tragen soll. Zusätzlich zu dem Feature, für das er eingestellt wurde, soll er wissen, wie der Code verpackt wird, wie er ausgeliefert wird, wo Passwörter und Schlüssel liegen, welchem von drei Monitoring-Dashboards er trauen kann und was um zwei Uhr nachts zu tun ist, wenn ein Alarm losgeht. Jedes davon ist ein eigenes Werkzeug mit eigenen Eigenheiten. Jedes einzelne ist ein Umweg, der keine Zeile Produktcode hervorbringt.

Diese Last ist der eigentliche Preis, und er ist nicht klein. Erhebungen dazu, wofür Entwickler ihre Zeit verbrauchen, landen immer wieder im selben unbequemen Bereich: Irgendwo zwischen einem Fünftel und zwei Fünfteln der Arbeitswoche verschwinden in Reibung, die nichts mit dem Produkt zu tun hat. Eine Plattform rechtfertigt ihr Budget, indem sie diese Zeit zurückgibt. Sie macht Entwickler nicht klüger; sie nimmt ihnen die Steuer ab, die sie für das Privileg zahlen, etwas ausliefern zu dürfen.

Das Dashboard ist der leichte Teil

Hier geht der Großteil der Plattform-Projekte still und leise schief. Das sichtbare Stück einer Plattform ist ein Portal: eine einzige Webseite, auf der ein Entwickler klickt, um einen neuen Dienst aufzusetzen, einen bestehenden zu finden oder dessen Zustand zu prüfen.

Das bekannteste Beispiel ist Backstage, das Portal, das Spotify intern gebaut und dann an die Open-Source-Gemeinschaft übergeben hat – seither der Standard-Startpunkt für Tausende Firmen. Ein Portal ist wirklich nützlich, und es ist zugleich der leichte Teil der Aufgabe, grob das sichtbare Fünftel.

Das Portal ist nur eine Eingangstür. Der eigentliche Wert ist der Motor dahinter – die Maschinerie, die aus der Anfrage eines Entwicklers echte Infrastruktur macht: eine Datenbank, eine Warteschlange, einen Ort zum Ausführen des Codes, alles korrekt für jede Umgebung verdrahtet, ohne dass jemand die Schritte von Hand ausführt. Dieser Motor ist der Großteil der Arbeit und fast kein bisschen Ruhm – genau deshalb überspringen Teams ihn. Sie kaufen eine schicke Eingangstür, schrauben sie an nichts und landen bei einem Katalog, der jeden Dienst auflistet und Entwicklern erlaubt, nichts weiter zu tun, als über sie zu lesen. Eine Eingangstür, die sich auf eine Wand öffnet, ist schlimmer als gar keine Tür, weil sie fertig aussieht.

Golden Paths: die eine Idee, die zu klauen lohnt

Die mit Abstand beste Idee aus dem Platform Engineering hat einen schlichten Namen: der Golden Path, die geebnete und voll unterstützte Route von der Idee zum laufenden Dienst. Stell dir eine Vorlage vor, in der Logging, Monitoring, Sicherheitsprüfungen und eine Auslieferungs-Pipeline bereits verdrahtet sind, sodass ein Entwickler, der sie nimmt, in Minuten statt in Tagen von null zum laufenden Dienst kommt. Spotify, das den Begriff geprägt hat, beschrieb ihn als die Route, die so gut unterstützt ist, dass sie zu nehmen schlicht der Weg des geringsten Widerstands ist.

Der Haken ist ein Abwägen zwischen Standardisierung und Freiheit. Die geebnete Straße ist gerade deshalb schnell, weil sie schmal ist: Sie unterstützt eine Hauptsprache, ein Datenbankmuster, einen Weg zur Auslieferung – und wer sie verlässt, den trägt die Plattform nicht mehr. Ebnest du zu wenige Straßen, lassen deine besten Entwickler die Plattform hinter sich; versuchst du, jede Straße zu ebnen, baust du etwas, das alles schlecht unterstützt und nichts gut ausliefert. Die Disziplin besteht darin, die zwei oder drei Routen zu ebnen, die den Großteil der Arbeit abdecken, und zum langen Rest laut Nein zu sagen.

Die Straße funktioniert nur, wenn sie wirklich die schnellste ist. In dem Moment, in dem sie zwar vorgeschrieben, aber langsamer als der Umweg ist, fahren die Entwickler darum herum – und das Plattform-Team verbringt seine Quartale damit, die Einhaltung zu überwachen, statt die Straße zu verbessern. Jede Voreinstellung, die in diesen Weg eingebacken ist, bis hinunter zu etwas so Grundlegendem wie der Frage, wie Container (die übliche Art, Software so zu verpacken, dass sie überall gleich läuft) gebaut und betrieben werden, wird zur Entscheidung, die jedes Team erbt. Selbst diese eine Entscheidung ist schwerer beladen, als sie aussieht, wie unser Vergleich von Docker und Podman für Teams, die ausliefern, zeigt.

Wann sich der Bau wirklich lohnt

Nichts davon ist umsonst, und das wirft die einzige Frage auf, die man vor dem Start stellen sollte: Ist die Firma groß genug, dass die Plattform sich selbst trägt? Eine Zahl, die viel zitiert wird, liegt bei rund fünfzig Entwicklern, aber sie ist ein Platzhalter für etwas Echtes, keine harte Grenze. Der eigentliche Auslöser ist der Moment, in dem mehrere Teams aufhören, denselben Kontext zu teilen, und jedes anfängt, dieselbe Maschinerie neu zu erfinden. Darunter hat ein kleines Team meist genug geteiltes Wissen, dass eine Handvoll gut gepflegter Skripte und eine ordentliche README den Job erledigen – und eine Plattform zu bauen, besteuert nur dieselbe kleine Gruppe, die sie eigentlich entlasten sollte.

Es gibt einen ehrlichen Haken, den die Leute, die das durchgezogen haben, immer wieder melden: Eine neue Plattform bremst Teams tendenziell aus, bevor sie diese beschleunigt. Die Plattform ist selbst etwas, das Entwickler erst lernen müssen, bevor sie sich auszahlt – die Produktivitätskurve sackt also ab, bevor sie steigt. Diesen Einbruch wegzureden, ist der Weg, auf dem Plattform-Teams ihre Glaubwürdigkeit schon im ersten Quartal verbrennen; ihn vorab beim Namen zu nennen, ist der Weg, bis zu dem Punkt zu überleben, an dem es funktioniert.

Wie „funktioniert” aussieht, hat einen anerkannten Maßstab. Die Branche misst die Auslieferung von Software mit einem Satz von Kennzahlen namens DORA, der auf einer einfachen Spannung sitzt: wie schnell ein Team ausliefert gegen wie sicher es ausliefert. Eine Plattform verdient ihr Geld, indem sie die Auslieferung schneller macht, ohne sie zerbrechlicher zu machen – aus zwei Wochen Wartezeit auf einen neuen Dienst wird ein selbst bedienter Klick am selben Tag. Genau diese eine Veränderung, von Wochen auf Stunden, ist meist das, was eine Plattform überhaupt erst finanziert bekommt.

Wo diese Projekte sterben gehen

Die zwei häufigen Arten, wie eine Plattform stirbt, sind früh sichtbar, wenn man die Form kennt.

Die erste ist die Eingangstür, die sich auf nichts öffnet: ein Portal, das jeden Dienst katalogisiert und keine echte Aktion auslöst, sodass der Katalog binnen weniger Monate veraltet, weil niemand einen Grund hat, ihn aktuell zu halten. Die zweite ist das Überbauen, bevor es irgendjemand braucht – Abstraktionsschichten stapeln für ein Team, das zweimal die Woche eine App an einen Ort ausliefert. Die Plattform wird zu ihrem eigenen Produkt, abgekoppelt von dem, wonach Entwickler tatsächlich gefragt haben, und fügt jeder Änderung Verzögerung hinzu, während sie Schmerzen beseitigt, die niemand gespürt hat.

Das verräterische Zeichen ist in beiden Fällen dasselbe, und es ist einfach: keine Messung, ob die Plattform überhaupt genutzt wird. Ein Team, das nicht sagen kann, welcher Anteil der Deployments über den Golden Path läuft oder wie viele Dienste im letzten Monat aus einer Vorlage entstanden sind, fliegt blind. Behandle die Plattform als Produkt und miss, ob sie überhaupt jemand nutzt – sonst merkst du erst, dass sie tot ist, wenn der Katalog ein Jahr veraltet ist.

Der KI-Teil, ehrlich gehalten

Der neueste Zusatz im Verkaufsgespräch ist KI, und die geerdete Version ist schmaler als die der Keynote. Was heute funktioniert, ist, KI für die mühseligsten Momente einzusetzen: das Gerüst eines neuen Dienstes erzeugen, Standard-Konfiguration ausfüllen, in normaler Sprache statt mit einer Wiki-Suche beantworten, „wo ist das Ding, das X macht”. Was noch weitgehend eine Demo ist, ist die Plattform, die sich ohne menschliches Zutun selbst bereitstellt und repariert. KI verkürzt die Auffahrt auf die geebnete Straße; sie fährt das Auto noch nicht. Wer dir heute das Zweite verkauft, verkauft die Folie, nicht das Produkt.

Häufig gestellte Fragen

Worin unterscheidet sich Platform Engineering von DevOps?

DevOps ist eine Kultur: die Idee, dass die Leute, die Software bauen, und die Leute, die sie betreiben, nicht durch eine Mauer getrennt sein sollten. Platform Engineering ist ein konkreter Weg, diese Idee in großem Maßstab umzusetzen. Statt dass jedes Team seinen eigenen Betrieb fährt, baut eine eigene Gruppe ein internes Produkt, mit dem sich alle Teams selbst helfen. DevOps sagt, Entwicklung und Betrieb sollten nicht in getrennten Silos sitzen; Platform Engineering ist das Personal- und Werkzeugmodell, das das wahr macht, sobald eine Firma zu groß ist, als dass geteilte Gewohnheiten allein sie noch zusammenhalten.

Brauche ich Kubernetes, um eine zu bauen?

Nein, auch wenn viele der beliebten Werkzeuge es voraussetzen. Kubernetes ist das inzwischen übliche System, um Software in Containern über viele Maschinen hinweg zu betreiben, und es ist mächtig und kompliziert. Du kannst eine völlig brauchbare interne Plattform auf einfacheren Fundamenten bauen, mit einem Portal und Vorlagen davor. Wenn du Kubernetes nicht ohnehin schon betreibst, ist es einzuführen, nur um eine Plattform zu bekommen, selbst schon der Fehler des Überbauens. Passe die Plattform an die Maschinerie an, die du bereits betreibst, nicht an die aus dem Konferenzvortrag.

Ist Backstage kostenlos, und was kostet es wirklich?

Die Software ist Open Source und kostenlos herunterzuladen. Der Preis ist betrieblicher Art: Backstage ist eine Anwendung, die dein Team selbst betreiben, gepatcht halten und erweitern muss – das bedeutet dauerhaft mindestens einen Bruchteil der Zeit eines Entwicklers. Kommerzielle Alternativen verlangen ein Abonnement dafür, dass du diese Anwendung nicht selbst betreiben musst. Die Wahl läuft auf eine vertraute Frage hinaus: Hast du Leute, die eine Codebasis langfristig besitzen und pflegen können, oder zahlst du lieber jemand anderen dafür?

Warum reicht eine normale Deployment-Pipeline nicht?

Eine Deployment-Pipeline führt ein festes Rezept aus, um Code zu bauen, zu testen und auszuliefern. Der Motor in einer Plattform sitzt eine Stufe darüber: Er nimmt die Anfrage eines Entwicklers („dieser Dienst braucht eine Datenbank und eine Warteschlange”) und arbeitet die konkreten Ressourcen für jede Umgebung aus, bevor er an die Pipeline übergibt. Die Pipeline führt ein bekanntes Rezept aus; der Motor entscheidet, was das Rezept dieses Mal enthalten soll. Genau dieser Entscheidungsschritt macht aus einem Klick im Portal echte, korrekt verdrahtete Infrastruktur.

Ab welcher Teamgröße ergibt eine Plattform Sinn?

Die weithin zitierte Schwelle liegt bei rund fünfzig Entwicklern, aber der ehrliche Auslöser ist der Kommunikationsaufwand, nicht eine genaue Kopfzahl. Sobald du mehrere Teams hast, die keinen täglichen Kontext mehr teilen und jedes für sich dieselbe Einricht- und Auslieferungs-Maschinerie neu baut, beginnt es sich zu rechnen, eine Gruppe diesen Preis einmal für alle zahlen zu lassen. Darunter gewinnen meist gut gepflegte Skripte und Dokumentation, weil der Unterhalt der Plattform bei demselben kleinen Team landet, das sie eigentlich befreien sollte.

Bau die Schicht, die wehtut

Die Reihenfolge des Baus ist die ganze Entscheidung. Liegst du unter dem Punkt, an dem mehrere Teams dieselbe Einrichtarbeit immer wieder neu erfinden, dann baue keine Plattform: Schreib die Skripte, schreib die README und schau wieder hin, wenn du in das Problem hineingewachsen bist. Liegst du darüber, dann fang bei dem einen Arbeitsablauf an, der deine Entwickler dieses Quartal am meisten kostet – die zwei Wochen Wartezeit auf einen neuen Dienst oder das Deployment, das niemand ohne Hilfe ausführen kann – und baue nur den Motor, der ihn behebt. Ebne eine gute Straße, beweise, dass die Leute darauf fahren, und ebne die nächste erst, wenn die erste Last trägt. Die Plattform von der Konferenzfolie ist die, die zum Friedhof wird; die, die hält, ist die Schicht, die tatsächlich wehgetan hat.

---

Foto: cottonbro studio / Pexels