In the Code: DevOps - Clash of Cultures oder alles in Minne?

DevOps, 2009 als Ansatz proklamiert, Software-Entwicklung und Betrieb besser zu "verdrahten", scheint mittlerweile ein alter Hut. Doch das Konzept verfolgt nicht mehr und nicht weniger als das Ziel, IT grundlegend zu überdenken.
 
Das Konzept "DevOps" zielt darauf ab, gegensätzliche Anreize für Software-Entwicklung und Betrieb auszubalancieren: Vereinfacht gesagt, ist die Entwicklung an häufigen und schnellen Release-Zyklen interessiert. Der Betrieb hingegen setzt alles daran, den Zustand einer stabil laufenden Anwendung nicht durch Änderungen – geschweige denn unausgereifte – zu gefährden.
 
Die Entwickler werden an ihrer Flexibilität, Kreativität und Experimentierfreudigkeit gemessen. Die Betreiber hingegen an Stabilität, Performance und Verfügbarkeit. Dieser Interessenskonflikt führte in der Vergangenheit zu oft dazu, dass es für die Entwickler völlig irrelevant war, ob neue Features überhaupt ins Produktionssystem gelangten. Und andersherum waren aufseiten des Betriebs oftmals die Bedenken zu gross, Updates einzuspielen, weil man um die Performance oder Sicherheit der Produktivumgebung fürchtete. Hinzu kommt, dass Dev und Ops zumeist unter Zeit- und Erfolgsdruck aufeinandertrafen, nämlich beim Deployment eines neuen Releases oder bei Problemen, wie beispielsweise einem Systemausfall.
 
Der Betrieb als Flaschenhals
Doch sind gemischte Teams und Verantwortlichkeiten die Lösung? Die Frage stellt sich, ob die Zusammenführung der unterschiedlichen Welten – Philosophien, Herangehensweisen, Kulturen – überhaupt sinnvoll und machbar ist. Die gegenwärtige Diskussion wird zumeist aus der Entwickler-Sicht geführt. Agile oder Lean Software-Development wird als Antwort auf fast alle Herausforderungen der digitalen Transformation gesehen, bei der das Business, der Entwickler und der Endkunde so nahe als möglich aneinander rücken. Der Betrieb wird auf diesem verkürzten Weg von der Applikation zum Nutzer als hemmend, als Flaschenhals, empfunden.
 
Zwar wird die DevOps-Bewegung mittlerweile auch massgeblich vom Betrieb her getrieben: Bei Agile Operations oder Agile System Administration werden agile Methoden aus der Software-Entwicklung in den Betrieb getragen. Doch selbst wenn gemäss einer Studie von Pierre Audoin Consulting (PAC) bereits fast zwei Drittel der IT-Verantwortlichen DevOps als relevant für ihr Unternehmen einschätzen, stösst das Modell auf beiden Seiten nach wie vor auf Skepsis und der endgültige Durchbruch in der Praxis steht noch aus.
 
Mit "Kulturwandel" ist es nicht getan
Jede Bewegung ist nur so stark, wie sie von den Beteiligten getragen wird. Die zwischenmenschliche Komponente, die unterschiedlichen Persönlichkeitstypen in Entwicklung und Betrieb auszutarieren, darf nicht unterschätzt werden. Doch nur mit dem Buzzword "Kulturwandel" ist es nicht getan. Drei weitere Elemente sind ebenso wichtig, damit DevOps im Arbeitsalltag funktionieren: Toolset, Automatisierung, Prozesse.
 
Toolset
Von den Gartner-Marktforschern stammt der Begriff der "bimodalen" IT. Die auf die Kundeninteraktion ausgerichteten IT-Systeme, die "Systems of Engagement", werden von den "Systems of Record" getrennt. Durch die Entkoppelung dieser beiden Systemwelten, beispielsweise durch Modularisierung oder Microservices, reduziert sich die Komplexität und es wird eine "IT in zwei Geschwindigkeiten" ermöglicht: hier die flexible Entwicklungs-, Test- und Deployment-Umgebung, da die stabile, transaktionale Geschäftsprozess-Infrastruktur.
 
Sollen die Systeme im Hinblick auf verkürzte Lieferzeiten, schnellere Wechsel der Funktionalität und deutlich gesteigerte Qualität bei der Auslieferung von Software optimiert werden, lässt sich dies mit herkömmlichen Mitteln nicht mehr erreichen.
 
Das Toolset dafür sind der Einsatz neuer agiler Prozesse, Microservices, Continuous Delivery, Container-Technologie und Cloud. Diesen Tools widmet sich auch die nächste DevOps-Conference die vom 12. bis 15. Juni 2017 in Berlin stattfindet.
 
Automatisierung
Continous Delivery – die Automatisierung sämtlicher Aspekte des Deployments – sorgt dafür, dass Modifikationen oder neue Features so schnell wie möglich in die Produktion gebracht werden können, ohne dafür hohe Risiken für das Gesamtsystem einzugehen. Dem DevOp-Mindset folgend kann durch Continous Delivery "sanfter Druck" auf die Entwickler ausgeübt werden, ihre Software nicht nur für die Testumgebung, sondern auch für deren Überführung ins "reale Leben" zu bauen und im Hinblick auf ein reibungsloses Deployment bei der Architektur und den technischen Details überlegter vorzugehen.
 
Es ist darüber hinaus ein erklärtes Ziel der DevOps-Bewegung, die Automatisierung von Vorgängen im IT-Betrieb und die gemeinsame Nutzung von Tools zwischen Entwicklung und Betrieb zu fördern. Beispielsweise können die Entwickler ihre verwendete Konfiguration der Infrastruktur an den Betrieb weitergeben und mit diesem abstimmen. Oder aber Entwicklung und Betrieb entwickeln den Infrastruktur-Code direkt gemeinsam und schliessen somit von vornherein Inkompatibilitäten zwischen den Entwicklungs-, Test- und Produktivumgebungen aus.
 
Prozesse
Selbst die glühendsten Verfechter von DevOps sind sich einig, dass es weder notwendig, noch wünschenswert ist, Entwicklung und Betrieb zusammenzulegen. Gleichwohl liegt eine Schwierigkeit bei der Definition von DevOps-Prozessen darin, dass in vielen Unternehmen, vor allem kleineren, die Grenze zwischen Entwicklung und Betrieb gar nicht so streng gezogen wird.
 
Es ist daher fraglich, ob Prozesse, die für kleine Unternehmen gut funktionieren, auch in grösseren Unternehmen anwendbar sind. Dennoch oder gerade deshalb ist die DevOps-Bewegung bestrebt, geeignete Prozesse für die Einführung und Nutzung von DevOps-Ideen zu definieren. Sicher ist, dass es vermutlich nicht ohne interdisziplinäre Experten geht, die an der Schnittstelle zwischen beiden Bereichen arbeiten. Doch DevOps ist gleichwohl nicht als Stellen- oder Rollenbeschreibung zu sehen. Konkrete Vorschläge für die Prozessdefinition sind innerhalb der DevOps-Bewegung noch in der Ausarbeitung.
 
Modulare DevOps-Plattformen als Managed Service
Klar ist: Das zukünftige Arbeiten in der Softwareentwicklung und im IT-Betrieb wird sich für beide Seiten ändern. Die Softwareentwicklung wird sich zunehmend mit Aspekten aus dem Betrieb auseinandersetzen, etwa mit dem Aufsetzen von physikalischen oder virtuellen Maschinen, der Absicherung von Systemen oder der minutiösen Planung und Durchführung von Deployments. Im IT-Betrieb wird ebenfalls verstärkt auf Automatisierung gesetzt, mit Infrastructure as Code, Versionskontrolle und automatisierten Tests.
 
Was liegt also näher, als bei der Einführung von Technologien für Software-Entwicklung und Deployment auf Plattformen zuzugreifen, die den neuen Verfahrensweisen bereits Rechnung tragen? Die gegebenenfalls ein ganzes Ökosystem an Services mit einer integrierten technischen Entwicklungs- und Betriebsplattform im Hintergrund miteinander verflechten. Modulare Plattformen auf PaaS-Basis erleichtern die Einführung von DevOps, wenn sie den Betrieb von Java- wie auch Datenbank-Workloads kombinieren und Container für eigene Anwendungsentwicklungen bieten. Container abstrahieren eine Software von Faktoren wie Betriebssystem-Versionen oder Netzwerkarchitekturen, so dass eine App problemloser von einem Test- in das Produktivsystem transferiert werden kann. In Kombination mit Cloud-Plattformen als rein softwarebasierte Infrastruktur wird das Deployment wesentlich beschleunigt und vereinfacht.
 
PaaS-Plattformen dieser Art können mittlerweile mitsamt Skalierung, Daten und Middleware als gemanagter Service bezogen werden. Als besonders praktisch erweisen sich unterschiedliche Plattform-Editionen, die auf die verschiedenen Bedürfnisse von Entwicklung und Betrieb Rücksicht nehmen. Eine Developer Edition beispielsweise bietet den Entwicklern einen hohen Self-Management-Anteil bei der Konfiguration und der Middleware, während die Production Edition eher auf Servicepakete fokussiert. So kann durch die Symbiose von Betriebsplattform und Software-Modulen dem wachsenden Kosten- und Innovationsdruck im Unternehmen begegnet werden. (Thomas Williams)
 
Thomas Williams ist Portfolio Manager bei T-Systems Schweiz.