Quo vadis DevOps?
Die DevOps-Philosophie scheint in den letzten Jahren ordentlich an Fahrt aufgenommen zu haben. Ein Blick auf die Häufigkeit der Suchanfragen bei Google Trends offenbart, dass dieser subjektive Eindruck nicht täuscht. Seit etwa zwei Jahren erleben wir ein steigendes Interesse an einer Idee, die es bis dato kaum zu einer allgemeingültigen Definition geschafft hat. Wie sieht unter diesen Umständen die Zukunft von DevOps aus?
Die anfänglich von einer Handvoll Entwicklern propagierte Strategie, Entwicklung und Betrieb enger zu verzahnen findet immer stärker Einzug in den Unternehmen, dank der Vielzahl von Toolherstellern und selbsternannten DevOps-Evangelisten, die von ihren Vorzügen auf diversen Blogs und Talks schwärmen. Und die neu eingeführten Konferenzen mit den ähnlich klingenden Namen (DevOps Conference, DevOps Enterprise, Continous Lifecycle,…) haben mittlerweile im deutschsprachigen Raum einen festen Platz in der IT-Fachwelt. Diese Entwicklung ist nicht wirklich überraschend, denn der DevOps-Trend hat endgültig den kritischen Punkt eines typischen Hypes überschritten und setzt sich in einem selbstverstärkenden Erfolg weiter fort.
Setzt man sich als Laie mit der DevOps-Idee auseinander, so sucht man zunächst vergeblich nach einem Autor oder einem Gremium, der oder das die Deutungshoheit über diesen Terminus besäße. Es existiert keine offizielle Referenz oder ein Manifest, wie es bei der agilen Bewegung mit den vier Leitsätzen und zwölf Prinzipien der Fall ist. Für die Herausgabe eines umfassenden Standardwerkes, das alle historischen und aktuellen Aspekte einbezieht, ist es wahrscheinlich noch zu früh. Sogar an die Ausarbeitung eines deutschsprachigen Wikipedia-Artikels hat sich bisher noch niemand getraut; das englische Pendant beruft sich bei der Definition hingegen auf über sechs verschiedene Quellen mit teils unterschiedlichen Aspekten. In der Konsequenz hat sich die IT-Gemeinde auf den kleinsten gemeinsamen Nenner geeinigt – und zwar auf die Betrachtung ausnahmslos aller Aspekte, die die Zusammenarbeit von Entwicklung und Betrieb betreffen.
Im Folgenden seien die am häufigsten genannten Eckpfeiler von DevOps aufgezählt:
- Kommunikation: Der Austausch von Informationen innerhalb der Abteilungen soll begünstigt werden. Alle für den Betrieb relevanten Details sollten rechtzeitig ermittelt werden, da sie in Zukunft die Verfügbarkeit und Stabilität der Anwendung maßgeblich beeinflussen. Die Entwickler schreiben wartungsfreundlichen Code, in dem sie Einsicht in das Tagesgeschäft des IT-Betriebs und die Laufzeitumgebungen erhalten.
- Kollaboration: Bei wichtigen Entscheidungen, sei es im Rahmen des Architekturentwurfs, aber auch beim Störungsmanagement, sollen die Abteilungen enger zusammenarbeiten. Dies fördert die Sensibilität für die oft als konträr empfundenen Arbeitsziele. Die Schnittstellen zwischen Entwicklung, Betrieb und Qualitätssicherung sollen ausgebaut werden.
- Automatisierung: Ein hoher Automatisierungsgrad des Entwicklungs- und Bereitstellungsprozesses ermöglicht eine rasche Integration von Softwareänderungen, ein kurzes Time-To-Market und die zeitnahe Reaktion auf Probleme.
- Kultur: DevOps möchte eine Kultur fördern, in der sich alle beteiligten Akteure als wichtigen Teil einer gemeinsam zu pflegenden Wertschöpfungskette verstehen. Diese Kultur schließt die Neugier für die Arbeitsweise und das fachliche Know-how der anderen mit ein.
Ist die vage Formulierung ein Fluch oder ein Segen?
Die diffuse Lage im Hinblick auf die Eingrenzung von DevOps kann ein Fluch und ein Segen zugleich sein. Auf der einen Seite darf jedes Softwareentwicklungsverfahren, das wesentliche Elemente des Continous Delivery oder etwa die Container-Technologie einsetzt, das DevOps-Etikett tragen. Es gibt schließlich keine Instanz und auch kein Kriterienkatalog, das einem Stellenbewerber oder einem Entwicklungsteam das Tragen dieses Etikettes verbieten könnte. Unlängst haben die Marketingstrategen diverser Tools-Anbieter den DevOps-Begriff für sich entdeckt und preisen nun Produkte als DevOps-fördernd an, wobei die Mehrzahl ihrer Angebote lediglich einen Teilaspekt dessen abdeckt, was man gemeinhin unter DevOps zusammenfasst. Bei dieser Beliebigkeit läuft die Softwareindustrie Gefahr, den DevOps-Begriff zu einem inhaltsleeren "Buzzword" zu degradieren, das im Laufe der Zeit seine Schlagkraft verliert. Dem könnten sich die bereits bekannten Security-Probleme hinzugesellen und dem Ruf von DevOps einen empfindlichen Dämpfer verpassen.
Ungeachtet dessen setzen sich folgende Strategien unter dem Mantel von DevOps erfolgreich durch:
- Continous Build: Das zeitnahe Bauen und Testen von Codeänderungen ermöglicht ein schnelles Feedback über ihre Kompilierfähigkeit. Statische Codeanalysen bewerten darüber hinaus die Qualität des Codes anhand verschiedener Metriken.
- Continous Delivery: Ein rasches, möglichst automatisiertes Deployment der gebauten Artefakte transportiert die frischen Codeänderungen in ein Zielsystem, das als Grundlage für Black-Box-Tests herangezogen werden kann.
- Deployment Pipeline: Die technische Infrastruktur für die Umsetzung von Continous Delivery sieht mehrere Qualitätsstufen (Stages) vor, die eine Codeänderung mit steigender Fitness durchläuft. Das letzte Glied einer Deployment Pipeline ist das Deployment in eine produktive Laufzeitumgebung.
- Infrastructure as Code: Analog zum Quellcode der Endanwendung stehen die Baupläne der darunterliegenden Infrastruktur (Serverinstanzen, Netzwerkkonfiguration) als ausführbare und wiederholbare Anweisungen im Konfigurationsmanagement zur Verfügung.
- Container-Technologie: Die container-basierte Virtualisierung stellt einen leichtgewichtigen Ansatz für den Betrieb virtueller Maschinen dar. Hierbei werden einzelne Computerprozesse samt ihrer Abhängigkeiten zum Betriebssystem in ein einheitliches Format verpackt und zur Ausführung gebracht. Diese virtuellen Gastprozesse heißen Container und werden idealerweise abteilungsübergreifend genutzt. Die Entwickler testen die Lauffähigkeit und Kompatibilität ihrer Kompilate auf lokaler Ebene, die Qualitätssicherung nutzt Container für individuelle Abnahmetests und der IT-Betrieb kann hochverfügbare Serverfarmen mit Hilfe von Containern effizient skalieren.
- Orchestrierung: Während die Automatisierung die computergestützte Ausführung einer einzelnen, abgeschlossenen Aufgabe umschreibt, kümmert sich die Orchestrierung darum, die automatisierten Aufgaben in einem komplexen Systemumfeld breitflächig zu streuen.
Nun bietet der DevOps-Begriff aber auch eine ideale Projektionsfläche für neuartige Ideen und Konzepte. Da er nach landläufiger Meinung alle Ebenen des ingenieursmäßigen Handelns beinhaltet, nämlich Methodik, Technologie als auch Kultur, erhalten innovative Aspekte aus dem Softwareentwicklungs- und -bereitstellungsprozess eine neue Chance, erprobt zu werden und sich zu beweisen. Ein Beispiel hierfür ist die Datenvirtualisierung, ein – grob gefasst – abstrahiertes und einheitliches Verfahren für den Zugriff auf Daten in einer heterogenen Systemlandschaft. Mit DevOps kommt jetzt ein weiterer positiver Aspekt hinzu: moderne Datenvirtualisierungslösungen bieten die Maskierung und Konvertierung von Daten im Live-Betrieb an, das insbesondere beim Aufbau einer Deployment Pipeline mit mehreren Stages (Entwicklung, Integration, Abnahme, …) und produktionsnahen Daten sehr vorteilhaft sein kann.
Ein vollkommen neues Handlungsfeld im IT-Betrieb bietet das weitestgehend von Business Analysten dominierte BPM (Business Process Management) an. Beim BPM handelt es sich um einen systematischen Ansatz, um Geschäftsprozesse zu modellieren, sie auszuführen und zu überwachen – mit dem Ziel, sie einfacher steuern und verbessern zu können. Softwareentwicklung hat als Geschäftsdomäne schon immer mit Entwicklern, Testern und Systemadministratoren als ihren Fachexperten existiert. Mit einer geschickten Integration einer Process Engine – derjenigen Instanz, die die Ausführung maschineller Aktivitäten, als auch die Koordination der menschlichen Akteure sicherstellt – versetzt man sie in die Lage, automatisierte Build-, Test- und Deploymentschritte planmäßig und eigenständig auszuführen. Der Auslieferungsprozess wird für die Entwicklungsabteilungen als auch für den IT-Betrieb transparent.
Ausblick
Es drängt sich der Gedanke auf, dass ausgerechnet die weit gefasste Formulierung der DevOps-Bewegung zum nötigen Durchbruch verholfen hat. Welche technologische Neuerung hätte denn nicht zum Ziel, mindestens eines der DevOps-Versprechen – die Förderung des Business Alignments, die Reduzierung des Time-To-Market oder die Stärkung der unternehmensweiten Kollaboration – einzulösen? Alleine unter dem DevOps-Leitmotiv der "Automatisierung" lässt sich der Einsatz von einem Großteil der zur Verfügung stehenden Entwickler- und SysAdmin-Tools rechtfertigen.
Rückblickend auf die relativ kurze Geschichte ist DevOps dennoch eine Erfolgsstory und kann zu Recht als ein gewinnbringender Trend bezeichnet werden. Das erste Mal finden altbewährte Methoden aus den Entwicklungsabteilungen (SCM, Unit Testing) auch Einzug in den IT-Betrieb. Die Wahrnehmung der Systemadministratoren als eine Gruppe von Nerds wandelt sich und tausende Entwickler setzen sich neuerdings mit unixoiden Betriebssystemen auseinander. Die Beachtung nicht-funktionaler Softwareanforderungen wie die der Resilienz oder der Konfigurierbarkeit rücken wieder stärker in den Fokus. Unter diesen Gesichtspunkten mag man dem Luftikus DevOps seine Beliebigkeit gerne verzeihen.
Dem Gartner Hype Cycle [1]– einer anerkannten Methodik zur Beurteilung neuer Technologien – nach, befände sich DevOps zweifelsfrei auf dem Weg zum "Gipfel der überzogenen Erwartungen", unweigerlich gefolgt vom "Tal der Enttäuschung". Weil sich DevOps aber nie als eine singuläre Technologie verstand, sondern als ein weit abgestecktes Portfolio verwandter Techniken, könnte sich die Entwicklung der letzten Jahre noch einige Zeit fortsetzen. Auch – oder gerade weil – DevOps sich stetig neu erfindet.
