Platform Engineering und Internal Developer Platforms

Das Problem, das Plattformen lösen

Im Jahr 2006 fasste Werner Vogels, Chief Technology Officer von Amazon, das Betriebsmodell seines Unternehmens als you build it, you run it zusammen: Das Team, das einen Service schreibt, deployt, überwacht und repariert ihn auch. Die Idee wurde zentral für DevOps und für Microservices, und sie funktioniert: Teams, die ihre eigene Software betreiben, spüren die Folgen ihrer Designentscheidungen und beheben sie. Doch das in diesem Kapitel beschriebene cloud-native Werkzeugset ist groß. Ein Produktteam, das heute einen Service bauen, betreiben und absichern muss, muss womöglich Container-Images, Kubernetes-Objekte, Infrastructure as Code, Pipelines, Observability, Secrets-Management, Netzwerkrichtlinien, Scans der Software-Lieferkette und Kostenkontrollen verstehen, bevor es eine Zeile Geschäftslogik schreibt.

Wenn jedes Team all das allein löst, passieren drei Dinge. Aufwand fällt mehrfach an, denn zehn Teams schreiben zehn leicht unterschiedliche Pipelines. Die Qualität schwankt, denn manche Teams verschlüsseln ihre Datenbanken und konfigurieren Backups, andere vergessen es. Und die Zeit, die Produktteams mit Infrastruktur verbringen, fehlt für das Produkt. Platform Engineering ist die Antwort darauf: Ein eigenes Team baut eine Internal Developer Platform (IDP), die diese Fähigkeiten so bündelt, dass Produktteams sie per Self-Service nutzen können.

Evan Bottchers Artikel von 2018 auf martinfowler.com liefert eine viel zitierte Beschreibung: Eine digitale Plattform ist ein Fundament aus Self-Service-APIs, Werkzeugen, Diensten, Wissen und Unterstützung, gestaltet als überzeugendes internes Produkt. Jeder Teil dieser Beschreibung zählt. Self-Service heißt: keine Tickets für Routinebedarf. Wissen und Unterstützung heißt: Dokumentation und Menschen, nicht nur Software. Überzeugend heißt: Teams nutzen sie aus freien Stücken, weil sie besser ist, als die Arbeit selbst zu erledigen. Internes Produkt heißt: Sie wird wie ein Produkt mit Kunden geführt, nicht wie ein Projekt oder eine Kostenstelle.

Eine IDP ist kein einzelnes Produkt. Meist ist sie eine Integration vorhandener Werkzeuge (ein CI-System, ein GitOps-Controller, die Managed Services eines Cloud-Anbieters, ein Observability-Stack, ein Secret Store) hinter einheitlichen Schnittstellen und sinnvollen Standardwerten. Die eigentliche Arbeit des Plattformteams besteht darin, sie auszuwählen, zu integrieren, zu dokumentieren und zu unterstützen und die Erfahrung ihrer Nutzung zu gestalten, nicht darin, einen neuen Orchestrator zu schreiben.

Golden Paths und Paved Roads

Das Wertvollste, was eine junge Plattform bieten kann, ist ein Golden Path: ein unterstützter und dokumentierter Weg mit klaren Vorgaben, eine häufige Aufgabe durchgängig zu erledigen, etwa einen neuen Service zu erstellen und in Produktion zu bringen. Spotify machte den Begriff bekannt (sein Engineering-Blog beschrieb 2020 seine Golden Paths); Netflix spricht von der Paved Road. Die Metapher ist präzise. Eine befestigte Straße ist der einfachste Weg und wird instand gehalten, aber Sie dürfen trotzdem ins Gelände abbiegen, wenn Sie einen guten Grund haben; Sie bekommen dann nur nicht die Unterstützung der Straße.

Ein guter Golden Path hat fünf Eigenschaften. Er ist durchgängig: Er führt ein Team von einem leeren Repository bis zu einem überwachten Service in Produktion, nicht nur durch einen Schritt. Er hat klare Vorgaben: Er trifft die üblichen Entscheidungen (Sprachversionen, Log-Format, Deployment-Strategie, Datenbank-Standardwerte), damit Teams es nicht tun müssen. Er ist optional: Teams mit ungewöhnlichen Anforderungen können ihn verlassen, was das Plattformteam zwingt, ehrlich zu prüfen, ob der Weg tatsächlich besser ist. Er ist unterstützt: Wenn er nicht funktioniert, repariert ihn das Plattformteam. Und er entwickelt sich weiter: Services, die aus der Vorlage des Vorjahres entstanden sind, erhalten Updates, statt auf ihrer Ausgangsversion stehen zu bleiben.

Backstage und Entwicklerportale

Ein Entwicklerportal ist die Eingangstür vieler Plattformen. Das bekannteste ist Backstage, entwickelt bei Spotify, im März 2020 als Open Source veröffentlicht, im September 2020 von der Cloud Native Computing Foundation (CNCF) als Sandbox-Projekt aufgenommen und im März 2022 in den Incubation-Status befördert. Seine Kernfunktionen sind ein Softwarekatalog, in dem jeder Service, jede Website, Bibliothek, API und Ressource mit Owner und Beziehungen registriert ist; Software-Templates, die neue Projekte aus Golden-Path-Vorlagen erzeugen; TechDocs, das als Markdown neben dem Code geschriebene Dokumentation veröffentlicht; und ein großes Ökosystem von Plug-ins, die Pipelines, Kubernetes-Status, Kosten und Incidents neben jedem Katalogeintrag anzeigen.

Jede Komponente beschreibt sich selbst in einer kleinen Datei in ihrem eigenen Repository, sodass die Angaben zur Zuständigkeit beim Code liegen und wie Code reviewt werden:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: restaurant-ratings
  description: Stores and serves customer ratings of restaurants
  tags: [python, http]
spec:
  type: service
  lifecycle: production
  owner: team-restaurants
  system: restaurant-discovery
  providesApis: [ratings-api]
  dependsOn: [resource:ratings-db]

Zwei Vorbehalte. Backstage ist ein Framework, das eine Organisation selbst zusammenbaut und betreibt, wofür meist Engineers mit TypeScript- und React-Kenntnissen nötig sind, und die Qualität seiner Plug-ins schwankt; für Teams, die es nicht selbst betreiben wollen, gibt es gemanagte Backstage-Dienste und kommerzielle Portale. Wichtiger noch: Ein Portal ist keine Plattform. Ein schönes Portal vor manuellen, ticketgetriebenen Prozessen zeigt die Warteschlange bloß hübscher an. Beginnen Sie mit den Fähigkeiten und dem Golden Path; ergänzen Sie ein Portal, wenn dahinter genug steckt, dass es sich lohnt, es zu finden.

Die Plattform als Produkt

Der wichtigste Gedanke im Platform Engineering ist, dass die Plattform ein Produkt ist und die Entwicklungsteams, die sie nutzen, ihre Kunden sind. Das bedeutet: einen Produktmanager oder eine Plattformleitung, die die Roadmap verantwortet; Nutzerforschung (Interviews, einem Team beim Erstellen eines Service zusehen, Umfragen) vor dem Bauen; Dokumentation und Onboarding, die als Features behandelt werden; veröffentlichte Service Level Objectives für die Plattform selbst; Versionierungs- und Abkündigungsrichtlinien, damit Teams planen können; und vor allem eine Akzeptanz, die verdient statt verordnet wird. Wenn Teams die Plattform meiden, ist das Marktfeedback, keine Befehlsverweigerung.

Team Topologies (Matthew Skelton und Manuel Pais, 2019), behandelt in Abschnitt 11.5, liefert das Organisationsmodell. Ein Plattformteam ist dazu da, die Last der Stream-aligned Teams zu verringern, also der Teams, die an einem Strom fachlicher Änderungen wie Bestellungen oder Kurierdisposition ausgerichtet sind, und arbeitet mit ihnen vor allem im Modus X-as-a-Service zusammen: ein klares Self-Service-Angebot mit wenig Abstimmungsbedarf. Der Collaboration-Modus wird bewusst und nur kurz eingesetzt, etwa beim Entwurf einer neuen Fähigkeit mit ein oder zwei Pionierteams. Skelton und Pais prägten auch den Begriff Thinnest Viable Platform: die kleinste Plattform, die wirklich hilft, was für eine kleine Organisation eine gut geschriebene Wiki-Seite mit freigegebenen Diensten und eine gemeinsame Pipeline-Vorlage sein kann.

Das bedeutet auch, dass die Plattform das Gesetz von Conway zu ihren Gunsten nutzen muss: Die Schnittstellen der Plattform werden zu den Grenzen zwischen dem Plattformteam und jedem Produktteam, deshalb sollten sie stabil, dokumentiert und schmal sein wie jede gute Abstraktion.

Self-Service mit Guardrails

Self-Service beseitigt die Warteschlange; Guardrails halten ihn sicher. Der Unterschied zu herkömmlichen Kontrollen liegt darin, wo die Prüfung stattfindet. Ein Gate ist eine Person, die eine Anfrage genehmigen muss, etwa ein Change Advisory Board oder ein Datenbankadministrator, der ein Ticket prüft. Ein Guardrail ist eine automatische Grenze, die alles durchlässt, was den Richtlinien entspricht, und alles andere im Moment der Anfrage blockiert oder markiert. Guardrails werden meist als Policy as Code geschrieben (eingeführt in Abschnitt 10.4) und in Pipelines, Admission Controllern und Richtlinien der Cloud-Organisation durchgesetzt.

Gute Guardrails haben drei Eigenschaften gemeinsam: Sie geben eine klare Meldung, die erklärt, was blockiert wurde und wie es sich beheben lässt; sie werden wie Code versioniert und getestet, mit einer Phase von Warnungen, bevor eine neue Regel zu blockieren beginnt; und sie haben einen dokumentierten Weg für begründete Ausnahmen, denn ein Guardrail ohne Ausnahmeweg wird beim ersten Irrtum wieder zum Gate.

Kognitive Last reduzieren, nicht alles verbergen

Team Topologies übernimmt den Begriff der kognitiven Last aus John Swellers pädagogischer Forschung und unterscheidet drei Arten. Intrinsische Last steckt in der Aufgabe selbst, etwa zu verstehen, wie Liefergebühren funktionieren. Extrinsische Last kommt aus der Umgebung, etwa sich die zwölf Schritte zu merken, mit denen man eine Datenbank beantragt. Lernbezogene Last ist die Anstrengung des Lernens, die künftige Arbeit erleichtert, etwa die Domäne tiefer zu verstehen. Eine Plattform sollte die extrinsische Last beseitigen, damit Teams ihre begrenzte Aufmerksamkeit auf die intrinsische und lernbezogene Last in ihrer eigenen Domäne richten können.

Das heißt nicht, alles zu verbergen. Ein Team, das seinen Service betreibt, muss immer noch verstehen, wie er sich in Produktion verhält: seinen Ressourcenverbrauch, seine Fehlermodi, seine Latenz und seine Kosten. Abstraktionen, die zu viel verbergen, werden im ungünstigsten Moment undicht, nämlich während eines Incidents, wenn das Team feststellt, dass es die Logs nicht sehen kann oder nicht weiß, auf welcher Datenbankstufe es läuft. Gute Plattformen sind transparent: Sie bieten sinnvolle Standardwerte und einfache Schnittstellen und lassen Teams dennoch unter die Haube schauen und Einstellungen überschreiben, wenn sie es brauchen.

Messen, ob die Plattform funktioniert

Der Wert einer Plattform zeigt sich in den Ergebnissen anderer Teams, also müssen ihre Messgrößen dort ansetzen. Nützliche Messgrößen fallen in vier Gruppen, und ein ausgewogenes Set nimmt aus jeder mindestens eine.

Das SPACE-Framework, 2021 in ACM Queue von Nicole Forsgren, Margaret-Anne Storey und Kollegen von GitHub, Microsoft Research und der University of Victoria veröffentlicht, warnt, dass sich Entwicklerproduktivität nicht mit einer einzigen Zahl erfassen lässt. Es nennt fünf Dimensionen: Zufriedenheit und Wohlbefinden (Satisfaction and well-being), Leistung (Performance), Aktivität (Activity), Kommunikation und Zusammenarbeit (Communication and collaboration) sowie Effizienz und Flow (Efficiency and flow). Es empfiehlt, mehrere Dimensionen gleichzeitig zu messen, darunter mindestens eine Wahrnehmungsgröße wie eine Umfrage, und Einzelpersonen nie nach Aktivitätszählungen wie Commits oder Codezeilen zu beurteilen.

Die Belege zu Plattformen sind ermutigend, aber nicht bedingungslos. Der DORA-Bericht Accelerate State of DevOps 2024 ergab, dass Nutzer von Internal Developer Platforms eine um etwa 8 % höhere individuelle Produktivität und eine um 10 % höhere Teamleistung angaben, der Durchsatz der Softwareauslieferung und die Stabilität von Änderungen aber um 8 % bzw. 14 % niedriger lagen. Der Bericht bietet mögliche Erklärungen an, etwa zusätzliche Übergaben und zusätzliche Schritte durch die Plattformschicht selbst, und die Lehre für Architekten lautet, neben der Zufriedenheit auch die Auslieferungsergebnisse zu messen und mit einem Einbruch zu rechnen, solange eine Plattform reift.

Risiken und Fehlermuster

Plattforminitiativen scheitern auf erkennbare Weise. Am häufigsten ist eine Plattform, die niemand will: Ein Team verbringt ein Jahr damit, eine ehrgeizige Allzweckplattform zu bauen, bringt sie heraus und stellt fest, dass die Produktteams bereits brauchbare Lösungen haben und keine Zeit für eine Migration. Schlank anzufangen, mit echten Nutzern und einem Golden Path, ist das Gegenmittel. Das zweite ist das umbenannte Betriebsteam: Ein Infrastrukturteam wird in Plattformteam umbenannt, arbeitet aber weiter aus einer Ticket-Warteschlange, sodass sich nichts ändert außer den Stellenbezeichnungen. Wenn Routineanfragen noch ein Ticket und eine Person brauchen, ist es noch keine Plattform.

Weitere Risiken sind eine verordnete Nutzung, die das Feedback beseitigt, das eine Plattform nützlich hält; Überabstraktion, bei der eine selbst gebaute Schicht die zugrunde liegenden Werkzeuge so vollständig verbirgt, dass Teams sie weder debuggen noch erweitern können und das Plattformteam zum Engpass für jede Änderung wird; die Vernachlässigung des Long Tail der Services, die aus alten Vorlagen entstanden sind; und eine Plattform, die zum Single Point of Failure wird, dessen Ausfall jedes Deployment stoppt. Umgekehrt braucht eine kleine Organisation vielleicht gar kein Plattformteam: Ein paar gemeinsame Vorlagen, die Freiwillige pflegen, können jahrelang die Thinnest Viable Platform sein.