Freigeben über

Was ist eigentlich … “DevOps”?

  • Artikel

“DevOps” ist zur Zeit in aller Munde und man mag sich fragen, was es damit auf sich hat. Ich habe im Internet nach der offiziellen Definition gesucht, mit dem Ergebnis, dass es gar nicht so leicht ist die eine offizielle Definition zu finden. Es zeichnet sich aber ein gewisses Muster in den Antworten ab, so dass ich zum Entschluss gekommen bin, dass eine Definition auf deutsch durchaus sinnvoll sein kann.

Diese Definition habe ich bewusst auf das Wesentliche gekürzt (auch auf die Gefahr hin, dass dann wieder Unschärfen auftreten) - ich mag halt Einzeiler:

      

“DevOps ist die Integration des IT-Operations Teams in ALM.”

Und was bedeutet das?

Klingt ganz einfach, oder? Das bedeutet, dass all die Ansprüche, die man mit dem ALM-Ansatz an moderne Softwareentwicklung stellt, in Zukunft auch die IT-Admins einschließen soll.

Vielleicht muss man sich für das bessere Verständnis noch einmal vor Augen halten, was ALM eigentlich will: Es geht bei ALM darum Transparenz zu schaffen über das was der Kunde/das Business will, was die Entwickler umsetzen und wie weit sie dabei fortgeschritten sind und wo dabei die typischen Fehlerquellen sind. Das Ziel ist es möglichst früh festzustellen, wenn irgendetwas nicht wie geplant läuft – im Idealfall noch bevor das tatsächlich der Fall ist, so dass man frühzeitig gegensteuern kann. Ziel des Unterfangens ist es, bessere Software herzustellen – häufig, aber nicht immer, umgesetzt mit ein paar agilen Basisprinzipien. Dabei ist das Ziel der agilen Herangehensweisen hierbei auf Änderungen schnell reagieren zu können.

Was fehlt hierbei? Die Integration des Betriebs der Software nach dem Release!

All die Transparenz, die – im Idealfall – zwischen Business, Kunden, Projektleitern, Testern, Entwicklern usw. herrscht, wird mit DevOps ausgedehnt auf die Jungs und Mädels, die am Ende immer den schwarzen Peter haben, wenn die Anwendung im Live-Betrieb nicht läuft: Dem Operationsteam – also denen, die die Software tatsächlich auf den Servern dieser Welt installieren und dafür sorgen, dass die Server gepatched und immer up & running sind.

Wenn man hier ein wenig genauer hinsieht, wird man feststellen, dass die Ziele, die das Operations-Team und das Dev-Team haben mitunter sehr gegensätzlich sind. Natürlich wollen beide Parteien, dass die Software am Ende vernünftig und stabil läuft. Während das Dev-Team aber das Ziel hat immer neue Versionen auszuliefern (das ist nunmal der Job eines Entwicklers), ist die oberste Prämisse des Operations-Teams Stabilität und Verfügbarkeit (das ist nun mal der Job des Admins). Wenn das System gerade läuft könnte man es ja einfach laufen lassen – aber dann kommen die Entwickler daher und wollen eine neue Version installieren… hier gibt es genug Potential für Reiberein.

Der Ansatz, das Operations-Team mit in das Gesamtkonzept zu integrieren, ist mehr als fair und es ist absolut vernünftig hier die agilen Methoden, die in der Software-Entwicklung für ein Umdenken gesorgt haben, auch im Zuge der DevOps zu evaluieren und bei Bedarf heranzuziehen. Ähnlich wie ALM den Fokus vom reinen Codeschreiben löst und auf mehrere Rollen ausweitet, wird der Blick an dieser Stelle noch einmal “weitwinkliger”. Dabei hat das in erster Linie auch nicht mit irgendwelchen Tools zu tun – es ist eher eine Frage der Wahrnehmung und ein Bewusstsein – oder sogar Philosophie oder Kultur – bei allen involvierten Parteien, dass eine stärkere Integration hier einen Vorteil bringen kann.

Aber genau dieses Umdenken ist ja auch erforderlich, wenn man den Schritt macht von der Frickelbude zum professionellen Software-Engineering, vom planlosen Vorgehen zum strukturierten Arbeiten, vom Wasserfall in die Agilität. Dabei darf ein Ziel nicht aus den Augen verloren werden: Es geht nicht darum Ideologien zu leben, sondern der optimalen Wertschöpfung einen Schritt näher zu kommen.

Was hat sich also getan hinsichtlich DevOps?

Wir haben unsere ALM Plattform aufgebohrt und liefern jetzt Tools, die die Zusammenarbeit von Developer & Operations – DevOps – ermöglichen. Auch wenn ich oben noch geschrieben habe, dass es bei DevOps nicht um Tools geht (woran ich nach wie vor festhalte), wird in der Realität früher oder später ein Tool notwendig werden, um die gewollte Transparenz und Integration zu schaffen (was kein Widerspruch sein muss!). Konsequenterweise wurde der DevOps Support in unsere bestehende ALM Lösung integriert – so haben wir jetzt mit VS2013 unter anderem folgende Möglichkeiten:

1. Release Management um Software vereinfacht und schneller ausrollen zu können – um “Continuous Delivery” in der Praxis vereinfacht möglich zu machen.

2. Verfügbarkeit & Performancedatenauswertung über Live Systeme mit Application Insights. Außerdem die Möglichkeit Build Marker zu setzten, um den Bezug zwischen neuen Software Versionen und den Performancedaten herstellen zu können.

3. Die Möglichkeit über SCOM Intellitrace Daten zu sammeln, um im Fehlerfall schnell die Ursache finden zu können.Das ist schön, da es den Admin da abholt, wo er ohnehin schon unterwegs ist.

4. Application Insights. um Telemetrie Anwendungen abzufragen – es ist immer hilfreich zu wissen, wie eine Anwendung tatsächlich genutzt wird.

Und was sagt Sam?

Wie Sam Guckenheimer so schön auf der Keynote der (grandiosen) Almdays 2014 formuliert hat: Für viele ist DevOps das gleiche wie Release Management. Für uns gehört da ein bisschen mehr dazu: U.a. die Möglichkeit den “Root Cause” bei Problemen im Live-Betrieb zu finden und die Nutzung des Systems im Live Betrieb faktenbasiert zu verstehen (Usage Analytics/Telemetrie). Sam Guckenheimer bezeichnet das dann als “neue Art von ALM” – was ich sehr treffend finde.

 image

Mehr zu DevOps findet Ihr unter anderem hier: