8 Min. Lesezeit

Platform Engineering ist 2026 keine Randnotiz mehr. Gartner hat das Thema im Hype Cycle 2024 auf den Slope of Enlightenment gesetzt, die Puppet State of DevOps Reports der letzten drei Jahre zeigen ein konsistentes Muster: Teams mit einer etablierten Internal Developer Platform deployen häufiger, schneller und mit weniger Failures als Teams ohne. Die Frage ist nicht mehr, ob Platform Engineering DevOps ersetzt, sondern wie Unternehmen den Wechsel machen, ohne die Fehler der ersten Welle zu wiederholen.

Das Wichtigste in Kürze

• Platform Engineering ist eine Team-Disziplin: Ein dediziertes Team baut und betreibt eine interne Plattform als Produkt. Dev-Teams sind dessen Kunden.
• Internal Developer Platform (IDP): Ein Self-Service-Portal, das Infrastruktur, Deployments, Observability und Compliance-Guardrails bündelt. Ziel: Golden Paths statt Ticket-Queues.
• Backstage ist der De-facto-Standard: Das von Spotify 2020 als Open Source veröffentlichte Framework ist seit 2022 CNCF Incubating Project und basis für die meisten IDPs 2026.
• Kommerzielle Anbieter wachsen: Humanitec, Port.io, Qovery und Mia-Platform bieten Managed IDPs mit geringerer Build-Komplexität. Gartner listet sie als Emerging Market.
• Die grösste Gefahr: IDP wird als IT-Projekt geführt statt als Produkt. Dann wird aus dem Self-Service-Portal eine neue, interne Plattform-Monopol-Abteilung mit Ticket-System.

Warum DevOps die eigenen Erwartungen nicht eingelöst hat

Der DevOps-Ansatz, wie er seit 2009 diskutiert wurde, basierte auf einer einfachen These: Entwickler und Betrieb gemeinsam verantwortlich. Gemeinsame Ziele, gemeinsame On-Call, gemeinsame Deployment-Pipelines. In der Praxis hat das in vielen Organisationen zu einer anderen Realität geführt: Entwickler sollen jetzt alles können, von Kubernetes-YAML über Terraform bis hin zu CI-Pipeline-Design und Observability-Konfiguration. Die Cognitive Load, wie Matthew Skelton und Manül Pais im Buch Team Topologies beschreiben, explodierte.

Das Muster zeigte sich ab 2021 deutlich. Entwickler beschwerten sich in Surveys über zu viele Tools, zu viele Verantwortungsbereiche und zu wenig Zeit für Feature-Entwicklung. Der Puppet State of DevOps Report 2022 war der erste, der diesen Effekt klar beziffert hat: Entwicklerteams in Unternehmen mit niedrigem Platform-Maturity-Level gaben bis zu 40 Prozent ihrer Zeit für Infrastruktur- und Tooling-Aufgaben aus statt für Feature-Code. Das ist der Punkt, an dem Platform Engineering als Lösung aufgetaucht ist.

Die Grundidee ist nicht neu, aber die Terminologie und die Produktsicht sind es. Statt eine zentrale Ops-Abteilung wiederauferstehen zu lassen, die Tickets bearbeitet und Tooling vorschreibt, baut ein Platform Team eine selbstbedienbare Plattform mit klaren Abstraktionen. Entwickler bekommen Golden Paths, die 80 Prozent der Standardfälle abdecken und können sich auf die verbleibenden 20 Prozent konzentrieren, in denen echte Domain-Expertise wichtig ist.

Was eine moderne Internal Developer Platform liefert

Eine IDP 2026 ist mehr als ein CI/CD-Tool mit Oberfläche. Sie bündelt mindestens fünf Capabilities: Infrastructure-as-Code-Templates für alle gängigen Service-Typen, integrierte Observability mit Prometheus und OpenTelemetry, Secret Management über HashiCorp Vault oder Cloud-native Äquivalente, Policy-as-Code über Open Policy Agent für Compliance- und Security-Guardrails und einen Service Catalog, der jedes deployete Service-Asset mit Ownership, Dependencies und Observability-Dashboards verbindet.

Backstage liefert die UI- und Plugin-Basis, die die meisten Organisationen als Ausgangspunkt nehmen. Das Service-Catalog-Feature allein ist Grund genug, mit Backstage zu starten: Für alle deployete Services zeigt es den aktuellen Owner, die Last-Deployment-Zeit, das verwendete Runtime-Framework, die Observability-Dashboards und die Dokumentation. Wenn in einem 500-Mitarbeiter-Unternehmen niemand mehr weiß, wer einen bestimmten Service maintained, beginnt der Vertrauensverlust und Platform Engineering adressiert genau das.

Die Herausforderung ist, dass Backstage out-of-the-box nur das Framework ist. Die eigentliche Plattform entsteht durch die Plugins und die Konfiguration. Spotify selbst hat mehrere Jahre und ein Team von 15 bis 20 Ingenieuren investiert, bevor Backstage intern den Produktivstatus erreichte. Wer das naiv unterschätzt, landet mit einem Prototyp, der keinem hilft. Genau deshalb ist der kommerzielle Markt für Managed IDPs und IDP-Builder 2025 und 2026 deutlich gewachsen.

„Die Frage ist nicht mehr, ob Platform Engineering DevOps ersetzt, sondern wie Unternehmen den Wechsel machen, ohne die Fehler der ersten Welle zu wiederholen.“

Team Topologies: Der organisatorische Rahmen

Ohne die richtige Team-Struktur wird Platform Engineering zur kosmetischen Rebranding-Übung. Das Team Topologies Framework von Skelton und Pais definiert vier Team-Typen: Stream-aligned, Platform, Enabling und Complicated-Subsystem. Ein Platform Team ist kein allwissender Dienstleister, sondern ein spezialisiertes Team mit dem Auftrag, die Cognitive Load der Stream-aligned Teams zu reduzieren. Das macht es durch Plattform-Produkte, nicht durch Ticket-Verarbeitung.

Der Schlüssel zum Erfolg liegt in drei Prinzipien. Erstens: Die Plattform hat interne Kunden, nicht User. Feedback, Feature-Requests und Usability-Metriken werden wie bei einem externen Produkt behandelt. Zweitens: Goldene Pfade sind keine Pflicht, sondern Standardweg. Ein Entwicklerteam, das aus guten Gründen eine andere Architektur braucht, kann sie bauen, solange es die Konsequenzen kennt. Drittens: Die Plattform misst sich an Developer Experience, nicht an Infrastruktur-Uptime. Uptime ist notwendige Bedingung, nicht das Ziel.

Die typischen Fehler der ersten Welle

Die Organisationen, die 2022 und 2023 Platform Engineering gestartet haben, haben drei Muster wiederholt, die heute vermeidbar sind. Erstens haben viele Teams die Plattform auf der Greenfield-Seite gebaut, ohne die Migration bestehender Services einzuplanen. Das Ergebnis: eine schöne IDP für neue Services, 200 alte Services mit dem gleichen alten Ticket-Prozess.

Zweitens haben viele Platform Teams keine Self-Service-Mentalität durchgehalten. Unter Druck kehrten sie in den klassischen Ops-Modus zurück: Entwicklerteam stellt Ticket, Platform Team deployt. Das ist schneller kurzfristig, aber es untergräbt das Produktverständnis. Eine Plattform, auf die die Kunden keinen direkten Zugriff haben, ist keine Plattform.

Drittens wurde Developer Experience selten systematisch gemessen. Ohne SPACE-Framework-Metriken oder vergleichbare Ansätze fehlt die Feedback-Schleife und die Plattform optimiert auf das, was das Team subjektiv für wichtig hält, nicht auf das, was die Stream-aligned Teams wirklich bremst.

Build vs. Buy: Die wirtschaftliche Entscheidung

Die Build-vs-Buy-Frage entscheidet sich 2026 an drei Faktoren: Team-Größe, Regulatorik und strategische Bedeutung der Plattform. Für Unternehmen unter 100 Entwicklern ist ein Eigenbau mit Backstage in fast allen Faellen unwirtschaftlich. Die Total Cost of Ownership einer self-hosted IDP liegt nach konservativen Schätzungen bei 1,2 bis 2,5 Millionen Euro über drei Jahre, wenn man Plugin-Entwicklung, Betrieb, Wartung und Schulung realistisch einkalkuliert. Ein Managed Angebot wie Port.io oder Humanitec liegt im gleichen Zeitraum bei 150.000 bis 450.000 Euro, je nach Entwicklerzahl und Feature-Scope.

Der Vorteil des Eigenbaus liegt in der vollständigen Kontrolle über die Plattform-Roadmap und in der Möglichkeit, sehr spezifische Compliance-Anforderungen abzubilden. Wer in einer stark regulierten Branche arbeitet und Daten nicht in externe SaaS-Lösungen geben darf, hat wenige Alternativen zu einer selbst-betriebenen IDP. Hier zahlt sich die Investition aus, weil die Kosten für Non-Compliance ein Vielfaches der Plattform-Kosten ausmachen können. Für alle anderen Unternehmen gilt: Managed IDP zuerst, Eigenbau später, wenn der Scope es rechtfertigt.

Ein oft übersehener Kostenblock sind Schulung und Adoption. Eine Plattform, die niemand nutzt, ist teurer als keine Plattform. Erfolgreiche Organisationen budgetieren 15 bis 25 Prozent des Plattform-Budgets explizit für Developer Advocacy, Onboarding-Sessions und Dokumentation. Das klingt viel, ist aber die einzige Investition, die Adoption messbar beschleunigt.

Migrations-Pfade für bestehende Landschaften

Der Greenfield-Fall ist selten. Die meisten Organisationen haben 50 bis 500 bestehende Services, eine heterogene Tool-Landschaft aus Jenkins, GitLab CI, ArgoCD, Terraform-Modulen und manueller Helm-Chart-Verwaltung. Die Platform-Engineering-Initiative muss diese Landschaft adressieren, sonst bleibt die IDP ein Inselprojekt.

Der pragmatische Migrationspfad beginnt mit einem Service-Katalog-Audit. Welche Services laufen aktuell, wer betreut sie, welche Runtimes, welche Observability-Anbindung, welche Security-Compliance-Klasse? Diese Inventarisierung dauert bei mittelgroßen Organisationen sechs bis zehn Wochen, liefert aber die Datenbasis für jede folgende Entscheidung. Ohne sie läuft Platform Engineering blind.

Im zweiten Schritt identifiziert das Platform Team drei bis fuenf Service-Archetypen, die 70 bis 80 Prozent der bestehenden Workloads abdecken. Für jeden Archetyp wird ein Golden Path gebaut: eine klar definierte, vom Platform Team gewartete Blaupause von Repository-Template bis Deployment-Pipeline. Neue Services starten ausschließlich auf einem dieser Pfade. Bestehende Services wandern über einen kontrollierten Migrationszeitraum nach, in der Regel gekoppelt an anstehende Refactoring-Arbeiten oder Framework-Updates.

Der dritte Schritt ist die Deprecation der Legacy-Infrastruktur. Hier passieren die meisten Fehler. Viele Platform Teams lassen die alten Tools zu lange parallel laufen, weil die Migration einzelner Services aufwendig ist. Die Folge: zwei Plattformen gleichzeitig, doppelter Betriebsaufwand, keine klaren Verantwortlichkeiten. Erfolgreich ist, wer harte Deadlines setzt und Migrationshilfe leistet, aber keine Ausnahmen dauerhaft toleriert.

Was 2026 neu ist: AI-augmentierte Plattformen

Der Trend des letzten Jahres: Platform Teams integrieren AI-Assistants direkt in den Plattform-Workflow. Nicht als Copilot für Code-Generation, sondern als Interaktionsschicht zwischen Entwickler und Plattform. Ein Beispiel: Statt ein Scaffolding-Template manuell auszufuellen, beschreibt der Entwickler in natürlicher Sprache, was er braucht. Die Plattform schlägt Template, Konfiguration und notwendige Policies vor, generiert die Pull-Requests und dokumentiert die Entscheidung.

Humanitec hat mit Portal Agent 2025 ein erstes Produkt in diese Richtung gebracht. Port.io integriert AI-Features für Service-Katalog-Abfragen. Backstage bietet seit Anfang 2026 experimentelle MCP-Plugins, die externe LLMs an Service-Katalog und Tech-Docs anbinden. Die tatsaechliche Produktivitaetssteigerung ist schwer zu messen, aber die Adoption steigt schnell. Entwickler akzeptieren AI-Assistants in der Plattform, weil sie den kognitiven Overhead beim Navigieren großer IDPs reduzieren.

Key Facts auf einen Blick

Definition Platform Engineering: Eine interne Plattform wird als Produkt gebaut und betrieben. Stream-aligned Teams sind Kunden mit Self-Service-Zugriff.

Referenz-Framework: Backstage (Spotify, 2020 Open Source, CNCF Incubating seit 2022). Service Catalog, Tech Docs, Plugin-Ecosystem.

Kommerzielle Anbieter: Humanitec, Port.io, Qovery, Mia-Platform. Alle Managed IDPs oder IDP-Builder mit geringerer Einstiegshürde als ein Backstage-Eigenbau.

Organisatorisches Modell: Team Topologies (Skelton, Pais, 2019). Vier Team-Typen, klare Verantwortungen, Platform Team reduziert Cognitive Load.

Metriken: DORA-Metriken (Deployment Frequency, Lead Time, Change Failure Rate, MTTR), SPACE-Framework für Developer Experience. Ohne Messung kein Feedback.

Typische Implementation-Dauer: 6 bis 12 Monate bis zu einer produktiven IDP bei konsequenter Produktorientierung. Bei halbherzigem Commitment deutlich länger.

Häufige Fragen

Was unterscheidet Platform Engineering von klassischem DevOps?

DevOps ist primär ein kulturelles Prinzip: gemeinsame Verantwortung von Entwicklung und Betrieb. Platform Engineering operationalisiert dieses Prinzip durch eine interne Plattform als Produkt. Stream-aligned Teams behalten ihre Verantwortung für Code, bekommen aber eine Plattform, die Infrastruktur, Deployments und Observability als Self-Service liefert. Platform Engineering ersetzt DevOps nicht, sondern macht es skalierbar.

Lohnt sich Backstage für mittelständische Unternehmen?

Selten als Eigenbau. Die Investition in Plugin-Entwicklung, Hosting und Wartung ist für Teams unter 100 Entwicklern oft unwirtschaftlich. Managed IDPs wie Port.io oder Humanitec bieten den gleichen Funktionsumfang mit deutlich geringerem Betriebsaufwand. Wer unter 50 Entwicklern plant, sollte mit einem Managed-Angebot starten und später migrieren, wenn die Komplexität es rechtfertigt.

Welche Metriken zeigen, dass Platform Engineering funktioniert?

Die DORA-Metriken sind der erste Kompass: Deployment Frequency steigt, Lead Time sinkt, Change Failure Rate geht runter, MTTR wird schneller. Daneben sollten Teams SPACE-Metriken für Developer Experience erheben. Eine gute Plattform kann man daran erkennen, dass Entwicklerteams sich über die Plattform nicht mehr beschweren, sondern Feature-Requests einreichen.

Wie gross sollte ein Platform Team sein?

Das hängt von der Plattform-Scope ab. Als Faustregel: ein Platform Team von 4 bis 8 Ingenieuren pro 100 Stream-aligned Entwickler. Kleinere Teams können eine schlankere Plattform betreiben, dürfen aber nicht den Fehler machen, Platform Engineering mit einem halben Stellenanteil anzugehen. Das funktioniert nicht.

Welche Rolle spielen AI-Assistants für Platform Engineering 2026?

Eine wachsende. Copilot-ähnliche Tools sind inzwischen in Backstage und kommerziellen IDPs integriert, vor allem für Scaffolding und Troubleshooting. Die tatsächliche Wertschöpfung liegt aber nicht im reinen Code-Generieren, sondern in der Beschleunigung der Plattform-Interaktion: ein Entwickler beschreibt in natürlicher Sprache, was er braucht, die Plattform liefert die passende Template-Auswahl und dokumentiert sie mit. 2026 ist das in den ersten Managed IDPs live, in Backstage als Experimental-Plugin verfügbar.

Weiterführende Lektüre

→ Agentic AI in der Cloud: Wie autonome Workflows den DevOps-Alltag verändern

→ KI-Inference-Kosten in der Cloud: FinOps-Strategien für GPU-Workloads 2026

→ Serverless KI ist überbewertet und hier ist was stattdessen zählt

Quelle Titelbild: Pexels / panumas nikhomkhai (px:17489153)