08.01.2016 (Doc Storage)
3 von 5, (17 Bewertungen)

DevOps: Mehr Nachteile als Vorteile?

  • Inhalt dieses Artikels
  • DevOps: zwei völlig andere Arbeitsweisen
  • DevOps lässt den »Wolf ins Schafsgehege«
  • Continous-Delivery oder Release-Management

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

Stellen Sie Ihre Frage
Doc. tec. Storage beantwortet alle Ihre technischen Fragen zu Storage, Backup & Co.

Stellen Sie Ihre Frage an: DocStorage@speicherguide.de
Kommentare (4)
15.10.2018 - Chaos

Es mangelt hier offensichtlich ein Verständnis der heutigen Softwareentwicklung. Die Ausführungen sind grundsätzlich richtig, beschreiben aber ein seit vielen Jahren veraltetes Bild von monolitischen Softwaresystemen.

Modernere Konzepte wie das DevOps sind jedoch für solch veraltete Systeme nicht ausgerichtet. Jeder der moderne Software-Entwicklung versteht, dem sollte klar sein, dass das DevOps für Service-orientierte-Architekturen ausgelegt ist, die beinahe täglich released werden können und teilweise müssen.

Monolitische Systeme haben selbstverständlich auch heute noch ihre Daseinsberechtigung und für diese sind DevOps in der Tat nur bedingt geeignet, aber es ist nicht angemessen ein Konzept schlecht darzustellen, wenn man dieses in einem sichtlich falschen Bezugsrahmen einsetzt.

11.01.2016 - ch

Entwicklung und Betrieb sind in der Tat zwei verschiedene Bereiche und damit verschiedene Arbeitsweisen - aber zusammen hängen tun sie allemal, daher macht intensive Kommunikation und Zusammenarbeit Sinn. Und dann ist da noch die Sache mit der Continous Delivery. Ich sehe das so, dass hier eher Zeit gespart werden kann...unsere Welt verändert sich viel zu schnell, um ein halbes Jahr auf ein SW Release zu warten, dessen Features vielleicht vor 9 Monaten definiert wurden. Ein einziger - oder lange Zyklen beim Release bergen schlicht und ergreifend das Risiko, ein "falsches", nämlich dem Markt nicht gerecht werdendes Produkt zu liefern. Die agilere Arbeitsweise mit regelmässigen Releases gibt die Chance, das Produkt beim Kunden zu testen (ob interner oder externer Kunde ist irrelevant) und zu prüfen, ob es die Anforderungen erfüllt, die tatsächlich für das Business notwendig sind...nicht mehr (also kein "Gold plating") und nicht weniger. Und was genau das ist, bedarf der ständigen Überprüfung. Und während das Produkt dann frühzeitig eingesetzt wird und permanent verbessert wird (wo sinnvoll und nötig), kann es schon für Umsatz oder Prozessverbesserungen (in aller Regel dann auch verbunden mit besseren Ergebnissen) sorgen.

11.01.2016 - KOM

Habe ich DevOps falsch verstanden? Ich bin bisher davon ausgegangen, dass mit DevOps hauptsächlich eine bessere Zusammenarbeit zwischen Entwicklung und Betrieb erreicht werden soll. Dies beinhaltet im besten Fall, wohl auch das teilen der gleichen Plattform. Aus meiner Sicht ist dies aber die letzte Ausbaustufe. Als viel wichtiger erachte ich jedoch die verbesserte Kommunikation und Abstimmung der Prozesse. So würde ich mir als "Betriebler" oft wünschen, bereits im frühen Stadium der Entwicklung die Bedürfnisse des Betriebes einfliessen zu lassen.

08.01.2016 - joachim.stephan

Sehr schlüssige Argumentation. Ich frage mich, wer auf solch einen Unsinn kommt. Allein der Punkt "jederzeit in der Lage zu sein, die neueste Version einer Anwendung auszurollen" ist für jeden, der nur einen Hauch Ahnung von Softwareentwicklung hat, das Aus für diesen Ansatz.


Mehr von Doc. tec. Storage 12.07.2019 Analysten-Prognosen sind verschwendete Lebenszeit

Diesmal nimmt sich Doc Storage die Trendvorhersagen von Marktforschern vor. Seiner Ansicht nach ist vieles nur ein Blick in die Glaskugel, anderes dagegen so offensichtlich, dass es keine weitere Betrachtung benötige. Er hält diese Art von Info für verschwendete Lebenszeit.


28.06.2019 DSGVO bleibt aus DV-Sicht ein unsägliches Thema

Kolumne: Unser Doc Storage ist kein Freund der DSGVO. Dies hat er in mehreren Kolumnen klar formuliert. In seinem zweiten Teil zu »Ein Jahr DSGVO« fasst er nochmal zusammen, warum die Thematik aus seiner DV-Sicht für Firmen unsäglich ist.


14.06.2019 Ein Jahr DSGVO: Aufwand unerträglich hoch

Kolumne: Zur Einführung der DSGVO hat Doc Storage mächtig Dampf abgelassen. Ein Jahr später lässt kaum ein Verband ein gutes Haar an der Datenschutz-Grundverordnung. Der Aufwand für Firmen und IT-Abteilungen sei unerträglich hoch.


07.06.2019 Welchen Flash für welche Anwendung?

Vor rund sechs Jahren schickten sich Flash-Speicher an, sich in Computern und Storage-Systemen zu etablieren. Damals galten die Lösungen aber noch als proprietär. Wo steht die Technik heute und welcher Flash eignet sich für welchen Einsatzzweck?


17.05.2019 NAS-Caching oder Tiering für VMs multiple Zugriffe?

In einer Lehrumgebung werden virtuellen Maschinen auf einem NAS mit 10GbE-Anbindung gespeichert. Nachdem eine Erweiterung mit NVMe-Flash ansteht, stellt sich die Frage, ob eine Caching- oder eine Tiering-Konfiguration die sinnvollere Wahl ist?


10.05.2019 Wird Flash nun auch zum Backup-Medium?

Flash wird zunehmend auch für Backup interessant. Der Geschwindigkeitsvorteil soll die Dauer der Sicherung wie auch der Wiederherstellung reduzieren. Macht dies in der Praxis bereits Sinn – auch aus Kostensicht?

powered by
Boston Server & Storage Solutions Datacore Software
Itiso GmbH Seagate Technology
N-TEC GmbH FAST LTA AG
Fujitsu Technology Solutions GmbH Infortrend