DevOps: Ein Portal macht noch keine Plattform
Warum DevOps an falschen IDP scheitert
Platform Engineering ist im Alltag vieler IT‑Organisationen angekommen. Eigene Plattformteams, Self‑Service‑Ansätze und interne Entwicklerplattformen (Internal Developer Platform, IDP) sollen die Codeentwicklung beschleunigen, den Betriebsaufwand senken und DevOps‑Prinzipien skalierbar machen. Doch trotz steigender Investitionen bleiben viele Initiativen hinter den Erwartungen zurück. Nicht aus Mangel an Tools – sondern weil sie am Kernproblem vorbeigehen.
Der häufigste Fehler: Unternehmen bauen ein Entwicklerportal, das im Wesentlichen ein Katalog ist, und nennen es “Plattform”.
Sichtbarkeit ist noch keine Automatisierung
Sebastian Scheele, CEO bei Kubermatic und Vorstandsmitglied der Cloud Native Computing Foundation (CNCF), kennt das Problem: “Die erste Generation von IDPs konzentrierte sich auf ein konkretes Problem: Entwickler konnten nichts finden. Dienste waren über Wikis, Slack-Threads und implizites Wissen verstreut.”
Zentrale Kataloge helfen, Ordnung zu schaffen, verbessern die Auffindbarkeit und reduzieren die kognitive Last. Doch genau hier endet der Mehrwert oft. Entwickler können einen Service zwar entdecken – ihn aber nicht eigenständig nutzen. Statt Self‑Service folgen Tickets inkl. Freigabeprozessen und Wartezeiten. Aus DevOps‑Sicht ist das ein folgenschwerer Bruch: Automatisierung endet bereits an der Oberfläche.
Scheele bestätigt: “Ein Entwickler findet einen Datenbankdienst im Katalog, er klickt darauf und dann… eröffnet er ein Jira-Ticket. Oder er schreibt jemandem auf Slack oder wartet darauf, dass ein Pull-Request in einem GitOps-Repo geprüft wird, auf das er keinen Zugriff hat.”
Dieses Muster wird auch als „Portal‑Falle“ beschrieben: Hoher Aufwand für UI, Katalog und Dokumentation – bei unveränderten Bereitstellungsprozessen im Hintergrund. Die Konsequenz ist vorhersehbar: geringe Akzeptanz, ausbleibende Produktivitätsgewinne und Plattformteams, die zu Gatekeepern werden statt zu Enablern.
Portal vs. Plattform
Der entscheidende Unterschied liegt nicht im Design, sondern in der Funktion:
Ein Entwicklerportal beantwortet die Frage „Was gibt es?“ Es bietet Kataloge, Dokumentationen und kontextuelle Informationen.
Eine Entwicklerplattform beantwortet die Frage „Was kann ich jetzt bekommen?“ Sie stellt Ressourcen bereit, orchestriert Services und verwaltet deren Lebenszyklus.
Erfolgreiche DevOps‑Organisationen trennen diese Ebenen voneinander. “Die erfolgreichsten Platform-Engineering-Unternehmen behandeln diese als separate Architekturebenen. Das Portal ist die Eingangstür. Die Plattform ist das Gebäude dahinter. Man braucht beides. Nur die Eingangstür zu bauen und dies als Plattform zu bezeichnen, ist der Grund, warum Initiativen scheitern”, so Scheele.
Für ihn ist eine Entwicklerplattform “der Motor im Hintergrund: Bereitstellung, Mandantenfähigkeit, Service-Lebenszyklus und Automatisierung.”
Warum der Unterschied für DevOps strategisch relevant ist
DevOps lebt von Durchgängigkeit: Von der Anforderung über Provisionierung bis Betrieb soll alles automatisiert, reproduzierbar und überprüfbar sein. Sobald menschliche Übergaben, implizites Wissen oder Sonderprozesse erforderlich sind, verliert das Modell an Skalierbarkeit.
Eine echte Plattform wirkt als technischer Verstärker: Sie ist eine API-native Provision-Engine und standardisiert „Golden Paths“, ohne Teams zu entmündigen. Damit wird die Plattform selbst zum Produkt – mit klaren Verantwortungen, SLAs und messbarem Nutzen.
“Die Plattformen, die im Zeitalter der Agenten eine Rolle spielen werden, sind nicht diejenigen mit den schönsten Dashboards. Es sind diejenigen mit der am besten kombinierbaren, API-gesteuerten Architektur”, weiß der Open-Source-Enthusiast.
Fünf Kriterien zur Auswahl einer IDP
Ob Eigenentwicklung, Open Source oder Kaufmodell – bei der Bewertung einer IDP sollten IT‑Verantwortliche weniger auf Marketingversprechen und mehr auf strukturelle Eigenschaften achten:
- Stellt die Plattform bereit – oder katalogisiert sie nur? Wenn nach der Auswahl eines Services ein Ticket erforderlich ist, handelt es sich nicht um Self‑Service, sondern um ein Schaufenster.
- Wie wird Mandantenfähigkeit umgesetzt? Namespace‑Trennung mit RBAC reicht in größeren Umgebungen nicht aus. Entscheidend ist echte Isolation, die Teams unabhängig arbeiten lässt und Risiken begrenzt.
- Welche APIs stehen zur Verfügung? DevOps‑Automatisierung braucht maschinenlesbare, standardisierte Schnittstellen. Plattformen, die primär über eine (grafische) Benutzeroberfläche funktionieren, sind für moderne Pipelines und Automatisierungen nur eingeschränkt nutzbar.
- Wer trägt den operativen Aufwand? Frameworks und Baukästen erfordern kontinuierliche Pflege. Managed Ansätze reduzieren diesen Aufwand, können aber die Anpassungsfähigkeit einschränken. Beides ist legitim – solange es bewusst entschieden wird.
- Ist die Plattform zukunftsfähig gegenüber Automatisierung und KI? Mit agentenbasierter Automatisierung wachsen die Anforderungen. Plattformen müssen programmatisch steuerbar sein, um Workflows nicht nur für Menschen, sondern auch für Maschinen zugänglich zu machen.
Fazit: DevOps braucht Substanz, nicht nur Oberfläche
Die Debatte um IDPs hat sich weiterentwickelt. Die Frage ist nicht mehr, ob Unternehmen ein Entwicklerportal brauchen, sondern was dahinter passiert. Für IT‑Verantwortliche bedeutet das: Nicht nur der Inhalt entscheidet, sondern vor allem die Fähigkeit, Bereitstellung, Betrieb und Governance zu automatisieren.
Eine erfolgreiche IDP ist kein Katalogprojekt. Sie ist eine strategische Infrastrukturentscheidung – und damit ein zentraler Hebel für dauerhaft funktionierendes DevOps.