Platform Engineering vs. DevOps: Was steckt hinter Internal Developer Platforms?

In der Cloud-Native-Szene erhalten Internal Developer Platforms (IDPs) viel Aufmerksamkeit. In ihrem Vortrag auf dem Cloud-Native-Festival CloudLand 2025 ordnen Alexander Hoeft und Artem Lajko ein, was hinter dem Konzept steckt, wo die Abgrenzung zu klassischen DevOps-Ansätzen liegt – und warum viele Organisationen noch nicht reif für den Aufbau einer solchen Plattform sind.

Das Grundprinzip einer IDP besteht darin, Entwicklerteams eine zentrale Plattform bereitzustellen, über die sie Infrastruktur und Services im Self-Service nutzen können. Statt sich selbst um Provisionierung, Konfiguration und Betrieb kümmern zu müssen, greifen Entwickler auf vorgefertigte, standardisierte Bausteine zurück. Das soll die kognitive Last senken und die Produktivität steigern.

Hoeft und Lajko betonen dabei einen wesentlichen Punkt, der in der Diskussion häufig untergeht: Die Rolle eines Platform Engineers unterscheidet sich grundlegend von der eines DevOps Engineers. Während DevOps Engineers typischerweise direkt in Produktteams arbeiten und dort Entwicklungs- und Betriebsaufgaben vereinen, agieren Platform Engineers als Dienstleister für die gesamte Organisation. Sie bauen und pflegen die Plattform, die andere Teams „konsumieren“ – behandeln deren Bedürfnisse also ähnlich wie ein Produktteam seine Endnutzer.

Wer allerdings glaubt, mit dem Aufbau einer IDP sofort loslegen zu können, dem erteilen die Sprecher eine klare Absage. Organisationen sollten zunächst ein belastbares Fundament an Automatisierung geschaffen haben, bevor sie eine Plattform darüber errichten. Konkret empfehlen Hoeft und Lajko, dass grundlegende Prozesse wie Infrastructure as Code, CI/CD-Pipelines und automatisierte Tests bereits etabliert und ausgereift sein müssen. Ohne diesen Reifegrad laufe man Gefahr, Komplexität nicht zu reduzieren, sondern lediglich auf eine neue Ebene zu verlagern.

Backstage als IDP-Komponente: Kein Selbstläufer

Ein konkretes Werkzeug, das in der IDP-Diskussion regelmäßig auftaucht, ist das von Spotify entwickelte, heute von der CNCF betreute Open-Source-Projekt Backstage. Es dient als Developer-Portal und kann als zentrale Oberfläche für eine IDP fungieren. Hoeft und Lajko warnen jedoch vor typischen Fallstricken beim Einsatz: Backstage sei keine schlüsselfertige Lösung, sondern ein Framework, das erheblichen Anpassungs- und Pflegeaufwand erfordere. Wer es einführe, ohne genügend Ressourcen für die kontinuierliche Weiterentwicklung einzuplanen, ende schnell mit einer halbfertigen Plattform, die von den Entwicklerteams nicht angenommen werde. Zudem bestehe die Gefahr, Backstage als reinen Service-Katalog zu betreiben, ohne die dahinterliegenden Automatisierungsschichten tatsächlich aufzubauen.

Trend oder nachhaltige Entwicklung?

Die zentrale Frage des Vortrags – ob IDPs nur ein Trend sind – beantworten die Sprecher differenziert. Das zugrundeliegende Konzept, Entwicklern Infrastruktur als Produkt anzubieten, sei keineswegs neu und habe sich in großen Technologieunternehmen bereits bewährt. Allerdings müsse jede Organisation ihren eigenen Reifegrad realistisch einschätzen. Eine IDP ist demnach kein Projekt, das man nebenbei aufsetzt, sondern eine strategische Entscheidung, die personelle Ressourcen, Organisationsstruktur und technische Voraussetzungen gleichermaßen betrifft.

Über die Speaker

Alexander Hoeft und Artem Lajko sind für das IT-Beratungsunternehmen iits-consulting tätig. Hoeft arbeitet dort in der Rolle eines Senior Platform Engineer und ist darüber hinaus als Blogger und Sprecher auf Konferenzen aktiv. Lajko ist Head of Platform Engineering bei iits und außerdem Platform Engineering Ambassador und Kubestronaut. Auch er ist Blogger, Speaker und zudem Buchautor („Implementing GitOps with Kubernetes“).

(map)