DevOps ist das breit eingesetzte Schlagwort für eine weitreichende Transformation der IT-Organisation in Unternehmen. Allerdings wird DevOps, je nach Kontext, für diverse Teilaspekte dieser Transformation verwendet. Diese können organisatorische Änderungen, Einführungen neuer Prozesse oder sogar einzelne Tools sein. In diesem zweiten Artikel der kurzen Reihe zu DevOps wollen wir uns insbesondere den methodischen Aspekten von DevOps, wie den Betriebsprozessen oder der Software-Architektur und -Bereitstellung widmen.
In unserem vorangegangenen Artikel zum Thema DevOps haben wir uns hauptsächlich auf die kulturellen Aspekte von DevOps konzentriert und deren Bedeutung für eine erfolgreiche Einführung des Vorgehensmodells angeschaut. An dieser Stelle wollen wir uns nun den Methoden rund um DevOps widmen.
Generell sind Änderungen an Tools und Methoden nicht so schwer vorzunehmen wie Änderungen der Unternehmenskultur. Jedoch tragen solche Änderungen an Methoden in der Praxis ebenfalls massgeblich dazu bei, dass die dahinterliegenden Ziele, wie eine schnellere Lieferfähigkeit von Software-Lösungen, erreicht werden können.
Die für die Software-Entwicklung verwendeten Projektmethoden haben sich von klassischen Wasserfallmodellen über die Zeit in Richtung iterativer und agiler Projektmethoden weiterentwickelt. Bei den klassischen Wasserfallmethoden folgt im Allgemeinen auf eine abgeschlossene Konzepthase eine einmalige Realisierungsphase. Bei den agilen Methoden werden die Konzeption und Realisierung mehrmals, beziehungsweise iterativ, mit signifikant kleineren Lieferobjekten durchlaufen. Es besteht dadurch die Möglichkeit, auch während der Realisierung noch wesentlichen Einfluss auf das Endprodukt zu nehmen.
Mit DevOps wird die agile Methodik nicht nur im Rahmen der Projektphase zur Entwicklung eines neuen Software-Produktes eingesetzt, sondern auch im gesamten Produkt-Lebenszyklus und damit insbesondere auch in der produktiven Betriebsphase eines Produktes angewendet.
Organisatorisch wird die Entwicklung hin zu einem DevOps-Vorgehensmodell oft stark auf der methodischen Ebene vorangetrieben. Hierzu gehören neben der Ausrichtung der Betriebsprozesse auch die architektonischen Grundentscheidungen und die Eckpfeiler des Softwareentwicklungsprozesses. Die eingesetzten Methoden können wesentlich einfacher geändert werden als die Firmenkultur. So ist es auch möglich, einzelne Aspekte, etwa die Umstellung auf eine Microservice-Architektur, (vorerst) auszulassen und dennoch die massiven Vorteile durch die Verwendung von DevOps zu erzielen.
Aus organisatorischer Sicht betrachtet unterschiedet sich das DevOps-Modell vom klassischen Be-triebsmodell, welches vielerorts entlang von Betriebsprozessen nach ITIL definiert ist, durch eine In-tegration der unterschiedlichen Bereiche. Die Unterteilung der Verantwortungsbereiche auf die klassischen drei Phasen «Plan» (Planen), «Build» (Aufbauen/Entwickeln) und «Run» (Betreiben) wird in integrale DevOps-Teams aufgeteilt, welche je alle drei Bereiche abdecken.
Besonders wichtig zu betonen ist die Tatsache, dass mit der Verlagerung der Verantwortung für den Betrieb in die DevOps Teams die Notwendigkeit unternehmensweiter Betriebsprozesse im Allgemeinen nicht entfällt. Die Betriebsprozesse sind oft nicht die ersten Punkte bei der Verlagerung der Verantwortlichkeiten in die einzelnen Teams, da die DevOps Teams schliesslich fortan selbst für den Betrieb zuständig sind.
Selbst ohne ein vollständiges Betriebsprozess-Framework wie beispielsweise nach ITIL anzuwenden, benötigt es im Rahmen des DevOps Modells meist definierte und nachvollziehbare Change Management und Problem Management Prozesse. Dies ist oft ein kritischer Punkt, da die Entwicklungsteams entsprechende, historisch oft als bremsend angesehene, Prozesse bei der Umstellung auf DevOps gerne umgehen. Frameworks wie Scaled Agile Framework® (SAFe) bieten jedoch Anknüpfungspunkte, um dies zu verhindern. Hierfür muss jedoch das Bewusstsein der Notwendigkeit und die entsprechende Steuerung bestehen.
Allgemein stellt die reduzierte zentrale Steuerung eine Herausforderung für die Governance in Unternehmen dar. Dies ist nicht nur der Fall, wenn beispielsweise regulatorische Anforderungen bestehen. Es kann schon der verstärkte Einsatz von Open-Source-Software ohne zentrale Governance zu «technical debt» oder, schlimmer noch, Security-Risiken führen, wenn mehrere Teams die gleichen Tools mit leicht unterschiedlichen Ansätzen und eventuell sehr heterogenem Know-how einsetzen.
In klassischen Entwicklungsmodellen ist die Konzeption der Sicherheitsaspekte an eine Software-Lösung und insbesondere die Prüfung der Sicherheitsaspekte vielfach die Aufgabe eines dedizierten Teams. Dabei wird zuerst das funktionale Design der Lösung konzipiert und in agilen Projektmethoden nicht selten auch zu einem gewissen Teil bereits umgesetzt, bevor den Sicherheitsaspekten entsprechend Beachtung geschenkt wird. Dies führt einerseits oft zu Verzögerungen im Vorhaben, da gewisse Aspekte erst zu einem späteren Zeitpunkt auftauchen und detailliert geklärt werden müssen. Zusätzlich ist die Wahrscheinlichkeit hoch, dass mit diesem Vorgehen schlussendlich nicht die optimale Lösung implementiert werden kann.
Beim kollaborativen DevSecOps-Ansatz werden die Sicherheitsaspekte von Beginn weg im Design der zukünftigen Lösung berücksichtigt und die Security-Expertise ist zu jedem Zeitpunkt ein integraler Bestandteil des Entwicklungsteams. Die Sicherheitsaspekte in modernen Software-Entwicklungs- und Bereitstellungsmodellen lassen sich dabei im Wesentlichen in zwei Kategorien aufteilen:
- Sicherheit der Komponenten und Daten (z.B. Zugriffs- und Rechteverwaltung, Verschlüsselung der Datenübertragung und -speicherung)
- Sicherheit innerhalb der Prozesse (z.B. Scanner zur Prüfung bei der Bereitstellung von Containern, automatische Tests zur Compliance-Prüfung von Infrastructure-as-Code Skripten)
Um eine integrale Sicherheit von Software-Lösungen garantieren zu können, müssen im Rahmen des Designs sowie der (Weiter-)Entwicklung beide Kategorien zu jedem Zeitpunkt berücksichtigt werden. Es ist zwingend notwendig, dass innerhalb eines DevSecOps-Teams die entsprechenden Fähigkeiten genügend abgedeckt werden können. Auch hier gilt wieder, dass Kultur einen integralen Bestandteil der Transformation hin zu DevSecOps darstellt. Aufgrund des Ausmasses der Änderungen widmen wir uns DevSecOps in einem separaten Artikel.
Trotz ihrer Bedeutung für den Alltag stellt die Umstellung der Betriebsprozesse selten das erste Thema dar, an welches bei der Umstellung auf DevOps gedacht wird. Im Gegensatz dazu werden kleine häufige Software-Releases sehr oft thematisiert, denn schliesslich ist es das Ziel einer Umstellung auf DevOps, (mehrfach) täglich «releasen» zu können. Insbesondere Web-Anwendungen eignen sich hierfür besonders, da ein neuer Release den Nutzenden problemlos jederzeit zugänglich gemacht werden kann. Bei der Entwicklung von «statischerer» Software, etwa mobile Applikationen, eignen sich kleine Releases dennoch ebenso. Obwohl kleine Releases zwar keine laufenden Updates bei den Nutzenden ermöglichen, begrenzen sie die Komplexität der Software-Verwaltung im Rahmen des Releaseprozesses. Dies ermöglicht beispielsweise durch die Reduktion möglicher Fehlerquellen eine einfache Fehlersuche – insbesondere natürlich, wenn Tests automatisiert stattfinden.
Um (Teil-)Applikationen unabhängig voneinander entwickeln und releasen zu können, spielt die Fokussierung auf APIs eine zentrale Rolle. Klar definierte Schnittstellen erlauben, wie schon bei der objektorientierten Programmierung, eine lose Koppelung von Komponenten. Darüber hinaus erlauben APIs es aber auch, neue und innovative Funktionen schnell zu entwickeln, da die Orchestrierung bestehender Funktionen in den Mittelpunkt rückt. Gerade auch der Trend zu Low-Code Plattformen und ähnlichen Ansätzen, die zum Teil sogar Fachanwendern direkt erlauben Prozesse zu automatisieren (Citizen Developer) , treibt diesen Gedanken der Orchestrierung bestehender Funktionalitäten auf die Spitze. Siehe auch “Digitale Plattformen: Enabler einer agilen Unternehmensarchitektur Teil 1” und Teil 2.
Doch auch in der «herkömmlichen» Softwareentwicklung sind direkte Folgen einer Umstellung auf kleine, über APIs miteinander gekoppelte Bestandteile von Applikationen im Rahmen des Trends zu «Microservice» Architekturen erkennbar. Die technologischen Aspekte von DevOps thematisierten Container-Technologien unterstützen diesen Trend massgeblich und werden im nächsten Artikel aufgegriffen.
Selbstverständlich verlagert sich die Komplexität bei dieser Art der Architektur aus den einzelnen Applikationen selbst in das Beziehungsnetz zwischen den Applikationen. Hier hilft es jedoch, dass die Herausforderungen zwischen verschiedenen Applikationen sehr viel ähnlicher werden und oft sogar technisch angegangen werden können. Dies erfolgt etwa durch Service-Mashes auf Container-Plattformen. Die Verlagerung von Komplexität in Richtung der Plattformen, auf welchen die Applikationen entwickelt werden, ist allgemein erkennbar. Dies ist insbesondere vorteilhaft, wenn die Plattformen nicht durch die DevOps Teams selbst betrieben werden müssen, sondern beispielsweise bei einem Cloud-Provider eingekauft werden können.
Im Spannungsfeld zwischen Methoden und Tools befindet sich auch der Einsatz von «Continuous Ingegration» sowie «Continuous Delivery» oder sogar «Continuous Deployment». Während wir uns an dieser Stelle auf die methodischen Aspekte fokussieren, gibt es eine Vielzahl an konkreten Tools zur Umsetzung von CI & CD. Auf der methodischen Seite ist die Sicherstellung der konstanten Lieferfähigkeit und vor allem auch die automatisierbare Durchsetzbarkeit von Qualitätsstandards zentral beim Einsatz von CI/CD.
Neben automatisierten Tests können auch weitere Qualitätsstandards, insbesondere Security-Standards innerhalb der CI/CD Pipeline durchgesetzt werden. So können Abhängigkeiten der entwickelten Software auf Schwachstellen geprüft werden oder auch Quellcodes statisch analysiert werden. Diese automatisierte Durchsetzung von Qualitätsstandards (bis hin zum Abbrechen der CI/CD-Pipeline bei der Verletzung der Qualitätserwartungen) ermöglicht auch die Durchsetzung von zentralen Vorgaben, etwa diejenigen der IT-Security.
Bei der Verwendung von Continuous Delivery kann der Einbezug der Business-Vertreter, in agilen Umfeldern meist Product Ownern (PO), im Rahmen der Freigabe zum Deployment in das produktive Umfeld die geteilte Verantwortung von IT und Business unterstreichen. Zudem können, je nach Umfeld, auch regulatorische Auflagen im Sinne der «segregation of duties» erreicht werden, indem sie – sogar technisch verankert – Teil des Prozesses werden.
DevOps als Methodik ist sehr eng mit der agilen Projektmethodik verzahnt. Sie ergänzt die agile Herangehensweise zusätzlich um die betrieblichen Aspekte. Der organisatorische Aspekt des DevOps-Modells bedingt eine Integration der Fähigkeiten der Software-Entwicklung, der Infrastruktur-Service Bereitstellung, der Testing- und Qualitätssicherung, sowie der betrieblichen Aspekte wie Support, Pflege und Weiterentwicklung von Lösungen. Damit dabei IT-Lösungen auch die ständig zunehmenden IT-Sicherheitsanforderungen erfüllen können, ist eine enge Integration der Fähigkeiten im Bereich Cyber Security zwingend notwendig. Der methodische Ansatz zur Verzahnung des DevOps-Modells mit den entsprechenden Cyber Security Fähigkeiten führt zu einer Weiterentwicklung des Modells in Richtung DevSecOps.
Neben den agilen Methoden für Entwicklung, Bereitstellung und Betrieb moderner Software-Lösungen ist eine moderne Software-Architektur ein weiterer Grundstein für eine effiziente und effektive Nutzung der DevOps Fähigkeiten. Durch die Prinzipien von Microservice-Architekturen sowie die Fokussierung auf kleinere Software-Elemente, welche über APIs miteinander kommunizieren, können eine partielle Weiterentwicklung und der Betrieb einzelner Elemente nach agilen DevOps-Methodiken ermöglich werden.
Aus technisch prozessualer Sicht bieten bewährte Tools und Frameworks das Fundament für eine automatisierte Verwaltung, Qualitätssicherung und Bereitstellung von Software-Lösungen im Rahmen der CI/CD-Methodik.
Zusammengefasst bilden die organisatorischen Methodiken von DevOps gepaart mit einer modernen Software-Architektur und einer automatisierten Software-Bereitstellung über eine CI/CD Pipeline die technische Grundlage für eine nachhaltige DevOps-Implementierung. Neben diesen methodischen und technischen Elementen sind für DevOps auch die entsprechenden Fähigkeiten der Mitarbeitenden entscheidend. Die enge und interdisziplinäre Zusammenarbeit innerhalb der DevOps Teams ist daher ein ebenso wichtiger Erfolgsfaktor.
Für die effektive Implementierung der erläuterten DevOps-Methoden stehen unterschiedliche Tools zur Verfügung, auf welche wir in unserem nächsten Artikel weiter eingehen werden.
Wenn Ihnen der Artikel gefallen hat, würden wir uns als Eraneos Group sehr freuen, Ihre Initiativen, Erfolgserlebnisse aber auch Herausforderungen im Zusammenhang mit der Etablierung und Nutzung von DevOps in Ihrer Organisation tiefergehend zu diskutieren. Dabei unterstützen wir Sie gerne mit unserer Erfahrung und Expertise im Themenfeld von DevOps und der agilen Transformation.
DevOps: eine Frage der Kultur?
Die IT Organisation der Zukunft ist businessorientiert und wird damit zu einem wichtigen Treiber der digitalen Transformation.
Wir begrüssen Sie gerne an unseren Veranstaltungen und diskutieren mit Ihnen über ausgewählte Fragenstellungen zu aktuellen Themen.
Enabler einer agilen Unternehmensarchitektur
Was sind digitale Plattformen? Welche Eigenschaften und Kernfähigkeiten beinhalten sie? Welche Entscheidungen sind bei deren Einsatz zu treffen und wie gestaltet sich eine generische IT-Architektur unter Einbezug von digitalen Plattformen?