7 Meinungen zum Thema DevOps

Will jemand in einer Company DevOps einführen, gehts eigentlich IMMER mit der folgenden Frage los: Was ist DevOps? Und genau bei dieser Kernfrage wird deutlich, warum DevOps eigentlich so ein wahnsinnig schweres Thema sein kann. Es gibt eben keinen goldenen “DevOps Weg” dessen Beschreitung einen direkt zum Himmelreich der Softwarentwicklung führt. Vielmehr starten die meisten Unternehmen als erstes in eine Phase umfangreicher Diskussion über das “Was”. Die Folge sind viele verschiedene Meineungen zum Thema DevOps die in beliebig viele Richtungen auseinander driften und oft eine gemeinsame Strategie zunichte mache, weil der gemeinsame Weg nicht gefunden wird.

7 Meinungen zum Thema “Was ist DevOps”

Die meist gehörten 7 Meinungen zum Thema DevOps die ich in meinem Tagebuch die letzten 6 Jahre notiert habe, möchte ich Dir hier einmal zusammenfassen.

DevOps Meinung 1: DevOps ist Kultur

Sagen wir mal, die DevOps Bewegung ist sehr fokussiert auf den kulturellen Wandel und das zurecht. In großen Teilen geht es darum, das Entwickler mehr Verantwortung für den Betrieb Ihres Produktes entwickeln und Betriebler die Infrastruktur auf den Bedarf der Software besser anpassen, indem beide voneinander lernen. Aber ich denke die letzten Jahre haben am Beispiel großer Unternehmen gezeigt, dass ein Geschäftsführer nicht einfach eine “neue Kultur” im Unternehmen ausrufen kann und damit ist es dann getan. Im Artikel “Bring was Liebe ins Business” habe ich Kultur mit einem “Bakterienstamm” verglichen. Kultur wächst von innen heraus aus eigenem Antrieb. Ich kann als Koch nur alle Zutaten, Wärme und Zeit hinzugeben, ob mein Hefeteig dann was wird, habe ich danach nicht mehr in der Hand.

DevOps Meinung 2: DevOps ist organisatorische Veränderung

Auch hier liegen wir nicht ganz falsch, und ich bin immer dankbar, wenn ich nicht den Satz höre “Das (die organisatorische Veränderung) können wir hier nicht machen“. Die organisatorischen Veränderung muss passieren, da führt kein Weg dran vorbei. Ich bin sogar der Meinung, je radikaler die Veränderung durchgeführt wird (und damit meine ich nicht, dass man Menschen auf die Straße setzt) um so effektiver wird der Wandel auch vollzogen. Wenn ich DEV und OPS Menschen ins gleiche Team setze, dann müssen sich zwangsläufig die Kultur, die Arbeitsweise und auch die genutzten technischen Mittel verändern. Aber laufe ich nicht auch Gefahr, dass sie sich beiden zusammen hinsetzen und einfach nur Ihre bisherigen Vorgehensweisen gemeinsam weiterverwenden?
Ich muss mir ganz klar die Frage stellen, wie begleite ich nun den Prozess der Veränderung, wie kann ich (egal in welcher Rolle ich mich grade befinde) immer wieder neue Impulse setzen?

DevOps Meinung 3: DevOps macht uns schneller

Diese Meinung zu DevOps höre sehr oft: Wir wollen DevOps machen, weil wir mehr Geschwindigkeit erreichen wollen.
Eine beliebte Szenario in dem der Wunsch nach mehr Geschwindigkeit oft erstmal enttäuscht wird ist, Features in viele kleine Häppchen zu schneiden. Diese kommen dadurch zwar viel schneller in Produktion an, aber sind dafür noch nicht vollständig. Am Ende brauchen wir für die gesamte Entwicklung des Features sogar mehr Zeit, weil das Userfeedback mit verarbeitet wird (und mit Sicherheit sieht es am Ende komplett anders aus als geplant). Tatsächlich sind wir also mit DevOps erstmal gefühlt langsamer. Man kann zwar argumentieren, dass das Feature nun auch wirklich fertig ist, aber würde man bei klassischer Vorgehensweise ein Feature neu entwickeln mit dem der User nur 80% zufrieden ist (Wenn man diese Kennzahl überhaupt erhebt)? Vielleicht ist “schneller” gar nicht die richtige Kennzahl. Am Ende zahlt DevOps ja gar nicht in eine “schnellere” Entwicklung sondern in eine höhere Zufriedenheit ein?

DevOps Meinung 4: DevOps ist CI/CD/VC/Agil/IaC/Cloud/Monitoring/FeedbackLoop

Nope. Ganz einfach NEIN!!! Oder ja. Also Jein. Naja, Alles was ich hier in die Überschrift gepackt habe, sind Methoden. Die können hilfreich sein und sollten in der Mehrheit aller Fälle auch angewendet werden. Aber sie definieren nicht “DevOps”. Ein agiles Team kann SCRUM aus dem Lehrbuch machen, wird aber wohl deswegen nicht automatisch ein DevOps Team. Wenn diese Argumentation den meisten noch klar ist, höre ich aber auch oft: Wir machen CI/CD, deswegen sind wir ein DevOps Team. Oweia, das ist “weird“. Schliesslich ist ja auch entscheidend, was am Ende der Pipeline herauskommt. Fällt da ein Artefakt, was der Betrieb weiter bearbeiten muss? Interessiert sich das Entwicklungsteam für die Belange der User? Wie automatisiert ist die Pipeline wirklich? Was passiert eigentlich mit den negativen Ergebnissen der statischen Code-Analyse?

DevOps Meinung 5: DevOps ist (unsere) Technik

Eigentlich geht es bei dieser DevOps Meinung um 2 Themen: Zum einen versuchen Firmen oft Ihr Produkt als die DevOps Lösung zu verkaufen. Natürlich sind technische Lösungen ein wichtiger Baustein einer DevOps Transition, aber bietet ein Unternehmen nur ein Produkt sollte man Abstand nehmen. Schau Dir genau an, was das Unternehmen noch macht. Engagieren sich die Leute auf Konferenzen auch in Vorträgen die nichts mit Ihrem Produkt zu tun haben? Wird ein Blog betrieben der das Thema DevOps auch anders als aus der Produktsicht betrachtet? Bieten das Unternehmen Dienstleistungen an, die auf die kulturelle/organisatorische Transition abzielen?
Aber auch im eigenen Unternehmen, reicht es nicht nur ein k8s aufzusetzen und damit wars dass dann. Oft erlebe ich dann, dass ein weiteres Silo im Unternehmen entsteht: Das Plattform-Team (k8s), das OPS-Team (Monitoring, Backup) und das DEV Team die nach wie vor nicht (oder nur via Tickets) miteinander reden. Der Beginn vieler meiner Projekte ist tatsächlich genau so definiert:

Wir sind unzufrieden mit dem Betrieb, weil der die Anwendung nicht kennt und wir immer wieder helfen müssen. Der Betrieb betreibt jetzt nur noch eine Plattform wir machen den Betrieb der Anwendung selber. Dann ist die Schnittstelle (durch den Container) sauber definiert und alles passt.

Natürlich ist das auch nicht ganz falsch. Aber wie es bleiben jede Menge Fragen offen. Wie erfahren sind denn die Entwickler darin, “Betrieb zu machen”? Auf welche Weise wird nun der 1st-, und 2nd Level organisiert? Worin unterscheidet sich nun ein Applikationsproblem von einem Plattform Problem (Grade in Hinblick darauf dass Applikationen immer mehr Features der zugrundeliegenden Plattform als elementares Element verwenden)?

DevOps Meinung 6: DevOps definiert sich durch KPIs

So langsam wird es gruselig, aber tatsächlich: Schaut man sich die verschiedenen “State of DevOps” reports an, landet man immer wieder bei den klassischen 4 Metriken:

• Lead-time
• Time-to-recover
• Deployment frequency
• Time-to-restore

Und natürlich ist es völlig richtig, den Fortschritt der DevOps Transition zu messen. Wie Tom DeMarco schon sagte: “Was ich nicht messen kann, kann ich nicht kontrollieren”. Und auch wenn wir unseren DevOps Teams viele Freiheiten einräumen, müssen wir am Ende des Tages alle unsere Brötchen verdienen. Aber sind die Zahlen wirklich der einzig relevante Faktor für uns? Sollte es wirklich unser erklärtes Ziel sein, einfach nur einmal die Woche zu deployen?

DevOps Meinung 7: DevOps ist ein Beruf

Natürlich kann man “DevOps” Experte sein, weil man sich mit der Idee beschäftigt und viel Zeit darin investiert. Letztlich bezeichne ich mich ja sogar selber so. Aber wie oft sehe ich die Stellenbschreibung “Wir suchen einen DevOps Engineer -> Kann alles, macht alles, ist 3in1”. Eigentlich ist das der Bodensatz aller DevOps Unwahrheiten, da hier eigentlich nur jemand gesucht wird, der Software entwickeln kann, ITIL Experte ist und auch noch alle Tools beherrscht. Wir hatten so etwas auch schon zu Pre-DevOps-Zeiten als alle Welt nach “Fullstack-Entwicklern” gefragt hat. Wenn wir schon dabei: Man kann auch kein DevOps “Zertifikat” machen.

Fazit

Gut, jetzt hat er ganz schlau dahergeredet der Herr Frickeldave, aber ja noch nicht wirklich was gesagt. Alles ist irgendwie DevOps, aber auch irgendwie nicht. Wie soll das weiterhelfen?

Dieser Artikel soll eines klar machen: Willst du dein Unternehmen in die schöne neue DevOps Welt führen, dann solltest du Dir darüber klar sein, dass jeder etwas anderes unter DevOps versteht. Diese ganzen Meinungen kannst du nicht weg-ignorieren und den goldene Weg definieren. Du wirst ähnlich wie in diesem Artikel die verschiedenen Meinungen in deinem Unternehmen aufnehmen, analysieren und in die DevOps Roadmap aufnehmen müssen. Wenn du vor einem Team von 50 Leuten stehst, die der Meinung sind, dass DevOps primär die Einführung einer Containerplattform bedeutet, dann wirst du dich dieser Meinung ein Stück weit beugen und darauf eingehen müssen, selbst wenn du anderer Meinung bist und dich vielleicht eher auf kulturellen Aspekte konzentrierst (oder umgekehrt, dies nur als Beispiel).

Vielleicht hilt Dir ja auch der Folge Artikel über das “DevOps Stoßpendel” weiter.