Platform Engineering ist die Disziplin, eine interne Plattform zu bauen und zu betreiben, die Entwicklungsteams selbst nutzen, ohne jedes Mal jemanden zu fragen. Die Cloud Native Computing Foundation (CNCF) beschreibt eine solche Plattform als eine abgestimmte Sammlung von Fähigkeiten, die ein eigenes Team wie ein Produkt pflegt [1]. Der Zweck ist schnell gesagt: Ein Entwicklungsteam soll sich mit seinem Produkt beschäftigen, nicht mit der zwanzigsten Variante von Auslieferung, Netzwerkfreigabe und Protokollierung.
Der Vergleich, der meistens trägt, ist der Verlag. Ein Verlag gibt seinen Autoren eine Vorlage, ein Lektorat und einen Druckprozess. Was im Buch steht, entscheiden die Autoren weiter selbst. Eine interne Plattform macht dasselbe für Software: Sie gibt den Weg vor, nicht das Produkt.
Diese Seite behandelt Platform Engineering als Vorgehen: was eine Plattform ist, wie sie sich von DevOps und Cloud Engineering unterscheidet und woran man merkt, ob sie hilft. Produktnamen kommen erst im vorletzten Abschnitt vor, und dort als Beispiel.
Warum Teams das überhaupt bauen
Der Auslöser ist fast immer derselbe. Ein Unternehmen hat nicht mehr zwei Entwicklungsteams, sondern zehn. Jedes hat sich seinen eigenen Weg in die Produktion gebaut, weil das zum jeweiligen Zeitpunkt der schnellste war.
Danach kostet jede Änderung zehnmal. Eine neue Prüfung vor dem Ausrollen, eine neue Protokollpflicht, ein Wechsel des Basis-Images: Das muss zehnmal erklärt, zehnmal eingebaut und zehnmal nachgehalten werden.
Wer es nicht einbaut, fällt erst beim nächsten Vorfall auf. Und dann lautet die Frage nicht mehr, ob die Auflage sinnvoll war, sondern warum niemand sagen kann, wo sie gilt.
Die CNCF nennt das Ziel Reduktion der kognitiven Last [1]. Praktisch heißt das: Der Weg in die Produktion wird einmal gebaut, dokumentiert und geprüft. Vorbereitete Wege können technische Vorgaben bereits enthalten. Anwendungsspezifische Anforderungen und Verantwortlichkeiten müssen die Teams weiterhin prüfen.
Platform Engineering, DevOps und Cloud Engineering
Die drei Begriffe werden oft vermischt. Sie beschreiben verschiedene Ebenen, und die Verwechslung ist der Grund, warum Diskussionen darüber im Kreis laufen.
DevOps ist eine Haltung: Wer baut, betreibt auch. Entwicklung und Betrieb sitzen nicht in getrennten Abteilungen mit einem Ticket dazwischen. DevOps sagt nichts darüber, wer die Werkzeuge dafür bereitstellt.
Cloud Engineering ist das Fundament unter der Plattform: Konten und Abonnements, Netzwerk, Identität, Richtlinien und die Frage, ob sich das alles wiederholen lässt. Es entscheidet, was überhaupt möglich ist.
Platform Engineering ist das Angebot, das auf diesem Fundament entsteht: Laufzeitumgebungen, Auslieferungswege, Vorlagen, ein Katalog. Es entscheidet, was ein Team ohne Rückfrage bekommen kann.
Eine Faustregel für die Abgrenzung: Cloud Engineering legt das Grundstück an und verlegt die Leitungen. Platform Engineering baut die Häuser, die man beziehen kann. DevOps ist die Regel, dass wer einzieht, auch putzt.
Woraus eine Plattform besteht
Drei Bausteine tauchen in fast jeder Umsetzung auf.
- Vorbereitete Wege (Golden Paths). Fertige Abläufe für wiederkehrende Aufgaben. Ein neues Dienst-Repository entsteht aus einer Vorlage und bringt Pipeline, Auslieferung und Grundkonfiguration mit.
- Selbstbedienung. Teams fordern Umgebungen, Datenbanken oder Berechtigungen über eine feste Schnittstelle an, statt ein Ticket zu schreiben und zu warten.
- Katalog oder Portal. Eine Stelle, an der sichtbar ist, welche Dienste existieren, wem sie gehören und wo ihre Dokumentation liegt.
Die Reihenfolge ist wichtig. Das Portal ist der sichtbarste Baustein und der letzte. Tragfähig wird eine Plattform durch die Wege darunter, und die setzen eine Infrastruktur voraus, die als Code vorliegt.
Woran man erkennt, dass es funktioniert
Eine Plattform ist kein Projekt mit Abnahme, sondern ein Produkt mit Nutzern. Also misst man sie wie ein Produkt.
DORA betrachtet aktuell fünf Kennzahlen: Auslieferungshäufigkeit, Zeit vom Commit bis zur Produktion, Wiederherstellungszeit nach fehlgeschlagenen Deployments, Änderungsfehlerrate und Anteil ungeplanter Deployments infolge von Produktionsstörungen [4].
Dazu kommen zwei Zahlen, die die Plattform direkt betreffen. Wie lange braucht ein neues Team bis zur ersten eigenen Auslieferung? Und wie viele Anfragen landen pro Woche beim Plattformteam? Steigt die zweite Zahl, lohnt sich ein Blick auf die Ursachen: zusätzliche Nutzer, neue Anforderungen oder Lücken in der Selbstbedienung.
Freiwillige Nutzung ist ein gutes Signal. Verbindliche Nutzung allein belegt den Nutzen noch nicht: Dazu gehören Rückmeldungen der Teams, kürzere Wartezeiten und weniger manuelle Umwege.
Wann es sich nicht lohnt
Das Reifegradmodell der CNCF sagt deutlich, dass jede weitere Ausbaustufe zusätzliches Geld und zusätzliche Zeit kostet und die höchste Stufe kein Ziel an sich ist [2].
Bei wenigen Teams können gemeinsame Vorlagen und eine gepflegte Anleitung genügen. Ob sich eine weitergehende Plattform lohnt, hängt von wiederkehrendem Aufwand, Wartezeiten und Betriebsanforderungen ab.
Ohne Fundament lohnt sie sich ebenfalls nicht. Wer Konten, Netz und Berechtigungen noch von Hand pflegt, baut ein Portal auf Sand: Es zeigt dann Dinge an, die es so nur einmal gibt.
Beispiel: wie so eine Plattform aussieht
Ein häufiger Zuschnitt, an konkreten Werkzeugen erklärt. Die Namen sind ein Beispiel, keine Empfehlung, und jedes davon ist austauschbar.
Als Laufzeitumgebung dient Kubernetes, ein System, das Anwendungen in Containern über mehrere Maschinen verteilt und am Laufen hält. Die Infrastruktur darunter liegt als Terraform-Code im Repository.
GitLab CI baut und prüft die Anwendung. Ein GitOps-Agent gleicht verwaltete Cluster-Ressourcen laufend mit dem versionierten Sollzustand ab. Bei diesem Modell, GitOps, wird die automatische Korrektur von Abweichungen gezielt eingerichtet.
Der vorbereitete Weg ist eine Vorlage. Ein Team legt daraus ein neues Repository an und bekommt Pipeline, Auslieferung, Protokollierung und Grundberechtigungen mit. Sichtbar wird das Ganze in einem Katalog, etwa Backstage.
Was an diesem Zuschnitt nicht austauschbar ist, ist die Frage darunter: Bekommt ein Team den Weg ohne Rückfrage, und ist dieser Weg der bequemste?
Platform Engineering ist keine Werkzeugentscheidung. Es ist die Entscheidung, den Weg in die Produktion einmal zu bauen und wie ein Produkt zu pflegen, statt ihn in jedem Team neu entstehen zu lassen.
Was Sie danach entscheiden können
- Ob Ihre Organisation eine Plattform braucht oder ob Vorlagen und eine gepflegte Anleitung reichen.
- Welche der drei Bausteine (Wege, Selbstbedienung, Katalog) zuerst entstehen sollte und welcher warten kann.
- Woran Sie in sechs Monaten messen, ob die Plattform ihren Zweck erfüllt.
Häufige Fragen
Ist Platform Engineering das Gegenteil von DevOps?
Nein. Es ist eine Antwort auf ein Problem, das DevOps erzeugt: Wenn jedes Team seinen Betrieb selbst macht, macht jedes Team ihn anders. Platform Engineering stellt die gemeinsamen Werkzeuge bereit, die Verantwortung bleibt beim Team.
Brauche ich dafür Kubernetes?
Nein. Kubernetes ist verbreitet, aber eine Plattform kann genauso auf verwalteten Diensten einer Cloud aufsetzen. Entscheidend ist, dass es einen vorbereiteten Weg gibt, nicht welche Laufzeitumgebung darunter liegt.
Ab wie vielen Teams lohnt sich das?
Eine feste Zahl gibt es nicht. Ein brauchbares Signal ist der Moment, in dem dieselbe Grundlage zum dritten Mal parallel entsteht, oder in dem Wartezeiten auf ein zentrales Team im Liefertakt sichtbar werden.
Was ist der Unterschied zwischen einer Plattform und einer Internal Developer Platform?
In der Praxis keiner. Internal Developer Platform (IDP) ist der gängige Name für genau diese interne Plattform. Wann sich der Aufbau lohnt, behandelt ein eigener Artikel.
Quellen
- CNCF Platforms White Paper CNCF TAG App Delivery
- Platform Engineering Maturity Model CNCF TAG App Delivery
- What is platform engineering? Microsoft Learn
- DORA's software delivery performance metrics DORA
- What I Talk About When I Talk About Platforms Evan Bottcher, martinfowler.com, 2018