Die DevOps-Verschwörung

Was ist dieses DevOps? Glauben wir dem Wikipedia-Eintrag, so beschreibt DevOps «… einen Prozessverbesserungs-Ansatz aus den Bereichen der Softwareentwicklung und Systemadministration. DevOps ist ein Kunstwort aus den Begriffen Development (englisch für Entwicklung) und IT Operations (englisch für IT-Betrieb).»

Es gibt mehrere Definitionen von DevOps. Generell versucht der Begriff das Zusammentreffen von Entwicklern und Operations-Personen zu schildern, unter Verwendung von Ansätzen wie «Agile» und «Lean».

Operations oder «Ops» schert dabei alle Sub-Disziplinen wie Systemadministratoren, Betriebsmitarbeiter, Datanbankadministratoren, Network-Enigneers und Security-Speziallisten über einen Kamm.

Man könnte überspitzt schon sagen, es unterscheidet nur zwischen «Devs» (Developern) und dem Rest. Die Devs gelten dabei als die Erschaffer einer Lösung, wohingegen die Ops das wohlbehütete «Aufwachsen» und «Gedeihen», das heisst den stabilen Betrieb des Produkts sicherstellen müssen.

Silo-Denken behindert Fortschritt und Effizienz

Durch das Betrachten dieser Gruppen als eigene Silos, hat sich in den letzten Jahren eine Mauer zwischen den Fronten gebildet, die den Fortschritt einer Firma behindern und dem Time-To-Market der Produkte schaden. Durch diese Frontenbildung wurde in vielen Projekten schon viel «Geld verbrannt». Das Ziel sollte eigentlich sein, Agile- und Lean-Methoden nicht nur auf den «Code Level» zu beschränken. Somit wird DevOps oft als eine Kultur, Philosophie oder eine Bewegung beschrieben. Es handelt sich defacto um «Vorgehensempfehlungen», für dessen Erreichung oder Perfektion uns verschiedenste «Tools» zur Verfügung stehen.

Was ist das Grundziel von DevOps?

Um das zu beantworten, müssen wir uns zuerst fragen, was genau die Probleme dieser zwei Lager sind, und woher die Probleme rühren.

Die Developer-Fraktion

Die Developer würden am liebsten alle drei Sekunden einen neuen Release in der Produktion vornehmen. Ob das Ganze läuft, ist ja nachher das «Problem» des Operations-Teams. Sie müssen die Vorgaben und Wünsche des Business in Bezug auf die Funktionsvielfalt abdecken und schneller als die Konkurrenz am Markt sein. Das Operations-Team wird dabei oft als Bremsklotz wahrgenommen.

Die Gegenspieler, das Operation-Konglomerat

Die Stabilität der Umgebung ist das A und O. «Don’t Touch a running System»! Da die Operations-Leute meist nicht in den Gesamtprozess einbezogen werden, stehen sie oft vor vollendeten Tatsachen. Sie sind es auch häufig, die am Wochenende und in der Nacht das Piket-Telefon betreuen müssen, während der Developer friedlich mit seinem Kopfkissen kuschelt und bereits vom nächsten Release träumt.

Die ideale Welt

Das Ziel muss deshalb unbedingt sein, das Vertrauen zwischen den einzelnen Abteilungen zu stärken. Weiter sollen alle Parteien von Anfang an einbezogen werden. Durch die Definition von z.B. nicht funktionalen Anforderungen durch das Operations-Team wird unter Umständen der spätere Betrieb optimiert und vereinfacht. Durch die optimierte Zusammenarbeit der Teams soll die Qualität der einzelnen Releases verbessert werden. Da das Operations-Team von Anfang an mit im Boot sitzt, soll es positiver gegenüber Changes oder neuen Releases eingestellt sein.

Fazit: DevOps als Brückenbauer

DevOps beschäftigt sich also damit, diese beiden Lager auf die gleiche «Wellenlänge» zu bringen. Es soll ein gemeinsamer Vorgehensstandard umgesetzt werden, damit sozusagen beide Teams von denselben Voraussetzungen, Funktionen und Zielen sprechen. Durch die Steigerung der Effizienz und Qualität durch z.B. Automatisierung, «Continuous Integration» und «Continuous Deployment» soll das Vertrauen in neue Veröffentlichungen gestärkt werden.

Das heisst, neben den zum Teil angewandten Agile- und Lean-Methodologien verfügt DevOps auch über Tools und Toolsets, um dieses Ziel zu erreichen.

Somit stellt DevOps nicht ein Agile 2.0 dar, sondern ist eine eigene Methodologie und «Bewegung oder Kultur».

Ich hoffe, ich konnte Ihnen das Thema allenfalls schmackhaft machen.