Warum „Platform Engineering“ eigentlich der falsche Begriff ist und wie man den Golden Path findet, erklärt Daniel Kocot, Senior Solution Architect, im folgenden Interview.
Marco Paga: Warum ist Platform Engineering interessant?
Daniel Kocot: Ich habe im September [2022] einen ersten Versuch eines Blogposts gestartet, um das Thema aufzunehmen und zu verstehen, woher der Drive kommt, um festzustellen, dass wir das bei codecentric seit 2014 gemacht haben, ohne es „Platform Engineering“ zu nennen. Wir haben schon immer etwas ausgeliefert oder zu Kunden mitgebracht, um sie zu befähigen, Softwareprodukte schneller umzusetzen. Das heißt, es ist alles schon da gewesen, jetzt gibt es einen Begriff dafür – der vielleicht nicht ganz passend ist, das schon vorab.
Maximilian Mayer: Lass uns den Begriff „Platform Engineering“ gleich vorab klar definieren, damit jeder von uns versteht, was das überhaupt ist, wenn wir darüber sprechen.
DK: Platform Engineering ist eigentlich ein falscher Begriff. Ich baue keine Plattform auf, sondern unterstütze dabei, eine Plattform entstehen zu lassen. Also Softwareprodukte oder ein Softwareprodukt an sich. Das heißt, ich bin in der DevOps-Schiene unterwegs und versuche entsprechend, all das, was diese Software braucht, in den Lebenszyklus zu integrieren. Darin steckt auch Governance: dass man Vorgaben macht und schaut, wohin die Reise gehen könnte. Ich möchte damit verhindern, dass Teams etwas benutzen, was im Unternehmen nicht gesetzt ist, und baue Schranken auf. Wenn wir über Platform Engineering reden, dann auch über den „Golden Path“ und welche Rolle Spotify darin hat.
MM: Wir reden also nicht von einzelnen CI/CD-Pipelines, sondern Platform Engineering ist eher so etwas wie ein Meta-Begriff.
DK: Genau. Es ist ein Überbegriff. Vielleicht möchte ich auch nicht, dass eine Plattform das für mich erledigt, sondern eine Art von Orchestrierung und eine unendliche Anzahl von verschiedenen Plattformen, die mir helfen, Dinge voranzutreiben. Es kommt auch darauf an, wo ich unterwegs bin. Falls ich mit Azure arbeite, ist es eventuell sinnvoll, gewisse Sachen mit Azure DevOps zu lösen. Aber ich kann es durch Platform Engineering so abstrahieren, dass die Software-Entwicklungsteams gar nicht mitbekommen, welche darunter liegenden Technologien sie benutzen. Ganz klar spielt hier auch Developer Experience eine Rolle: das Gefühl zu haben, sich auf die Entwicklung konzentrieren zu können, ohne z. B. irgendwelche Pipelines bauen zu müssen. Es ist alles schon da.
MP: Das heißt, es ist zum einen Dokumentation, also es sind Hilfestellungen oder Ideen hinterlegt, wie bestimmte Dinge umgesetzt werden, welche Technologien oder innerhalb welchen Technologiespektrums man sich bedienen sollte. Und ich habe auch schon Artefakte mitgebracht, z. B. ein Testing oder etwas in Richtung CI/CD. Das ist ein Baukasten, aus dem ich mich bediene. Fehlt außerdem noch etwas?
DK: Es ist, grob gesagt, genau dieser Baukasten. Was wichtig ist: Ich muss die Entwickler abholen und mich erkundigen, was sie benutzen, was „State of the Art“ ist. Vielleicht stelle ich z. B. fest, dass eine bestimmte Frontend Library nicht das Richtige ist. Ich muss einen Weg finden, die Dinge langfristig besser steuern zu können. Das trägt Spotify sehr stark nach außen, mit Backstage z. B. Die Grundlage von allem ist der sogenannte „Golden Path“: den Fokus auf die reine Entwicklung zu legen. Wir haben, wie ihr auch wisst, sehr häufig Debatten über CI/CD-Pipelines, welches Tooling, warum und zu welcher Zeit. Das will man umgehen, indem man sagt: OK, du willst eine Spring-Boot-Anwendung entwickeln – hier ist ein Button, der ganz viele Dinge auslöst. Schon passieren Sachen im Hintergrund, und ich kann mich wieder auf die Entwicklung fokussieren. D. h. ich kann das Repo auschecken und direkt anfangen, ohne mir Gedanken machen zu müssen, was ich ja auch nicht will. Ich will mir nicht zuerst etwas aufbauen, sondern direkt starten. Es ist alles gesetzt, es gibt vielleicht gewisse Spielregeln, an die ich mich halten muss. Die kann ich auch noch verändern. Aber es ist ein Baukasten, plus ein bisschen mehr.
„Was wir hier tun, ist nichts Neues. Wir geben dem Ganzen einen anderen Raum und eine andere Position.“
MM: Das gibt es in der IT doch eigentlich seit 20, 30 Jahren und es hat jetzt einfach einen neuen Namen bekommen – oder sehe ich das grundlegend falsch? Ich komme aus dem Ops-Bereich, dort wurde den Entwicklern häufig schon vorgearbeitet: „Schubs deine Sachen da hinein, dann verteilen wir es weiter“ usw., d. h. sie hatten schon früher in mehr oder weniger komfortablen Konstrukten schöne Buttons, auf die sie nur noch klicken oder E-Mails, die sie verschicken mussten, um Sachen über den Zaun zu werfen. Sehe ich das verkehrt?
DK: Die Grundlage ist immer schon da gewesen. Was wir hier tun, ist nichts Neues. Wir geben dem Ganzen einen anderen Raum und eine andere Position. Wir wollen den gesamten Entwicklungszyklus transparent unterstützen und bieten dir ein gewisses Set von Möglichkeiten. Du kannst natürlich auch den Golden Path verlassen und sagen: Juckt mich alles nicht. Aber wenn du in einem Großunternehmen gewisse Regularien hast und bestimmte Software- und Infrastrukturkomponenten nutzen möchtest, hast du hiermit eine gewisse Chance, alles in eine Art von Alignment zu setzen, sodass alle das nutzen, was da ist und kein Wildwuchs entsteht. Denn das sehen wir bei sehr vielen Kunden: Sehr, sehr viele Komponenten, aber man fragt sich, in welchen Komponenten das Service-Team, das für die Bereitstellung zuständig ist, eigentlich fit ist. Man muss sich um eine schnellere Time-to-Market bemühen. Und am meisten halten Diskussionen darüber auf, was man verwendet und warum. Es gibt auch Sicherheit, wenn alles standardisiert ist und es geht dann nur noch um die Entwicklung: das Erstellen und Deployment von Software.
Der Golden Path
MP: Kannst du den Begriff „Golden Path“ noch einmal für uns einordnen und sagen, was sich dahinter verbirgt?
DK: „Golden Path“ ist das, was die Geschwindigkeit bei Spotify ausmacht. Die können relativ schnell Sachen ausliefern, die bekommen ein schnelles Onboarding hin. Der Golden Path zielt darauf ab, gewisse Sachen zu standardisieren: Abhängigkeiten von Services, Discovery von Services etc., sodass ich Sachen nicht nur schnell finde, sondern auch schnell nach dem Baukastenprinzip zusammenklicken und mich aufs Entwickeln fokussieren kann.
„Man muss sich um eine schnellere Time-to-Market bemühen. Und am meisten halten Diskussionen darüber auf, was man verwendet und warum.“
MM: Das Gedanke hinter dem Golden Path ist also „Schuster, bleib bei deinen Leisten“ bzw. „Entwickler, kümmere dich bitte darum, dass du entwickelst und nicht um das Drumherum“, denn Letzteres wird schon vorbereitet. Spannend, dass du Standardisierung nennst, denn daran scheitert es oft in Unternehmen: Man möchte oft den zweiten Schritt vor dem ersten machen – Kubernetes und all die fancy Sachen – aber der erste Schritt, Dinge zu standardisieren, wird vergessen. So entsteht Schatten-IT: Leute, die die neuesten Sachen machen wollen, treffen auf solche aus dem „Legacy“-Bereich, die noch nicht abgeholt sind und beim Bewährten bleiben wollen. Mit Platform Engineering lassen sich alle schön einfangen, um einen Rahmen zu geben, oder?
DK: Platform Engineering ist eine Art von Knowledge Sharing: Ich teile das Wissen, das ich im Unternehmen gesammelt habe, wie ich Dinge aufbaue. Marco nannte es vorhin „Dokumentation“. Für Entwickler ist es dann alles unter einem Dach, und ich muss nur dafür Sorge tragen, dass die Entwickler es benutzen. Natürlich gibt es Feedback Loops. Was man mit Platform Engineering erreichen möchte, ist eine Art Self-Service.
MP: Self-Service heißt, es ist noch kein Platform Engineering, wenn man ein gutes Confluence-Wiki pflegt und ein Ticket-System hat, wo man bestimmte Dinge anfragen kann. Da geht es schon um mehr.
DK: Ja. Ich mag den Begriff „Developer Experience“ nicht – das ist immer so eine eine platzende Seifenblase, und kein Mensch kann etwas damit anfangen – aber es geht darum, dass der Entwickler sagen kann: „Ich klicke mir etwas zusammen, dann passiert etwas Magisches. Ich muss nicht wissen, wie ein Kubernetes-Deployment funktioniert, weil es gar nicht meine Baustelle ist. Ich will nur sehen, dass mein Service in irgendeinem Cluster liegt und funktioniert.“
MM: Ich war jahrelang im Ops-Bereich tätig und kenne den ewigen Konflikt mit Entwickler-Teams, die mal etwas anderes machen wollen. Wenn man denen dann sagt: Nimm das und benutze es, wird es immer welche geben, die ihre eigenen Tools benutzen wollen, das neueste JavaScript-Framework usw. Hier sehe ich die Gefahr, dass sich Geschichte wiederholen könnte. Wie gehe ich damit um?
„Platform Engineering ist eine Art von Knowledge Sharing: Ich teile das Wissen, das ich im Unternehmen gesammelt habe, wie ich Dinge aufbaue.“
DK: Gute Frage. Man muss den Mehrwert erklären können: Warum gehen wir so vor? Weil wir Geschwindigkeit wollen. Wenn das der eine oder andere als Gängelung auffassen sollte, kann man sagen: Ja, du kannst das anders machen, aber dann bekommst du keine Unterstützung und wir können das nicht jedes Mal machen. Wir können nicht auf jede Technologie reagieren, weil wir einen Plan haben. Wenn jemand Vorschläge hat, kann er die natürlich einbringen. Das ist dann allerdings ein Abweichen vom Golden Path, vom „One-Click Shop“, wie es ein Kunde von mir nennt. Ich mache einen Klick und bin schon in der Entwicklung. Ich kenne genug Beispiele von Kunden, wo das schon so funktioniert: Das nennt sich dann „App Store“ o. ä., wo du dir wirklich mit einem Klick Applikationen in jeder Programmiersprache zusammenbauen lassen kannst. Und alles ist konfiguriert. Das ist möglich. Es ist nur die Frage, wie schnell ich das auf die Mannschaft übertragen kann.
Es geht auch um Adaption, nicht um Kopieren. Nur weil Spotify es so macht und Backstage nutzt, heißt es nicht, dass wir es auch so machen. Es geht darum, zu entscheiden, was mir aktuell hilft – und wenn es erstmal nur ein Git-Repo ist.
MP: Diese Einordnung ist wichtig. Es ist ein Weg, den man geht, und je nachdem, wo man startet, kann man relativ schnell Mehrwert bieten. Während des Prozesses lassen sich ja auch Schleifen drehen. Wenn Leute andere Technologien verwenden wollen, die z. B. schneller oder besser machen, kann man diesen Leuten Anknüpfungspunkte bieten – sei es, dass man sich in einer Gilde austauscht oder in Sachen Architektur die Möglichkeit hat, einen Dialog aufzubauen oder das Ganze auszutesten, zu validieren, ob das wirklich mehr bringt, dass es irgendwo geregelt ist, und die Potentiale mitnehmen kann.
DK: An Begrifflichkeiten gibt es auch noch „Internal Developer Platform“, abgekürzt IDP, was total schlecht gewählt ist, weil IDP normalerweise etwas anderes bedeutet. Max hat es schon gesagt: Es gibt tausend Begriffe für Dinge, die eigentlich schon da sind. Man muss für sich schauen, was das Ziel ist, welcher Player im Markt man ist: Bin ich ein Datenlieferant, muss ich natürlich bis zum Ende durchautomatisieren, und das muss ich in eine Plattform – jetzt sage ich es schon wieder – oder einen Lebenszyklus gießen. Das ist es, was wir als Entwickler tun: Wir haben eine Idee, setzen diese um, indem wir etwas entwickeln, wir testen, kommunizieren viel, holen Feedback. Und am Ende gibt es ein Artefakt, das in eine Produktion deployt wird. Was wir [mit Platform Engineering] leisten, ist einfach eine Art Unterstützung. Wir helfen, Sichtbarkeit zu erlangen, Dinge zu sehen und zu verstehen, das Suchen und Finden für Entwickler noch einfacher zu machen – in der Regel braucht man einfach eine Such-Engine, die einem hilft, Dinge wiederzufinden. Wir bauen nichts Neues, sondern nehmen Komponenten, die seit 20 Jahren oder länger schon da sind – und geben ihnen ein neues Ansinnen.
MM: Es ist also weniger die Frage, womit als die Frage, wie man es macht. Hier sehe ich zwei Kernelemente: Standardisierung und Integration der Möglichkeiten. Oft hat man eine Build-Pipeline und einen Kommunikationskanal an anderer Stelle. Wenn man das miteinander sauber integrieren kann, ist das schon die halbe Miete. Wenn man dann noch klar macht, dass es das ist, was mit dem Label „Platform Engineering“ gemeint ist, hat man den Begriff schon entmystifiziert.
„Es geht um Adaption, nicht um Kopieren. Nur weil Spotify es so macht und Backstage nutzt, heißt es nicht, dass wir es auch so machen.“
Tool-Unterstützung
MP: Was wirklich wichtig ist, ist, dass man nicht einfach irgendein Tool kauft und installiert. Sondern es geht um viel mehr.
Trotz allem gibt es Tools, die unterstützen. Was sind sonst noch Tools, die man nutzen kann?
DK: Backstage ist eine Art Entwicklungsportal oder -Framework. Es kommt darauf an, was man braucht. Es gibt auch Humanitec, das so etwas wie Plattform-Orchestrierung bietet, eine zentrale Steuerungseinheit. So werden Dinge einfacher und greifbarer, weil wir nicht so viel über die darunter liegende Plattform wissen müssen, sondern einfach eine Art Konfigurationsmanagement machen. Bei Humanitec gibt es auch eine Beschreibungssprache, die sich Plaform-Agnostic Workload Specification nennt. Die beschreibt, wie ein Workload Plattform-agnostisch aussehen soll. Das heißt, ich kann mir in einer YAML-Datei den Workload beschreiben, den ich auf verschiedene Plattformen auslagern möchte. Jonas hat über Crossplane geschrieben, das auch in diese Richtung geht: Es bietet Möglichkeiten für verschiedene Cloud-Hersteller, bewegt sich also in Richtung Multi-Cloud, und kann Dinge dadurch vereinfachen. Es gibt, wie immer, einen Haufen Tools, und man muss sich für sich überlegen: Was will ich eigentlich erreichen bzw. was hilft mir im Moment? Aktuell brauchen die meisten eine Sichtbarkeit auf vorhandene Services und darauf, wie eigentlich entwickelt wird, was die eigenen Standards sind. Daraus ergeben sich im Laufe der Zeit weitere Tools, die ich brauche, um den Platform-Engineering-Begriff füllen zu können. Das Erste ist für die meisten Discovery. Das ist ein einfaches und lösbares Problem: Sichtbarkeit auf das, was ich habe und wo ich stehe.
MP: Vielen Dank, Daniel, dass du dir die Zeit genommen hast, mit uns das Thema Platform Engineering mit Leben zu füllen und den Leuten näher zu bringen!
Dieses Gespräch führten Max, Marco und Daniel im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter https://www.codecentric.de/softwerkercast.
Maximilian Mayer arbeitet als APM Consultant für die codecentric AG. Er hat viele Erfahrungen als Linux-Admin und im DevOps-Umfeld gesammelt. Neben Automatisierung interessiert er sich für Ruby-Entwicklung. Motorräder und alte Autos zählen zu seinen Leidenschaften.
Marco Paga entwickelt Software aus Leidenschaft. Gerne arbeitet er im Team an der Lösung komplexer Probleme. In der Vergangenheit hat er dabei erfolgreich Legacy-Applikationen modernisiert, um diese auf geänderte Herausforderungen vorzubereiten. Alle Beteiligten auf diesem Weg mitzunehmen und für neue Technologien zu begeistern – das ist für ihn selbstverständlich.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Daniel Kocot & Marco Paga & Maximilian Mayer
11.12.2024 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*innen
Daniel Kocot
Senior Solution Architect / Head of API Consulting
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Marco Paga
Senior Solution Architect
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.