Machen Sie eigentlich auch DevOps?
Aus dem Leben eines Consultants. Ein Kommentar.
Vor einiger Zeit hatten wir ein Initial-Gespräch mit einem potentiellen Kunden, der gerne seine Infrastruktur automatisiert sehen wollte. Wir sprachen über mögliche Konzepte und Tools, die sinnvollerweise zum Einsatz kommen sollten. Bis dieser letzte Satz fiel: "Eines noch zum Schluss – machen Sie denn eigentlich auch DevOps?"
Eine schwierige Frage und zudem eine Frage, die man als Consultant in letzter Zeit sehr häufig hört.
Aber warum eigentlich? Ist diese Frage nicht einfach mit Ja oder Nein zu beantworten? Ist es heutzutage nicht vielleicht sogar notwendig, "DevOps zu machen", die Frage also immer mit "Ja!" zu beantworten? Warum hört man diese Frage so häufig? Und was ist die korrekte Antwort auf diese Frage?
Um zu verstehen, was DevOps eigentlich sein soll, lohnt sich ein Blick in die Vergangenheit, die Ursprünge und die Entstehung von DevOps:
Es ist 2007, Patrick Debois ist IT-Consultant in Belgien und hat ein neues Projekt begonnen, bei dem ein Rechenzentrum migriert werden soll. Patrick ist zuständig für das Testing und erkennt schon bald, dass er mehr Zeit mit der wechselseitigen Kommunikation zwischen Operations auf der einen und Development auf der anderen Seite verbringen muss, als mit dem tatsächlichen Projekt. Er beginnt sich zu fragen, ob es nicht auch andere Leute gibt, die ähnliche Probleme haben und ob es keine allgemeingültige Lösung für solche Probleme geben könnte. Patrick lernt über ein Entwicklerteam agile Methoden kennen und experimentiert damit auch im Operationsbereich. Schließlich veröffentlicht er seine Ergebnisse in einem Paper [1].
Ein Jahr später – im August 2008 – stellt er dieses Paper bei der Agile Conference in Toronto vor. Dabei findet er im Konferenzprogramm eine Diskussionsrunde mit dem Titel "Agile Infrastructure" und beschließt, dort mit hoffentlich Gleichgesinnten weiter zu diskutieren, nur um festzustellen, dass er der einzige Teilnehmer ist: Der Softwareentwickler Andrew Shafer, der die Session halten wollten, hatte im Vorfeld soviel negatives Feedback erhalten, dass er beschlossen hatte, nicht aufzutauchen. Glücklicherweise konnte Patrick ihn im Laufe der Konferenz dennoch treffen und die beiden tauschten ihre ersten Ideen zu Infrastructure as Code aus.
Wieder ein Jahr später – es ist der 23.6.2009, 13:00 Uhr – in Downtown San José: Man mag sich vorstellen, dass sich die Teilnehmer der gerade stattfindenden Velocity-Konferenz in einem leichten Mittagstief befinden, als John Allspaw und Paul Hammond die Bühne betreten. Beide arbeiten für flickr, Allspaw als Leiter der Operations, Hammond als Leiter des Engineering. Sie wollen den Teilnehmern gerne erläutern, wie Development und Operations zusammenarbeiten können – "without being huge assholes to eachother".
Knapp 9.400 Kilometer davon entfernt erfährt Patrick über Twitter von der Konferenz und von diesem Talk. Er ist begeistert und gleichzeitig betrübt darüber, dass er nicht persönlich teilnehmen kann. Dies tut er auf Twitter kund. Prompt schlägt ihm Paul Nasrat – auch auf Twitter – vor, seine eigene Velocity-Konferenz in Belgien zu organisieren. Was eigentlich als Witz gemeint war, wird schnell Realität. Auch ein Name ist schnell gefunden – die ersten DevOpsDays finden statt und sind ein großer Erfolg. Schnell finden sich viele Gleichgesinnte – auf der Welle dieses Erfolgs etabliert sich schließlich der Begriff DevOps, der bis heute Bestand hat.
Das Mindset ist wichtig! Erst wenn es hier passt, kann man die geeigneten Tools auswählen.
Aus dieser Geschichte heraus lässt sich auch nachvollziehen, was DevOps eigentlich bedeuten soll: Der Paradigmenwechsel von klassischem Silodenken hin zu Infrastructure as Code unter Verwendung agiler Methoden.
In der Praxis wird DevOps häufig stellvertretend für Automatisierung, schnelle Software-Releases und -Rollouts verwendet. Nutzer setzen es dann damit gleich, ein Toolset zu verwenden, das verspricht, diese Ziele zu erreichen. Doch nur das passende Toolset führt in der Regel nicht zum gewünschten Erfolg. Das Mindset zu DevOps ist wichtig! Erst wenn es hier passt, kann man die geeigneten Tools dazu auswählen.
Für das Mindset spielen Kommunikation und Motivation die größte Rolle. Bisherige Abteilungsgrenzen und Zuständigkeiten bzw. Verantwortlichkeiten verschwimmen oder verschieben sich. Ein aktiver Austausch sowie der Wille zur Zusammenarbeit zwischen den Abteilungen ist essenziell, um die Prozesse zu verbessern, zu standardisieren und schließlich zu automatisieren.
Jahrelang wurden Prozesse optimiert, indem für jeden Schritt im Workflow eine eigene Spezialabteilung mit Experten gegründet wurde, die ihren kompletten Fokus auf dieses Thema richtet, wie z. B. das Netzwerk, den Storage oder das Erstellen von VM-Hüllen. Dadurch bestand die Arbeit darin, die jeweilige Teilaufgabe zu erledigen und das Ergebnis an die nächste Abteilung weiterzugeben, damit z. B. die Experten für Windows oder Linux das jeweilige Betriebssystem installieren. Neue Server wurden somit mitsamt aller Anforderungen durch viele Abteilungen gereicht und die jeweiligen Spezialisten haben die passenden Einstellungen vorgenommen.
Dann kam die Automatisierung in Mode und die Abteilungen haben Tools eingeführt, um ihre Konfigurationen schneller und reproduzierbar automatisiert durchzuführen. Um die Übergaben zwischen den Abteilungen zu optimieren oder auch im Nachhinein noch Änderungen durchzuführen wurde oft eine Kontrollinstanz eingeführt – das Change-Management. Dafür gibt es unterschiedliche Ausprägungen von einer gemeinsamen Dokumentation und dem damit verknüpften Ticketsystem bis hin zu einer eigenen Abteilung, die Änderungswünsche überprüft und diese den Verantwortlichen zuteilt.
Schnittstellen zwischen den Abteilungen gab es schon immer. Um die Prozesse zu optimieren konnte man auch hier schon Standards entwickeln, die Prozesse vereinfachen und automatisieren. Gerade in sehr großen Umgebungen wurden aber immer mehr kleinteilige Abteilungen mit einem fest definierten Zuständigkeitsbereich geschaffen. Das hat den Vorteil, dass man genau weiß, wer für Aufgaben zuständig ist und als Teil des Systems leichter argumentieren und diskutieren kann, weshalb die eigene Abteilung für die entsprechende Aufgabe nicht zuständig ist... Dank der Automatisierung wäre das Erledigen im Zweifelsfall nur ein Aufwand von 5 Minuten – also benötigt man neue Tätigkeiten, die die Arbeitszeit füllen.
Als die Automatisierung so viele Aufgaben übernommen hatte, dass Entwickler immer schneller Releases ihrer Software produzieren konnten, diese automatisiert testen und direkt produktiv ausrollen (lassen) konnten, war der Zeitpunkt erreicht, an dem das Konzept von DevOps an Bedeutung gewann. Bei mehreren Releases am selben Tag sind Diskussionen über Zuständigkeiten offensichtlich nicht zielführend. In der Folge hat man für ein agiles Umfeld die Zuständigkeiten und Verantwortungsbereiche wieder zusammengelegt. Entwickler und der Betrieb müssen bei all den Aufgaben, die sowieso größtenteils von Pipelines und automatisierten Prozessen übernommen werden, enger zusammen arbeiten.
Dieses Konzept ist in den letzten Jahren insbesondere im Container-Umfeld notwendig geworden. Beim Einsatz von Kubernetes und ähnlichen Technologien funktionieren die bisherigen Zuständigkeiten und die alten Betriebsstrukturen nicht mehr, da viele Komponenten nun anders und enger verzahnt sind.
In vielen Unternehmen gibt es aber auch Menschen, die Veränderungen kritisch gegenüber stehen. Sie argumentieren damit, keine Zeit zu haben, ihre Prozesse zu automatisieren und dafür neue Tools einzuführen. Ein DevOps-Konzept überfordert zusätzlich. Und trotz (erzwungener) Einführung neuer Werkzeuge stellen sich die angepriesenen Vorteile nicht ein. Wenn also die Unternehmensstruktur nicht zu den DevOps-Tools passt oder einzelne Mitarbeiter eine solche Umstellung blockieren, scheitern die entsprechenden Projekte nicht selten.
Genau an dieser Stelle stehen heute viele Unternehmen, die nun nach Hilfe bei der Einführung von DevOps suchen. Sie würden gerne aktuelle Technologien in Kombination mit dem Konzept schneller Releases sowie Continous Integration/Delivery/Deployment nutzen. Dabei nehmen sie sich nicht selten die ganz Großen wie Google oder Facebook zum Vorbild. Ohne das nötige Mindset bleibt allerdings immer etwas auf der Strecke.
Eine weitere Frage bleibt im Raum stehen: Wie können wir überhaupt DevOps machen, wenn wir gar keine Entwicklungsabteilung haben? Das Konzept lässt sich auch einfach auf andere Zuständigkeiten übertragen, indem man Abteilungen kombiniert und von deren Zusammenarbeit profitiert. Dadurch kommen analog zu DevOps viele weitere Bezeichnungen zustande, die inzwischen durchaus verbreitet sind und zu Buzzword-Bingo einladen. Beispiele dafür sind: SecOps, DevSecOps, GitOps, TestOps, NetOps, AIOps, DataOps, WinOps. Oder sogar CatOps – der Kreativität sind keine Grenzen gesetzt. Sinnvollerweise haben diese Abteilungen jedoch gewisse Überschneidungen, so dass eine Zusammenarbeit tatsächlich Prozesse optimieren kann.
Was ist die Quintessenz? Zum einen die wirklich sinnvolle Idee, agile Methoden auch auf Nicht-Entwicklungsbereiche zu übertragen und das Silodenken zwischen verschiedenen Abteilung abzutragen. Zum anderen – leider auch – die inflationäre Verwendung eines Begriffs, vor allem im Marketing, mit all den Nebenwirkungen, die so etwas mit sich bringen kann. Man denke an all das, was man findet, wenn man nach "Agilität" sucht.
Und aus diesem letzten Punkt heraus erklärt sich auch die Herausforderung, eine gute und kompetente Antwort auf die Ausgangsfrage des Textes – "Machen sie eigentlich auch DevOps?" – zu geben: Entweder man wählt den bequemen Weg und gibt die klassische Consultingantwort, die es schon lange vor DevOps gab und die auch in 40 Jahren garantiert noch "funktionieren" wird: "Das kommt darauf an..."
Oder aber man erklärt, dass man als Consultant für seine Kunden durchaus auch DevOps in seiner Gesamtheit – also inklusive des Paradigmenwechsels – "machen" würde. Dass DevOps aber auch ein schwieriger Begriff sein kann und man, falls gewünscht, auch nur einzelne Aspekte davon, wie das Tooling, abbilden und vermitteln könnte. Diese Wahl bleibt jedem Consultant selbst überlassen.
Wir bevorzugen letzteres.
