Alles über Platform Engineering: Warum es nötig ist, wie man es aufbaut und wie Erfolg aussieht

• als organisatorische Disziplin zum Aufbau und Betrieb interner Produkte für interne Engineers als Nutzer grundlegend etwas anderes als bloßes DevOps-Rebranding oder das Management von Kubernetes-Clustern
• Laut dem DORA-Report 2025 haben 90 % der Organisationen mindestens eine interne Plattform eingeführt, und die Plattformqualität entwickelt sich zu einem Indikator, der direkt vorhersagt, ob AI-Tools Wert schaffen
• Da Cloud und Open Source unendlich viele Primitive bereitstellen, besteht der zentrale Daseinszweck darin, das Problem des „Over-General Swamp“ zu lösen, in dem jedes Team seine eigene Pipeline baut
• Plattformen wie echte Produkte zu behandeln und sie mit Software-Abstraktionen, Metadaten-Registern und operativen SLOs für den Median-Entwickler auszustatten, ist die strukturelle Voraussetzung für Erfolg
• Gute Plattformen funktionieren so natürlich, dass Entwickler ihre Existenz vergessen, und schlechte Plattformen verstärken mit AI-Tools nur das Chaos, während gute Plattformen den Durchsatz erhöhen

---

Warum Platform Engineering existiert

• Over-General Swamp

  • Weil Cloud und OSS unendlich viele Primitive wie Queues, Object Stores, Datenbanken, CI-Runner und Service Meshes bereitstellen, trifft jedes Application-Team andere Entscheidungen
  • Ein Jahr später sind alle Services zu einem „Sumpf aus Glue Code“ verkommen, in dem jeder seinen eigenen Deployment-Pipeline-Stack, Retry-Logik, Monitoring-Konventionen und subtil falsche IAM-Bindings hat
  • Zwei Ursachen schaffen diesen Sumpf: die Explosion der Wahlmöglichkeiten und höhere operative Erwartungen wie 24/7-Betrieb, Sicherheit, Compliance und Kostenmanagement
  • In realen Landing-Zone-Projekten gab es Fälle, in denen 20 Teams nahezu identische Terraform-Module für VPC, IAM und Budget-Alerts jeweils neu erfanden – jeweils mit anderen Bugs

• Vier Dinge, die Platform Engineering tatsächlich leistet

  • Die Primitive, die Entwickler sehen, werden eingeschränkt, damit sie nur auf kuratierte Weise verwendet werden
  • Wiederkehrende Plumbing-Arbeit wird in Shared Services absorbiert, um anwendungsspezifischen Glue Code zu reduzieren
  • Wenn sich zugrunde liegende Primitive ändern, behandelt das Plattformteam es nur einmal und zentralisiert damit die Migrationskosten
  • Entwickler werden dabei unterstützt, das von ihnen Gebaute selbst zu betreiben, ohne Linux-Kernel-Experten werden zu müssen
  • DevOps bedeutete „Entwickler sollen den Betrieb verantworten“, und Platform Engineering bedeutet: „Wir liefern gute Tools für diesen Betrieb als echtes Produkt“
  • Auch auf der DORA-2025-Capabilities-Seite wird es nicht als Tool-Kategorie, sondern als soziotechnische Disziplin definiert

Fünf Säulen (Pillars)

• Kuratierter Produktansatz (Curated Product Approach)

  • Es wird bewusst entschieden, was die Plattform unterstützt und was nicht
  • Wenn ein Team statt Pub/Sub Kafka will, lautet die Antwort nicht „Hier ist der Doku-Link“, sondern „Das ist der unterstützte Umfang, das sind die Gründe, und hier ist der Offramp, falls es nicht passt“
  • Auch das Ablehnen gehört zur Arbeit

• Softwarebasierte Abstraktionen (Software-Based Abstractions)

  • Eine Plattform ist Software, kein Wiki, und ihre Interfaces sind API, CLI und SDK
  • Entwickler sollen durch das Schreiben einer kleinen deklarativen Datei einen produktionsreifen Service provisionieren können
  • Das Score-Projekt unter dem Dach der CNCF ist ein typisches Beispiel: Mit einer einzigen Workload-Spezifikation werden Datenbank, Topics, Service Accounts und Deployment automatisch provisioniert
    • Entwickler müssen intern nicht wissen, ob es Cloud SQL, Pub/Sub oder Cloud Run ist

• OSS-Anpassung und Metadaten-Register

  • Statt Vanilla-Argo CD oder Backstage unverändert einzusetzen, werden sie mit auf die Organisation zugeschnittenen Plugins, Standardrichtlinien und Integrationen betrieben
  • Ohne ein Metadaten-Register (Servicekatalog) lässt sich nicht nachvollziehen, wer was besitzt, wie Abhängigkeiten aussehen und was tatsächlich läuft
  • Backstage ist das De-facto-Standard-OSS-Framework für diese Ebene und wird in über 270 Organisationen in Produktion betrieben
    • Die CNCF hat die Zertifizierungen Certified Backstage Associate und Certified Cloud Native Platform Engineering Associate eingeführt
    • Ob Backstage, Port oder Cortex verwendet wird: Es braucht eine Single Source of Truth dafür, „welche Services existieren, wem sie gehören und welche Abhängigkeiten bestehen“

• Service für eine breite Nutzerbasis

  • Interne Plattformen haben oft nur wenige, aber sehr lautstarke Kunden; ihr Zweck ist jedoch, die typischen Aufgaben des Median-Entwicklers gut zu unterstützen
  • Wird nur für Elite-Nutzer gebaut, umgehen die übrigen Teams die Plattform, und es entstehen Shadow-Plattformen

• Betrieb als Foundation

  • Wenn die Plattform ausfällt, fällt das Unternehmen aus; daher gehören 24/7-On-Call, echte SLOs, echtes Change Management und Supportlast dazu
  • Sie ist kein „Tool“, sondern der „Boden“, von dem alles darüber Gebaute annimmt, dass er trägt

Wann und wie man beginnt

• Kein Plattformteam zu früh gründen

  • Bei einer Größenordnung von 10 Engineers braucht es kein Plattformteam, sondern Zusammenarbeit (cooperation)
    • Es reicht, wenn eine Person die Deployment-Skripte verwaltet, eine andere Terraform betreut und man sich auf Konventionen einigt
  • Wird zu früh ein Team aus 1–2 Personen gebildet, werden diese zur Ticket-Queue, während der Rest der Organisation passiv wird
  • In der Regel ist ein Team ab etwa 50 Engineers sinnvoll, wenn es mehrere Deployment-Ziele gibt und niemand mehr die eine richtige Antwort auf die Frage kennt, wie ein neuer Service ausgerollt werden soll

• Bestehende Infrastrukturorganisation umstellen

  • Bei der Umwandlung eines Infra-/SRE-Teams in eine Plattformorganisation ist der schwierigste Teil nicht die Technik, sondern die Kultur
  • Infrastrukturverantwortliche sind an die Gatekeeper-Rolle des „Geht nicht“ gewöhnt, Plattformverantwortliche müssen jedoch „einfache Ja-Antworten ermöglichen“
    • viel mit Kunden sprechen
    • nicht nur Operatoren einstellen und entwickeln, sondern auch Software Engineers, die gern Tools bauen
    • das Anreizsystem aktualisieren, damit „200 Teams um 5 % schneller gemacht“ mehr Anerkennung erhält als „einen neuen Cluster ausgerollt“
  • Der häufigste Fehlmodus ist, einfach einen PM oben draufzusetzen und es dabei zu belassen; das erzeugt keine Plattform, sondern Theater

Aufbau eines Plattformteams

• Vier Rollen

  • Software Engineer: baut die Produktoberflächen der Plattform wie API, SDK und Portal
  • Systems Engineer: kennt die zugrunde liegenden Primitive wie Kubernetes, Linux, Networking und Cloud-Control-Planes in der Tiefe
  • Reliability Engineer: fokussiert sich auf Betriebsqualität, On-Call, SLOs und Observability
  • Systems Specialist: tiefgehender Domänenexperte für Datenbanken, Sicherheit, Networking usw.
  • Bei zu starkem Software-Fokus bricht ein schönes Portal unter realer Last zusammen; bei zu starkem System-Fokus entsteht ein robuster Cluster, den niemand ohne Ticket nutzen kann

• Hiring

  • Bei der Einstellung sollte Customer Empathy oberste Priorität haben
  • Ein Engineer, der nach einem Gespräch mit einem frustrierten App-Entwickler das Problem nicht klar verstanden hat, ist nicht geeignet
  • Technische Exzellenz ohne Empathie erzeugt eine präzise, aber von niemandem genutzte Plattform
  • Für Software-Rollen kann dieselbe Level-Matrix verwendet werden, für Systems Specialists sollten jedoch flexible Titel erlaubt sein, weil ihr Marktwert und ihre Skills sich nicht sauber auf eine Software-Engineer-Laufbahn abbilden lassen

• Manager und weitere Rollen

  • Drei gemeinsame Eigenschaften hervorragender Platform-Engineering-Manager: echte Erfahrung im Betrieb von Plattformen, Erfahrung mit der Auslieferung langfristiger Multi-Quarter-Projekte und Besessenheit fürs Detail
    • Plattformen belohnen Details; der selten wirkende 1-%-Fall, der übersprungen wurde, verursacht 80 % der Supportzeit
  • PMs, Technical Writer, Developer Advocates und Support Engineers sind alle wichtig, sollten aber erst eingestellt werden, wenn das Engineering-Team ausreichend gereift ist
  • Ein PM, der zu früh in ein vierköpfiges Plattformteam gesetzt wird, ist am Ende nur ein Stuhl in Form einer Roadmap

Die Plattform als Produkt

• Interne Kunden sind schwieriger

  • Interne Kunden sind captiven Nutzer, die nur schwer abwandern können, haben starke Meinungen und nur ein schwach ausgeprägtes Produktverständnis
  • Sie sagen, was sie wollen (want), aber das unterscheidet sich oft von dem, was sie tatsächlich brauchen (need)
  • Sie verlangen, dass die Plattform ihnen die Arbeit abnimmt, statt Werkzeuge zu fordern, mit denen sie ihre Arbeit gut erledigen können
  • Das eigentliche Backlog entsteht, wenn man sich neben sie setzt und beobachtet, wie oft sie den Kontext wechseln müssen, um eine einzige Änderung auszurollen

• Discovery, Roadmap, Fehlermodi

  • Platform Discovery erfolgt nicht per A/B-Test, sondern als Pilot, mit einem aufgeschlossenen Team und anhand der gemessenen Verkürzung der Lead Time nach einem echten Deployment
  • Die vier Zeithorizonte der Roadmap
    • Vision (mehrjährig): die Richtung der Plattform
    • Strategy (jährlich): die Wetten dieses Jahres
    • Goals and Metrics (quartalsweise bis jährlich): die Definition von Erfolg
    • Milestones (quartalsweise): das, was tatsächlich ausgeliefert wird
  • Fehlermodi, die Teams häufig scheitern lassen
    • Migrationskosten unterschätzen (immer das 2- bis 3-Fache der Erwartung)
    • Das Änderungsbudget der Nutzer für neue Funktionen überschätzen
    • Sich auf das Hinzufügen von Funktionen konzentrieren, obwohl in Wirklichkeit Stabilität das Problem ist
    • Zu viele PMs im Verhältnis zur Größe des Engineering-Teams (2 PMs auf 5 Engineers sind ein Problem)

Betrieb der Plattform

• On-Call ist keine Option

  • Da die Plattform als Fundament betrieben wird, ist 24/7-Abdeckung nicht verhandelbar
  • „You build it, you run it“ gilt auch hier; das ist keine Bestrafung, sondern eine Feedback-Schleife
  • Wenn ein einzelner Engineer mehrmals pro Woche gepaged wird, muss man nicht den Dienstplan, sondern das System ändern
  • Ausgebrannte Plattform-Engineers liefern schlechte Plattformen aus

• Support: die verborgene Hälfte der Arbeit

  • Ein Bereich, der auf Konferenzen kaum behandelt wird, aber die entscheidende Hälfte des Platform Engineering ist
  • Vierstufiges Framework
    • Stufe 1: Support-Level formalisieren (P0 vs. P3, Reaktionszeiten usw.)
    • Stufe 2: Unkritischen Support vom On-Call trennen, damit Fragen wie „Wie füge ich einen CronJob hinzu?“ niemanden aus dem Schlaf reißen
    • Stufe 3: Wenn das Volumen es rechtfertigt, dedizierte Support-Spezialisten einstellen
    • Stufe 4: Eine zur Größe passende Engineering-Support-Organisation aufbauen
  • Wer Stufe 1 überspringt, sorgt dafür, dass Engineers die Hälfte ihrer Zeit mit Antworten auf Slack-DMs und die andere Hälfte mit Beschwerden verbringen

• Operatives Feedback

  • SLOs und SLAs sind Pflicht, Error Budgets nützlich, aber optional
  • Synthetisches Monitoring erkennt Fehlermodi, bevor Nutzer ein Ticket einreichen
  • Operational Reviews sind kein flüchtiger Blick auf grüne Dashboards, sondern erzwingen die Prüfung realer Daten
  • In den DORA-2025-Daten war die Plattformfähigkeit mit der höchsten Korrelation zur Nutzererfahrung klares Feedback zum Arbeitsergebnis — bei einem Fehlschlag müssen Nutzer genau wissen, was fehlgeschlagen ist und was sie tun müssen

Planung und Lieferung

• Langfristige Projekte brauchen ein Proposal

  • Plattformprojekte wie Migrationen, Re-Architekturen oder neue Control Planes dauern quartalsweise Zeiträume
  • Wesentliche Bestandteile eines guten Proposals: das zu lösende Problem, die Begünstigten, der Umfang, was explizit nicht im Umfang liegt, und die Definition von Erfolg
  • Vor dem Schreiben von Code zuerst das Dokument verfassen, reviewen lassen und dann in einen Umsetzungsplan mit konkreten Meilensteinen überführen
  • Der Fehlermodus „long slog“ — wenn sich ein Projekt über Jahre hinzieht und niemand mehr weiß, warum — ist fast immer das Ergebnis dieses ausgelassenen Schritts

• Bottom-up-Roadmap-Planung

  • Die vier Arten von Arbeit in einer Plattform-Roadmap: KTLO (keep-the-lights-on), Anweisungen der Führung, selbst entschiedene Systemverbesserungen und direkte Kundenanfragen
  • Man kann nicht allein nach Kundennachfrage priorisieren; KTLO hat Priorität 1, Anweisungen Priorität 2, für den Rest braucht es ehrliche Diskussionen mit Stakeholdern

• Zweiwöchentliche Erfolge und Herausforderungen (Biweekly Wins and Challenges)

  • Alle zwei Wochen ein kurzes Dokument verfassen: was ausgeliefert wurde (Erfolge), was blockiert ist (Herausforderungen), kurz, öffentlich und ohne Übertreibung
  • Drei gleichzeitige Effekte: Das Team formuliert den Fortschritt klar, Stakeholder erhalten ein realistisches Lagebild, und Herausforderungen werden früh sichtbar, um Unterstützung durch das Leadership auszulösen
  • Ein Dokument, das nur Erfolge enthält, ist ein Dokument, dem niemand vertraut — Herausforderungen also nicht weglassen

Re-Architektur und Migration

• Re-Architektur statt v2

  • Wenn eine Plattform veraltet ist, ist der Reflex „Lasst uns v2 bauen“ fast immer die falsche Antwort
  • Warum v2-Projekte scheitern: Investitionen in v1 werden eingefroren, es dauert länger als erwartet, und die Migrationskosten von v2 sind höher als die Kosten der vermiedenen Re-Architektur
  • Innerhalb der bestehenden Plattform re-architektieren, dabei Kompatibilität so weit wie möglich erhalten und niedrigere Umgebungen, langsame Rollouts und tranchebasierte Migrationen nutzen
  • Vier Planungsschritte
    • Das Ziel der Endarchitektur groß denken
    • Migrationskosten einrechnen (immer Faktor 2 bis 3)
    • wichtige Ergebnisse innerhalb von 12 Monaten identifizieren, die fortlaufende Investitionen rechtfertigen
    • Zustimmung des Leaderships einholen und bereit sein zu warten

• Sicherheit ist architektonisch

  • Sicherheit nachträglich aufzusetzen ist unmöglich; die Architektur muss von Beginn an Least Privilege, Isolation und Nachvollziehbarkeit erzwingen
  • Wenn eine Plattform verlangt, dass sich jedes Team an die korrekten IAM-Bindings erinnert, liegt der Fehler nicht beim Team, sondern bei der Plattform

• Migration: das unterschätzte schwierige Problem

  • Die häufigsten Antipatterns
    • Allen Teams ein Clipboard und eine Deadline geben und verlangen, dass sie selbst migrieren
    • Nur ein Mandat aussprechen, ohne klaren On-Ramp und Off-Ramp
    • Den Long Tail ungewöhnlicher Use Cases unterschätzen
  • Engineering-Ansätze für einfachere Migrationen
    • Nutzungsmetadaten verfolgen, um Nutzer alter Versionen exakt zu identifizieren
    • Wenn 200 Teams migrieren müssen, schreibt das Plattformteam die Skripte, nicht die App-Teams
    • Eine Architektur für transparente Migration entwerfen, bei der das neue System die alte API verwendet
    • Den On-Ramp so klar dokumentieren, dass neue Teams Self-Service nutzen können
  • Mandate wirken nur ein- oder zweimal, danach werden sie zu bloßem Rauschen
  • In den meisten Fällen ist es am besten, den neuen Pfad so gut zu machen, dass der alte Pfad von selbst verkümmert

• Außerbetriebnahme (Sunsetting)

  • Keine Angst davor haben, Produkte abzuschalten
  • Ein robustes Deployment-System ist sieben halb unterstützten Deployment-Systemen überlegen, und Außerbetriebnahmen sind ein Merkmal reifer Teams

Beziehungen zu Stakeholdern

• Power-Interest-Grid

  • Stakeholder entlang zweier Achsen abbilden: Macht (power) und Interesse (interest)
    • Hohe Macht, hohes Interesse: regelmäßige Updates und Abstimmung
    • Geringe Macht, geringes Interesse: eine Statusseite reicht aus
  • Keine Teamzeit verschwenden, indem man einem VP mit geringem Interesse Informationen zu Kubernetes-Upgrades liefert

• Kommunikation ohne Oversharing

  • Transparent, aber nicht übermäßig — Senior Leader müssen nicht über Debatten zu drei gRPC-Retry-Strategien Bescheid wissen, sondern ob Meilensteine erreicht werden und welche Risiken bestehen
  • 1:1-Meetings gezielt nutzen und Erwartungen sowie Zusagen an sichtbarer Stelle nachverfolgen

• Nein sagen, ohne Beziehungen zu beschädigen

  • Den Business Impact klar benennen, etwa: „Wenn wir diese Funktion hinzufügen, verzögert sich die Migration um ein Quartal, was das Unternehmen $X kostet“
  • „Ja, mit Kompromiss“, „Nein, aber mit aufgezeigtem Pfad“, und manchmal kann es besser sein, eine Schattenplattform zuzulassen, als die Kosten eines Streits zu tragen
  • In der Budget-Saison nicht nach einzelnen Personen, sondern nach Teams und Fähigkeiten gebündelt präsentieren und eine klare Meinung dazu haben, was gekürzt und was beibehalten werden soll — sonst entscheidet die Finanzabteilung stattdessen und entscheidet falsch

Wie Erfolg aussieht

• Ausgerichtete Plattform (Aligned)

  • Erforderlich sind Zielausrichtung (warum sie existiert), Strategieausrichtung (Wetten sind teamübergreifend konsistent) und Planungsausrichtung (keine Konflikte bei Meilensteinen)
  • Fehlende Ausrichtung entsteht, wenn alle Runtime-Teams Kubernetes wollen und das Observability-Team versucht, alle Frameworks zu unterstützen
    • Das zeigt sich in widersprüchlichen Kundenleitfäden, Doppelarbeit und frustrierten Entwicklern, die dazwischen festhängen
    • Gelöst wird das nicht durch Konsens, sondern durch prinzipiengeleitete Führung

• Vertrauenswürdige Plattform (Trusted)

  • Vertrauen wird langsam aufgebaut und kann durch eine einzige schlechte Migration verloren gehen
  • Vertrauen entsteht durch die Art des Betriebs (Kommunikation bei Störungen, Einhalten von Zusagen), die Art der Investitionen (große angekündigte Wetten tatsächlich ausliefern) und Lieferprioritäten
  • Beispiel einer „overcoupled platform“: Zu viel Custom-Logik wird in die Plattform gepackt, sodass jede Änderung Monate dauert — die Lösung ist nicht zusätzliche Engineering-Arbeit, sondern Annahmen über den Umfang infrage zu stellen
    • Manchmal liegt ein Vertrauensproblem nicht daran, dass zu wenig getan wird, sondern daran, dass zu viel getan wird

• Eine Plattform, die Komplexität beherrscht

  • Softwarekomplexität ist unvermeidlich, akzidentelle Komplexität (accidental complexity) aber nicht
  • Es gilt, zwischen irreduzibler Problemkomplexität und akzidenteller Komplexität zu unterscheiden, die durch schlechte menschliche Koordination, Shadow Platforms, die dasselbe Problem zweimal lösen, und unendliches Wachstum entsteht
  • Drei praktische Hebel
    • Wachstum kontrollieren: Eine Plattform, die alles unterstützt, unterstützt am Ende nichts gut; den Umfang klar festlegen
    • Product Discovery nicht nur dafür nutzen, herauszufinden, was hinzugefügt werden soll, sondern auch, was eingestellt werden sollte
    • Shadow Platforms managen: Wenn Teams parallele Lösungen bauen, ist das ein Signal dafür, dass der Plattform real etwas fehlt oder jemand den Zuständigkeitsbereich ausweitet — auf beides muss reagiert werden

• Eine geliebte Plattform (Loved)

  • Drei Formen
    • „Es funktioniert einfach“-Liebe: Die meisten Nutzer nehmen die Plattform gar nicht bewusst wahr, Deployments laufen durch, CI ist grün — langweilig zu sein ist das größte Kompliment
    • „Das fühlt sich wie ein Hack an“-Liebe: kleine Freuden wie ein CLI-Befehl, der ohne weitere Erklärung offensichtlich das Richtige tut
    • Offensichtliche Liebe: Umfragewerte, Retention, organische Adoption, Empfehlungen der Plattform an andere Teams
  • Wenn eine Plattform geliebt wird, kämpfen andere bei Budgetanträgen für sie; wird sie nur geduldet, ist sie nach einem einzigen schlechten Incident durch Ersatz bedroht

Prioritäten in der Praxis

• Grobe Reihenfolge beim Start bei null oder beim Neuaufbau
  • Priorität 1: Unterstützungsumfang festlegen, dokumentieren und verteidigen
  • Priorität 2: In Software-Abstraktionen statt in ein Wiki investieren (Software mit echten APIs wie Score, Crossplane, eigenes SDK usw.)
  • Priorität 3: Metadaten-Registry aufbauen (mit Backstage usw., um zu wissen, was wo läuft und wem es gehört)
  • Priorität 4: Nicht für das lauteste Team bauen, sondern für das Durchschnittsteam
  • Priorität 5: Betrieb als erstklassige Funktion behandeln, etwa mit SLOs, On-Call und Support-Tiers
  • Priorität 6: Nicht nur nach Systemkompetenz einstellen, sondern nach Empathiefähigkeit
  • Priorität 7: Schonungslose Kommunikation wie zweiwöchentliche Erfolge und Herausforderungen, transparente Roadmap und ehrliches Stakeholder-Management
  • Priorität 8: Unnötiges beenden, konsolidieren, ablehnen
• Im Einklang mit DORA-Daten ist die Plattformqualität ein Multiplikator für alles, auch für AI-Adoption — eine schlechte Plattform verstärkt das Chaos durch AI-Tools, eine gute Plattform erhöht den Durchsatz
• Bevor man die Rakete baut, muss man zuerst den Boden bauen

[kalista22]

Ich denke, dass die interne Kommunikation überaus wichtig ist.