Drei Fragen und Antworten: Ist Platform Engineering mehr als ein Hype?
Platform Engineering gilt als Königsweg zu geringerer Komplexität. Ob der Ansatz diesem Anspruch gerecht wird, erklärt Andreas Grabner.
(Bild: iX)
Die Softwareentwicklung und Anwendungsbereitstellung sind einem steten Wandel unterworfen, hin zu mehr Effizienz, Leistung und Qualität. Lange Zeit prägte DevOps die technischen Methoden in Entwicklung (Dev) und Betrieb (Ops) sowie die Zusammenarbeit beider Bereiche. Inzwischen gilt jedoch Platform Engineering als der Königsweg – aber was ist dran an diesem Hype? Andreas Grabner, CNCF Ambassador, DevRel für CNCF Keptn und DevRel für DevOps & Platform Engineering bei Dynatrace, beleuchtet die Hintergründe.
Platform Engineering hat sich in den vergangenen Jahren zu einem Hype entwickelt. Wo liegen die GrĂĽnde dafĂĽr und was sind die entscheidenden Treiber dahinter?
Für den Hype gibt es nach meiner Einschätzung mehrere Ursachen, am wichtigsten sind aber die Ineffizienz und die daraus resultierende Frustration bei vielen Entwicklungsteams. Doch woher kommt das? Mit jedem großen Technologiewechsel – etwa vom AppServer in Richtung Containerorchestrierung oder beim Übergang von Services zu Serverless – geht eine neue Komplexität der Tools und Prozesse einher. Wenn gleich mehrere Teams in einer Organisation lernen müssen, wie sie in dieser "neuen Technologiewelt" entwickeln, bauen, testen, deployen, releasen, betreiben … dann kommt es in der Folge oft zu dupliziertem Aufwand. Was heißt das? Jedes Team versucht im Alleingang herauszufinden, welche Tools am besten passen – meist basierend auf den dabei gesammelten Erfahrungen. Teamübergreifend führt das jedoch zu dem Problem, dass es am Ende viele unterschiedliche Ansätze und Lösungen gibt, anstatt sich gemeinsam an einem Golden Path zu orientieren.
Und genau an diesem Punkt setzt Platform Engineering an, mit dem Ziel, die Komplexität zu verringern. Interne Self-Service-Plattformen sollen den Entwicklungsteams ermöglichen, sich auf das Wesentliche ihrer Entwicklungsarbeit zu fokussieren, statt Zeit und Kraft darauf zu verschwenden, alle notwendigen Tools miteinander integrieren zu wollen!
Platform Engineering verfolgt mit diesem Ansatz nichts grundsätzlich Neues, sondern setzt den von DevOps eingeschlagenen Weg konsequent fort. Für viele ist es daher die logische Evolution in Richtung "DevOps as a Product" oder "DevOps as a Platform". Auf der anderen Seite ist der mit Platform Engineering verbundene Hype für verschiedene Toolhersteller und Serviceanbieter aber auch ein willkommener Aufhänger, mit dem sich "gut Geld verdienen lässt" – obwohl es grundsätzlich um dieselben Themen wie vor 10 Jahren geht.
Videos by heise
Was unterscheidet erfolgreiche von weniger erfolgreichen Platform-Engineering-Initiativen? An welchen Faktoren lässt sich der Erfolg überhaupt messen und was sind die notwendigen Voraussetzungen?
Nach meiner Erfahrung hängen die Erfolgschancen davon ab, ob ein Unternehmen die Plattforminitiative primär als Projekt mit einem Ablaufdatum oder eher als ein internes, sich kontinuierlich weiterentwickelndes Produkt betrachtet. Letzteres führt mit deutlich höherer Wahrscheinlichkeit zum Erfolg. Es setzt aber auch voraus, dass die Plattforminitiative genauso behandelt wird wie jedes andere Softwareprodukt. Am Anfang sollte daher eine (Markt-)Analyse stehen, anhand derer sich klären lässt, ob es tatsächlich den Bedarf für eine Plattform innerhalb der Entwicklungsteams gibt. Ist das der Fall, gilt es, die konkreten Probleme zu benennen, die die Plattform lösen soll, und wie sich der angestrebte Mehrwert sichtbar und messbar machen lässt.
Wenn es dann zur Umsetzung kommt, ist die Plattform wie jedes andere Softwareprodukt zu behandeln. Das heißt, es braucht Produktmanager und/oder Product Owner, die sich um die Features kümmern und diese mit den zukünftigen Usern der Plattform eng und kontinuierlich abstimmen. Die Umsetzung gehört in die Verantwortung von Architekten und Entwicklern. Wichtig dabei ist, Erfolgskriterien zu definieren, etwa wie viele Benutzer bestimmte Features der Platform innerhalb der ersten drei Monate adaptieren sollen. Voraussetzung dafür ist, dass die Verwendung der Plattform und deren Features messbar sind, beispielsweise über geeignete Observability-Tools. Neben den bekannten DORA- und SPACE-Metriken sollten aber auch weitere typische Messgrößen aus der Softwareproduktion in die Beurteilung einfließen – darunter etwa "wie schnell ein neuer Entwickler produktiv sein kann" oder "wie viel Zeit Code Reviews von Pull Requests benötigen" und "wie lange schließlich das Deployment in Produktion dauert."
Welche konkreten Beispiele fĂĽr Platform Engineering gibt es und in welchen Bereichen (Organisationen, Unternehmen, Branchen etc.) lassen sich diese sinnvoll einsetzen?
Ein typisches Beispiel ist das automatische Bereitstellen einer neuen Entwicklungsumgebung, die alle Sicherheits- und Qualitätsanforderungen für moderne Softwareentwicklung erfüllt. In vielen Organisationen dauert es oft Stunden oder sogar Tage, bis ein Entwickler seine erste Zeile Code schreiben, diese bauen, deployen und testen kann. Die Gründe dafür sind meist manuelle Prozesse, um etwa neue Git-Repositories anzulegen oder einen Dev-Kubernetes-Cluster zu erzeugen. Insbesondere in großen Unternehmen mit vielen Entwicklerinnen und Entwicklern führt das zu hoher Ineffizienz, die über kurz oder lang Frustration in den Teams nach sich zieht. Hier hilft eine Self-Service-Plattform, indem sie den kompletten Prozess automatisiert und den Entwicklern die für sie erforderlichen Dienste auf einfache Weise zur Verfügung stellt.
Dieser Plattformansatz lässt sich flexibel auf weitere Anwendungszwecke übertragen, beispielsweise für den individuellen Self-service-Release von Features für ausgewählte Kunden oder den Zugriff auf relevante Observability-Daten (Logs, Metriken, Traces) fürs Troubleshooting. Auch das Skalieren von Anwendungen mit besonderem Fokus auf die Kosten lässt sich via Plattform als Selbstbedienungsdienst einrichten.
Die Frage, die sich natürlich immer stellt: wie viel Aufwand und Geld steckt man in solche Plattformen und was ist am Ende der tatsächliche Nutzen. Hier komme ich wieder auf die Messbarkeit aus der zweiten Frage zurück. Wenn man nicht messen kann, ob die Effizienz der Entwicklungsteams und die resultierende Qualität der Software steigt, dann helfen auch die besten Beispiele und Use Cases nichts.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.
(Bild:Â cloudland.org)
Vom 1. bis 4. Juli 2025 finden Interessierte beim Cloud Native Festival CloudLand ein prall gefülltes Line-up mit mehr als 200 Highlights – darunter auch das Thema Platform Engineering. Besucherinnen und -Besucher erwartet eine bunte Mischung überwiegend interaktiver Sessions, Hands-ons und Workshops, begleitet von einem umfassenden Rahmenprogramm, das zum aktiven Mitmachen einlädt.
Verteilt auf bis zu zehn Streams, die von Themen aus den Communities der Cloud-Hyperscaler AWS, Azure und Google geprägt sind, gibt es Sessions zu:
- Cloud-native Software Engineering
- Architecture
- AI & ML
- Data & BI
- DevOps
- Public Cloud
- Security & Compliance
- Organization & Culture
- Sovereign Cloud
- Compute, Storage & Network
Erstmals sind beim CloudLand-Festival auch zahlreiche Vertreterinnen und Vertreter von verschiedenen CNCF-Projekten vertreten. Unter anderem präsentiert CNCF Ambassador Andreas Grabner einen Vortrag zum Thema "Was ist Platform Engineering und wie erhöht man damit Developer Productivity!?"
Tickets fĂĽr das Festival sind noch bis zum 6. Mai zum gĂĽnstigen FrĂĽhbucherpreis zu haben.
(map)