Bruce Lee über DevOps: Meistert eure Tools, liefert bessere Software

Insgesamt kann der Kampfkünstler die notwendige Basisarbeit und die erforderliche Präzision aus den Augen verlieren. Mehr verschiedene Tritte zu trainieren, bringt nichts, solange ihr die Tritte, die ihr bereits kennt, nicht auf ein Niveau gebracht habt, auf dem sie wirklich nützlich sind.

Neue Dinge zu trainieren, statt bestehende Fähigkeiten zu perfektionieren, bedeutet, dass der Kampfkünstler seine wertvolle Trainingszeit verschwendet. Vielleicht wäre es für ihn sogar besser, die Zeit für eine völlig andere Sportart zu nutzen, statt sich von seinem Hauptziel ablenken zu lassen: besser in den Kampfkünsten zu werden.

Davon nehme ich mich nicht aus. „Habt ihr das Wu-Dang-Schwert der Acht Unsterblichen, ,Ba Xian Jian‘, gesehen? Das muss ich unbedingt lernen!“ Wenn mir solche Gedanken kommen, brauche ich einen Freund in der Nähe, der mich an Bruce Lee erinnert.

Das Äquivalent zu 10.000 Tritten in Tech-Unternehmen

In den meisten modernen DevOps - und Engineering-Teams werden neue Tools zu schnell und ohne ausreichende Überlegung eingeführt – oft zulasten des kundenorientierten Produkts. Zeit und Ressourcen sind begrenzt, und sie für die falschen Themen einzusetzen, wirkt sich direkt auf die Produktqualität aus.

Ein konkretes Beispiel ist ein Team, das einige wenige, sehr kleine Services auf VMs betrieb. Dabei handelte es sich um kleine Python-Skripte in Docker-Containern auf einem stabilen Ubuntu-System. Wartung und Updates konnten buchstäblich von jedem mit grundlegenden Kenntnissen in Ubuntu und Python schnell durchgeführt werden.

Eines Tages beschloss das Team, diese Services in die Cloud auf Kubernetes zu migrieren – einfach, weil Kubernetes großartig ist. Dafür wurden zusätzliche Automatisierungsebenen mit Tools eingeführt, die im Team nicht weit verbreitet waren. Um die Möglichkeiten von Kubernetes auszuschöpfen, wurden die VMs durch ein Virtual Scale Set und redundanten Netzwerkspeicher ersetzt, wodurch Azure deutlich stärker in die Toolchain des Teams aufgenommen wurde. Um die Services und Kubernetes optimal zu überwachen, wurde außerdem das Standard-Monitoring-Backend ersetzt. Dadurch kam eine weitere Datenbank hinzu, die dem Team zuvor unbekannt war. 

Ab diesem Punkt erforderte das Lösen eines Problems mit den kleinen Services im Vergleich zur vorherigen Version so viel zusätzliches Wissen, dass faktisch eine Wissensinsel entstanden war: Die meisten im Team hatten schlicht keine Zeit, aufzuholen. Die Weiterentwicklung wurde verlangsamt, und die Fehlersuche wurde zu einem ernsten Thema, das Stunden oder Tage dauern konnte. 

All das ohne erkennbaren Nutzen für das Produkt und mit einem deutlichen Rückgang der Produktivität. 

Ein weiteres sehr typisches Muster betrifft Jenkins: Stellt euch ein Unternehmen vor, das das allseits beliebte Jenkins in einer typischen, veralteten Installation nutzt. Das Team beschließt, zu GitHub zu wechseln, findet aber wegen der komplexen alten Pipelines nie die Zeit, sie alle zu migrieren. Nun sind also zwei Pipeline-Systeme im Einsatz. Irgendwann wechseln einige andere Teams von GitHub zu Azure DevOps, und das ermutigt das Hipster-Team, für seine eigene Lösung zu argumentieren: Niemand hat je davon gehört, aber sie soll angeblich alle Probleme lösen, weil sie neu, klein und schick ist.

An diesem Punkt ist Jenkins immer noch ein Problem, das genau den gleichen Einsatz erfordert. Zusätzlich haben die Teams Wissensinseln und Barrieren geschaffen.

Sollten wir also alle wieder zu Perl zurückkehren?

Wir könnten Hunderte Seiten mit Beispielen füllen, und sie würden euch alle bekannt vorkommen. 

Neue Programmiersprachen in den Stack aufnehmen, neue Monitoring-Tools hinzufügen, neue Cloud-Anbieter ergänzen, neue Automatisierungstools einführen, von einem Tech-Stack zu einem anderen migrieren, weil der neue bessere Ergebnisse verspricht, obwohl ihr es eigentlich nicht wisst. Die Liste ist lang.

Ich plädiere nicht dafür, nur Perl auf Unix zu nutzen, nur weil diese Kombination alle Aufgaben erledigt. Das wäre zu extrem. Doch in vielen Fällen bringt die Erweiterung des Tech-Stacks oder die Migration zu einem neuen Stack nicht die gewünschten Ergebnisse oder hat unerwünschte Nebenwirkungen. Und ihr müsst zugeben: Diese Perl/Unix-Experten der alten Schule kennen wirklich jeden noch so kleinen Winkel ihrer Umgebung – etwas, das kaum jemand sonst von sich behaupten kann.

Ich habe in mehreren Unternehmen gearbeitet, in denen der Tech-Stack aus verschiedenen Gründen sehr begrenzt war. Das führte dazu, dass die Mitarbeiter teamübergreifend den Code, die Infrastruktur und das Produkt verstanden. Das waren die einzigen wirklich agilen Unternehmen, die ich je erlebt habe. 

Als Consultant ist einer meiner Lackmustests für den Reifegrad einer Organisation, darauf zu schauen, wie viele Tools sie im Einsatz hat. Nutzen sie eine kleine Auswahl an Tools so, dass sie den größtmöglichen Mehrwert daraus ziehen? Oder herrscht bei ihnen eine ausufernde Tool-Anarchie? Natürlich liegt die Antwort auf einem Spektrum. Im echten Leben gibt es kein Schwarz und Weiß. 

Warum keine neuen Tools hinzufügen?

Eine kurze Liste von Dingen, die sich durch eine neue Ergänzung des Stacks verschlechtern können, umfasst Komplexität, Produktivität, Wartbarkeit, Teamfokus und Wissensaustausch. 

Komplexität: Der stille Killer des modernen Engineerings

Komplexität untergräbt die Produktivität schneller als schlechter Code. Es ist gefährlich einfach, eure DevOps-Toolchain so weit anwachsen zu lassen, dass sie niemand mehr vollständig versteht. Ein neues Tool verursacht keine versteckten Kosten von null. Zusätzliche Anforderungen an die Infrastruktur, neue Arten von Datenbanken, neue Build-Systeme, neue Package Manager, Wissensaufbau, das Ablösen alter Tools, Datenmigration – all das und mehr sind versteckte Kosten zusätzlich zum neuen Tool selbst. 

Jemand sagte einmal, dass das Reduzieren von Komplexität die wichtigste Aufgabe jedes Senior Engineers sei – und das stimmt absolut. Die meisten modernen Unternehmen haben den Kampf gegen die Komplexität verloren und sie nicht mehr unter Kontrolle. Das macht sie langsam, verringert die Stabilität, die Fehlersuche dauert zu lange, und jede Entwicklung ist teuer. Ihre Lösung besteht meist darin, noch ein paar weitere Komplexitätsebenen hinzuzufügen. Dabei sollten sie die Komplexität reduzieren.

Produktivität: Die versteckten Kosten der Einführung eines neuen Tools

Die Einführung eines neuen Tools hat offensichtliche Kosten: Sie braucht Zeit.

Zusätzlich entstehen versteckte Kosten durch eine höhere kognitive Belastung, denn die zunehmende Komplexität zwingt Entwickler dazu, ihre Aufmerksamkeit aufzuteilen. Die Wartungskosten verdoppeln sich, die Zeit zum Lesen der Dokumentation verdoppelt sich, und Entwickler müssen sich merken, wann welches Tool verwendet wird und wo welche Daten gespeichert sind. Das sind Kleinigkeiten, die sich jedoch summieren.

Betrachten wir den typischen Fall eines Unternehmens mit mehreren Wissensdatenbanken. Jedes Mal, wenn Wissen nicht gefunden wird, weil im falschen Tool gesucht wurde, geht Produktivität direkt verloren. Außerdem besteht das Risiko, dass das Falsche umgesetzt wird.

Die Produktivität kann regelrecht zum Erliegen kommen, wenn die Komplexität des Systems zu groß wird.

Wartbarkeit: Wenn niemand dafür verantwortlich ist, geht es kaputt.

Jemand muss das Tool warten. Das kann ein internes Team sein, oder euer Unternehmen lagert diese Aufgabe an ein anderes Unternehmen aus. In beiden Fällen entstehen jedoch direkte Kosten in Form von Zeit und Geld für die Wartung des neuen Tools – und diese Kosten verschwinden nicht so schnell. Selbst bei SaaS-Lösungen ist die Möglichkeit, sie bei Bedarf abzuschalten, rein theoretisch, sobald sie in den Entwicklungs-Workflow integriert sind.

IT Ops hat einen schlechten Ruf, weil sie die Wartungskosten sichtbar machen und klar die Ressourcen einfordern, die sie für jedes zu wartende System benötigen. Dabei ist genau das gut! Wenn niemand das Tool vollständig versteht und dadurch Wartung, regelmäßige Administrationsaufgaben oder Updates übernehmen kann, ist es nur eine Frage der Zeit, bis das glänzende neue Tool zu einem großen Problem wird. Selbst wenn jemand es vollständig versteht, muss diese Person auch Zeit für das Tool aufwenden dürfen.

Der häufige Fall, dass ein begeisterter Fürsprecher eines Produkts die Einführung eines Tools vorantreibt und es anschließend allein wartet, wird schlecht enden, sobald diese Person das Unternehmen verlässt oder in ein neues Team wechselt. Wenn euch jemand sagt, dass er ein neues Tool nebenbei warten kann, ist das ein klares Warnsignal dafür, dass in Zukunft etwas schiefgehen wird.

Teamfokus: Einfachheit hält Teams auf Kurs.

Ein Build-System oder ein Monitoring-System zu haben bedeutet beispielsweise, dass es immer im Fokus steht. Probleme oder Updates werden erkannt und angegangen, wenn sie auftreten. Sobald es mehrere solcher Systeme gibt, finden Entwickler und Management Wege, die unpopuläre Arbeit des Behebens von Problemen zu umgehen und stattdessen die lohnendere Aufgabe zu übernehmen, Features im anderen Tool auszurollen. Daten werden nicht mehr aktualisiert, Jobs zur Datenerfassung verbrauchen Ressourcen, obwohl sie nicht mehr benötigt werden, und Produktivität geht verloren, wenn Entwickler ihren Fokus zwischen verschiedenen Tools wechseln müssen. Vielleicht noch schlimmer: Gerade bei Monitoring- oder Tools zum Wissensaustausch können Manager falsche Entscheidungen treffen, weil sie sich meist nur auf wenige Tools konzentrieren und ihre Antworten aus dem falschen Tool beziehen.

Ein Teilaspekt dieses Problems ist die Frage nach der Verantwortung. Ein Team – nicht eine einzelne Person – muss für die Administration, Updates und allgemeinen Anwendungsfälle des Tools verantwortlich sein. Dieses Team muss die Nutzung genau beobachten und sicherstellen, dass das Tool nicht außerhalb des festgelegten und vereinbarten Zwecks verwendet wird. Ohne eine solche Verantwortung beginnt die unstrukturierte Nutzung des Tools, und mit der Zeit werden alle möglichen Sonderfälle damit abgedeckt. Das sorgt im gesamten Engineering-Team für viel Verwirrung und erschwert die Wartung.

Ohne einen klaren Verantwortlichen für die Cloud-Repositories und ohne klare Vorgaben zu ihrer Nutzung stellte ein Unternehmen fest, dass es aufgrund eines Teams, das große Mengen an Binärdateien hochlud, kurz davorstand, das Speicherlimit für Repositories zu erreichen. Das Problem zu beheben und die Binärdateien nach Artifactory zu verschieben, war deutlich kostspieliger, als Artifactory von Anfang an zu nutzen.

Wissensaustausch: Gemeinsames Verständnis ist besser als individuelle Expertise.

Das Wissen darüber, wie das neue Tool genutzt und gewartet wird, muss in allen relevanten Teams geteilt und aktuell gehalten werden. Das kann als sichtbare Kosten auftreten oder sich nur durch Verzögerungen bei Aufgaben bemerkbar machen – vorhanden ist es immer.

Ein Sonderfall ist eine neue Programmiersprache: Ein guter Entwickler kann sich in wenigen Tagen in jede neue Sprache einarbeiten. Es dauert jedoch Monate oder Jahre, sie wirklich fließend zu beherrschen. Bis dahin fallen zeitaufwendige Refactoring-Aufgaben an, um den Code in der neuen Sprache an die bestehenden Qualitätsstandards und Best Practices anzupassen.

Die Frage, wie ein neues Tool zusammen mit bestehenden Tools genutzt werden soll, muss sorgfältig beantwortet werden. Andernfalls kann eine unkontrollierte Nutzung im Wildwest-Stil die Nachverfolgung des Datenflusses erschweren oder unmöglich machen. Betrachtet das obige Beispiel mit den Binärdateien: Ein Git-Repository ist dafür eindeutig nicht der richtige Ort. Viele neue Mitarbeiter mussten zusätzliche Zeit aufwenden, um das auf die harte Tour zu lernen. Die Recherche, wo Daten gespeichert sind, dauerte länger, weil sie nicht am naheliegenden Ort lagen, und das Monitoring der Speicherlimits hätte – falls vorhanden – wissen müssen, dass es zwei Speichertypen gibt.

Aber AI wird das schon lösen!

Diese Ansicht ist bei vielen Unternehmen beliebt, die den Kampf gegen die Komplexität verloren haben. Sie ist jedoch falsch. Letztlich bedeutet AI auf das Chaos zu setzen nur, eine weitere Komplexitätsebene hinzuzufügen, über die ihr noch weniger Kontrolle habt. Wenn eure Komplexität so weit gewachsen ist, dass kein menschliches Team mehr verstehen kann, was vor sich geht, sitzt ihr auf einer tickenden Zeitbombe.

Ich schätze den Einsatz von AI-Tools in meiner täglichen Arbeit sehr und empfehle, sie zu nutzen, um eure Komplexität in den Griff zu bekommen und zu reduzieren, statt sie blind weiter zu erhöhen.

So bleibt ihr fokussiert

Wenn jemand ein neues Tool zu eurem Stack hinzufügen möchte, haltet inne und fragt:

• Brauchen wir es wirklich?

• Wie hoch sind die Gesamtkosten – einschließlich Wartung und Einarbeitungsaufwand?

• Können wir zufriedenstellende Ergebnisse erzielen, indem wir die Funktionen eines bestehenden Tools nutzen?

• Welchen konkreten Nutzen hat es für das Produkt?

Stellt dieselben Fragen nach einiger Zeit für jedes Tool, das ihr bereits habt, und reduziert euren Stack so, wie Bruce Lee seine Tritte trainierte: indem ihr euch auf das konzentriert, was im Kampf wirklich funktioniert.

Wenn ihr tatsächlich ein neues Tool einführt, erstellt zunächst ein MVP (kein POC) und stellt euch die Fragen erst danach. Wahrscheinlich gewinnt ihr dabei neue Erkenntnisse und stellt möglicherweise fest, dass ihr das neue Tool gar nicht braucht.

Hört auf, 9.9999 Tritte zu trainieren, und konzentriert euch stattdessen auf den einen, der in einem Kampf wirklich funktioniert.