DevOps in der On-premise-Welt

DevOps beschreibt die Philosophie der Kollaboration aller an der Entwicklung und dem Betrieb einer Applikation beteiligter Experten von der Prozessebene und den Rollen bis zur kulturellen Veränderung. Im Zusammenhang mit Cloud-basierten Applikationen und der digitalen Transformation ist DevOps gängig. Technologie-übergreifende Geschäftsprozesse in den heutigen, zumeist hybriden Systemlandschaften erfordern die Übertragung von DevOps-Methoden auch auf eher monolithische On-premise-Systeme. Zwar führt die zumeist monolithische Architektur zu Abstrichen, doch gerade aus kultureller Sicht lässt sich DevOps auch in der On-premise-Welt leben.

Entwicklung und Betrieb Hand in Hand

Die Verbreitung des künstlich aus den Begriffen Development und Operations gebildeten Wortes DevOps lässt sich bis zu den ersten DevOpsDays im Jahr 2009 in Ghent zurückverfolgen [Dev09]. Kerngedanke war und ist, durch die enge Kooperation (Share) zwischen Entwicklung und Betrieb die Änderungsgeschwindigkeit und -qualität enorm zu erhöhen. Dazu wurde unter anderem diskutiert, wie man mithilfe von Pipes und Kanban-Methoden Entwicklung und Betrieb beschleunigen kann hin zu einer stetigen, automatisierten Integration (Continuous Integration) und Freigabe (Continuous Deployment) von Änderungen.

Der Automatisierungsgedanke ist eine wesentliche Dimension von DevOps. Gleichzeitig dient die stetige Vermessung (Measurement) der Benutzeradaption und -zufriedenheit als Feedback-Channel zur Verbesserung der Applikation. Der Applikationslebenszyklus schließt sich damit, weswegen auch gern das Unendlichkeitszeichen in der Darstellung von DevOps genutzt wird. Der Arbeit in Teams mit übergreifenden Expertisen kommt trotz aller unterstützenden Werkzeugen besondere Bedeutung zu (Culture). Daher sind schlanke IT-Prozesse (lean) ein weiterer wichtiger Baustein.

Abbildung 1 fasst die Dimensionen von DevOps zusammen als CAMS (Culture, Automate, Measure, Share) und folgt damit der von [Deb12] gegebenen Beschreibung. Es finden sich jedoch auch Definitionen, denen „lean“ (vgl. [Urb16]) als wichtiges Kriterium oder auch weitere Kriterien (vgl. [San18]) hinzugefügt wurden. Was allen gemein ist, ist eine viel engere Zusammenarbeit von Entwicklung und Betrieb beziehungsweise die enge Kooperation aller am Softwareentwicklungsprozess beteiligten Parteien, die sich auch in der Organisation und im Teamaufbau niederschlagen muss. Dies erfordert kulturelle Anpassungen des Arbeitsumfelds.

Eine verbindliche Definition von DevOps ist jedoch nicht gegeben. Es besteht aber ein gemeinsames Verständnis und ein Konsens darüber, dass DevOps die Softwareentwicklung und den Betrieb erheblich verbessert. Im Umfeld von Cloud-basierten Applikationen hat sich DevOps durchgesetzt. Zahlreiche Studien belegen den Erfolg, wie [New18]. DevOps kann jedoch nicht durch das Umlegen eines Schalters oder die blanke Einführung von Werkzeugen aktiviert werden. Nicht zuletzt durch die hohen Anforderungen an die Organisationskultur und gemeinschaftliche Arbeit der Experten ist Dev­Ops eher als eine Philosophie anzusehen, deren Implementierung eine fortlaufende Evolution mit Zwischenzielen ist (siehe Abbildung 2).

Die DevOps-Evolution

Die Evolution zu DevOps beginnen Sie bereits mit der Einführung einer agilen Entwicklung. Agil war schon vor einigen Jahren ein regelrechter Hype. Die Erfahrungen haben uns gelehrt, dass „agil“ geeignete Werkzeuge in der Entwicklung, aber auch insbesondere zur Unterstützung möglichst schlanker IT-Prozesse insbesondere des Änderungsmanagements erfordert. Aber selbst die besten Werkzeuge können unzureichende Teamarbeit oder gar Konflikte nicht ausgleichen. Während umgekehrt echte Zusammenarbeit von Experten sogar manche Schwächen in Werkzeugen oder technischen Systemen auszugleichen vermag.

DevOps baut darauf auf, erhebt die bereichsübergreifende Zusammenarbeit, Verständnis und Erfahrungsaustausch insbesondere zwischen Development und Operations zur Maxime. Noch drängender wird der kulturelle Wandel, wenn es darum geht, einen nahezu fließenden, stetigen Änderungsfluss zu erreichen. Geeignete Werkzeuge, um dies zu managen, sind unabdingbar, doch erzwingt dies auch die lückenlose Zusammenarbeit der Experten.

Schauen wir auf die Organisationsstrukturen, die sich in der klassischen On-premise-Welt gebildet haben, so ist dies meist funktional ausgerichtet. Experten mit vergleichbaren Aufgaben und Wissen bilden Teams. Schon allein durch die unterschiedliche Aufgabenstellung der einzelnen Teams ergeben sich Kommunikationshindernisse zwischen den Teams. Verstärkt wird dies, wenn Aufgabenbereiche wie der technische Betrieb gar an externe Dienstleister ausgelagert werden. Die angestrebte hohe Änderungstaktung in DevOps erfordert jedoch eine enorme Feinabstimmung zwischen den Teams und Experten, eine Arbeit Hand in Hand. Besteht die Organisation aber aus Tempeln je Aufgabengebiet, wird dies nicht gelingen. Die Organisation muss entlang den Applikationsprozessen angepasst werden, also Rollen-übergreifend, wie in Abbildung 3 dargestellt. Aufgabensilos müssen zugunsten von Interaktion und Informationsaustausch zwischen den Funktionen weichen.

Momentan ist die digitale Transformation in aller Munde. Sie geht zunehmend einher mit der Einführung Cloud-basierter Applikationen. Diese machen es vor, wie DevOps unter Einsatz von Werkzeugen wie Git, Jenkins, Docker, Marven, Gerrit usw. funktionieren kann. Nicht alles mag den Idealen von DevOps entsprechen, dennoch ist die Änderungsrate eher fließend oder zumindest weitaus häufiger als das für die On-premise-Welt bislang angesehene Ideal möglichst weniger Releases pro Jahr.

Zugegebenermaßen haben Cloud-basierte Applikationen auf Basis von Microservices einen entscheidenden, architektonischen Vorteil: nämlich genau diese stringent gekapselten Microservices. Diese Kapselung reduziert die mögliche Tragweite einer einzelnen Änderung und damit das Risiko ungewollter Wechselwirkungen. Klassische On-premise-Lösungen basieren bestenfalls auf Serviceorientierten Architekturen (SOA), weisen jedoch häufig noch zentrale, absolut übergreifende Komponenten wie das Datenbank-Managementsystem oder zentrale Dienste auf. Änderungen an diesen Komponenten können sich dadurch potenziell immer auf die ganze Applikation auswirken, bergen also ein erhebliches Risiko.

„Never touch a running system“ hat sich im Laufe der Zeit beim Betrieb von On-premise-Applikationen als Leitspruch entwickelt, wenngleich nicht immer ernst gemeint. Es zeigt jedoch die konträre Situation zwischen dem Cloud-basierten Ansatz und dem bisherigen Betrieb in eigener Hand. Betrachten wir die momentan typische Situation in der Firmen-IT, so finden wir zumeist gemischte (hybride) Systemlandschaften bestehend aus einem Mix von IaaS, PaaS, SaaS und On-premise-Anwendungen. Häufig bildet die On-premise-Landschaft den Business-kritischen Kern, umfasst das größte Datenvolumen und wird besonders abgesichert. Cloud-basierte Applikationen werden insbesondere für die Interaktion mit dem Endanwender eingesetzt. Prozesse passieren somit alle Arten von Cloud-basierten und On-premise-Anwendungen.

Abbildung 4 skizziert eine aktuell typische Vertriebsapplikation und das Zusammenspiel verschiedener Technologien. Häufig erfolgt der Direktvertrieb an Kunden mittels eines Internetauftritts. Im Hintergrund könnten die Verkaufsaufträge durch eine Cloud-basierte Anwendung weiterbearbeitet werden, um dann in einem vielleicht zentralen On-premise-System verwaltet und zur Produktion weitergegeben zu werden. Mehr und mehr werden die Produktionsstrecken auch mittels Internet-of-Things-Techniken gesteuert. Sensoren vermessen und überwachen die Produktionsschritte und liefern Daten, die verwaltet und ausgewertet werden, womöglich auch unter Verwendung einer Cloud-basierten Applikation. Die Geschäftsprozessobjekte könnten wiederum im On-premise-System zusammenlaufen. Die Lieferkette könnte direkt mit eingebunden sein.

Sicherlich unterscheiden sich die Implementierungen der Vertriebsprozesse je Firma. Typisch sind jedoch die Mischung verschiedener Technologien und die zunehmend enge Integration von technischen Komponenten und auch Geschäftsprozessen. Anstelle eines system­orientierten IT-Managements tritt ein zunehmend stärker Geschäftsprozess-orientiertes IT-Management.

Ist es da realistisch, innerhalb der Applikationslandschaft und der Business-Prozesse mit komplett unterschiedlichem Entwicklungs- und Betriebsmuster zu arbeiten?

Bimodale IT

Der Begriff der bimodalen IT oder auch IT der zwei Geschwindigkeiten wurde unter anderem von Gartner [Gar17] geprägt. Dabei wird davon ausgegangen, dass Cloud-basierte Applikationen Dev­Ops-Praktiken anwenden. Damit unterliegen sie weitaus häufigeren Änderungen, bestenfalls ähnlich einem stetigen Wasserfall. On-premise-Systeme, auch Systems of Record genannt, verharren dagegen im althergebrachten Releasemanagement, wo Änderungen gesammelt und gebündelt, möglichst selten in die Produktion übernommen werden.

Tabelle 1 trägt wesentliche Unterschiede in der früheren On-premise und dem DevOps-Ansatz bei der Adaption von Innovationen und den dafür erforderlichen Änderungen zusammen.

Doch betrachten Sie noch einmal Abbildung 4. Sind diese unterschiedlichen Änderungsgeschwindigkeiten tatsächlich realistisch, wenn die verschiedenen technischen Komponenten und Systeme durch den übergreifenden Geschäftsprozess derartig abhängig sind? Nach meiner Praxis­erfahrung erfordert die Integration der verschiedenen Technologien möglichst auch eine Angleichung der Änderungsgeschwindigkeiten unabhängig von dem einzelnen System.

Die logische Schlussfolgerung ist die Erhöhung der Änderungstaktfrequenz entlang gemeinsamer Geschäftsprozesse. Sicherlich erfordert nicht jede Änderung gleichzeitig eine Änderung in einem abhängigen System, aber die Wahrscheinlichkeit ist gegeben. Darüber hinaus wird sogar ein auf die Geschäftsprozesse End-to-End ausgerichtetes zentrales Änderungsmanagement benötigt. Somit muss ernsthaft über die Einführung von DevOps-Methoden bei Systems-of-Record-Systemen nachgedacht und realisiert werden.

DevOps im System-of-Record-Umfeld

Wie bereits dargestellt, ging die Entwicklung von DevOps einher mit der Verbreitung Cloud-basierter Anwendungen auf der Grundlage von zum Beispiel Java und Open-Source-Produkten. Doch gibt es nicht die Definition von DevOps. Tatsächlich ist die genaue Beschreibung von DevOps auch nicht ausschlaggebend. Essenziell ist die Notwendigkeit, die Änderungs- oder Anpassungsgeschwindigkeit von Geschäftsprozessen an die sich zunehmend schneller ändernden Märkte anzupassen. DevOps in seinen Dimensionen ist eine geeignete Antwort darauf und zwar unabhängig von der Technologie. Allen Ansätzen zur Definition gemein ist die erforderliche Änderung der Kultur der Zusammenarbeit der an Entwicklung und Betrieb beteiligten Experten, weswegen DevOps auch gern als Philosophie betrachtet wird.

Dabei spielt es keine Rolle, auf welcher Technologie das einzelne System basiert. Es geht darum, bei der Adoption von Innovationen schneller zu werden, das heißt in der Konsequenz, die Änderungsgeschwindigkeit um ein Vielfaches zu erhöhen, indem Entwicklung und Betrieb Hand in Hand arbeiten.

Aus technologischer Sicht vereinfacht die in Microservices gekapselte Architektur Cloud-basierter Anwendungen die Umsetzung der DevOps-Prinzipien, denn einzelne Änderungen betreffen in aller Regel nur einen einzelnen Microservice. Jeder Microservice ist unabhängig und zum Beispiel auch in unterschiedlichen Sprachen entwickelbar. On-premise-Systeme oder System of Records dagegen sind bestenfalls von serviceorientierter Architektur. Services sind bestenfalls gekapselt, wobei es zentrale Bausteine gibt, deren Änderungen immer das gesamte System betreffen.

Diese Systeme sind eher monolithisch aufgebaut. Für gängige On-premise-Systeme, wie SAP S/4 Hana, empfiehlt es sich, stringent modular zu entwickeln, um die Reichweite von Änderungen zu begrenzen. Geeignete Verfahren, um potenzielle Weiterentwicklungen, also Änderungen hinsichtlich des Risikos für das On-premise-System zu klassifizieren, sind ebenfalls hilfreich. Durch die in dem SAP-System zentrale Code-Verwaltung und die Möglichkeiten des Tracking von verwendetem Coding beispielsweise kann die Auswirkung einer potenziellen Änderung abgeschätzt werden.

Diese Maßnahmen können den technischen Vorteil von Microservices in Teilen aufwiegen, erzeugen zwar auch einen erhöhten Aufwand, doch gleichzeitig ermöglicht dies bereits eine erhebliche Beschleunigung des Änderungsdurchsatzes in den On-premise-Systemen und damit auch hin­sichtlich der Technologie-übergrei­fen­den Prozesse. Grundsätzlich erfordern kundenspezifische Veränderungen der Standardsoftware auch die kundenspezifische Verifizierung der Auswirkungen von Änderungen. Typische, zumeist Cloud-basierte Applikationen beschränken daher kundenspezifische Änderungsmöglichkeiten bereits auf ein absolutes Minimum.

Hinsichtlich der Möglichkeiten zur Auto­matisierung von Integration, Testen und Freigabe von Änderungen oder Vermessung gibt es aus rein technischer Sicht weniger Nachteile. Nachteilig wirken sich dort eher herstellerspezifische Werkzeuge und Verfahren aus, die teilweise noch nicht mit den verbreiteten Open-Source-Werkzeugen im DevOps-Umfeld kompatibel sind. Jedoch zeichnen sich auch hier eine Weiterentwicklung und ein Umdenken ab, wie am Beispiel abapGit [Git19]) für die SAP ABAP-Entwicklung zu erkennen.

Code-Repository und parallele Entwicklung

Git hat sich als typisches Werkzeug für den DevOps-Ansatz herauskristallisiert. Es sind insbesondere zwei wesentliche Eigenschaften, die Git von der bisherigen Code-Verwaltung in Systems of Record abheben:

• die verteilte Code-Verwaltung in lokalen Repositories und
• die dadurch mögliche parallele Entwicklung und Bearbeitung von Code oder auch anderen änderbaren Objekten wie Parameter-Sets (Betriebssystem, System, Berechtigungseinstellungen usw.).

Abbildung 5 verdeutlicht den verteilten Repository-Ansatz und den zentralen Ansatz, wie er zum Beispiel in Systems of Record üblich ist. Beginnt ein Entwickler in einem On-premise-System mit der Änderung einer Quelle, greift die zentrale Quellen-Verwaltung. Die Quelle wird gegen andere Entwickler und deren Änderungen gesperrt. Erst nach Abschluss seiner Arbeiten wird die Quelle vom ersten Entwickler wieder für andere freigegeben.

Das führt häufig dazu, dass in der Praxis mehrere sogenannte Entwicklungslandschaften aufgebaut werden, um so langfristige Projekte und die schnellläufigere Wartung zu trennen und parallel durchzuführen. Irgendwann müssen diese Entwicklungslinien dann wieder zusammengeführt werden. Kollisionen, das heißt der Abgleich von unterschiedlichen Änderungen an der gleichen Code-Quelle, sind eher mit einem negativen Stigma behaftet.

Anders mit Git. Parallele Arbeit an einer Code-Quelle ist erwünscht und durch lokale Kopien des Code-Repository und lokale Entwicklungsumgebungen ermöglicht. Kollisionen sind gängig und gehören zum normalen Alltag. Entwickler sind nicht gezwungen, aufeinander zu warten. Kollisionen müssen aber auch abgeglichen werden, was auch hier nur eingeschränkt automatisierbar ist.

Entwicklungsumgebungen

Eine weitere Ableitung aus dem verteilten Entwicklungsansatz ist die für jeden Entwickler erforderliche Entwicklungsumgebung. Wirft man einen Blick auf die gängige Java-Praxis oder Cloud-basierte Lösungen, werden geeignete Entwicklungsumgebungen durch Container-Virtualisierung erzeugt.

Bei Systems of Record ist meist das komplette System zur Entwicklung erforderlich, wodurch Entwicklungssysteme häufig durch Kopien vorhandener Systeme erzeugt werden müssen. Oder es stehen ein oder zwei Entwicklungssysteme permanent zur Verfügung, die fest in einer definierten Systemfolge aus zum Beispiel Entwicklungs-, Test- und Produktionssystem eingebunden sind. Häufig sind Systems of Record so groß, dass eine Kopie enorm Zeit- und Ressourcen-aufwendig wäre, weswegen permanent Entwicklungssysteme vorgehalten werden, statt sie dynamisch, bei Bedarf schnell zu erzeugen.

DevOps maßgerecht anpassen

Hier zeigen sich also wesentliche Unterschiede zwischen den Technologien, aber auch die sich bisher herausgebildeten typischen Arbeitsweisen in der On-premise-Welt. Gleichzeitig sind dies aber keine Gründe, um DevOps komplett zu verwerfen, sondern zu adaptieren und Möglichkeiten auszuschöpfen. Ist es wirklich erforderlich und wenn ja in welchem Grad, parallel an der gleichen Code-Quelle zu entwickeln? Wie hoch ist der Aufwand zum Kollisionsabgleich? Und was ist eigentlich das Ziel? Ist es nicht, Code möglichst schnell anzupassen und zur Verfügung zu stellen? Erfordert dies, hochgradig parallel zu programmieren? Oder wie kann ich meinen Änderungszyklus mit anderen Mitteln beschleunigen?

Dies sind nur einige Fragen, die Sie sich ernsthaft stellen sollten. DevOps lässt sich nicht an der Verwendung eines Werkzeugs oder Technologie festmachen. Sie müssen Ihren eigenen DevOps-Weg finden. Essenziell ist die Integration der verschiedenen Technologien, um Geschäftsprozess-orientierte Änderungsprozesse anstelle von rein System-orientierten zu realisieren. Werkzeuge sind hilfreich, aber es ist entscheidend, wie sie in den Prozessen und der Arbeitskultur eingebunden und eingesetzt werden.

Trotz aller Werkzeuge und technologischer Aspekte bleibt für den Erfolg von DevOps in erster Linie die Änderung der Kultur der Kooperation von Entwicklung und Betrieb ausschlaggebend. Gelingt es nicht, Organisation und die persönliche Einstellung der Mitarbeiter auf ein Miteinander einzustimmen, wird DevOps unabhängig von der eingesetzten Technologie nicht funktionieren. Diesen kulturellen Wandel zu vollziehen, erfordert einen längeren Entwicklungsprozess, der durch die Implementierung geeigneter Werkzeuge lediglich unterstützt werden kann.

Weitere Informationen

[Deb12] P. Debois, Devops Areas - Codifying devops practices, siehe:
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/

[Dev09] Devopsdays Ghent, 2009, siehe: legacy.devopsdays.org/events/2009-ghent

[Gar17] Gartner, Bimodal IT, 2017, siehe: https://www.gartner.com/it-glossary/bimodal/

[Git19] abapGit, GitHub Inc., siehe: https://github.com/larshp/abapGit

[New18] New Relic: Measuring DevOps, siehe: https://newrelic.com/devops/measuring-devops

[San18] M. Sánchez-Gordón, R. Colomo-Palacios, Characterizing DevOps Culture: A Systematic Literature Review, in: Proc. of 18th Int. Conf., SPICE 2018, Thessaloniki, Greece, October 9–10, Springer, 2018, siehe: https://link.springer.com/chapter/10.1007%2F978-3-030-00623-5_1

[Urb16] N. Urbach, F. Ahlemann, IT-Management im Zeitalter der Digitalisierung – Auf dem Weg der IT-Organisation der Zukunft, Springer-Verlag, 2016