# Was ist Platform Engineering? Ein praktischer Leitfaden URL: https://codebasechat.com/de/journal/was-ist-platform-engineering Type: blog Locale: de Published: 2026-10-13 Updated: 2026-10-13 --- > Was ist Platform Engineering? Ein verständlicher Leitfaden zu internen Entwicklerplattformen, Golden Paths und der Frage, wann sich ein eigenes Plattformteam lohnt. Was ist Platform Engineering? Platform Engineering bezeichnet den Aufbau und Betrieb einer internen Plattform, die Entwicklern Self-Service für alles gibt, was sie zum Ausliefern von Software brauchen: Umgebungen, Pipelines, Services, Dokumentation und Leitplanken. Ein kleines Team behandelt den Weg von „Ich habe eine Idee“ bis „Es läuft in Produktion“ als Produkt, und die Entwickler sind dessen Kunden. Das Ziel ist weniger Wartezeit, weniger Tickets und weniger Werkzeuge, die man lernen muss. Das Problem kennen Sie wahrscheinlich schon. Ein neuer Service braucht ein Repository, eine Pipeline, eine Datenbank, Secrets, Dashboards und einen Bereitschaftsplan, und jedes davon liegt hinter einer anderen Wiki-Seite oder bei einer anderen Person im Slack. ## Warum ist Platform Engineering überhaupt entstanden? „You build it, you run it“ hat gut funktioniert, solange ein Team einen Service und eine Handvoll Werkzeuge besaß. Es skaliert nicht mehr, wenn der Werkzeugkasten aus Kubernetes, Terraform, drei CI-Systemen, einem Secrets-Manager, einem Service Mesh und einem Observability-Stack besteht. Jede Produktentwicklerin sollte plötzlich nebenbei Infrastruktur-Ingenieurin sein. Die Kosten zeigen sich dabei nicht als Zeile im Budget, sondern als kognitive Last. Eine Entwicklerin, die 90 Minuten braucht, um herauszufinden, welches Helm-Chart das „richtige“ ist, wurde nicht durch fehlende Fähigkeiten ausgebremst. Ihr fehlten Standardwerte. ![A smooth paved path winding up a grassy hillside, a metaphor for a golden path](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/4d5d1f-inline1.webp) Platform Engineering ist die Korrektur. Statt jedes Team denselben Stack von Grund auf zusammenstellen zu lassen, baut ein eigenes Team ihn einmal, macht ihn zur einfachen Option und hält ihn gesund. Auch die Analysten sehen diesen Sog: Gartner rechnet damit, dass [bis 2026 80% der großen Softwareentwicklungsorganisationen Plattform-Engineering-Teams haben](https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering), 2022 waren es 45%. Ein Beispiel aus dem Alltag: Ein Team braucht eine Datenbank für einen neuen Service. Ohne Plattform bedeutet das ein Ticket, drei Abstimmungsrunden und ein Blick in eine Wiki, die seit dem letzten Umzug niemand angefasst hat. Mit einem Golden Path ist es ein Formular, eine Pipeline und ein Eintrag im Katalog, und das Team kann am selben Nachmittag mit dem eigentlichen Code anfangen. ## Was baut ein Plattformteam eigentlich? Die Anbieter-Diagramme lassen wir kurz beiseite. In den meisten Unternehmen liefert ein Plattformteam vier Dinge. - **Eine interne Entwicklerplattform (IDP).** Die Sammlung von Self-Service-Werkzeugen und Workflows auf Cloud und CI. Das kann ein Backstage-Portal sein, ein Produkt eines Anbieters oder ein gut gepflegtes Repository mit Vorlagen und einer CLI. - **Golden Paths.** Meinungsstarke, unterstützte Wege für häufige Aufgaben wie „neuen API-Service anlegen“ oder „eine Queue hinzufügen“. - **Leitplanken.** Richtlinien, Scans und Kostenlimits, die standardmäßig greifen, sodass die sichere Option auch die bequemste ist. - **Dokumentation und Auffindbarkeit.** Ein Katalog, der beantwortet: Wer besitzt diesen Service, wo liegt sein Runbook und wovon hängt er ab? Dafür braucht es keine neue Produktkategorie. Viele gute Plattformen haben als Cookiecutter-Vorlage und eine README angefangen, die jemand aktuell gehalten hat. ## Was ist ein Golden Path, und warum ignorieren Teams ihn? Die CNCF beschreibt einen Golden Path als „templated composition of well-integrated code and capabilities for rapid project development“, eine Definition, [die Google Cloud anhand eines Spring-Boot-Beispiels erklärt](https://cloud.google.com/blog/products/application-development/golden-paths-for-engineering-execution-consistency). Einfach gesagt ist es eine Vorlage, die einem neuen Service am ersten Tag ein Repository, eine Pipeline, Logging und Deploy-Konfiguration gibt. Der Fehlermodus ist genauso simpel. Ein Pfad, den niemand angefordert hat und der ohne Absprache mit den Teams gebaut wurde, die ihn nutzen sollen, bleibt bei einstelliger Adoption stehen, während sich das Plattformteam fragt, warum Entwickler weiter Tickets öffnen. Der Pfad muss kürzer sein als der Workaround, sonst nehmen die Leute den Workaround. Zwei Regeln halten Golden Paths am Leben: - **Gepflastert, nicht eingezäunt.** Entwickler dürfen den Pfad verlassen, übernehmen dann aber den Support für alles, was sie abseits davon bauen. - **Wie ein Produkt betreiben.** Jemand liest das Feedback, misst die Nutzung und löscht Pfade, die niemand verwendet. ## Ist Platform Engineering nur DevOps mit neuem Namen? Teilweise, und die ehrliche Antwort ist nützlicher als die aus dem Marketing. DevOps ist eine Kultur: geteilte Verantwortung zwischen Entwicklung und Betrieb, kurze Feedbackschleifen. Platform Engineering ist eine Möglichkeit, diese Kultur auf Skalierung tragfähig zu machen, indem wiederkehrende Betriebsarbeit zu einem Produkt wird. SRE ist noch einmal eine andere Disziplin. SREs definieren Zuverlässigkeitsziele, messen sie und entscheiden, wann man das Ausliefern stoppt, um sie zu schützen. Ein Plattformteam stellt die asphaltierte Straße bereit. Ein SRE-Team sagt Ihnen, wie viel Risiko Sie sich darauf leisten können. Wer beides verwechselt, kauft oft das falsche Team ein: Eine Plattform löst keine Zuverlässigkeitsprobleme, die aus fehlenden Fehlerbudgets entstehen. - **DevOps** ist eine Kultur und eine Sammlung von Praktiken. Das Ergebnis sind geteilte Verantwortung und Automatisierung. Es scheitert typischerweise, wenn daraus ein Jobtitel und eine Ticket-Warteschlange wird. - **SRE** ist eine Disziplin für Zuverlässigkeit. Das Ergebnis sind SLOs, Fehlerbudgets und ein Incident-Prozess. Es scheitert typischerweise, wenn daraus eine Bereitschaftsrotation ohne Entscheidungsbefugnis wird. - **Platform Engineering** ist ein internes Produktteam. Das Ergebnis ist eine Self-Service-Plattform mit Golden Paths. Es scheitert typischerweise, wenn daraus eine Plattform wird, die niemand nutzt. Die Fehlermodi sollte man zweimal lesen. Ein Plattformteam, das Tickets annimmt und alles baut, was verlangt wird, ist ein umbenanntes Ops-Team und erbt alle alten Warteschlangenprobleme. ![Server rack with tangled cables on one side and neatly routed cables on the other](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/483c49-inline2.webp) ## Wann lohnt sich ein eigenes Plattformteam? Verzichten Sie darauf, wenn Sie weniger als etwa 30 Ingenieure und ein bis zwei Services haben. In dieser Größe reichen ein gutes Template-Repository und ein gemeinsames Terraform-Modul, und ein eigenes Plattformteam wäre nur Overhead. Ein paar Leute in einem Team von zehn werden ohnehin still zur Plattform, und das ist in Ordnung. Es zahlt sich aus, wenn dieselben Signale immer wieder auftauchen: - Neue Services brauchen Wochen bis zur Produktion, meist weil sie auf andere warten. - Drei Teams haben dasselbe Deployment-Problem auf drei verschiedene Arten gelöst. - Das Onboarding eines neuen Ingenieurs bedeutet einen Haufen Erfahrungswissen und viel „Frag Priya, die weiß das“. - Sicherheits- und Compliance-Prüfungen passieren am Ende, pro Team, von Hand. Die kleinste nützliche Variante nennt Team Topologies die thinnest viable platform: gerade so viel, dass der größte wiederkehrende Schmerz verschwindet, gut dokumentiert und nicht mehr. Fangen Sie mit dem einen Workflow an, der über alle Teams hinweg die meisten Stunden kostet, meist „neuen Service anlegen“ oder „Preview-Umgebung bekommen“. Feature-Management ist ein gutes Beispiel für eine Fähigkeit, die als geteilter Service günstiger ist als zehnmal privat. Ein Flag-Service, den jedes Team aufrufen kann, mit derselben Audit-Spur und denselben Aufräumregeln, erspart jedem Team, sein eigenes halbfunktionierendes Toggle-System zu schreiben. Ob Sie ihn kaufen oder bauen: Er gehört auf die Plattform und nicht in jedes Repository. ## Was hat eine Plattform mit dem Lesen von Code zu tun? Mehr, als die Diagramme zugeben. Eine Plattform ist nur so nützlich wie das Wissen rund um sie herum. Wenn eine Entwicklerin fragt „Wie authentifiziert sich Service A gegenüber Service B?“, steht die Antwort im Code, in der Konfiguration und in einem Runbook, das vielleicht sechs Monate alt ist. Hier verliert ein Plattformteam still viel Zeit. Es bekommt die Slack-Frage „Wo ist X konfiguriert?“ und beantwortet sie aus dem Gedächtnis, zum fünften Mal in dieser Woche. Der Effekt wird sichtbar, sobald ein Repository über 80.000 Zeilen wächst und das Plattformteam zum menschlichen Suchindex wird. ![Developer laptop with a code editor next to a notebook sketch of a system diagram](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/428ff2-inline3.webp) Ein paar Werkzeuge helfen hier, und sie lösen unterschiedliche Hälften des Problems. Docs-as-Code-Tools halten den geschriebenen Teil nah am Quellcode. Code-bewusste Assistenten beantworten Fragen zum Code selbst. Der Assistent von Sourcegraph richtet sich an große Organisationen mit vielen Repositories und wird Unternehmen auf Angebotsbasis verkauft. Für Plattformteams in großen Beständen passt das besser als für ein Team mit fünfzehn Leuten. Für den Alltag im Editor deckt ein allgemeiner Assistent schon viel ab, mit dem Vorbehalt, dass er nur den Kontext kennt, den Sie ihm geben. Das Muster, das wir kopieren würden: Golden-Path-Vorlagen, der Verantwortlichkeitskatalog und ein durchsuchbarer Index des Codes liegen an einem Ort, und neue Ingenieure dürfen dort Fragen stellen, bevor sie einen Menschen fragen. Messbar ist das auch, und zwar in Stunden. Beantwortet Ihr Plattformteam nach der Einführung weniger als zehn „Wo ist das konfiguriert?“-Fragen pro Woche, hat es funktioniert. ## Wie fangen Sie an, ohne eine Kathedrale zu bauen? Die meisten Plattform-Initiativen scheitern, weil sie mit dem Tool beginnen. Die bessere Reihenfolge lautet: Menschen, dann Pfade, dann Werkzeuge. - **Zehn Entwickler interviewen.** Fragen Sie, wo sie zwischen einem gemergten PR und einem laufenden Feature Zeit verlieren. Sie werden dieselben drei Antworten hören. - **Einen Pfad auswählen und in einem Monat ausliefern.** Eine einzige „neuer Service“-Vorlage, die Ende-zu-Ende funktioniert, schlägt ein Portal mit 40 leeren Kacheln. - **Vorher und nachher messen.** Verfolgen Sie die Zeit bis zum ersten Deployment eines neuen Services und die Zeit bis zum ersten gemergten PR eines neuen Mitarbeiters. Diese beiden Zahlen sagen mehr als jede Zufriedenheitsumfrage. - **Roadmap und Changelog veröffentlichen.** Plattformarbeit bleibt unsichtbar, solange Sie sie nicht sichtbar machen. - **Dinge löschen.** Stellen Sie Pfade und Werkzeuge ein, die niemand nutzt. Eine kleinere Plattform, der die Leute vertrauen, schlägt eine größere, die sie umgehen. Ein Portal zu kaufen, bevor die Workflows stehen, ist verführerisch, bringt aber nichts. Ein Portal über einem chaotischen Satz an Workflows liefert nur ein hübscheres Chaos, und ein Katalog mit 247 Einträgen, von denen die Hälfte veraltet ist, ist schlechter als gar kein Katalog. Was würden wir also am Montag tun? Nehmen Sie die eine Sache, die über Teams hinweg am meisten Zeit kostet, und machen Sie sie langweilig. In den meisten Firmen ist das das Anlegen eines neuen Services oder das Bekommen einer Testumgebung. Schreiben Sie den Pfad, legen Sie ihn dorthin, wo die Leute ihn finden, zählen Sie die gesparten Stunden, und entscheiden Sie erst dann, ob Sie ein größeres Team brauchen. Platform Engineering ist kein Toolchain, die man installiert. Es ist die Entscheidung, interne Entwickler als Kunden zu behandeln, und der Beleg dafür ist eine kürzere Strecke zwischen dem ersten Arbeitstag eines neuen Mitarbeiters und seiner ersten gemergten Änderung. ## FAQ ### Was ist Platform Engineering in einem Satz? Platform Engineering baut und betreibt eine interne Plattform, die Entwicklern Self-Service für Umgebungen, Pipelines, Services und Leitplanken gibt. ### Was ist der Unterschied zwischen Platform Engineering und DevOps? DevOps ist eine Kultur der geteilten Verantwortung. Platform Engineering ist eine Art, diese Kultur skalierbar zu machen, indem wiederkehrende Betriebsarbeit als Produkt gebaut wird. ### Was ist ein Golden Path? Ein Golden Path ist ein unterstützter, vorgegebener Weg für eine häufige Aufgabe, etwa das Anlegen eines neuen Services. Entwickler dürfen davon abweichen, übernehmen dann aber den Support für das, was sie selbst bauen. ### Ab wie vielen Ingenieuren lohnt sich ein Plattformteam? Als grobe Faustregel ab etwa 30 Ingenieuren und mehreren Services. Darunter reichen oft ein Template-Repository und ein gemeinsames Terraform-Modul. ### Muss man für Platform Engineering ein Portal wie Backstage kaufen? Nein. Ein Portal ist eine Option. Viele Plattformen beginnen mit einer Vorlage, einer CLI und einer gut gepflegten Dokumentation. Erst kommt ein sauberer Workflow, dann das Werkzeug. ### Woran erkennt man, dass eine Plattform scheitert? Typische Warnsignale sind Tickets für Standardaufgaben, Pfade mit einstelliger Nutzung und Fragen, die in Slack ständig wiederkehren, ohne dass es dafür eine Dokumentation gibt.