01.07.2022 Mark Melzel
Jeder Windows User kennt es: mitten bei der Arbeit wird man aufgefordert neue Updates einzuspielen. In dieser Zeit können der PC und die bereits vorhandene Software nicht genutzt werden. Für den Nutzer handelt es sich bei diesen Überholungen somit um tote Zeit. Die Problematik beschränkt sich zudem nicht nur auf Windows-Anwendungen - auch beim Aktualisieren von Serveranwendungen ist ein Herunterfahren vor dem Austausch einer neueren Version notwendig. Und genau an dieser Problemstelle setzt das sogenannte Zero Downtime Deployment an.
Aber was genau versteht man unter Zero Downtime Deployment? Ein gutes Beispiel zur Veranschaulichung stellt Netflix dar. Der Onlinedienst steht für Millionen von Nutzern weltweit zu jeder Tages- und Nachtzeit zur Verfügung - dennoch werden täglich neue Updates eingespielt. Diese haben für den User in den meisten Fällen keine merkbaren Auswirkungen. Im Best Case Szenario können somit mehrfach täglich neue Features eingeführt und Bugs unauffällig beseitigt werden. Für den Benutzer bleibt die Software jedoch zu jedem Zeitpunkt erreichbar und vor allem nutzbar.
Traditionell halten sich Entwicklungsteams an Release Pläne. Im Laufe des Entwicklungsprozesses werden alle Änderungen in einer Version zusammengefasst und dann am Ende eines solchen Zyklus in Form eines großen Releases bereitgestellt. Hierbei handelt es sich oft um einen stark manuellen Prozess. Ein solcher Ablauf kann sich beispielhaft wie folgt abbilden:
Die Stackholder werden vor dem Release darüber informiert, dass die Anwendung für einen spezifischen Zeitraum nicht erreichbar sein wird. Daraufhin wird die neue Softwareversion gebaut und der Server heruntergefahren. Die neue Software wird daraufhin installiert, konfiguriert und bereitgestellt. Nach einem kurzen Test steht die gesamte Anwendung im Normalfall wieder zur Verfügung. Im Schnitt nimmt dieser Prozess mehrere Minuten in Anspruch. Treten jedoch Komplikationen auf, kann die Erreichbarkeit der Anwendung auch nach diesem Zeitraum nicht sofort wieder gewährleistet werden. Je nach Branche kann ein Ausfall von Systemen nicht nur mit hohen Kosten, sondern auch mit negativem Feedback der User sowie Kündigungen der angebotenen Leistung einhergehen.
Werden signifikante Problemstellen wie kritische Bugs entdeckt oder ist die Anwendung gar nicht mehr nutzbar, wird auf eine frühere Version zurückgerollt. Alle Änderungen, die bis zu diesem Zeitpunkt umgesetzt wurden, werden somit wieder rückgängig gemacht. Weniger kritische Bugs werden in diesem Fall dokumentiert und ihre Änderung für die nächsten Versionen eingeplant. Je nach Release Zyklus kann der Prozess eines Bug-Fix somit mehrere Wochen bis Monate in Anspruch nehmen. Es handelt sich hierbei also um einen sowohl zeit- als auch kostenintensiven Prozess.
Zero Downtime Deployment macht im Gegensatz dazu Internetriesen wie Netflix, eBay oder Check24 erfolgreich. Täglich werden hunderte Änderungen in Produktion bereitgestellt. Bugs werden sofort am Tag der Entdeckung beseitigt und die Erreichbarkeit der Serveranwendungen ist zu jeder Zeit gewährleistet. So werden einerseits die Kundenbedürfnisse an die Plattformen erfüllt, doch auch intern bringt diese Vorgehensweise enorme Vorteile.
Softwareingenieure sind durch die Möglichkeit sofort auf Änderungen und Gegebenheiten einzugehen in der Lage zeitnah zu agieren, ohne auf längere Releases warten zu müssen. In diesem Kontext entfallen Deadlines und die Organisation eines ganzheitlichen Release Teams, welches häufig für Deployment und Testing einer neuen Software nötig ist. Daraus ergibt sich nicht nur ein signifikantes zeitliches und auch finanzielles Einsparungspotential für Unternehmen: Mit Hilfe von Zero Downtime Deployment ist es zudem sowohl möglich „feature-driven“ zu entwickeln und zu testen als auch (gleichzeitig) Echtzeitexperimente durchzuführen. In diesem Kontext können interne als auch externe Kunden Teil eines QA Prozesses sein. Im Prozess ist es somit möglich sofort durch Feedback auf Änderungen zu reagieren und Tests auf Produktionsumgebungen durchzuführen.
Zero Downtime kann mit Hilfe des sogenannten Blue/Green Deployments erlangt werden.
Für eine optimales Blue/Green Deployment benötigt man mindestens zwei Server mit unterschiedlichen Versionen der Anwendung und zusätzlich ein CI/CD Prozess, der das automatische Deployen der Software ermöglicht. Dabei müssen ausreichend Test-Cases zur Verfügung stehen und allgemeine Best Practices eingehalten werden.
Änderungen am Datenbankschema können bei diesem Vorgehen eine Herausforderung sein. Daher muss zunächst ein Datenbank Refactoring durchgeführt werden. Die Datenbank muss in diesem Fall sowohl die neue als auch alte Softwareversion unterstützen können. Ist die Funktionalität nach dem Refactoring weiterhin gegeben, kann der Server nun als Ausgangspunkt für ein Rollback genutzt werden. Anschließend fährt man mit dem eigentlichen Blue/Green Deployment fort.
Hierbei handelt es sich um ein Verfahren, bei dem der Nutzerverkehr von einer Produktivumgebung auf eine Neue schrittweise umgeschlüsselt wird. Der Datenverkehr wird von der Umgebung mit der alten Version der Software (blau) auf die neue Version (grün) übertragen. Im Falle eines Rollbacks kann die blaue Umgebung weiterhin verwendet werden und als Vorlage für weitere Updates dienen. Sobald die grüne Umgebung zur Verfügung steht, und es zu keinen großen Komplikationen gekommen ist, kann die blaue Umgebung heruntergefahren werden. Nun wird die grüne Umgebung zur neuen Blauen und der CI/CD Prozess kann - wenn nötig - von Neuem gestartet werden.
Abschließend lässt sich sagen, das Zero Downtime Deployment für die Wartung einer Webanwendung definitiv den effizientesten Weg darstellt. Man bewahrt nicht nur seine Benutzer, sondern auch Stakeholder vor ständigen Updates mit Wartezeiten und nutzungsfreien Slots. Jeglicher Overhead für die Planung von Releases und die Koordination eines Teams entfällt in dieser Hinsicht. Der Erfolg eines etablierten Zero Downtime Deployment Prozesses hängt jedoch von mehrdimensionalen Faktoren ab. Sie beinhalten unter anderem hochwertige und in ausreichender Menge vorhandene Tests, sowie eine Deployment Strategie und allgemeine Best Practices im Bereich von CI/CD. Somit sind bei weitem nicht alle Unternehmen in der Lage Zero Downtime Deployment zur Verfügung zu stellen. Auch fehlende Ressourcen, beispielsweise in Form von entsprechend qualifizierten Mitarbeitern sowie fehlenden Möglichkeiten zur Implementierung der nötigen Prozesse, können hier als Dealbreaker agieren.
Leider ist das Zero Downtime Deployment für Windows Rechner aufgrund fehlender Möglichkeiten wie beispielsweise eines Blue/Green Deployments, auch in Zukunft keine Option. So werden wir während der Installation neuer Windows Updates weiterhin etwas länger auf unseren wohl verdienten Feierabend warten müssen.