Internal Developer Platforms: Erkenntnisse aus dem Panel der DEVOPS CONFERENCE 2023

Im April 2023 waren unter anderem Kelsey Hightower, Nicole Forsgren, Helen Baal und Dom Price als Speaker dabei.

Die DEVOPS Conference ist jedoch nicht nur ein Ort für Vorträge. Sie ist auch eine Community für den Wissensaustausch. Ein wichtiger Teil der Veranstaltung war der interaktive Track mit Kamingesprächen, offenen Diskussionen und Live-Demos.

Ich hatte das Privileg, eine Podiumsdiskussion über DevOps und Platform Engineering zu moderieren. Wie unterstützt der Aufbau von Internal Developer Platforms (IDPs) DevOps? Welche Vorteile und Herausforderungen bringt ihre Einführung mit sich? Wie wirken sie sich auf Kultur und Arbeitsweisen aus? Diese zentralen Fragen diskutierten die Panelteilnehmer:

Bjørn Hald Sørensen (Head of Technology bei Lunar)

Tuomas Leppilampi (DevOps Consultant bei Eficode)

Dan Grøndahl Glavind (DevOps Consultant bei Eficode)

Die Teilnehmer beteiligten sich aktiv an den Fragerunden. Außerdem führten wir eine Umfrage durch, um mehr über ihren Hintergrund zu erfahren: Mehr als 50 % des Publikums kannten IDPs nicht, rund 30 % hatten zumindest bereits damit begonnen, daran zu arbeiten, während die übrigen den Aufbau einer IDP in Erwägung zogen.

Hier ist eine Zusammenfassung der Podiumsdiskussion, gegliedert nach den wichtigsten Themen, die sich herauskristallisiert haben.

Podiumsdiskussion über DevOps und Platform Engineering

Brauchen wir IDPs wirklich?

Mario: Warum werden diese Internal Developer Platforms überhaupt benötigt? Oder folgen wir damit nur einem Trend, so wie vor einigen Jahren bei Kubernetes? Was denkt ihr?

Bjorn: Ich denke, es geht vor allem um die Herausforderungen und die Entwicklung unserer Softwareentwicklung. IDPs und Plattformen im Allgemeinen entwickeln sich weiter. Sie entstehen auch durch die gesamte kognitive Belastung, die wir Entwicklern auferlegen.

Wie können wir uns so organisieren, dass wir effizienter arbeiten? Ich denke, Platform Engineering ist definitiv einer der Ansätze, die Entwicklern derzeit echten Mehrwert bieten können.

Tuomas: Ich denke, es ist ein großer Wettbewerbsvorteil, wenn ihr euren Entwicklern sagen könnt: „Ihr könnt euch tatsächlich auf das Programmieren und das Lösen von Problemen konzentrieren – auf das, was ihr liebt –, statt euch beispielsweise mit Jenkins zu beschäftigen.“

Dan: Mit DevOps hatten wir die Denkweise: „You build it, you run it.“ Aber was bedeutet das eigentlich? Ging es um den gesamten Stack – von unseren Anwendungen bis hin zur Bare-Metal-Infrastruktur? Genau hier entsteht die Komplexität. Und Platform Engineering verspricht gewissermaßen: „Okay, wir müssen nicht all diese tiefgreifende Komplexität kennen.“

Technische und kulturelle Aspekte

Mario: Wenn man sich die Blogbeiträge und Materialien zu IDPs ansieht, habe ich das Gefühl, dass vor allem der technische Aspekt im Vordergrund steht. Geht es dabei aber nicht eigentlich stärker um Developer Experience? Wie seht ihr dieses Potenzial – die technische Seite und Developer Experience? Ist das etwas Spezifisches für IDPs, oder was ist hier der wichtigste Aspekt?

Tuomas: Aus Sicht des Nutzens bedeutet Developer Experience, gute Entwickler zu halten. Ihr bindet die Mitarbeiter ans Unternehmen, und das ist ein sehr wichtiger Teil des Trends rund um Platform Engineering.

Aus meiner Sicht geht es im Kern um DevOps. Es geht um die Art von DevOps und Agilität, die wir als Kultur erreichen wollen. Platform Engineering und Internal Developer Platforms sind nur ein Weg, diese Kultur zu schaffen und aufrechtzuerhalten.

Bjorn: Wenn wir über die Jahre hinweg von vielen Menschen erwarten, mehr zu wissen – etwa in autonomen Teams –, werden viele ausbrennen, wenn sie alles kennen sollen, was in komplexen verteilten Systemen schiefgehen kann. Das ist nicht der Zweck. Das bringt unseren Entwicklern keine Freude. Und es motiviert sie nicht, geschäftlichen Mehrwert zu schaffen.

Für mich ist eine IDP nicht einfach nur eine einzelne Sache. Sie ist keine Plattform und kein technisches Produkt, das man aus dem Regal nimmt und bereitstellt. Sie ist vielmehr eine ganzheitliche Sicht auf alles, was unsere Entwickler dabei unterstützt, die Aufgaben zu erledigen, die sie erledigen müssen.

Dan: Ich denke, es ist ein mentales Modell, um einige der Fähigkeiten anzugehen, die wir sowohl für uns selbst als auch für andere Entwickler verbessern wollen. Es ist etwas Ganzheitlicheres. Es geht darum, wie wir Fähigkeiten und Kompetenzen schaffen können, damit Menschen sowohl zufrieden als auch produktiv sind.

Aufwand und Faustregel

Mario: Eine IDP kann also viel Mehrwert bieten. Aber wenn sie alles bereitstellt, wird sie dann nicht schwer zu warten und zu verwalten? Und eine damit verbundene Frage: Gibt es eine Art Faustregel, wie viele Entwickler ein Unternehmen normalerweise haben sollte, damit sich der Aufbau einer IDP rechtfertigt?

Tuomas: Sie kann einfach aus einer Reihe von Dokumenten oder Anleitungen zu Best Practices bestehen. Es spielt also keine Rolle, ob ihr fünf oder zwei Entwickler habt. Sie schafft die mentale Vorstellung einer Plattform, auf der ihr steht, wenn ihr etwas Neues entwickelt – etwa ein Feature, eine Anwendung oder einen Service. Sobald ihr das habt, können andere leichter dazukommen.

Dan: Das war auch ungefähr meine Frage. Inwieweit werden Entwickler bei den Funktionen für Build-Ausgaben, den CI/CD-Tools, vielleicht bei der Sicherheit der Software Supply Chain und solchen Themen unterstützt? Und wie sieht der Wandel bei den Deployment-Strategien aus, über die wir sprechen?

Und was lässt sich in Bezug auf Observability, Monitoring und ähnliche Themen abdecken? Vielleicht ist es möglich, all diese Bereiche auf einmal abzudecken. Und wenn ihr das so seht, entwickelt ihr euch vielleicht hin zu mehreren Plattformteams, die an einer Plattform zusammenarbeiten.

Bjorn: Was wir anfangs gemacht haben, war genau das, was du gesagt hast: Anleitungen dazu, wie man Dinge umsetzt, einen neuen Service aufsetzt und effizient mit Software arbeitet – nicht nur bei den Grundlagen beginnen. Darauf haben wir dann nach und nach aufgebaut. Irgendwann sind wir darüber hinausgewachsen. Ähnlich wie bei DevOps: Es ging über die einzelnen Teams hinaus, um einen guten Weg für die Umsetzung zu finden.

Also haben wir zwei weitere Kernteams geschaffen, die genauer darüber nachdenken sollten, wie wir diese Workflows optimieren können, was wir automatisieren können und wie wir Entwickler in ihrer täglichen Arbeit unterstützen können. Das hat sich über die Jahre zu dem entwickelt, was wir heute haben: drei Plattformteams, die die Lunar Development Platform bereitstellen. Dabei bedienen wir unterschiedliche Nutzergruppen.

Ihr baut also klein angefangen auf, denn den Mehrwert, den ihr liefern könnt, lässt sich leichter definieren, wenn ihr ein Problem habt und sagen könnt: „Wir wollen, dass ein Team dieses Problem löst, und wir verstehen, wie groß das Problem ist.“ Das ist der Mehrwert. Dann müssen wir darüber nachdenken, daraus eine Plattform zu machen. Denn wir können dieses kleine Tool entwickeln und noch ein weiteres, aber mit der Zeit müssen wir das Ganze auch ganzheitlich betrachten. So verstehen Entwickler, wo sie Informationen finden.

Bei Lunar liegt unser Verhältnis bei eins zu zehn: Auf einen Platform Engineer kommen etwa zehn Entwickler, wenn man es so herunterbrechen will. Bei anderen Unternehmen sehen die Verhältnisse anders aus. Das hängt davon ab, wie gut eure Infrastruktur und eure Entwicklungsumgebungen aufeinander abgestimmt sind – und auch von eurer Technologiehistorie.

Kognitive Belastung

Mario: Wie viel kognitive Belastung ist für einen Entwickler in Ordnung? Ein Aspekt ist, einen zentralen Ort zu haben, an dem Entwickler ihre eigentliche Arbeit erledigen können. Aber löst das die gesamte kognitive Belastung? Oder geht es auch um Automatisierung? Wie greifen diese beiden Dinge ineinander?

Tuomas: Ich denke, das ist sehr individuell – vom Junior-Entwickler, der Dinge neu architekturiert und refaktoriert, bis zu den sogenannten „UNIX-Leuten“, die hochspezialisierte Arbeit leisten. Es hängt stark davon ab, wo eure Leidenschaft liegt. Es geht darum: Was für ein Entwickler seid ihr?

Bjorn: Ich denke, es ist individuell. Definitiv. Die typische Antwort lautet: „Es kommt darauf an.“ Aber ihr müsst mit euren Entwicklern sprechen. Fragt sie einfach: „Wo liegen eure Pain Points? Wo habt ihr das Gefühl, Zeit zu verschwenden? Bei welchen Aufgaben sinkt euer Engagement, weil ihr einfach nicht gerne damit arbeitet?“ Genau dort verläuft die Grenze der kognitiven Belastung.

Das ist wie bei der 80-Prozent-Regel: Wenn ihr Funktionen bereitstellt, die 80 % der Technologie abdecken, etwa den organisatorischen Teil, dann investieren wir unsere Zeit vielleicht nicht richtig.

Wenn ihr die kognitive Belastung nur für ein Team reduziert, es aber für alle tun könnt, weil es wichtigere Themen gibt, solltet ihr immer an den Dingen arbeiten, die allen helfen. Auch dabei geht es wieder darum herauszufinden, wie viel Belastung ihr dem Team zumuten könnt.

Dan: In der Theorie der kognitiven Belastung gibt es verschiedene Arten von Belastung. Da ist die intrinsische kognitive Belastung, bei der die Aufgabe selbst von Natur aus komplex ist. Vermeiden wollen wir aber die extrinsische kognitive Belastung: Dinge, die euch einfach zusätzlich aufgebürdet werden und die euch überhaupt nicht interessieren, etwa monotone Arbeit.

Ich denke, eine mögliche Antwort ist: Wenn ihr ständig das Rad neu erfindet und glaubt, dass jemand das zum Vorteil aller lösen könnte, dann kann das ein Zeichen dafür sein, darüber nachzudenken, ob es sinnvoll ist, mehr Teams zu unterstützen. Es gibt aber keine feste Zahl dafür, ab wann es sich lohnt, in ein Team zu investieren, das gemeinsame Probleme löst.

Platform Engineering und DevOps

Mario: Wie hängt diese Plattform-Initiative mit DevOps zusammen? Wie viele Teams sollte es geben? Oder provokanter formuliert: Ich würde sogar sagen, dass ein Plattformteam ein Anti-DevOps-Muster ist.

Tuomas: Es gibt gewissermaßen drei unterschiedliche Bereiche. Erstens die Entwickler, die das betreiben, was sie entwickeln. Sie brauchen also gute Observability, die Möglichkeit für Rollbacks und Kontrolle über die für sie relevanten Betriebsbereiche. Dann gibt es Plattformteams, die die Plattform entwickeln, Konfigurationen festlegen, den Entwicklern zuhören und auch dem dritten Bereich, der meiner Meinung nach Managed Services sein sollte.

Dann haben wir das Plattformteam, das sich darauf konzentriert, den Entwicklern zuzuhören und das Beste aus der Konfiguration herauszuholen. Gleichzeitig haben die Entwickler weiterhin ausreichend Zugriff auf Betrieb, Runtime und alles andere, damit sie das betreiben können, was sie entwickelt haben.

Bjorn: Genau hier kommt Platform Engineering ins Spiel. Ihr wollt sicherstellen, dass ihr euren Entwicklern keine Verantwortung wegnehmt – ihr wollt sie befähigen.

Der wesentliche Unterschied zwischen der Zeit vor DevOps und heute mit Platform Engineering liegt in der Denkweise: überzeugende interne Produkte zu schaffen und zu verstehen, dass wir da sind, um Entwickler zu unterstützen.

Dan: Wenn ihr das Buch Team Topologies heranzieht – ein wirklich großartiges Buch, falls ihr es noch nicht gelesen habt –, geht es darin um Interaktionen zwischen Teams. Ein Plattformteam sollte die Plattform als Service oder Produkt bereitstellen. Der interessanteste Teil ist jedoch die Zusammenarbeit. Wie finden wir heraus, was wir jetzt und als Nächstes tun sollten?

Die Rolle eines Developer Portals

Mario: Wir haben darüber gesprochen, dass IDPs oder Plattformen einen zentralen Einstiegspunkt bieten, über den Entwickler den Großteil ihrer Aufgaben im Softwareentwicklungszyklus erledigen können. Einer davon ist das Developer Portal. Und wenn wir uns im Kontext von IDPs umsehen, stoßen wir de facto auf Backstage. Ist Backstage also die Lösung für alles, was die Nutzung einer Plattform durch verschiedene Stakeholder betrifft? Wie seht ihr das?

Bjorn: Wir hatten intern Gespräche darüber, dass wir einen Ort brauchen, an den die Leute gehen können und der ihnen einen zentralen Überblick bietet – einen Einstiegspunkt zu allen anderen Informationen. Deshalb haben wir früh entschieden, Backstage einzusetzen, damit es wirklich zu dieser zentralen Informationsquelle wird. Das heißt aber nicht, dass es der Kern der Plattform ist. Es ist eher der Einstiegspunkt.

Backstage hilft uns also, einen Ort zu schaffen, an dem wir mit einer Suche in Backstage beginnen können. Wenn ihr dort keine Antwort findet, geht ihr zu Slack und stellt eure Frage dem Team. Aber rund um eine Plattform gibt es viele Dinge, die nicht Backstage sind, etwa CLI-Tools. All das ist weiterhin verteilt, aber Informationen dazu findet ihr trotzdem in Backstage.

Tuomas: Ich denke, Backstage ist ein guter Einstieg, um einen zentralen Überblick zu schaffen. Mit der Zeit stellt ihr aber vielleicht fest, dass euer Kern eher die Continuous-Delivery-Plattform ist, über die alle sehen können, wie wir Mehrwert für den Kunden liefern. Das kann dann zum Kern werden – während ihr anfangs vielleicht dachtet, dass ihr mit Templates beginnt.

Dan: Als ich mich erstmals mit Backstage beschäftigt habe, war ich sofort begeistert, weil es offenbar viele Probleme rund um Softwarekataloge und Verantwortlichkeiten löst. Außerdem bietet es eine Art Systemmodell, was ich großartig finde. Und natürlich gibt es auch die Templates, Plugins und so weiter.

Bjorn: Uns war klar, dass Entwickler vor allem beim Erstellen neuer Services Probleme haben. Wir hatten dieses Dokument in Confluence: Wenn du diese Bereiche brauchst, klicke diese Kästchen an, achte darauf, diesen Namen richtig zu setzen, und so weiter. Wir waren sicher, dass dies die eine Sache sein würde, die alle Entwickler lieben.

Wir haben in Slack gefragt: „Was sollen wir zuerst entwickeln?“ Und es stellte sich heraus, dass der Softwarekatalog die meisten positiven Bewertungen erhielt. Er lag weit vor dem zweitplatzierten Thema. Denn viele Entwickler wollen vor allem Verantwortlichkeiten klären: Was haben wir? Und wen kann ich fragen? Genau das wollten wir mit etwas Einfachem ermöglichen.

Den Nutzen der Plattform messen

Mario: Wenn die Plattform genutzt wird und nachhaltig ist, stellt sich die nächste Frage: Wie verbindet ihr die Ergebnisse von Platform Engineering mit den Geschäftsergebnissen? Reicht das aus oder lassen sich dafür Kennzahlen definieren? Sind die DORA-Metriken in diesem Kontext ebenfalls hilfreich? Und wie könnt ihr sagen, ob diese Plattforminitiative geschäftlichen Mehrwert gebracht hat oder nicht?

Dan: Wenn wir als Plattformteam daran gemessen werden, wie wir andere Teams unterstützen, dann sind Kennzahlen wie Durchsatz, Stabilität und Zuverlässigkeit für uns wirklich wichtig. Vielleicht sollten wir uns auch darauf konzentrieren, wie wir diese mit den Anwendungen verknüpfen können, die unsere Entwickler ihren Nutzern zur Verfügung stellen.

Leistungsfähigkeit, Kommunikation und Zusammenarbeit sowie die Effizienz des Flows. Einige Aspekte der Effizienz werden vielleicht durch DORA abgedeckt. Aber es geht um mehr als nur messbare Mengen. Es gibt auch qualitative oder wahrgenommene Faktoren.

Bjorn: Der geschäftliche Mehrwert einer Plattform sollte sich idealerweise aus den Problemen ableiten, die sie lösen muss. Ich denke, es ist schwierig, KPIs zu finden, die monatlich bestätigen, ob es weiterhin sinnvoll ist, ein Plattformteam zu haben.

Tuomas: DORA-Metriken sind eine Möglichkeit. In der Praxis habe ich sie allerdings nicht besonders häufig gesehen. Und ich denke, die fünfte Kennzahl, die berücksichtigt wurde, ist Zuverlässigkeit. Sie hängt gewissermaßen mit dem Verhalten zusammen, das Nutzer erleben: SLIs, SLOs und der Runtime-Aspekt – die Experience und Funktionalität der Runtime.

Ist Platform Engineering für alle geeignet?

Mario: Gartner sagt inzwischen, dass IDPs notwendig sind, um DevOps-Initiativen zu skalieren. Wie seht ihr also Platform Engineering im Kontext des DevOps-Reifegradmodells? Ist das nur etwas für Spitzenreiter, oder sollte es für alle Unternehmen relevant sein? Und wie wird es in, sagen wir, fünf Jahren aussehen? Wird es dann noch eine Plattform geben? Oder etwas anderes? Wird es DevOps noch geben oder nicht?

Tuomas: Ich denke, für die Skalierung ist es absolut entscheidend, dass wir einige Dinge abstrahieren können. Dann können wir uns wirklich auf die Geschäftsergebnisse konzentrieren. Wie verändern wir tatsächlich das Leben der Endnutzer?

Ich habe das Glück, in einem Büro mit vielen Designern zu arbeiten. Wir essen zusammen zu Mittag und trinken gemeinsam Kaffee. Dabei habe ich viel über Design Thinking und Service-Design-Methoden gelernt, die mir sehr dabei geholfen haben, Probleme aufzudecken, die ein Unternehmen oder eine Organisation haben könnte.

Bjorn: Ich denke, es wird auf jeden Fall etwas geben, denn die zugrunde liegenden Probleme werden nicht verschwinden. Sie könnten sich aber als andere Abstraktionen herausstellen.

Wir werden uns weiterhin das nächste große Problem ansehen, das es zu lösen gilt – nicht die nächste Lösung und nicht den nächsten Trend. Dann können wir uns den Lösungsraum anschauen: „Was gibt es hier, das uns helfen kann, dieses Problem zu lösen? Ist es ein Plattformteam? Ist es stattdessen ein Produktdenken oder ein Tool? Ist es etwas anderes?“ Aber wir müssen zunächst das nächste Problem identifizieren.

Dan: Wie viel Zeit verbringt ihr damit, herauszufinden, worin eure Probleme bestehen? Und wie arbeitet ihr tatsächlich zusammen, um diese Probleme in greifbare Lösungen zu verwandeln? Das ist für mich der interessante Teil.

Zusammenfassung

Die Diskussion im Panel war sehr interessant und brachte viele unterschiedliche Themen rund um DevOps und Platform Engineering auf. Deutlich wurde: Eine Plattform besteht nicht nur aus Technologie, sondern ist auch ein Ansatz, Entwickler zu unterstützen und Prozesse effizienter zu gestalten.

Platform Engineering sollte konkrete Ziele verfolgen, den Fokus auf Developer Experience legen und eine Kultur der Zusammenarbeit zwischen Teams fördern.

Jedes Unternehmen ist anders. Daher sollten Maßnahmen im Platform Engineering auf konkrete Herausforderungen ausgerichtet sein und kontinuierliches Feedback von verschiedenen Stakeholdern einholen – nicht nur von Entwicklern, sondern auch von Produkt- und Business-Verantwortlichen.