Miteinander statt aneinander vorbei

Entwicklung und IT-Betrieb haben vor allem in größeren Unternehmen meist nicht viel miteinander zu tun. Die Entwickler programmieren, der IT-Betrieb sorgt für den Einsatz der Ergebnisse und stellt - oft für nur kurze Zeit - Testumgebungen zur Verfügung. Die Folge ist oftmals eine fehlende Abstimmung zwischen beiden Bereichen.

Dadurch dauert die Inbetriebnahme neuer Software lang, oft trifft zudem die Anwendung trotz ausufernder Spezifikationen nicht die exakten Wünsche der Anwender. Die Anforderungen haben sich bis zur Freigabe wahrscheinlich schon wieder geändert, so dass das Produkt zur Auslieferung schon wieder veraltet ist ("dead on delivery"). Das gilt insbesondere für Web- und Mobile-Applikationen.

Zudem ist die Kommunikation zwischen Entwicklung und Betrieb bei Problemen oft ungenügend, wodurch sich Ausfälle in die Länge ziehen können. Weitere Folgen der unzureichenden Kooperation: Softwarewildwuchs, Sicherheitslücken und zu hohe Kosten.

Die Entwicklung reagierte zuerst

Auf den "Need for Speed" reagierten die Entwicklungsbereiche zunächst mit agiler Programmierung. In Scrums, einzelnen, oft nur ein oder zwei Wochen dauernden Programmierphasen, entstehen dabei Teilfunktionen, die anschließend vom Kunden abgenommen und später gegebenenfalls erweitert oder modifiziert werden. Doch im IT-Betrieb ging es bisher weiter wie gehabt.

Der Gedanke, dass die beiden Bereiche wesentlich enger verzahnt werden müssten, wird zwei Männern zugeschrieben: dem belgischen IT-Consultant Patrick Dubois und Andrew Shafer, Senior Director Technology bei der EMC-Tochterfirma Pivotal. So berichtet jedenfalls der auf DevOps spezialisierte Blog ITRevolution. Demnach gründeten Dubois und Shafer im Social Network Google+ 2009 eine Agile System Administrator Group. Im selben Jahr fanden in Gent internationale "DevOps Days" statt.

Inzwischen hat sich DevOps vor allem im angloamerikanischen Raum ziemlich weit verbreitet. In Europa gestaltet sich der Umgang mit dem Thema bisher eher zögerlich, wie eine von T-Systems Multimedia Solutions in Auftrag gegebene Spotlight-Analyse des Beratungsunternehmens PAC belegt.

Aber was ist DevOps nun eigentlich? - Jedenfalls ist es kein Produkt. Vielmehr handelt es sich eher um ein Bündel bisher kaum kodifizierter Best Practices, Methoden und Tools, die aber auch die Struktur der Software beeinflussen. Und was ist das Ziel? Programme und Versionen sollen in kurzen Zyklen und im Gleichtakt mit dem IT-Betrieb bereitgestellt werden. Statt monolithischer Programme entstehen kombinierbare Mikroservices. Daraus können beispielsweise Cloud-Provider schnell immer wieder neue Services zusammenstricken, zumindest in der Idealvorstellung.

Fehler im Entwicklungsprozess sollen dank DevOps früher aufgedeckt, Kompatibilitätsprobleme, etwa mit der Einsatzumgebung, von vornherein vermieden werden. Testequipment steht fast ohne Wartezeiten sowie ausreichend lang bereit, bei Fehlern wird die Ursache schnellstmöglich gefunden und behoben, denn hierfür ist ja gerade bei neuen Produkten die Hilfe der Entwickler meist unabdingbar.

Inzwischen gibt es auch eine Reihe von Open-Source-Tools für nahezu jede Phase im Produktlebenszyklus einer nach DevOps-Prinzipien entwickelten und genutzten Software (siehe "Produkte für DevOps" auf Seite 28). Die Softwareriesen haben ebenfalls erkannt, dass sie an der neuen Welle nicht vorbeikommen, und stellen ihre Toolboxen auf DevOps um. Ob dabei aus Anwendersicht mehr als Wortgeklingel herauskommt, muss abgewartet werden.