Im Laufe meiner Karriere als IT-Berater, in der ich mit verschiedenen Plattformen und Technologien gearbeitet habe, bin ich auf eine Vielzahl von Begriffen gestoßen, die mir erklären sollten, wie das jeweilige Unternehmen an die moderne Softwareentwicklung herangeht. Begriffe wie Agile, DevOps, SAFe und andere.
Sie alle werden von einer leidenschaftlichen Gruppe von Befürwortern vertreten, die den jeweiligen Begriff gegen jede Skepsis verteidigt. Persönlich bin ich für keinen dieser Begriffe und auch gegen keinen. Wenn etwas für ein Unternehmen funktioniert, ist das großartig. Auf der Suche nach demselben Erfolg tappen viele Unternehmen in die Falle, eine überbewertete Lösung als neue Vorlage oder Schablone zu betrachten, in die sich alle einfügen müssen, wenn sie erfolgreich sein wollen.
Das Wichtige, was Unternehmen erkennen müssen, ist, dass DevOps keine Lösung nach dem Muster „one size fits all“ für jedes Unternehmen ist. Mein Eindruck ist, dass alle etwas tun müssen, sobald ein Trendsetter wie Google, Facebook oder Microsoft sich für eine bestimmte Vorgehensweise entscheidet.
Wenn dann noch der zusätzliche Druck hinzukommt, sich selbst zu ernst zu nehmen – und ein wenig drakonisch zu werden –, ist man wie ein neuer Köder, der in den Angelteich für Leute wie mich geworfen wird, die nach so vielen IT-Projekten hinter sich im Allgemeinen voller Zynismus sind.
Warum „DevOops“?
Wenn ich Unternehmen frage, wo sie bei ihrer DevOps-Reife stehen, lautet die Antwort meist ungefähr: „Wir befinden uns auf dem Weg dorthin.“ Ähnliches lässt sich über Unternehmen in Bezug auf kontinuierliche Performance-Tests sagen. Das bedeutet im Allgemeinen, dass das Unternehmen zwar etwas tut, es aber noch nicht ganz verstanden hat.
Das bringt mich zu dem Grund, warum ich die meisten aktuellen DevOps-Initiativen inzwischen als „DevOops“ bezeichne – also als fehlgeleiteten Versuch, DevOps umzusetzen. Die meisten Führungskräfte und Unternehmen halten ständig Ausschau nach der neuesten Entwicklung, dem neuesten Trend oder den neuesten Schlagwörtern, um Innovationen zu beschleunigen, Zeit und Geld zu sparen und es mit der Konkurrenz aufzunehmen. In den vergangenen Jahren war DevOps eines der größten Schlagwörter für Unternehmen weltweit.
Letztlich ist einer der wichtigsten Faktoren bei der Einführung eines Agile- oder DevOps-Modells in Unternehmen F.O.M.O. (die Angst, etwas zu verpassen). Daher versuchen Unternehmen, DevOps-Praktiken zu übernehmen, um relevant zu bleiben.
Das führt im Vergleich zu ihrem älteren, traditionellen Ansatz letztlich zu noch mehr Problemen im Softwareentwicklungsprozess. Das soll nicht heißen, dass Ihr traditionelles Modell die Zukunft Ihres Unternehmens ist. Sie müssen sicherstellen, dass Sie für diese Art von Modell bereit sind.
Nachahmung ist die aufrichtigste Form der Anerkennung … oder etwa nicht?
Wenn Unternehmen ihre Wettbewerber nachahmen, versuchen sie, mit der Konkurrenz Schritt zu halten und relevant zu bleiben. Oft tun sie dies, ohne sich zunächst zu überlegen, wie sich ein DevOps-Modell am besten umsetzen lässt für sie – oder ob sie DevOps-Praktiken überhaupt benötigen. Wenn Ihr Hauptziel darin besteht, um der Geschwindigkeit willen schneller zu werden, ist das ein Rezept für eine Katastrophe (oder in diesem Fall für Probleme bei der Produktentwicklung).
Bei Performance-Tests löst es das Problem nicht, Geschwindigkeit der Performance vorzuziehen. Unternehmen fragen mich oft, ob sie jeden API-Test oder jeden End-to-End-Performance-Test in eine CI-Pipeline integrieren sollten, um Zeitmesswerte zu erfassen, und sie möchten dies so schnell wie möglich tun.
Doch dadurch sind die Messwerte im Allgemeinen nicht valide, helfen nicht bei der Lösung von Performance-Problemen und werden zu einer „Checkbox-Aktivität“. Warum sind diese Messwerte nicht valide, fragen Sie? Weil die erfassten Messwerte dem Publikum (also den Entwicklern) keinen echten Mehrwert bieten und deshalb übersehen oder als irrelevant betrachtet werden.
Unterdessen werden Performance-Probleme, mit denen Unternehmen bereits zu kämpfen hatten, weiterhin erst erkannt, wenn es zu spät ist. Im Allgemeinen gibt es dann einen Produktionsausfall oder ein Problem mit der Kundenerfahrung in einem Support-Ticket, das bearbeitet werden muss. Die Automatisierung hat das Problem nicht gelöst. Die Geschwindigkeit, mit der die Tests durch die CI-Pipeline liefen, hat das Problem nicht gelöst. Die Probleme bestehen weiterhin.
Aber Moment, es gibt einen Lichtblick!
Meiner Erfahrung nach deuten drei Dinge darauf hin, dass ein Unternehmen ein DevOps-Modell bzw. eine DevOps-Strategie erfolgreich umgesetzt hat:
- Service-Virtualisierung (oder eine entsprechende Lösung) wurde implementiert: Dadurch können sie gegen unfertige Funktionen und Services testen und müssen nicht warten, bis die Entwicklung abgeschlossen ist. Wenn sie keine Möglichkeit haben, an der Testautomatisierung für bereits funktionierende Funktionen zu arbeiten, während andere noch nicht erstellt wurden, geraten sie bei der Automatisierung ins Hintertreffen, und das Testen wird immer hinterherhinken.
- Sie haben die Produktionsfreigabe davon entkoppelt, dass Benutzer Zugriff auf die neuen Funktionen erhalten: Das bedeutet, dass sie Code zunächst unauffällig bereitstellen, damit Endbenutzer in dem von ihnen gewählten Tempo Zugriff erhalten, etwa in Pilotgruppen. Wenn eine Einführung alles durcheinanderbringt, können sie über Feature-Flags schnell zur vorherigen Version zurückkehren.
- Automatisierung wiederkehrender Aufgaben: Sie überlegen ständig, wie sich der Aufwand im Arbeitsumfeld durch die Automatisierung wiederkehrender Aufgaben reduzieren lässt, und stellen gleichzeitig sicher, dass manuelle Prüfungen vorgesehen sind, selbst wenn es Ausnahmen von den standardmäßigen Bestanden/Nicht-bestanden-Kriterien gibt. Nicht alles ist immer eindeutig – bestanden oder nicht bestanden. Eine gute DevOps-Organisation kennt das richtige Gleichgewicht zwischen der Reduzierung unnötiger Arbeit und gedankenloser Pipeline-Geschwindigkeit.
Letztlich hängt die Lösung für die Probleme bei den Performance-Test-Initiativen eines Unternehmens davon ab, welche Ergebnisse es sich von seinen Testergebnissen verspricht. Wenn Sie solide Performance-Testergebnisse implementieren möchten, die es Ihrem Unternehmen ermöglichen, fundierte Geschäftsentscheidungen zu treffen, sollten Sie sich an der Erfahrung der Endbenutzer orientieren.
DevOps mit Blick auf die Zukunft
Derzeit befindet sich die Einführung von DevOps noch in der Phase des „Hype-Zyklus“ – also in dem Bereich, den Gartner als „Peak of Inflated Expectations“ bezeichnet. Daher gibt es viele Bemühungen, die es mit der Einführung von DevOps nicht völlig ernst meinen und die grundlegenden Dinge ablehnen, die DevOps zum Funktionieren bringen, weil sie schwierig umzusetzen sind.
In den nächsten fünf Jahren wird der DevOps-Hype abflauen, weil Unternehmen ihre Mitarbeiter „weiterqualifizieren“ und von neuen Mitarbeitern die erforderlichen Fähigkeiten für Site-Reliability-Ingenieure erwarten werden. Dann werden Unternehmen herausfinden, wie sie daraus den richtigen Nutzen ziehen können, und einige werden feststellen, dass sie ohne DevOps einen größeren Nutzen erzielen.
Über den Autor:
Scott Moore, Director, Customer Engineering, Tricentis