DevOps Teil 9: Missverständnisse und Kritik

Bewerten Sie diesen Beitrag!

Die genannten Ziele von DevOps sind alle nachvollziehbar. Allerdings hat die fehlende Fokussierung der DevOps-Bewegung auf ein klares, übergeordnetes Ziel zu diversen Missverständnissen und Kritikpunkten geführt. Betrachten wir eine Auswahl davon:

  • „DevOps ist nur ein Werbename, um altbekannte Dinge als neu anzupreisen.“ Fast ausnahmslos gehören die Gründer der DevOps-Bewegung selbst zu den Leuten, die schon vorher DevOps- Ansätze verfolgt haben. Sie wissen natürlich, dass viele der vorgeschlagenen Praktiken und Tools keine fundamentale Neuheit darstellen. Dennoch haben sie eine ungeheure Aufmerksamkeit für ein Problem erreicht, über das vorher in der Öffentlichkeit nicht viel geredet wurde. Allein das ist schon ein großer Erfolg. Die Initiatoren der Bewegung betonen übrigens regelmäßig, dass DevOps für sie keine Geldmaschine ist, und müssen sich sogar Vorwürfe gefallen lassen, warum sie nicht versuchen, aus DevOps mehr Kapital zu schlagen [18].
  • „DevOps ist ein Freifahrtschein für Entwickler, beliebigen Schaden auf dem Produktivsystem anzurichten.“ DevOps verlangt nicht, dass die Entwickler Schreibrechte auf den Servern des Produktivsystems oder gar deren Root-Passwort erhalten. Man kann einheitliche Deployment-Prozeduren und Infrastructure as Code auch unter Wahrung gewisser sinnvoller Beschränkungen einsetzen.
  •  „DevOps möchte Entwicklung und Betrieb durch eine Elite von Alleskönnern ersetzen.“ Das Heranzüchten einer solchen Elite wäre absurd. Nicht ohne Grund wurden vor vielen Jahren eine Spezialisierung und die daraus resultierende Trennung von Entwicklung und Betrieb eingeführt. DevOps versucht vielmehr, die Zusammenarbeit und den Wissensaustausch zwischen diesen Bereichen zu verbessern.
  • „DevOps möchte den Betrieb abschaffen und die Entwickler alles machen lassen.“ Dieser Gedanke, oft auch als Ruf nach „NoOps“ formuliert, ist ebenfalls absurd. Die treibende Kraft hinter DevOps sind Beschäftigte im IT-Betrieb, und es ist nicht deren Ziel, sich abzuschaffen.
  • „Mit DevOps müssen wir neue Tools lernen.“ Das mag sein, aber warum so negativ? Es ist für DevOps-Neulinge eine naheliegende Entscheidung, den Einstieg über Tools zu finden. Man kann gerade durch Automatisierung einen schnellen Mehrwert erhalten und außerdem eine gemeinsame Basis für die Zusammenarbeit von Entwicklung und Betrieb schaffen. Interessant in diesem Zusammenhang ist eine Umfrage, die Replay Solutions im Frühjahr 2011 durchgeführt hat und laut der Tools als sehr wichtig für den Erfolg von DevOps angesehen werden. Verbesserungen erhoffen sich die Befragten vor allem beim Defect Tracking und der Versionskontrolle [19]. Eine Umfrage von Puppet Labs vom Sommer 2011 bestätigt diesen Eindruck: Mit deutlichem Abstand wird die Automatisierung, z. B. mit Tools zum Konfigurationsmanagement, als größte erhoffte Verbesserung durch DevOps genannt [20]. Danach erst folgen abstraktere Ziele wie die Optimierung von Deployment-Prozessen oder die Verbesserung der Kommunikation zwischen den Abteilungen.
  • „Manchen Leuten kann man einfach keinen Respekt entgegenbringen.“ Tatsächlich entstehen Respekt und Vertrauen nicht auf Knopfdruck, sondern müssen durch Leistung „erworben“ werden. Man wird immer wieder Leute finden, die keine ausreichende Leistung bringen und deshalb niemals das Vertrauen ihrer Teammitglieder erhalten. Dennoch gilt im Kontext von DevOps: Entwicklung und Betrieb müssen zunächst einmal verstehen, was die jeweils andere Seite eigentlich macht und wie die alltäglichen Herausforderungen aussehen, bevor sie deren Leistung auch nur entfernt beurteilen können. Letzten Endes sind Teammitglieder, die mangelhafte Leistung bringen, natürlich ein Problem, aber kein spezielles von DevOps.
  • „DevOps wird durch PaaS-Angebote überflüssig.“ Das ist eine ernstzunehmende Kritik, denn die Nutzung so mancher Cloud-Angebote kann die konkreten Aufgaben des Betriebs deutlich beeinflussen. Die Entgegnung der DevOps-Verfechter ist, dass durch PaaS lediglich eine weitere Abstraktionsschicht bzw. neue Schnittstelle für die klassischen Funktionen des Betriebs (wie Deployment, Monitoring und Sicherstellung der Qualitätsanforderungen) entsteht. Man kann also trotzdem nicht ohne Betrieb auskommen.

Links & Literatur

[18] http://teddziuba.com/2011/03/devops-scam.html

[19] http://replaysolutions.com/2011-DevOpsSurveyResults

[20] http://rww.to/qiAxu1

Dies ist ein Teil des Artikels „Die DevOps-Bewegung – Was ist das eigentlich und was bedeutet es für uns?“ von Dr. Patrick Peschlow.

Die Einleitung zum Artikel finden Sie hier. Das vorige Kapitel erreichen Sie hier, und hier geht es weiter zum nächsten Kapitel.

Stichworte:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close