DevOps ist die Zusammenlegung von Entwicklung (Development) und Betrieb (Operations) in einem Team. Dadurch entstehen Synergien, die sich positiv auf beide Bereiche auswirken, weil die Wege kürzer werden und ein gemeinsames Verantwortungsgefühl für alle Bereiche des Systems entsteht.
Kompetenzen konzentrieren
Der Betrieb schaut nicht mehr nur singulär auf die Hardware und die Entwicklung nicht mehr nur auf die Software. Alle Belange können ganzheitlich im Sinne eines System Responsibility Engineering (SRE) betrachtet werden.
Treten zum Beispiel bestimmte Logmeldungen gehäuft auf, so kann der Betriebskollege direkt mit dem Entwickler reden, der die Funktion implementiert hat. Somit ist eine Analyse einfacher, schneller und zielgerichteter. Zum einen wird der Betrieb in seiner Arbeit unterstützt, zum anderen erhält der Entwickler Einsicht, wie seine Implementierung sich in der täglichen Anwendung verhält. Gleichzeitig kann ein Entwickler, der eine neue Funktion implementieret, sich das aktuelle Verhalten im Betrieb zeigen lassen und so die ideale Lösung aus Systemsicht entwickeln.
Damit werden alle Anforderungen, sowohl funktionale als auch nicht funktionale, immer gesamtheitlich betrachtet und die Applikation ist bestmöglich auf die Gesamtheit der Anforderungen ausgerichtet. Die Komplexität der Applikation wird somit leichter bewältigt, da sie aus allen nötigen Richtungen betrachtet wird. Dies ist im Besonderen für Systeme vorteilhaft, deren Komplexität über die Zeit wächst – und das sind fast alle. Auf der einen Seite sind da neue Funktionen, die die Anwendung erweitern, auf der anderen Seite wächst das Produktportfolio unter Umständen immer weiter, so dass neue Funktionalitäten in der Software abgebildet werden müssen.
Funktionale Trennung und Geschwindigkeit
Die klassische Aufteilung von Entwicklung und Betrieb ist, bedingt durch den Übergabeprozess, nicht der effizienteste Weg, um zu einer hohen Entwicklungsfrequenz zu kommen. Daraus wurde die Idee der DevOps geboren. Alle bestehenden qualitätssichernden und sicherheitsrelevanten Maßnahmen wurden neu strukturiert und so verzahnt, dass ein Team sie alle sicherstellt. Massive Prozessveränderungen, wie zum Beispiel der Ansatz des Blue-Green-Deployments, der sich mit geeigneten Architekturen noch weiter optimieren lässt, sind meist nicht notwendig.
Blue-Green-Deployment ist ein Ansatz, bei dem zwischen der alten und der neuen Version mittels eines Load Balancers umgeschaltet werden kann. Vorteil ist, dass im Falle von kritischen Fehlern oder Anwendungsproblemen die Applikation mit minimalem Aufwand auf die alte Version zurückgestellt werden kann. Ein weiterer Vorteil ist, dass sich dies nicht nur auf Tests beschränkt, weil sowohl Roll-out als auch Roll-back mit dieser Technik ohne Downtime möglich sind.
Erweitert man nun diesen Ansatz und lässt die Server in einer Containerlandschaft laufen, eröffnen sich weitere Optimierungsoptionen. Dazu wird im laufenden Betrieb ein weiterer Container mit der neuen Version hochgefahren. Wenn der Server gestartet ist, kann dieser mittels eines einfachen Health Checks geprüft werden. Fällt der Test positiv aus, wird der Load Balancer so erweitert, dass er einen kleinen Teil der Anwender auf diese Node umleitet. Hier bietet es sich an, eine relativ kleine Zahl an Benutzern zu wählen, die die Komplexität der Anwendung widerspiegelt, sagen wir zwischen 20 und 500 Usern.
Monitoren und optimieren
Nun beobachten Kollegen aus der Entwicklung und dem Betrieb gemeinsam das Logging. Sind die neuen Funktionen ok? Treten kleinere Fehler auf oder bricht etwas zusammen? Je nach Verlauf dieser Beobachtung, wird der Knoten wieder aus dem Load Balancer rausgenommen oder die Applikation wird sukzessive, sprich ein Container nach dem anderen, ausgetauscht. Wobei hier nicht die Installation pro Container gemeint ist, sondern dass die Container mit der neuen Version gestartet und die Container mit der alten Version nach und nach abgeschaltet werden. Über den Load Balancer landen alle Benutzer, welche die Seite neu aufrufen, auf der neuen Version. Somit ist ein downtime-freies Roll-out möglich während alle Benutzer nahtlos weiterarbeiten können.
Eine Möglichkeit, die Prozess-Laufzeit zu verkürzen, entsteht durch eine CI/CD-Pipeline. CI/CD steht für Continuous Integration / Continuous Deployment, also kontinuierliche Integration und kontinuierliches Ausrollen. Hierzu wird die Applikation zyklisch in einer Testlandschaft ausgerollt, dort automatisiert anhand einer angemessenen Testpyramide getestet, anschließend zur fachlichen Abnahme bereitgestellt und direkt nach Abnahme, wie oben beschrieben, auf die Produktion gebracht. Diese Vorgehensweise ermöglicht es, in kurzen Releasezyklen dem Kunden fortlaufend einzelne Features zur Verfügung zu stellen. Erfahrungsgemäß lassen sich hier alle Prozessanforderungen durch entsprechende Stufen in der CI/CD-Pipeline erfüllen. In Kombination mit einer scrum- oder kanban-basierten Projektvorgehensweise lässt sich so die Time to Market verkürzen und die Implementierung der wichtigsten Anforderungen leichter priorisieren. So wird eine flexible Reaktion auf die Marktbedürfnisse ohne großen Sonderaufwand standardisiert. Alle Beteiligten, vom Fachbereich bis zum Betrieb, können sich auf ihre Kernaufgabe konzentrieren und werden nicht durch Nebenläufigkeiten aufgehalten.
Voraussetzungen in der Architektur
Die Architektur der Software ist hier nur von untergeordneter Bedeutung, sowohl Microservices als auch monolithische Architekturen können in Containerlandschaften betrieben werden. Hier sollten die benötigten Funktionen und deren optimale Implementierung im Vordergrund stehen. Ob ein Monolith, der verteilt auf 8 Application Nodes läuft, die sich gegenseitig austauschen und so das Job Handling untereinander aufteilen, oder zwei kleine dedizierte Container, welche die Jobs neben den 8 Application Nodes alleine abarbeiten, wird nicht durch die Technik vorgegeben. Je nach Menge, Laufzeit und Kritikalität der Jobs bietet jede Lösung gewisse Stärken, die berücksichtigt werden können. Haben wir zum Beispiel einen Job, der einmal am Tag um 16:00 Uhr tausendfach parallel aufgerufen wird, so bieten sich dedizierte Container zum Job Handling an. Diese laufen über den gesamten Tag verteilt, bis zwischen 15:45 Uhr und 18:00 Uhr weitere dazu geschaltet werden, während eine der Application Nodes abgeschaltet wird, weil sie nicht benötigt wird.
Der Nutzen
Containerlandschaften bieten dadurch auch die Chance der Kostenoptimierung. Durch eine sinnvolle Verteilung von Jobs, Aggregierungen, Reportings und ähnlichem über den Tag, kann die CPU-Leistung auf echte Spitzenzeiten ausgelegt werden, und die Hardware arbeitet über den gesamten Tag mit relativ gleichmäßiger Auslastung und folgt nicht dem menschlichen Arbeitstag. Des Weiteren macht es aus Sicht der Applikation keinen Unterschied, wo sie läuft; egal ob Cloud, externes Hosting oder auf eigener Hardware. Auch hier sind es der Inhalt und die Kritikalität der Anwendung, die die Marschrichtung vorgeben.
Manche Dinge sind älter als ihre Benennung. Das Entwickeln und Betreiben von Applikationen passiert schon seit 15 Jahren – sowohl im Kundenauftrag als auch in selbstgenutzten Systemen. Mit DevOps und ein wenig Mut am Anfang lassen sich unzählige Stellschrauben im System passgenau auf die Aufgabe der Applikation einstellen – egal, ob diese zu Beginn schon bekannt waren oder nicht: ein 20-facher Anstieg des Datenvolumens in 12 Monaten, ein downtime-freies Roll-out als Wettbewerbsvorteil, Flexibilität im Ausbau der Anwendung, genau an der Stelle, wo sie gebraucht wird; all dies können wir mit den Mitteln von DevOps und gemeinsam mit dem Auftraggeber lösen.
Interesse an DevOps? Lesen Sie hier einen weiteren, etwas älteren Blogbeitrag zum Thema.
