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.

Anzeige

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 14.12.2018 NAS: Probleme beim Rebuild mit geklonten HDDs

Bei einem User stellt sich eine HDD in einem 3-Bay-NAS als defekt heraus. Einer von mehreren Maßnahmen ist der Versuch die vorhandenen Platten auf neue zu klonen. Dies bringt aber auch nicht den gewünschten Erfolg. Mögliche Ursachen: Das NAS arbeitet mit den Seriennummern und es darf die Reihenfolge der HDDs nicht verändert werden.


30.11.2018 Das Ende der Cebit ist ein Trauerspiel – ein Rant

Seit Jahren siechte die Cebit ihrem Ende entgegen. So formulierten es Experten und auch unser Doc Storage bereits mehrfach. Das Aus war quasi schon beschlossen, dürfte aber trotzdem nicht sein. Das Ende der Cebit belegt auch, wie schlecht es um den Digitalstandort Deutschland bestellt ist. Ein Rant von Doc Storage…


16.11.2018 Was ist das HAMR-Verfahren?

Herkömmliche Festplatten sind beschränkt in ihrer Kapazitätssteigerung. Neue Verfahren sollen das ändern, so unter anderem das Heat-Assisted Magnetic Recording (HAMR). Die Technik arbeitet mit einem Laser, noch fehlen aber fertige Serienmodelle. Doc Storage erklärt, was Sie dazu Wissen sollten.


02.11.2018 Kann man ehemalige NAS-HDDs ohne NAS auslesen?

Manchmal kann der Doc Leserfragen zwar schlüssig erklären, hat aber keine guten Nachrichten: Zwei Festplatten wurden aus einem Synology-NAS ausgebaut und nun wundert sich der Anwender, warum er nicht mehr auf die Dateistruktur zugreifen kann. Es gibt mögliche Chancen, die bringen aber selbst Profis ins Schwitzen.


19.10.2018 NAS: Wie viele Volumes sind sinnvoll?

Die Ausgangslage ist ein Desktop-NAS mit RAID-5-Verbund. Wie ordnet man hier am sinnvollsten seine Daten? Ist es besser ein einziges Standard-Volume nutzen oder zu versuchen mit mehreren Volumes eine Struktur aufzubauen? Wie viele Volumes sind sinnvoll?


12.10.2018 Was bringt NVMe-oF und NF1?

Kürzlich wurde mit Mission Peak ein neues skalierbares und angeblich hochperformantes Speichersystem vorgestellt. Das Gerät basiert auf NVMe-oF und nutzt NF1-SSDs. Sind diese Technologien wirklich so toll? Wie hoch darf man die Erwartungen schrauben?

powered by
TIM DCP Datacore Software
N-TEC GmbH Unitrends
Fujitsu Technology Solutions GmbH