DEVOPS UND DIE LIEGENDE ACHT

Next Article

PERSISTENTER STORAGE FÜR KUBERNETES & CO.

Cloud Computing ist nicht spurlos an den Methoden, wie Software entwickelt wird, vorbeigegangen: Cloud Native, DevOps, agile Entwicklung, Kubernetes, Microservices, Container und viele weitere Begriffe prägen das Geschäft. Doch wie passt das eigentlich alles zusammen?

„Wollen Sie die Änderungen speichern?“, fragt die Software. Der User bemerkt, dass er dabei ist, einen Fehler zu machen und klickt auf „Abbrechen“. Die Software entgegnet per Dialogfenster: „Wollen Sie den Vorgang wirklich abbrechen?“ und bietet zum Anklicken „Fortsetzen“ und „Abbrechen“ an. Der User holt sich daraufhin einen Kaffee und verzieht sich mit den Worten „Ich muss nachdenken“ auf die Dachterrasse des Firmengebäudes. Dort fragt er sich: „Wenn ich auf ‚Fortsetzen‘ klicke, wird dann der Speichervorgang fortgesetzt oder der Abbruchvorgang? Und wenn ich auf ‚Abbrechen‘ klicke, heißt das, dass der Abbruchvorgang abgebrochen wird oder der Speichervorgang?“ Kollegen, die seinen leeren Blick gesehen haben und sich nach dem Befinden erkundigen, kommen auch zu keinem Ergebnis.

Zu Zeiten, in denen ein paar bärtige Nerds im Keller vor sich hincoden, könnte dieses Dialogparadoxon lange Zeit bestehen und sukzessive Arbeitszeit der User „fressen“. Abhilfe schaffen Feedback-Schleifen zwischen Nutzern, Admins und Programmierern. Konzepte wie „DevOps“ (siehe Kasten) oder „agile Softwareentwicklung“ operationalisieren dies im Tagesgeschäft der Software-Entwicklung insbesondere im Zeitalter der Cloud-Native-Anwendungen, in denen Neuerungen schnell, technisch problemlos und von zentraler Stelle ausgerollt werden. Wie DevOps zielt auch „agile Softwareentwicklung“ darauf ab, vom Kunden angestoßene Änderungen schnell umzusetzen. Das Projektmanagement dahinter bedient sich eines iterativen (sich wiederholenden) und inkrementellen (schrittweisen) Vor- gehens und ist darauf aus, alle, die mit der Software zu tun haben, in den Entwicklungs-, später Verbesserungsprozess einzubinden.

Verschiedene Frameworks wie Scrum, Kanban oder Extreme Programming (XP) haben jeweils ihre eigenen Prinzipien und Regeln, schlagen aber alle in dieselbe Kerbe: eine iterative und agile Entwicklung. Agile Methoden sollen es ermöglichen, schnell auf Kundenfeedback zu reagieren, während DevOps sicherstellt, dass der Softwareentwicklungs-Prozess nahtlos funktioniert und die Anwendung kontinuierlich getestet und bereitgestellt wird. Bei Cloud Native kommt all dies zusammen: Der Begriff beschreibt SoftwareEntwicklung, die für den Einsatz in CloudComputing-Umgebungen ausgelegt ist.

Bei DevOps geht die Arbeit nie aus!

Die liegende Acht symbolisiert das fortwährende ineinandergreifen der acht DevOps-Phasen, die nach einem Software-Release in jeder Iteration wieder mit einer erneuten Planungsphase beginnt, in der fortan immer wieder Verbesserungen geplant werden.

Ständige Verbesserung ist daher Teil des DevOps-Prozesses, denn basierend auf Feedback aus dem laufenden Betrieb, speziell aus der MonitorPhase und auch im Sinne von Userfeedback werden Verbesserungen Teil des laufenden Prozesses. Die liegende Acht ist somit ein Symbol für die ständige Verbesserung und den kontinuierlichen Fluss innerhalb des DevOps-Konzepts.

In DevOps geht es zudem darum, eine gemeinsame Kultur zu schaffen, in der die Teams der Bereiche Development und Operations (also dem laufenden Betrieb) eng zusammenarbeiten und Wissen und Erfahrungen teilen. Automatisierung spielt eine große Rolle beim sogenannten „Continuous Improvement“, also der bereits in den Arbeitsprozessen strukturell angelegten, ständigen Verbesserung der Software.

1) Plan: In dieser Phase werden die initialen oder neuen Anforderungen an die Software definiert und der Plan für die Umsetzung erstellt.

2) Code: Hier wird die Software von den Developern entwickelt, wobei verschiedene Entwickler zusammenarbeiten, um Code zu schreiben, der den Anforderungen aus dem Operations-Segment entspricht.

3) Build: In dieser Phase wird der Code in ausführbaren Code kompiliert und in ein ausführbares Format gebracht, das auf der Zielplattform ausgeführt werden kann.

4) Test: Hier wird die Software getestet, um sicherzustellen, dass sie den Anforderungen entspricht und keine Fehler aufweist.

Die Anwendungen werden dabei von Grund auf für die Cloud entwickelt, wobei alle Aspekte der Entwicklung, Bereitstellung und Verwaltung auf Cloud-Computing abgestimmt sind.

So sind Cloud-Native-Anwendungen typischerweise in Containern verpackt, um Portabilität und Skalierbarkeit zu ermöglichen, sowie in Microservices aufgeteilt. Die Zergliederung in Microservices kommt der agilen Entwicklung und Wartung, beziehungsweise der DevOps-Philosophie besonders entgegen. Cloud-Native-Entwickler nutzen in der Regel automatisierte DevOps-Tools und Continuous-DeliveryMethoden, um schnellere Releases und Anpassungen zu ermöglichen.

So wird einerseits für die Cloud mit speziellen Methoden entwickelt, andererseits gibt die Cloud dem Dev- und dem OpsBereich auch etwas zurück, nämlich Flexibilität. So musste sich ein IT-Administrator früher, um eine Geschäftsanwendung bereitzustellen, um Folgendes kümmern: Data Center, Racks, Kühlung, Netzwerk, Switches, Router, Firewalls, Server- und Storage, Betriebssystem-, Datenbank-, Middleware- und Applikationsserver samt deren Betrieb. Bei einem Entwicklungsprojekt mussten Server, Storage, Lizenzen für Dev-, Test- und Integrationsumgebungen gekauft, installiert, gewartet und instand gehalten werden.

5) Release: In dieser Phase wird die Software als fertiges Produkt markiert und zur Veröffentlichung bereitgestellt.

6) Deploy: Hier wird die Software auf die Produktionsumgebung übertragen und für den Einsatz bereitgestellt.

7) Operate: Sobald die Software bereitgestellt wurde, wird sie angewendet, im Sinne eines laufenden Betriebes.

8) Monitor: In dieser Phase wird die Software überwacht, um sicherzustellen, dass sie reibungslos funktioniert und keine Leistungsprobleme oder Sicherheitsrisiken aufweist.

In der Cloud-Ära ist das nicht mehr so, denn viele dieser Aufgaben werden schon vom Cloud-Provider oder Hyperscaler im Voraus erledigt. Virtuelle Maschinen, die beispielsweise auf VMware-Servern laufen, können quasi nahtlos auf AWS, Azure oder GCP (Google Cloud) gewechselt werden. Dasselbe gilt für Docker-Container auf Kubernetes-Umgebungen, die die Grundlage bei der Bereitstellung von Cloud-NativeSoftware bilden.

Die Container-Technologie gibt es schon lange; bekannt geworden ist sie seit Docker das Thema als Container-Management groß gemacht hat. Docker ist eine freie Software zur Isolierung von Anwendungen mit Hilfe von Container-Virtualisierung. 2016 kam dann mit Kubernetes die Container-Orchestrierung hinzu, die den Umgang mit isolierten Microservices erheblich vereinfacht hat. Kubernetes (im Fachjargon auch „K8s“ genannt), ist ein ursprünglich von Google entwickeltes Open-Source-

System zur Verwaltung von ContainerAnwendungen. Das Zusammenspiel der Container zu managen wird als „Orchestrierung“ bezeichnet.

Das Klischee der blassen IT-Nerds, die im Firmenkeller in ihrer eigenen Welt ohne Tageslicht und ohne nennenswerten Kontakt zur Außenwelt vor sich hinarbeiten, wurde beispielsweise in der britischen Sitcom „The IT Crowd“ aufgegriffen. Spätestens seit DevOps und anderen Methoden zur ständigen und schnellen Verbesserung gilt: Dass alle Klischees immer falsch sind, ist leider auch eines. Aber FeedbackSchleifen, die den Austausch operationalisieren, können tief im Tagesgeschäft der Software-Entwicklung verwurzelt werden und User mit der IT zusammenbringen. Dann klappt es auch mit userfreundlichen Dialogfenstern und niemand muss sich mehr mit leerem Blick in der Frage verlieren, ob mit „Abbruch“ der Speicher- oder der Abbruchvorgang abgebrochen wird.

DevOps automatisiert die Zusammenarbeit zwischen Developern und Operations für laufende Verbesserungen.

Autor: Dr. Stefan Riedl