DAS nennt ihr DevOps?

Ist DevOps das neue Schwarz?

Mirco Hering

© Shutterstock.com/Volodymyr Tverdohlib

DevOps ist cool. Korrektur: DevOps ist Mainstream. Korrektur: DevOps hat den Mainstream bereits hinter sich gelassen und befindet sich auf dem besten Weg, zusammen mit „Agile“, „Big Data“ und der allmächtigen „Cloud“ zu einem übermäßig verwendeten Schlagwort zu werden. Wie viel Substanz steckt hinter dem Hype um DevOps?

DevOps ist überall: Mittlerweile kann man DevOps-Tools von Anbietern erwerben, die bislang für ALM-Tools bekannt waren. Auch Cloud-Anbieter, die einen bis dato mit virtueller Infrastruktur versorgt haben und sogar Beratungsunternehmen, die zuvor für IT-Strategien verantwortlich zeichneten, haben entsprechende Lösungen in petto. Aber wie kommt es, dass viele dieser DevOps-Praktiken und -Werkzeuge bei genauerer Betrachtung eine gespenstische Ähnlichkeit zu genau denjenigen Produkten aufweisen, die sie einem schon früher verkaufen wollten?

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

Meine gesamte Karriere bestand darin, sich mit dem zu beschäftigen, was früher unter dem Namen „Development Architecture“ bekannt war: Der Entwicklung von IDE-Erweiterungen und Compilern; später auch mit Tooling-Lösungen für die Unterstützung von Lieferprozessen. Die Realität sieht so aus, dass das Tooling und die Methodologie immer nur ein Teil der Antwort sein werden. Die kalte, harte Wahrheit ist, dass Engineering-Kenntnisse sowohl für DevOps-Teams (ja, ich wage, sie so zu nennen. Sie können sie allerdings auch mit der Bezeichnung Tools-Teams, Plattform-Teams, System-Teams versehen – oder je nach Bedarf einem beliebigen anderen Label, dass am ehesten zutrifft und/oder die wenigsten Leute kränkt oder beleidigt) als auch für Entwicklungs- und Operations-Teams wichtig sind.

Lesen Sie auch: DevOps bedeutet, Verantwortung abzugeben und Verantwortung zu übernehmen

Für all diejenigen, die in diesen Bereichen arbeiten, ist DevOps zugleich das beste und schlimmste, was ihnen passieren konnte. Einerseits umweht unsere Arbeit nun der Hauch der Sexiness. Lange Zeit galt die Auslagerung oder Investition in proprietäre oder kommerzielle Produkte von der Stange als die Antwort auf die gestiegene Komplexität und den Preisdruck in Projekten. Altbewährte Programmierpraktiken und die Unterstützung von Entwicklern durch die richtigen Tools galt nicht als sexy. Nun ist DevOps das neue Schwarz und viele Leute wollen mit mir über die Unterstützung von High-Performance-Delivery durch Engineering-Praktiken und das richtige Tooling für die Unterstützung von Entwicklern sprechen. Dass dieser wichtige Aspekt der IT-Lieferung sichtbarer wurde, war sicherlich ein erfreulicher Umstand.

Die Gefahren von DevOps

Aber es gibt eben auch eine gefährliche Kehrseite. Plötzlich macht es jeder. In meiner beratenden Rolle habe ich nicht wenig Zeit mit Analysen und Einschätzungen für Kunden verbracht. Dabei ist mir der Dunning-Kruger-Effekt deutlich häufiger begegnet, als ich gedacht hätte. All jenen, denen dieser Effekt unbekannt ist, lege ich eine kurze Stippvisite bei Wikipedia ans Herz – kurz gesagt beschreibt er die Tendenz inkompetenter Menschen, das eigene Können zu überschätzen (und die Kompetenz anderer zu unterschätzen).

Lesen Sie auch: DevOps stellt fehlende Synergien wieder her

Meiner Erfahrung nach zeigen sich die meisten Symptome des Dunning-Kruger-Effekts im Bereich kontinuierliche Integration. Ein übliches Szenario: Ich Frage meinen Gegenüber von Organisation XY, ob sie kontinuierliche Integration praktizieren, woraufhin dieser mit „ja, das tun wir“ antwortet. Natürlich könnte ich nun diesen Punkt auf meiner Liste abhaken und zum nächsten übergehen. Da sich kontinuierliche Integration meiner Erfahrung nach jedoch recht knifflig gestaltet, bohre ich stattdessen tiefer: „Woher wissen Sie, dass sie kontinuierliche Integration betreiben?“. Die Antwort:„Wir haben Jenkins als Continuous-Integration-Server“. Okay, der Kunde nutzt also ein gängiges CI-Tool, eine weitere Frage wird also schon nicht schaden: „Was machen Sie mit Jenkins und wie oft läuft es?“. An diese Stelle trifft mich der Dunning-Kruger-Effekt: „Wir nutzen es wöchentlich, für unseren Entwicklungszweig“. Und schon sind wir wieder an einem altbekannten Punkt – mein Assessment wird zur Unterrichtsstunde.

Um ehrlich zu sein bin ich der Ansicht, dass ein gutes Assessment genau das sein sollte: Ein pädagogisches Instrument. Dem einen dient es der Reflexion, dem anderen als Lehrstück, wie man derartige Gespräche mit Externen führt. Doch viel zu oft führt der beschriebene Gegensatz zwischen Selbstwahrnehmung („Wir praktizieren kontinuierliche Integration“) und Realität („Wir haben einen Jenkins-Server und lassen es ab und zu laufen“) dazu, dass Einzelpersonen und Teams, ja ganze Organisationen von sich behaupten, DevOps zu betreiben.

Lesen Sie auch: Spreadshirt auf dem Weg zur DevOps-Kultur: „Es geht immer um Menschen“

Natürlich bin auch ich nicht frei von Schuld. Die Verwendung des Begriffs „DevOps“ stellt häufig einen bequemen Weg dar, sowohl die zugrundeliegenden Praktiken als auch den für sie nötigen kulturellen Wandel zu beschreiben. Und wann ist man eigentlich dazu „berechtigt“, von sich zu sagen, dass man DevOps betreibt? Meine bevorzugte Antwort darauf lautet, dass wir uns auf einer Reise befinden. Und zwar wir alle. Jeder, der mit der Lieferung von IT-Lösungen zu tun hat, befindet sich auf der DevOps-Reise. Die Reiseroute stellt selten eine gerade Linie dar; häufig wird der Pfad auch verlassen oder man verläuft sich, wodurch man sich immer weiter vom Ziel entfernt. Doch wir alle befinden uns auf dieser Reise, um die IT-Lieferung zu verbessern. Denn genau darum geht es bei DevOps.

Und ja, es kümmert mich nicht, dass DevOps das neue Schwarz ist. Ich nehme die negativen Begleiterscheinungen des Hypes in Kauf, solange dies bedeutet, dass eine Diskussion über die Verbesserung der IT-Lieferung zustande kommt – nicht nur weil dies für unsere Unternehmen und Kunden für Bedeutung ist, sondern auch, weil sie die IT-Lieferung zu einer humaneren Angelegenheit macht. Sie nimmt den Stress aus dem Leben der Menschen, sorgt dafür, dass wir mehr Spaß an unserer Arbeit haben und führt zu besseren Lösungen für all unsere Probleme – angefangen bei eher banalen (z. B. einfacher Bilder auf Facebook posten zu können) bis hin zu wirklich bedeutenden (z. B. Familien in Katastrophengebieten via Crowdsourcing mit besseren Informationen zu versorgen).

Begleiten Sie mich auf dieser Reise – sie mag zwar lang (und beschwerlich) sein, aber jeder Schritt lohnt sich …

Aufmacherbild: Portrait of unshaved male biker von Shutterstock.com / Urheberrecht: Volodymyr Tverdohlib

Verwandte Themen:

Geschrieben von
Mirco Hering

Mirco has for the last 9 years worked on accelerating software delivery through innovative approaches (what would now be called DevOps) and a few years ago started experimenting with Agile methods. Mirco works for a major consulting and systems integration provider and supports major public and private sector companies in Australia and overseas in their search for efficient IT delivery. He also regularly writes about software deliver, Agile and DevOps on notafactoryanymore.com

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: