Dieser Artikel zeigt eine einzigartige Perspektive auf einen der neuesten Trends in der IT: Platform Engineering. Erfahren Sie, wie Platform Engineering dem Unternehmen nutzen und wie es sich auf DevOps-Teams auswirken könnte.
Wir vollziehen anscheinend einen Wandel hin zum Platform Engineering, und Sie, als Einzelner oder als Unternehmen, müssen diese Entwicklung ernst nehmen!
Ich weiß nicht, wann genau das DevOps-Konzept gescheitert ist. Ich bin mir nicht sicher, ob überhaupt jemand bemerkt hat, dass es zu wanken begann, aber zweifellos war es für Unternehmen schwer umsetzbar, weil es den wichtigsten Nerv (wer empfindliche Zähnen hat, weiß, was ich meine) in jeder IT-Praxis berührt hat: Die Kultur! DevOps erfordert nicht nur einen Wandel in der Technologie, sondern auch in den Prozessen und Kompetenzen (People, Process, Technology – PPT). Und das ist für Unternehmen eine ziemliche Herausforderung. Zumindest ist DevOps verwirrend, vor allem, wenn ein Unternehmen nicht „in der Cloud geboren“ wurde.
Platform Engineering steht für eine Linksverschiebung vieler DevOps-Praktiken (Entwicklung von Tools, Plattformen, Abläufen, Sicherheit usw.), auch wenn niemand das zugeben wird. Keiner wird das so sagen, aber ich bin überzeugt, dass mit Platform Engineering, das gemeistert werden soll, was DevOps nicht liefern konnte, und zwar indem schon früh im Gesamtzyklus etwas entstehen soll, das man jetzt als „Plattform-Team“ bezeichnet.
Aussagen wie „Plattform Engineering ist richtig eingesetztes DevOps“ oder liest von „der Evolution von DevOps (hin zu Platform Engineering)“, „der Modernisierung von DevOps“ oder gar: „Wir müssen Standardisierung und Konsistenz in die Entwicklungsabläufe einführen“. Doch wird im Wesentlichen mit diesen und ähnlichen Gedanken und Schlagzeilen eingestanden, dass Unternehmen DevOps-Praktiken irgendwie falsch implementieren. Also musste sich die „Cloud-native“ Community etwas Neues oder Anderes ausdenken, um das ganze Unterfangen vor dem Scheiterhaufen einer untergegangenen Technologie zu retten!
Fragt man bei einigen „DevOps-Paten“ nach, erfährt man, dass sie nicht einmal am Begriff (DevOps) interessiert sind, sondern „Continuous Delivery“ und andere Bezeichnungen vorziehen. Ich wäre mit einer Reihe allgemein anerkannter Begriffe und Definitionen zufrieden, die jeder annehmen und an die er sich mehr oder weniger halten kann, damit die Unternehmen diese Technologien weiter einführen und nutzen können. Also eher „kontinuierlich handeln“ als „kontinuierlich debattieren“.
Sarah Polan (Field CTO bei HashiCorp) sagt nein. In ihrem Blog „Platform Engineering – What We've Got Wrong“ führt sie aus: „Wir haben festgestellt, dass der einfache Teil in großen Unternehmen wie üblich die Technologie ist. Facebook, Apple, Amazon, Netflix und Google sind vielleicht in der Lage, diese mythischen DevOps-Einhörner zu kaufen. Der Rest der Branche muss sich damit begnügen, bröckelnde Architekturen zusammenzuflicken.“ Sarah Polan ist – wie ich – davon überzeugt, dass manche Unternehmen aufgrund fehlender Fertigkeiten und der Fluktuation in der IT-Branche, die letztes Jahr bis zu 30 % erreichte, Schwierigkeiten haben, DevOps konsequent zu skalieren.1
Welche anderen Gründe sprechen womöglich für ein Scheitern von DevOps? Scott Finnie, ehemaliger Redakteur von Computerworld.com, war auf der richtigen Spur, als er in seinem Blog „The Top 5 Ways DevOps Fails“ („Die 5 wichtigsten Gründe, warum DevOps scheitert“) schrieb: „Man darf die Kultur nicht ignorieren“.2
Ich möchte Finnies Argument weiterführen: Entwickler und Betriebsmitarbeiter haben unterschiedliche Eigenschaften: Erstere sind künstlerische, originelle Denker und Problemlöser; letztere sind pragmatisch, denken strategisch und scheuen Risiken. Zugegeben, das ist eine Verallgemeinerung, aber ich frage mich gelegentlich, ob die Vision einer Zusammenarbeit zwischen so unterschiedlichen Gruppen nicht zu idealistisch ist. Mehr noch: War DevOps vielleicht ein „Komplott“, damit Entwickler die Cloud-Infrastruktur gänzlich kontrollieren und den traditionellen Infrastrukturbesitzern Macht entreißen können? In bestimmten Kreisen wird heute von den Entwicklern erwartet, dass sie sämtliche Aspekte ihrer Cloud-Umgebung kennen, einschließlich Site Reliability und Site Observability!
Bemerkenswert ist zunächst, wie uneinheitlich unsere Branche Platform Engineering definiert, je nachdem, wem man folgt und was man liest. Beginnen wir mit der Prämisse. Die wichtigsten Zielsetzungen von Platform Engineering sind, den Entwicklungsprozess zu rationalisieren und zu standardisieren sowie die kognitive Belastung der Entwickler zu verringern.
Um diesen paradiesischen Zustand zu erreichen, wird ein einheitliches Ökosystem aus gemeinsamen, wiederverwendbaren Tools und Self-Service-Funktionen zusammengestellt und angeboten. Kurz gesagt ist Platform Engineering eine Plattform, die Entwickler nutzen können, ohne sich um die zugrundeliegende Infrastruktur zu kümmern.
Platform Engineering ist der Beweis dafür, dass es vielen Unternehmen schwerfällt, von DevOps zu profitieren. Trotzdem beunruhigt mich, dass Platform Engineering angeblich für den Entwickler von Vorteil ist, ihm aber in Wirklichkeit einen Weg vorschreibt, den er nicht gehen möchte, insbesondere indem es ihm sein Handwerkszeug vorgibt. Das Thema Site Reliability Engineering (SRE) hebe ich mir für einen künftigen Blogbeitrag auf!
Ich habe viele Debatten darüber gelesen, wie Platform Engineering die Berufsrollen beeinflussen wird. Wie und ob wir Mitarbeiter in Schubladen zwängen, richtet sich nach Größe und Zielen des jeweiligen Unternehmens. Ein optimaler Software-Entwicklungszyklus erfordert ein vielseitiges Team, in dem jedes Mitglied genau weiß, was von ihm erwartet wird, und entsprechend seinen Fähigkeiten und so arbeiten kann, dass es sich ernst genommen fühlt. Ohne Zweifel wird es zu Überschneidungen und Grenzverwischungen kommen, doch der neue Begriff „Plattform-Teams“ findet allmählich Eingang in den Wortschatz der Entwickler.
Als aufstrebender (oder vielleicht besser „rettender“) Technologieansatz soll Platform Engineering Anwendungen und Geschäftswert schneller bereitstellen.
Die fünf wichtigsten Ziele von Platform Engineering (es gibt mehr):
Das Hauptziel von Platform Engineering besteht darin, eine „Internal Developer Platform” bzw. ein „Internal Developer Portal” (IDP) zu schaffen, wie manche es leidenschaftlich nennen. IDP ist eine sorgfältig ausgewählte Sammlung von Tools, Lösungen, Funktionen und Prozessen, die Entwicklern Self-Service ermöglichen. Der Fokus liegt darauf, die internen Entwicklungspraktiken eines Unternehmens zu standardisieren, um einen „goldenen Weg“ zu schaffen, der unterstützten Entwicklungen den Weg zur Produktion ebnen soll.
Wie ich bereits erklärt habe, bin ich keinesfalls davon überzeugt, dass sich die Entwickler in einen Unternehmensstandard „treiben“ oder, um es diplomatischer auszudrücken, „vereinen“ lassen, um dann nicht mehr mit eigenen Entwicklungs-Tools und -Plattformen experimentieren zu dürfen.
So wie ich es sehe, ist Platform Engineering nicht eine Alternative zu DevOps, sondern ein Teilbereich davon (DevOps ist also doch nicht tot?). Betrachten Sie DevOps als übergeordneten Rahmen, in dem Platform Engineering bestimmte Aspekte des Entwicklungsprozesses abdeckt, während andere Elemente wie zum Beispiel SRE die Überschneidung vervollständigen, die jetzt in der Definition des gesamten Entwicklungsprozesses zu bestehen scheint.
Platform Engineering kann den Software-Entwicklungszyklus (Software Development Lifecycle; SDLC) zwar optimieren, ist aber kein Allheilmittel für alle Probleme bei der agilen Entwicklung. Ob der SDLC-Workflow erfolgreich ist, hängt noch immer stark von Faktoren wie der Zusammenarbeit im Team, klarer Kommunikation und effektivem Management ab.
Wie auch immer wir Platform Engineering bezeichnen; ich frage mich, wie es sich auf Unternehmen auswirken wird, die bereits stark in DevOps-Modelle und Teamstrukturen investiert haben.
Der Umfang der getätigten DevOps-Investitionen schwankt je nach Unternehmen erheblich, sie belaufen sich insgesamt aber auf mehrere Milliarden Dollar. Man kann also mit Sicherheit davon ausgehen, dass es häufig um sehr große Beträge geht.
Platform Engineering ist zweifellos ein weiterer kultureller Wandel, bei dem „traditionelle“ DevOps-Teams in den neuen Ansatz überführt werden. Entwickler müssen mit neuen Plattformen, Tools, Schnittstellen und eventuell sogar Sprachen zurechtkommen, und all das im Namen der Standardisierung. Halten wir kurz inne, um uns Folgendes zu verdeutlichen: Von erfahrenen Profis, die ihr Handwerk jahrelang verfeinert haben, erwarten wir, in ihren Entwicklungspraktiken auf diesen starken Wandel umzuschwenken.
Die Folgen für Rollen und Zuständigkeiten werden sich ebenfalls zeigen. Können wir wirklich sicher davon ausgehen, dass jeder bereit ist, sich diesem neuen Diktat zu beugen? Es ist leicht vorstellbar, dass der eine oder andere nicht einverstanden sein wird. Die potenziellen Konflikte und verlorene Talente mögen für einige Unternehmen akzeptabel sein.
Während ich oben die wahrgenommenen Vorteile von Platform Engineering dargestellt habe, liegt es an uns allen, insbesondere den IT-Anbietern und -Dienstleistern, unsere Kunden bei solchen Veränderungen zu unterstützen. Ich denke, da haben wir noch viel „Engineering“ vor uns!
Zunächst müssen wir erkennen, dass dieses ganze Thema zeitlich begrenzter Natur ist, dass wir einen umfassenden Konsens über die Bedeutung all dieser Begriffe finden und einen kohärenten Ansatz entwickeln müssen, an den sich die Unternehmen halten können. Ja, trotz des ganzen Chaos müssen wir das alles schaffen und vielleicht mit der Hilfe unserer Technologie- und Service-Partner unseren eigenen Weg zur Realisierung unserer Ziele für unser Unternehmen finden.
In Bezug auf Platform Engineering gibt es noch einigen Gesprächsbedarf. Wird es zum Beispiel die kognitive Überlastung der Entwickler wirklich verringern? Schließlich müssen viele von ihnen zunächst eine steile Lernkurve absolvieren. Könnte diese Überlastung längerfristig unbeabsichtigt auf die Ops- und SRE-Teams übergehen, wenn diese versuchen, die Ergebnisse des Platform Engineering in ihre Arbeitsabläufe zu integrieren?
Während Unternehmen in der Lage sein sollen, den Wert von DevOps auf Platform Engineering zu übertragen, müssen sie andere Investitionen abschreiben, die für den „klassischen“ DevOps-Ansatz entwickelt wurden, wie Tools, Prozesse und Teamdynamik. Es wird interessant sein zu sehen, wie ihre Finanzteams dies alles quantifizieren. Bislang möchte oder kann scheinbar niemand diese Fragen beantworten. Wer mit DevOps bisher noch gar nichts zu tun hatte, wartet nun vielleicht lieber ab, wie sich das alles entwickelt.
Während die Unternehmen ihre Optionen abwägen, verändert möglicherweise eine weitere Linksverschiebung die gesamte Landschaft. Ich habe dazu eine eher pragmatische und realistische Einstellung: Spielzeug haben wir genug. Wir müssen nur unsere Selbstgefälligkeit aufgeben, uns auf einige Branchenbegriffe einigen und den Kunden weiter dabei helfen, den Übergang in eine Cloud-native Zukunft zu bewältigen.
1 Platform Engineering Article, Sarah Polan, 2024, Pulse
2 The Top 5 Ways DevOps Fails, Scot Finnie, 2018, DevOps
