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 28.08.2020 Kommt mit QLC-Flash das Ende hybrider Speichersysteme?

Die ersten Arrays mit QLC-Flash-Technologie kommen auf den Markt. Einige Hersteller prophezeien durchaus vollmundig das Ende von hybriden Speichersystemen, also solchen mit Flash und Festplatten. Ist dieses Ende tatsächlich absehbar oder wie sieht die Zukunft in diesem Bereich aus?


21.08.2020 Mehr in die Zukunft agieren, weniger jammern

Jammern ist gerade irgendwie in Mode. Der Virus, der Markt, die Geschäfte – natürlich ist es aktuell schwierig. Für die Kunden gestaltet sich vieles aber positiv, braucht es doch weniger Manpower, um Produkte und Lösungen in Betrieb zu nehmen. Das macht sich im Geldbeutel bemerkbar. IT-Anbieter müssen künftig nicht nur in Studien in die Zukunft schauen, sondern sich generell schneller anpassen und auf neue Gegebenheiten reagieren.


07.08.2020 Marktstudien: Ergebnisse meist zu offensichtlich

Marktstudien belegen in der Regel bekannte Trends, mehr nicht. Wirkliche Erkenntnisse oder Neues fördern sie, laut Doc Storage, nicht zu Tage. Dies belegt er anhand zweier aktueller Beispiele: Die Analysekriterien sind schwammig, die Argumente eher fadenscheinig und die Resultate offensichtlich. Zudem sei fragwürdig, in wie weit Sponsoren die Ergebnisse beeinflussen.


31.07.2020 Business-Continuity: Zu viele Firmen unvorbereitet auf K-Fall

Jüngste Studien sprechen von einem steigenden Bewusstsein in Sachen Business-Continuity. Doc Storage kann den Zahlen allerdings wenig positives abgewinnen, denn noch nicht mal zwei Drittel aller Unternehmen besitzen einen Business-Continuity-Plan und fast die Hälfte verfügt über keine fest definierte Rückkehrmaßnahmen. Aus seiner Sicht ist es erschreckend, wie viele Firmen und IT-Abteilungen nicht auf einen Katastrophenfall vorbereitet sind.


24.07.2020 Ist Archiving-to-the-Cloud heute bereits sinnvoll?

Unsere Archivierungs-Hardware bedarf der Erneuerung. Bislang setzten wir auf LTO-6-basierende Tape-Librarys. LTO-7 haben wir bisher übersprungen. Nun stünde LTO-8 an. Aber es gäbe auch Archiving-to-the-Cloud. Macht es Sinn, sich damit ernsthaft zu befassen oder raten Sie weiterhin On-Premises?


17.07.2020 EU/US-Privacy-Shield: Datenaustausch nicht mehr rechtens

Das EuGH erklärt das EU/US-Privacy-Shield für unwirksam. Damit ist die Hauptgrundlage für Datentransfers zwischen der EU und den USA nicht mehr gültig. Für unseren Doc Storage ist dies keine Überraschung, weil jeder klardenkende EU-Bürger wusste, dass die US-Behörden am Schutz unserer Daten nicht wirklich interessiert waren. Lesen Sie hier seine generelle Einschätzung zur Thematik.

powered by
N-TEC GmbH FAST LTA
Cloudian Fujitsu Technology Solutions GmbH
Infortrend Zadara
Folgen Sie speicherguide.de auch auf unseren Social-Media-Kanälen
Folgen Sie und auf Facebook Folgen Sie und auf YouTube Folgen Sie und auf Twitter