Leserfrage: Seit Jahrzehnten herrscht eine strikte Trennung zwischen Software-Entwicklung (Development) und IT-Betrieb (Operations). Aber jetzt stehen auf einmal immer wieder Berater auf der Matte, die meinen, das würde – wegen dem massiven Virtualisierungs-Trend – nicht zu den Erfordernissen der digitalen Transformation passen. Continuous-Delivery soll sich so zum Beispiel nicht realisieren lassen. Müssen sich Administratoren tatsächlich damit befassen? Was sind die Vor- und Nachteile von DevOps?

Antwort Doc Storage:

Sie kennen meine »Liebe« zu den Beratern, die Ihnen meist gesunden Menschenverstand als etwas völlig Bahnbrechendes verkaufen wollen. Aber so ist es – leider – auch hier. Im Gegensatz zu früher, als die EDV jedes Geld hatte und (fast) alles durfte, der heimliche Regent der Unternehmen war, Prozesse definierte und ganze Firmen praktisch lenkte, ist in den letzten Jahren eine Revolution durch unsere Rechenzentren gegangen, die alle Ungelernten wie Wirtschaftswissenschaftler oder Buchhalter zu Regenten unseres Handelns gemacht haben. DevOps (Entwicklung und operatives DV-Geschäft in einem) und Continous-Delivery (kontinuierliches Ausrollen von Anwendungen) sollen den RZ-Betreiber zwingen, unter dem vorgeblichen Mäntelchen der Kosteneinsparung Entwickler- und operative Umgebungen zu verschmelzen sowie die Entwickler dazu zu bringen, jederzeit in der Lage zu sein, die neueste Version einer Anwendung auszurollen.

DevOps: zwei völlig andere Arbeitsweisen

Auf den ersten Blick scheint die Verschmelzung sinnvoll. Gemeinsame Nutzung von Rechnern, Netzwerk und Speichern, dadurch weniger Gerätschaften, weniger Energieverbrauch und weniger Klimatisierungsaufwand. Wenn wir den Blick allerdings über den Taschenrechner hinaus schweifen lassen, sehen wir die völlig andere Arbeitsweise von Entwicklern im Vergleich zu normalen Nutzern in derselben Umgebung. Da müssen einmal, weil es eben schnell gehen soll, möglichst viele Ressourcen an Rechen- und Speicherleistung zur Verfügung stehen, um ein Kompilat zeitnah fertigzustellen. Was machen in diesem Moment Datenbanken oder andere transaktionslastige Anwendungen aus der Produktion? Die dürfen sich entweder hintenanstellen, werden dadurch mehr oder weniger unbrauchbar aufgrund langer Lieferzeiten, oder blockieren den Entwickler dermaßen, dass er seine Arbeit auf die Nacht- oder Wochenendstunden verlegen muss.

Und es komme mir niemand mit Tiering, Kapazitäts-, Bandbreiten- und I/O-Beschränkung für einzelne Anwendungen. Wir alle, die wir dies schon einmal im RZ angewendet haben, wissen, dass wir den Tiger hiermit vielleicht bändigen, aber beileibe nicht ungefährlicher machen. Wir dürfen einen Grundsatz der Informatik niemals vergessen, der von keinem geringeren als Charles Darvin stammt: »Die Natur findet einen Weg.« Und die Natur, das ist in diesem Falle das Rudel an Entwicklern, welches mit absolut tödlicher Sicherheit einen Weg finden wird, sich zu genau dem Zeitpunkt die meisten der RZ-Ressourcen zu reservieren, zu dem sie sie brauchen. Und eben NICHT, zu welchem Sie als RZ-Verantwortlicher meinen, dass sie sie brauchen müssen. Dies ist das Gefährliche an DevOps.

DevOps lässt den »Wolf ins Schafsgehege«

Die Trennung in operatives und Entwicklergeschäft macht beide Seiten berechenbar, hält die Entwickler von den umsatzbringenden Anwendungen fern und ermöglicht weiterhin, Ressourcen nur auf der Seite erweitern zu müssen, wo sie in einem bestimmten Moment gebraucht werden. DevOps öffnet den Wölfen die Tore zum »Schafsgehege«: Die Schäfer können nur mit dem Stöckchen wedeln und ihre einzelnen Tiere verteidigen. Während eines gerettet wird, hat sich der Wolf schon einem anderen zugewendet und verschwindet damit in den Wald.

Continous-Delivery oder Release-Management

Kaum anders verhält es sich mit dem in diesem Zusammenhang gern propagierten Continous-Delivery (CD). Hiermit soll den Entwicklern aufgezwungen werden, jederzeit in der Lage zu sein, die neueste Version einer Anwendung auszurollen. Darf ich an die Berater einmal die Frage stellen wozu? Sollte es nicht im Interesse des Unternehmens liegen, den Entwicklern genau so viel Zeit zu lassen, wie sie zur Fertigstellung eines neuen Release mit den vereinbarten Eigenschaften brauchen? Wir benötigen kein CD, wir benötigen das, was wir schon seit Jahrzehnten – übrigens absolut erfolgreich – betreiben, nämlich Release-Management plus Projektentwicklungspläne, denen sowohl die Entwickler als auch die Kunden entnehmen können, wann mit welcher Eigenschaft der Software gerechnet wird. Das bedeutet – richtig – längere Release-Zyklen, garantiert aber auch, dass Entwickler nicht einen erkläglichen Teil ihrer kostbaren Zeit mit kompilieren und packetieren verbringen, nur um einer sinnlosen aber modernen Doktrin zu folgen.

Ich habe bis heute kein einziges Rechenzentrum gesehen, dass Geld dadurch einspart, indem es weniger ausgegeben hat. Eventuell eingesparte Investitionen in eine separate Entwicklungs-Infrastruktur rächen sich aus den genannten Gründen schnell und bitterlich.

Gruß
Doc Storage