Suche
Komplexität als Problem

DevOps: Symptom oder Lösung des Problems?

Moritz Hoffmann

DevOps ist der Versuch, ein neues Paradigma in der Software-Entwicklung zu etablieren. Doch nicht alles, was neu ist, löst auch das zugrunde liegende Problem. In all der herrschenden Euphorie um DevOps hat sich der Blogger und Software-Architekt Steven Lott mit kritischen Tönen zu Wort gemeldet. Verschleiert die DevOps-Begeisterung etwa ein tiefer gehendes Problem?

Continuous Delivery, Microservices, Container-Technologien, Cloud Computing und Agilität sind die Schlagworte, unter denen die Produktion und Auslieferung von qualitativ hochwertiger Software in einer kombinierten Arbeitsweise von Development und Operations schneller und einfacher bewerkstelligt werden soll. Was ist das Problem dabei? Für Steven Lott beginnt es bei der Frage, warum DevOps gerade in aller Munde ist.

Man mag die technischen und betrieblichen Vorteile neuer DevOps-Tools und DevOps-Methoden anführen, hat dann aber immer noch zu erklären, warum gerade die konsequente Verzahnung von Entwickler- und Betriebsbereich diese Vorteile bringen soll. Damit ist letztlich das Thema Geschwindigkeit angesprochen, und eben hier setzt auch Lott mit seiner Kritik an.

Diese richtet sich nicht etwa an DevOps per se, als vielmehr an die Richtung, die Enterprise-Entwickler mit Programmierplattformen wie Java eingeschlagen haben. Das Stichwort lautet: Komplexität…zu viel Komplexität! Der Grund, warum die Produktions- und Deployment-Zyklen so langsam wirken, sei nicht in einer falschen Arbeitsstruktur, sondern in der schieren Unmenge an Tools, Frameworks und APIs zu suchen, die Enterprise-Entwicklern bereit stehen.

Bunches of web-based tools to manage the bunch of server-based tools to build and deploy.
Let me emphasize this: bunches of tools.

Was mit DevOps nicht stimmt….

Microservices beschleunigten zwar die Build-Zeiten, führten aber wiederum zu vielen APIs, bis zuletzt für jede Funktion oder Operation ein eigenes API nötig wird. Das wird wiederum in der Anwendung der Continuous Integration und Continuous Delivery relevant, wenn Entwickler unter ständigem Zugzwang Richtung Deployment ihre Server erst einmal testbereit machen müssen. Auch hier gehe, so Lott, wieder unheimlich viel Zeit verloren, um die richtigen Software-Versionen mit den richtigen Produkten verknüpfen zu können, die richtigen Updates zu besorgen, und um schließlich die im Test auftauchenden Probleme zu beheben.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Ein weiterer Sprint ist nötig, um auf die offiziellen QA-Server zu gelangen. Auch hier beschreibt Lott aus Architektensicht einen sprichwörtlichen Irrgarten von VMs und Kompatibilitäten und XML-Konfigurationen. Irgendetwas, darauf ist Verlass, stimmt immer nicht. Um es zusammenzufassen:

What’s important here is that ⅔ of the duration is related to the simple complexity of Java.

Wie komplex darf’s denn sein?

DevOps ist laut Lott demnach lediglich als Versuch zu verstehen, dieser Komplexität Herr zu werden. DevOps führe kein neues Paradigma in die Software-Entwicklung ein, sei kein Trendsetter, kein Fortschrittskatalysator. Vielmehr ein Symptom einer völlig falschen Richtung, die eine sich selbst verschlingende Software-Entwicklung vor einigen Jahren eingeschlagen hat.

Natürlich kann DevOps in diesem Sinne helfen, die Dauer und Komplexität von Anwendungen und Bau von Enterprise-Software zu mindern. Grundsätzlich aber bleibt das Problem, dass mit der in DevOps stattfindenden Raffung nicht weniger, sondern abermals mehr Komplexität einhergeht, wie das Beispiel der Microservices zeigt.

This doesn’t seem right. More complexity to solve the problems of complexity just don’t seem right. […] It feels like DevOps is a symptom and Java is the problem.

Ketten statt Pipelines…

Stattdessen schlägt Lott eine Auslieferungskette der folgenden Art vor: Developer ⇒ QE ⇒ RE ⇒ Users

• Release Engineers reagieren auf die Wünsche der User
• Quality Engineers reagieren auf den Wunsch der Release Engineers, dass das Produkt anwendungsbereit ist
• Entwickler stellen dementsprechend die Software für die Release Engineers bereit
• Ebenso könnten sich Software-Verantwortliche um die Beschaffung, sei es den Kauf, das Leihen oder den Download von Software kümmern.

Weil es hier nicht wirklich eine Top-to-Bottom-Struktur vorherrscht, will Lott das Modell auch nicht als Totempfahl benennen. Eher handele es sich um eine Abfolge zwischen von mehr oder weniger wichtigen Partnern, in der Key Developers einen Wettbewerbsvorteil erarbeiten können.

Die Release-Engineers bringen das Produkt zu den Kunden. Beide Funktionen sind also wichtig. Klar könnten die Entwickler das Deployment auch übernehmen, nur werden sie dann entscheidend langsamer sein. Der Wettbewerbsvorteil ist dahin.

…about Big Things

Worum es Lott im Großen und Ganzen geht, fasst er in einer offenen Frage zusammen:

If a developer is spending time with DevOps (and TechOps) trying to get stuff deployed, who’s developing the Next Big Thing?

Im Rahmen von DevOps scheint diese Frage noch nicht beantwortet zu sein.

 

Verwandte Themen:

Geschrieben von
Moritz Hoffmann
Moritz Hoffmann
Moritz Hoffmann hat an der Goethe Universität Soziologie sowie Buch- und Medienpraxis studiert. Er lebt seit acht Jahren in Frankfurt am Main und arbeitet in der Redaktion von Software und Support Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: