This article is also available in English

Wenn Unternehmen den Weg in die Cloud gehen, haben sie oftmals eine klare Vorstellung von der gewünschten Infrastruktur und Software-Architektur. Dies beinhaltet üblicherweise:

Das Administratoren-Team ist üblicherweise für die Lieferung dieser Plattform verantwortlich, und das Endergebnis kann ähnlich wie hier aussehen.

Setup nach Cloud-Migration
Setup nach Cloud-Migration

Dies ist eine stark vereinfachte Darstellung. Weiterhin stehen wahrscheinlich Tools für das Monitoring, das Logging, die Dokumentation und die API-Spezifikation zur Verfügung. Andere Teams, wie etwa für die Qualitätssicherung, Sicherheit und Tests, sind ebenfalls beteiligt und bringen ihre eigenen Anforderungen und Wünsche mit ein.

Sobald die Plattform einsatzbereit ist und an die Entwicklungsteams übergeben wird, erwartet das Unternehmen, dass die Entwicklungsteams sich freudig auf die neuen Möglichkeiten und Verantwortlichkeiten stürzen und wie durch Zauberhand produktiver und agiler werden.

Warum akzeptieren Entwicklungsteams die neuen Möglichkeiten möglicherweise nicht?

In Wirklichkeit entwickelt sich die Akzeptanz der Software-Entwicklungsteams wahrscheinlich nur sehr langsam oder Teams zögern, die neue Methodik überhaupt anzunehmen. Träumen nicht alle davon, umfassende Verantwortung zu haben, mit coolen neuen Technologien wie Kubernetes und Container Runtimes zu arbeiten, und neue Architekturmuster wie Mikrodienste zu nutzen?

Es gibt wahrscheinlich mehrere Gründe, warum das nicht so ist.

Neue Verantwortlichkeiten sind beängstigend

Wenn ein Entwicklungsteam zuvor nur für die Entwicklung der Software verantwortlich war und ein anderes Team den Betrieb übernommen hat, kann es beängstigend sein, jetzt die Gesamtverantwortung für den Betrieb und die Sicherheit zu haben. Es reicht nicht länger aus, nur gut strukturierten und leicht zu pflegenden Code schreiben zu können – Teams müssen jetzt auch wissen, wie sich die Software verhält und wie sie die Betriebs- und Sicherheitsanforderungen erfüllt.

Die klassische Aufteilung zwischen der Softwareentwicklung und dem betrieblichen Bereich hat ihre Nachteile (vor allem die unvollständige und unzuverlässige Feedback-Schleife und verschiedene Ziele, die regelmäßig zu Konflikten führen), doch genau hier beginnen die meisten Teams und fühlen sich in ihrem jeweiligen Fachbereich wohl. Jetzt jedoch – mit mehr Verantwortung – besteht eine höhere Wahrscheinlichkeit, Fehler zu machen. Je nach Fehler- und Führungskultur kann dies zu einer allgemeinen Verweigerungshaltung führen.

Zu viele neue Tools und Paradigmen

Die Einführung von Container-Technologien und Kubernetes dient einem hehren Ziel: eine bessere Schnittstelle zu schaffen, um Software in Produktion zu bringen. Dies ist besser als eine schriftliche Anleitung, die missverstanden werden oder Fehler enthalten könnte. Entwickler sind es jedoch nicht gewohnt, betriebliche Aspekte ihrer Anwendungen in dieser Ausführlichkeit zu definieren. Hierbei geht es nicht nur darum, die Kubernetes-Terminologie zu lernen, sondern auch um:

Es wird erwartet, dass, mit Kubernetes und allen notwendigen Tools, die zur Verfügung stehen, Entwickler sich keine Gedanken mehr über betriebliche Aufgaben machen müssen und sich allein auf das Umsetzen neuer Fachlichkeit konzentrieren können, während die Plattform sich um alles andere kümmert. In der Praxis kann der Entwicklungsprozess in einer solchen Umgebung jedoch ganz anders aussehen, sodass sich beispielsweise ein Teil des Teams nur auf die Konfiguration und Optimierung der Tools konzentrieren muss. Je nach Größe und Anzahl der Teams kann dies zu einer Belastung werden, die Entwickler zu vermeiden versuchen.

Basierend auf der Cognitive Load Theory von John Sweller bedeutet dies auf die Softwareentwicklung übertragen, dass die Einführung neuer Technologien, Tools und Paradigmen die äußere Belastung erhöht und den Fokus von dem für das Team wichtigen Teil - der Komplexität der fachlichen Domäne und den zu lösenden Domänenproblemen - wegbewegt.

Falscher Teamfokus
Falscher Teamfokus

Erkennbarkeit und Verantwortung

In einer komplexen Umgebung, in der mehrere Teams an mehreren Diensten arbeiten, mangelt es den meisten Plattformen an Übersicht. Typische Fragen, die diesbezüglich auftreten und nicht beantwortet werden können, sind:

Diese Informationen finden sich in jeder Entwicklungsumgebung, sind aber weit verteilt. Einige Informationen befinden sich direkt auf der Plattform, während andere in Wikis, Dokumenten, Repositorys oder im schlimmsten Fall im Kopf einiger weniger Entwickler und Administratoren verteilt sind. Für die Entwicklungsteams ist es schwer, den Überblick zu behalten.

Tools lösen keine organisatorischen Prozesse

Nur weil Tools für ein kontinuierliches Deployment eingesetzt werden können, geschieht dies nicht automatisch. Bisher waren verschiedene Teams für spezifische Teile des Rollouts wie etwa dem Sicherstellen der Qualität, dem Release-Management oder der Sicherheitsprüfungen verantwortlich. Diese sind nicht durchgehend technische Teams, sondern mehr auf die Dokumentation und die auszuführenden Prozesse konzentriert. Für ein kontinuierliches Deployment müssen diese Schritte jedoch automatisiert werden. Da die nicht technischen Teams möglicherweise nicht in der Lage sind, diese Automatisierung zu leisten und sich zusätzlich unwohl dabei fühlen, Verantwortung abzugeben und nur auf den Code zu vertrauen, suchen sie vielleicht nach einer Möglichkeit, traditionelle Prozesse auf die neuen Paradigmen abzubilden, was zu ungenauen, prozessorientierten Forderungen an die Entwicklungsteams führt. Die früheren Anforderungen an Prozesse und die Dokumentation spiegeln sich jetzt in den Build- und Delivery-Pipelines wider. Entwicklungsteams haben das Gefühl, die neuen Tools nicht wie vorgesehen zu verwenden, sodass sie ihre Stärken ausspielen können, sondern sie zu nutzen, um die Prozesse, die schon immer Bestand haben, zu genügen. Es fühlt sich an, als würde man alten Wein in neuen Schläuchen verkaufen, dabei bleiben Motivation und Innovation auf der Strecke.

Ein Paradigmenwechsel wird nicht allein durch die korrekten Tools herbeigeführt.

Falscher Fokus für die Automatisierung

Eine Möglichkeit, das Nutzererlebnis für Entwickler zu verbessern, besteht darin, alles zu automatisieren und den Entwicklungsteams dies als Self-Services anzubieten. Diesen Self-Services fehlt jedoch meistens der ganzheitliche Blick auf den Entwicklungsprozess. Die Verantwortung der Teams beziehen sich oft auf klassische Disziplinen wie Sicherheit, Betrieb und Entwicklung, und können sich auf die Wahl und Einrichtung der jeweiligen Tools auswirken.

Disziplin-orientierte Dienste
Disziplin-orientierte Dienste

Geht man die Automatisierung von diesem Punkt aus an, kann dies zu einer sehr tool-orientierten Sicht führen. Jedes Team wird für seinen Teil Self-Services bereitstellen – wahrscheinlich auf unterschiedliche Weise. Ein Team automatisiert über ein Self-Service-Portal, das nächste über Tickets und ein anderes möglicherweise über Pull-Anfragen.

Entwicklungsteams haben eher den Bedarf an höherwertige Self-Services. Diese Self-Services müssen die folgenden Aspekte des gesamten Prozesses vereinfachen:

Bei zu klein geschnittenen Self-Services müssen sie verstehen, welche davon benötigt werden, um diese Aufgaben zu erfüllen. Das Entwicklungsteam muss also umfassende Kenntnisse aller Self-Services und ihrer Verbindungen miteinander besitzen. Dies vergrößert die kognitive Belastung, die ohnehin schon durch die neuen Tools zunimmt.

Self-Service und Automatisierung allein vereinfachen und verbessern nicht automatisch den Entwicklungsfluss, wenn sie nicht auf ein gemeinsames Ziel ausgerichtet sind.

Kubernetes ist nicht die beste Abstraktion für Entwickler

Kubernetes hatte einen enormen Einfluss auf unsere Vorstellung von dem Betrieb von Software ähnlich wie die Cloud. Es abstrahiert betriebliche Konzepte und bietet uns die Möglichkeit, sie deklarativ auszudrücken. Es bietet uns die Möglichkeit, alle Teile unserer Anwendung wie etwa Lastverteilung, die richtige Platzierung der Anwendung auf den Servern, Routing und Skalierung nach Belieben in Form von Ressourcen zu definieren. Wenn wir eine zustandsbehaftete Anwendung ausführen möchten, müssen wir eine StatefulSet-, Service-, PersistentVolumeClaim-, Ingress-Ressource und möglicherweise viele weitere Ressourcen erstellen. Wir können alles definieren, doch es mangelt an Fokus auf die Anwendung selbst und ist nicht vollständig entwicklerfreundlich. Darüber hinaus ist es fehleranfällig, wenn man nicht versteht, wie die Ressourcen miteinander interagieren und aufeinander aufbauen. Das ist für Entwicklungsteams, die sich einfach nur auf die Entwicklung neuer Fachlichkeit konzentrieren möchten, nicht überzeugend. Es kann anstrengend sein, selbst wenn es sich lohnt, sich umfassende Kenntnisse zu Kubernetes anzueignen.

An dieser Stelle möchten wir Dir gerne einen Tweet anzeigen. Um ihn zu sehen, musst Du dem Laden von Fremdinhalten von twitter.com zustimmen.

Kubernetes ist der Motor der Plattform und nicht die Plattform selbst. Sie dient daher dazu, eigene bessere Abstraktionen zu erstellen, damit Teams die Plattform leichter nutzen und sich darauf konzentrieren können, was von den Entwicklern gesteuert werden muss. Diese Idee wird in den meisten Plattformen vernachlässigt und es bleibt den Teams überlassen, herauszufinden, wie sie mit den neuen Möglichkeiten umgehen sollen.

Unausgewogenes Verhältnis zwischen der Menge an Entwicklern und der relativen Knappheit betrieblicher Experten

Der DevOps-Ansatz versucht, Entwicklungsteams und betriebliche Experten besser zusammenzubringen und im besten Fall die Zusammenarbeit als ein Team zu ermöglichen. Dies gilt auch beispielsweise für Test- und Qualitätssicherungs-Teams. Unternehmen versuchen dafür ein SRE Arbeitsmodell einzuführen, wie von Google beschrieben. Doch, wie wir uns immer wieder eingestehen müssen, sind wir nicht Google. Wir arbeiten selten in einer Umgebung, die so technik-fokussiert ist, wie Google. Meistens befinden wir uns in einer Organisation, die versucht, ihre internen Entwicklungsprozesse zu verbessern und über weniger betriebliche Experten als Mitarbeiter mit Entwicklungs-Fachkenntnissen verfügt. Der Versuch, einfach nur die Entwicklungs- und Betriebskonzepte von Google zu kopieren, ohne über dieselben organisatorischen Rahmenbedingungen zu verfügen, führt zu unzureichenden Ergebnissen und demotivierten Teams.

Platform Engineering als neuer Ansatz

Platform Engineering versucht einige dieser Lücken zu schließen, um Teams dabei zu helfen, unabhängiger zu werden. Platform Engineering versteht alle Prozesse und Tools als Unterstützung für Entwicklungsteams, um Erfolge zu erzielen. Das Ziel des Platform-Engineering-Teams ist, Hindernisse auszuräumen und die betrieblichen Bedürfnisse der Entwicklungsteams zu unterstützen. Es verbirgt Komplexität und interdisziplinäre Funktionen und Maßnahmen hinter einem allgemeinen Angebot für die Entwicklungsteams: der Plattform.

Plattform als Produkt
Plattform als Produkt

Es geht nicht nur um eine organisatorische Veränderung, sondern wir erwarten auch einige damit verbundene Vorteile.

Behandeln Sie Ihre Plattform wie ein Produkt

Wie Produkte für Endkunden muss auch die Plattform als Produkt für die Entwickler verstanden werden. Dies bedeutet, dass das Angebot eine Option ist und von den Entwicklungsteams ignoriert werden kann, wenn es ihre Bedürfnisse nicht erfüllt oder ihre Probleme nicht löst. Daher muss sie genau wie alle anderen Produkte, die in einem Markt konkurrieren, die Bedürfnisse ihrer Kunden verstehen und sie überzeugen. In Wirklichkeit gibt es selten eine zweite Option, aber es ist dennoch ein wesentlicher Einflussfaktor, sich auf die Bedürfnisse der Entwickler zu konzentrieren und nicht eine Plattform als Technikspielplatz zu verstehen, der rein die persönlichen Wünsche des Plattform-Teams erfüllt. Jede Aufgabe, jede Automatisierung und jede Verbesserung dient dazu, die Softwarelieferung besser, schneller, sicherer und stabiler zu machen.

Sie darüber hinaus als Produkt zu behandeln bedeutet außerdem, kontinuierlich an der Plattform zu arbeiten und sie zu verbessern. Sie ist ständig im Fluss, da es ständig neue Ideen und Aufgaben gibt, die sich in der Plattform widerspiegeln müssen, wie etwa neue Schwachstellen, neue Tools, neue Ansätze, neue Bugfixes etc.

Transparenz schaffen

Die Plattform muss Transparenz hinsichtlich ihrer Angebote, aber auch in Bezug auf die Verantwortlichkeit bestehender Software-Artefakte und ihre Abhängigkeiten bieten. Es muss einen zentralen Ort geben, an dem alle an den verschiedenen Orten verfügbaren Informationen gesammelt werden, um einen Überblick zu erhalten und eine Umgebung mit Hunderten von Diensten und Bibliotheken handhaben zu können.

Wir sprechen oft von einer Art Entwicklerportal als Haupteinstiegspunkt für jedes Entwicklungsteam.

Entwicklerportal
Entwicklerportal

Backstage ist ein mögliches Produkt, um einer Plattform diese Fähigkeit zu verleihen und wird aktuell zunehmend beliebter.

Höherwertige Self-Services

Self-Services sollten Entwicklungsbedürfnisse erfüllen und nicht rein tool-orientiert sein. Self-Services sind daher nicht:

Diese Schritte müssen zwar automatisiert werden, sollen aber gebündelt den Entwicklungsteams angeboten werden und sich auf den Entwicklungsprozess als Ganzes fokussieren:

Sie müssen die tägliche Arbeit der Entwicklungsteams verbessern. Das Plattform-Team muss die Balance zwischen der Abstraktion und der Flexibilität der Tool-Bereitstellung finden, ohne das, was im Hintergrund passiert, aus den Augen zu verlieren.

Die Plattform muss die 90 % der üblichen gewünschten Funktionen vereinfachen, um die Akzeptanz zu verbessern und die Abneigung des Teams zu mindern, darf hierbei jedoch nicht ein mögliches Abweichen vom goldenen Mittelweg verhindern.

Automatisieren und Shift-Left-Ansatz

In jeder Organisation herrscht eine direkte oder indirekte Vorstellung davon, wann eine Software bereit für die Produktionsumgebung ist. Dies spiegelt sich in Qualitäts-Meilensteinen, Prozessen oder manuellen Prüfungen wider. Diese Bedingungen liegen möglicherweise in unterschiedlichen Bereichen wie etwa:

Diese Aufgaben werden üblicherweise komplett manuell oder zumindest mit manuellen Interaktionen ausgeführt und sind Teil des Release-Prozesses, dem es an schnellem Feedback mangeln kann. Es kann beispielweise passieren, dass die Implementierung in der allerletzten Phase vor dem Einsatz nicht alle betrieblichen Bedingungen erfüllt, was den Prozess langsamer und komplizierter macht.

Die Plattform muss bei der Bereitstellung von Tools immer die Idee des kontinuierlichen Deployments im Blick haben. Sie muss daher den gesamten Prozess automatisieren, aber den Entwicklungsteams gleichzeitig schnelles und frühzeitiges Feedback liefern, d.h. so weit wie möglich den Shift-Left-Ansatz verfolgen und nicht bis zum letzten Moment warten, um mitzuteilen, dass ein Qualitätsmeilenstein möglicherweise nicht erfüllt wird.

Auch wenn andere Bedingungen und Vorschriften ein echtes kontinuierliches Deployment in die Produktionsumgebung verbieten, muss das Konzept der Entwicklungs- und Plattform-Teams dies zumindest technisch ermöglichen.

Löst das all unsere Probleme?

Platform Engineering ist – wie jeder andere Ansatz auch – kein Allheilmittel. Die einfache Einführung neuer Prozesse, Ideen und Tools sind nicht ausreichend, wenn die Organisation Veränderungen implizit ablehnt und alte Strukturen beibehalten möchte. Platform Engineering kann isoliertes Silodenken offenlegen, indem es Reibungspunkte zwischen den Teamzielen sichtbar macht, löst jedoch diese Probleme nicht automatisch. Die Bereitschaft, Änderungen anzunehmen und kontinuierliche Verbesserung als organisatorisches Konzept zu unterstützen, ist äußerst wichtig. Platform Engineering birgt die Gefahr, dass am Ende nur alten Prozessen und Strukturen ein neuer Name gegeben und der Organisation ein moderner Anstrich verpasst wird, wie bei den vielen Unternehmen, die jetzt von sich behaupten, agil zu sein, ohne einen passenden organisatorischen Rahmen zu schaffen. Platform Engineering kann letzten Endes der gleiche negative Beiklang drohen wie jedem anderen Bemühen, das Teams dabei unterstützt, autonomer und effektiver zu werden - das es nur zusätzliche Komplexität mit sich bringt, ohne bestehende Probleme zu lösen.

TAGS