Softwareentwicklung

DevOps in der Praxis von Micromata

: Das Akronym DevOps bezeichnet das Zusammenwachsen der beiden Bereiche Entwicklung (Dev = Development) und Betrieb (Ops = Operations) in der Softwarewelt.

DevOps Micromata

Aus dem Zusammenziehen Development und Operations – kurz DevOps – zu einem Team ergeben sich unterschiedlichste Chancen zur Verbesserungen der Softwarestabilität und -qualität und zur Prozessoptimierungen.

Was bisher geschah

Mit der Einführung der Serienfertigung hat sich in nahezu allen Industriezweigen die Trennung zwischen Entwicklung und Produktion etabliert. Seither wird über komplexe Freigabe- und Qualifizierungsprozesse sichergestellt, dass das entwickelte Produkt für den gewünschten Zweck einsetzbar ist und unter allen vorgesehenen Bedingungen funktioniert. Je nach Branche und Produkt kann dieser Prozess wenige Tage bis mehrere Monate dauern – für ein einzelnes Bauteil. Die Dauer richtet sich dabei einerseits nach der Zuverlässigkeit, mit der das Teil oder Produkt seine Funktion erfüllen muss, andererseits nach dem Gebiet, auf dem es eingesetzt werden soll.

Als extremes Beispiel seien hier eine einfache Schraube und ein Satellit einander gegenübergestellt: Schrauben werden gemäß gängiger Industriestandards produziert und sind somit einfach zu qualifizieren; eventuell reicht es sogar, zu prüfen, ob der Hersteller bestimmte Qualitätsangaben für seine Schraube macht. Die Materialien für einen Satelliten, der in der Erdumlaufbahn eingesetzt werden soll, erfordern hingegen ein vollkommen anderes Vorgehen: Denn im All entstehen sehr große Temperaturdifferenzen zwischen der sonnenzugewandten und der sonnenabgewandten Seite. Wird nun zum Beispiel eine Kameralinse auf der Oberfläche des Satelliten angebracht, muss diese zunächst in Testkammern qualifiziert werden. Hierbei wird die Linse Temperaturen zwischen +150 °C und -180 °C ausgesetzt, um zu sehen, ob sie unter diesen Bedingungen korrekt funktioniert (Quelle für den Satelliten).

Und warum macht man das?

Die Ursache für den Unterschied in der Vorgehensweise bei Schraube und Satellit ist leicht zu erkennen: Er liegt schlicht und ergreifend darin, dass im Fehlerfall unterschiedliche Kosten entstehen. Während der Entwicklung ist dieser Fehler mit wenig Aufwand zu beheben, wohingegen eine Fehlerbehebung im laufenden Betrieb ein Vielfaches kosten würde.

Für starre Produkte ist dies auch nach wie vor gültig, im Softwarebereich allerdings stimmt dies nur noch in Teilen. Bezogen auf Apps und Client-Programme haben sich die Endanwender in einem gewissen Rahmen daran gewöhnt, dass es Updates gibt. Allerdings sollte hier der Bogen nicht überspannt werden, die Update-Frequenz sollte in einem angemessenen Rahmen bleiben. Wöchentliche oder tägliche Updates sind nahezu nirgendwo mehr zu finden. Eher zyklische Updates, die je nach Kritikalität monatlich oder Quartalsweise erfolgen.

Was Endkunden im Gegenzug nicht wahrnehmen, sind Softwareanpassungen im Backendbereich. Leistungsoptimierungen, Datenablagestrukturen, Technologiemigrationen oder Wechsel von Frameworks sind für Endanwender nicht sichtbar. Hier besteht somit eine absolute Freiheit für den Betreiber, in welcher Taktung die neuen Versionen veröffentlicht werden.

Zwischen diesen beiden Extremen steckt die Weboberfläche, welche die Endkunden sehen und bedienen. Hier wird häufig mit fließenden Veränderungen gearbeitet. Die Software wird alle paar Wochen mit kleineren Änderungen angepasst, die jeweils einzeln kaum wahrnehmbar sind. Diese Änderungen verbessern wahlweise die User Experience oder präsentieren die Inhalte der Seite anders, so dass sich der Betreiber mehr Umsatz verspricht.

Funktionale Trennung und Geschwindigkeit

Die Anfangs angesprochene Aufteilung von Entwicklung und Betrieb ist durch den Übergabeprozess nicht der effizienteste Weg, hier zu einer hohen Frequenz 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 alle sicherstellt. Massive Prozessveränderungen, wie zum Beispiel der Ansatz des Blue-Green-Deployments, der sich mit geeigneten Architekturen noch weiter optimieren lässt.

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 größeren Unmutbekundungen von Anwendern die Applikation mit minimalem Aufwand auf die alte Version zurückgestellt werden kann. Ein weiterer Vorteil ist, dass sowohl Roll-out als auch Roll-back nahezu ohne Downtime möglich sind.

Erweitert man nun diesen Ansatz und lässt die Server in einer Containerlandschaft laufen, eröffnen sich weitere Optimierungsoptionen. Im laufenden Betrieb wird ein weiterer Container mit der neuen Version hochgefahren; sobald der Server gestartet ist, kann dann mittels eines einfachen Health Checks getestet werden. Fällt der Test positiv aus, wird der Load Balancer so erweitert, dass er einen kleinen Teil der Anwender auf diese Node leitet. Es bietet sich an, hier eine relativ kleine Zahl an Benutzern zu wählen, die die Komplexität der Anwendung widerspiegeln, sagen wir zwischen 20 und 500 Usern.

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.

Und was hat DevOps damit zu tun?

Das Zusammenlegen von Entwicklung und Betrieb eröffnet auf verschiedenen Ebenen Potentiale. Als erstes sei der Aufbau einer sinnvollen Testpyramide genannt. Die Funktionen der Software werden über so viele Unittests wie möglich geprüft, anschließend erfolgen die nun noch notwendigen System- oder Integrationstests; abschließend, soweit noch nötig, können GUI-Tests erfolgen. Hier kann der Betrieb seine Erfahrungen direkt an die Kollegen zurückfließen lassen, so dass Fehler beim nächsten Release nicht mehr auf der Produktion auftreten können. Dies betrifft im Besonderen die Bereiche der Applikation, in denen sich die Testumgebung von der Produktivumgebung unterscheidet. Sei es nun durch Mock-up-Schnittstellen oder Hardware-Ausstattung.

Ein weiterer Effekt ist, dass Roll-outs bei geeigneter Architektur durchaus zu Zeiten mit durchschnittlicher Last auf dem System stattfinden können. Die gemeinsame Beobachtung der Logmeldungen erhöht die Kommunikation zwischen Entwicklung und Betrieb, neue Logmeldungen können so direkt und klar erklärt werden. Desweiteren erfährt der Entwickler direkt am lebenden Objekt, wie seine Software sich verhält, er sieht was auf den Servern los ist.

Dies lässt sich noch durch die Wartungsunterstützung erweitern. Wartungstickets werden klassisch vom Betrieb abgearbeitet, in einem DevOps-Team kann ein Entwickler, idealerweise rollierend durch das Entwicklerteam, den Betriebskollegen als direkter Ansprechpartner in Fleisch und Blut zur Verfügung stehen, keine komplizierten Telefonkonferenzen oder Video-Calls.

Ein weiterer nicht zu unterschätzender Effekt ist das tägliche Miteinander. Die Kollegen wachsen zu einem Team zusammen und fühlen sich deutlich stärker für die Applikation verantwortlich, als wenn jeder nur auf seiner Seite des Zaunes sitzt.

Tobias Pressel

Projektleiter