Was ist eigentlich DevOps?

Missverständnisse rund um DevOps – und wie man es richtig macht
Kommentare

Sei es auf Konferenzen oder in Aufsätzen und Büchern – zurzeit wird der Begriff DevOps in der IT-Welt rege diskutiert. Das Interesse ist verständlich, denn zahlreiche IT-Abteilungen suchen nach Wegen, wie sich ihre Unternehmen aus der bestehenden Mischung aus verzögerten Projekten, fragwürdiger Produktqualität und verpassten Lieferterminen befreien können.

DevOps besitzt das Potenzial, viele Herausforderungen im IT-Umfeld zu bewältigen. Firmen und Organisationen, die DevOps bereits einsetzen – etwa Netflix, Walmart, Amazon oder Facebook – zeigen, dass die Grundsätze von DevOps dazu beitragen können, sich von Wettbewerbern abzusetzen. Entwickler-Teams können so Software mit besserer Qualität schneller umsetzen. Dadurch steht DevOps kurz davor, der neue Branchen-Standard für Software-Entwicklung zu werden.

Allerdings schleicht sich bei aller Begeisterung der Verdacht ein, dass nicht jeder dasselbe unter DevOps versteht. Diese Befürchtung verstärkt sich, wenn CTOs und Anbieter behaupten, sie würden DevOps „machen” oder Tools dafür anbieten. Vor diesem Hintergrund ist es sinnvoll, die verschiedenen und teils unsauberen Interpretationen von DevOps zusammenzuführen und zu vergleichen.

Was ist DevOps nun wirklich?

Was ist DevOps nicht? DevOps ist keine Methodik oder ein Prozess, auch kein einzelnes Tool oder eine Technologie. Tatsächlich kann man DevOps nicht einmal eindeutig den Bereichen Entwicklung und Betrieb zuordnen. DevOps ist auch keine Software-as-a-Service-Anwendung, auch wenn viele Unternehmen, die erfolgreich DevOps nutzen, aus diesem Bereich stammen.

Stattdessen wird DevOps nach gängigem Konsens als Teil der Unternehmenskultur mit bestimmten Prinzipien verstanden, die ein Unternehmen anstrebt und langfristig befolgt. Anhänger dieser Kultur schätzen Zusammenarbeit, Experimentierfreude und Lernbereitschaft. Alle Beteiligten einer DevOps-Kultur richten sich im gesamten Software-Delivery-Lifecycle (also nicht nur in Entwicklung und Betrieb) auf ein Ziel aus: die schnelle Umsetzung von stabiler, hochwertiger Software, angefangen beim Konzept bis hin zum Kunden oder Anwender.

Auch wenn nicht zwingend erforderlich, so ist die Automation von Software-Entwicklung, -Test und -Deployment durch Continuous Delivery (CD) ein anerkannter Schlüsselfaktor für DevOps. Automation ermöglicht eine schnellere Software-Umsetzung und stellt sicher, dass die Lösungen über die benötigte Qualität, Sicherheit und Stabilität verfügen.

DevOps Trinity

Vereinfacht betrachtet konzentriert sich DevOps auf die Zusammenführung aller Beteiligten des Software-Entwicklungszyklus auf drei Ebenen: Personal, Prozesse und Werkzeuge. Daher spricht man auch von der DevOps Trinity (Dreieinigkeit).

In der Praxis führen Missverständnisse über DevOps selbst – oder der Versuch einer übereilten Einführung – häufig dazu, dass Unternehmen diese Aspekte nicht vollständig beachten. Was nahezu unweigerlich zum Scheitern der Einführung und zur Nichterfüllung der Erwartungen führt.


Ein Beispiel wäre ein Unternehmen, das den vorausgesetzten Kulturwandel ablehnt und DevOps daher vorrangig als Tool- und Technologie-Unterfangen versteht. Man investiert einen signifikanten Betrag in automatisierte Testverfahren, vernachlässigt dabei jedoch, den Fokus auf die Qualität zu richten. Entsprechend unengagiert durchlaufen die Teams die Prozesse – und das ohne aktiv sicherzustellen, dass der notwendige Qualitätsanspruch gewahrt wird. Zu den wichtigsten Qualitätsaspekten gehören das Setzen wirksamer Qualitätsziele, die Einführung von Automation, zumindest bis zu einem gewissen Grad, sowie die Zusammenarbeit über Abteilungsgrenzen hinweg. Letzteres erlaubt es den Teams, Probleme frühzeitig und schnell zu korrigieren. Ohne diese Aspekte wird ein Unternehmen auf Dauer kaum Verbesserungen in der Qualität sehen. Stattdessen „erkauft“ man sich die schnelle Umsetzung fast zwangsläufig mit stetig sinkender Qualität. Auf Dauer sind Defekte im Code und das damit verbundene „Firefighting“ die Folge.

Umgekehrt scheitern auch diejenigen Unternehmen, die sich zwar dem kulturellen Wandel öffnen, aber weder agile Methoden noch automatisierte Tools einführen. Manuelle Schritte, starre Prozessstrukturen und umständliche Legacy-Werkzeuge sorgen dafür, dass die Erwartungen unerfüllt bleiben und die DevOps-Transformation letztendlich als fehlgeschlagene Initiative enden wird.

DevOps definieren

DevOps lässt sich in Form ganz unterschiedlicher Modelle definieren und beschreiben, die auf ihre Art alle richtig sind und zu einem tieferen Verständnis sowie einer nahtlosen Einführung führen können. Ein gutes Beispiel hierfür findet man in Three Ways of DevOps im Buch The Phoenix Project von Gene Kim. Es gibt natürlich große Schnittflächen zwischen den dort beschriebenen Wegen – systematisches Denken, Verstärkung von Feedbackschleifen, fortgesetztes Experimentieren und Lernen – und den bereits vorgestellten Prinzipien. Ein anderes Beispiel ist das sogenannte CAMS-Modell, das sich mit seinem Fokus auf Kultur, Automation, Management und Sharing ähnlich stark überschneidet.

Auf Basis des Drei-Ebenen-Modells gibt es eine weitere Definitionsmöglichkeit von DevOps, die viele IT-Fachleute anspricht. In diesem Gerüst setzt sich der Software-Development- Lifecycle aus zwei Hälften zusammen, Upstream (Development) und Downstream (Betrieb). Sie sind Teile desselben Software-Umsetzungsprozesses, doch sind die Hälften bei vielen Non-DevOps-IT-Unternehmen weitgehend abgekoppelt (Abbildung 1).

Abb. 1: Die Trennung zwischen Upstream- und Downstream-Personal, -Prozessen und -Werkzeugen.

Abb. 1: Die Trennung zwischen Upstream- und Downstream-Personal, -Prozessen und -Werkzeugen.

Im Upstream priorisieren die Entwickler Geschwindigkeit und Innovation, während im Downstream für den Betrieb der Schwerpunkt auf Qualitätseinhaltung, Stabilität und Uptime liegt. Upstream werden Point Tools für die Definition und Entwicklung von Software nach agilen Methoden verwendet. Downstream sind hingegen professionelle Werkzeuge für Testmanagement, Release, Deployment und Betrieb der Software die Norm. In Downstream-Meetings spricht man auch eher über Themen aus den Bereichen ITIL (Information Technology Infrastructure Library) oder PMBOK (Project Management Body of Knowledge) als über Kanban oder die letzte Scrum-Phase.

DevOps will diese beiden Welten vereinen und die Kluft zwischen Upstream und Downstream überwinden.

Wie DevOps funktioniert

Für Unternehmen stellt sich die Frage, wie man DevOps am besten erreicht. Tatsächlich gibt es einige grundlegende Schritte, mit denen jede Organisation den Weg für DevOps bereiten kann. Ein guter Anfang ist, im Upstream mit agiler Entwicklung und Continuous Integration (CI) zu beginnen. Gleichermaßen kann man im Downstream mit Continuous Delivery (CD) arbeiten. Der Erfolg beim Einsatz von CI und CD wird dabei stark durch Automation beeinflusst. Automation spart nicht nur Zeit, sondern reduziert auch Defekte, steigert die Konsistenz und ermöglicht Self-Service-Funktionen.

Automatisierte CI- und CD-Prozesse, in Verbindung mit offener Kommunikation und Kollaboration innerhalb der Unternehmensstruktur, können die Trennung zwischen Upstream und Downstream überwinden und so den Grundstein für eine DevOps-Transformation legen.

Agile Methoden, CI und CD liefern die Basis für eine DevOps-Transformation.

Abbildung 2: Agile Methoden, CI und CD liefern die Basis für eine DevOps-Transformation.

Die Diskussion über das Wie bei DevOps wird häufig zu sehr auf den technologischen Teil reduziert, auf den Zeitraum zwischen Code-Submission durch die Entwickler und Deployment der Software auf einem Server. Es ist aber genauso wichtig, sicherzustellen, dass die Bedürfnisse des Kunden verstanden werden. Im Anschluss kann entsprechend eine Lösung geplant und definiert werden. Weitere Schritte betreffen die Umsetzung und den Support, sobald das Programm in Betrieb geht. Die Feedbackschleife muss dabei weiter gefasst werden als nur in Bezug auf Dev und Ops. Daher ist es so wichtig, zu verstehen, dass DevOps als Prozesskette vom Konzept bis zum Kunden reicht.

Dabei sollte man im Hinterkopf behalten, dass die Vorteile einer DevOps-Einführung im Unternehmen nicht sofort voll zum Tragen kommen, sondern dass sie sich über die Zeit hinweg akkumulieren. Je stärker und konsistenter sich der Wandel verfestigt, desto mehr kann das Unternehmen die Fähigkeiten zur schnelleren und besseren Software-Umsetzung in einen Wettbewerbsvorteil ummünzen. Gleichzeitig steigen Innovationskraft und Effizienz – und das Unternehmen kann schneller auf Bedürfnisse des Marktes reagieren.

In Teil 2 dieses Artikels erklärt Brian Dawson warum DevOps so wichtig ist.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -