Schriftliche DevOps-Schulung

Wie bringen Sie DevOps-Code mit geringem Risiko in Produktion?

In vielen IT-Organisationen sind Produktions-Deployments aufwendig und stressig. Um Ruhe zu bewahren, versuchen Teams daher, möglichst selten in Produktion zu deployen. Unweigerlich werden die Lieferpakete dadurch größer und verursachen noch mehr Probleme. Dieser Teufelskreis verschärft sich und prägt leider viele der größten Organisationen, auch wenn Software und Technologie ihr Kerngeschäft sind.

Ihr DevOps-Team hat integrierte Kontrollen und Maßnahmen zur Risikominderung

In einer typischen IT-Organisation entwickelt das Entwicklungsteam die Software und das Betriebsteam spielt sie ein. Bei DevOps übernimmt Ihr eigenes eigenständiges und kompetentes Team die Kontrolle und die Risikominderung. Es setzt dazu auf automatisierte Deployments und Peer-Reviews im Team.

Produktions- und Nichtproduktionsumgebungen sind ebenso wichtig wie die Software Ihres Teams. Deshalb gelten diese drei Grundsätze:

1. Halten Sie alle Umgebungen konsistent, einschließlich Betriebssystemen, Komponenten, Schnittstellen, Patchständen, sonstigen Abhängigkeiten sowie eigener Software und Konfiguration.
2. Die Behebung von Problemen, die die Konsistenz Ihrer Umgebungen beeinträchtigen, hat oberste Priorität.
3. Setzen Sie in allen Umgebungen dieselben Deployment-Techniken ein. So wird die Probe für Produktion zum täglichen Ablauf.

Ihr integrierter Self-Service für Deployments

Ihr automatisierter Self-Service für Deployments folgt diesem Muster.

1. Code schreiben und in den Trunk einchecken.
2. Bereitstellbare Pakete bauen.
3. Pakete und Abhängigkeiten prüfen und feststellen, ob die Konfiguration bereit ist.
4. Prüfen, ob die Umgebung bereit ist.
5. Automatisierte Tests ausführen.
6. Alle Prüf- und Testergebnisse für Audits und Compliance dokumentieren.
7. Pakete in der Zielumgebung bereitstellen.
8. In der Zielumgebung automatisierte Tests ausführen, um das Deployment zu überprüfen.
9. System-, Leistungs- und Aktivitätsmetriken der Zielumgebung überwachen.
10. Schnell Rückmeldung geben und das Deployment korrigieren oder zurücknehmen, wenn etwas schiefgeht.

Deployments und Releases erfüllen unterschiedliche Aufgaben

Mit dem automatisierten Self-Service kann Ihr Team täglich Code in Produktions- und anderen Umgebungen bereitstellen. Da ein Deployment nicht immer eine neue Funktion oder einen Vorteil für Kunden freigibt, sollte das Team Anwendungen und/oder Umgebungen so gestalten, dass ein Release keine Codeänderung und kein weiteres Deployment erfordert.

Blue-Green-Deployment

Eine Herausforderung bei automatisierten Deployments ist der Wechsel vom letzten Testschritt in den Live-Betrieb. Er muss meist schnell erfolgen, damit die Ausfallzeit gering bleibt. Beim Blue-Green-Deployment nutzen Sie zwei möglichst identische Produktionsumgebungen. Eine davon ist live, im Beispiel die blaue. Bei der Vorbereitung eines neuen Releases führen Sie die letzten Tests in der grünen Umgebung durch. Sobald die Software dort funktioniert, stellen Sie das Routing so um, dass alle Anfragen an die grüne Umgebung gehen. Die blaue Umgebung ist dann inaktiv.

Canary-Deployment
(auch Dark Launch genannt)

Kanarienvögel dienten früher im Kohlebergbau als Frühwarnsystem. Gase wie Methan oder Kohlendioxid konnten den Vogel töten, bevor sie die Bergleute beeinträchtigten. Anzeichen von Unwohlsein warnten die Bergleute vor gefährlichen Bedingungen.

Vom Bergbau inspiriert, bringt ein Canary-Deployment Releases zunächst zu einem Teil der Nutzer oder Server. Die Änderung wird zuerst auf wenigen Servern bereitgestellt, dort getestet und anschließend auf die restlichen Server ausgerollt. Das Canary-Deployment warnt früh und begrenzt mögliche Ausfallzeiten. Schlägt es fehl, bleiben die übrigen Server unbeeinträchtigt.

Facebook, Google und viele führende Technologieunternehmen nutzen eine Form des Canary-Deployments namens „Dark Launch“. Sie geben neue Funktionen schrittweise an eine kleine Nutzergruppe frei und testen sie, bevor sie alle erreichen. So sehen sie, wie gut die Funktionen ankommen und wie sie sich auf die Systemleistung auswirken. Facebook nennt sein Werkzeug „Gatekeeper“, weil es den Nutzerzugang zu jeder neuen Funktion steuert.

Die Bezeichnung Dark Launch kommt daher, dass diese Funktionsstarts meist nicht angekündigt werden. Die Funktionen werden unauffällig für 1 Prozent, dann für 5 Prozent, dann für 30 Prozent der Nutzer und so weiter freigegeben. Manchmal ist eine Funktion ein paar Tage zu sehen und verschwindet dann ganz. Wahrscheinlich hat sie sich nicht bewährt oder das Unternehmen wollte zunächst Rückmeldungen für die weitere Entwicklung sammeln.

Release-Muster „Cluster Immune System“

Dieses Release-Muster erweitert das Canary-Deployment. Systeme zur Überwachung von Leistung und Softwareaktivität müssen eng mit dem Release-Prozess verzahnt sein.

Im dargestellten Canary-Deployment erfassen die Überwachungssysteme nach dem ersten Deployment auf dem orange markierten Server alle System-, Leistungs- und Aktivitätsmetriken. Überschreiten Probleme bestimmte Schwellenwerte, lösen sie frühzeitig Warnungen aus. Daraufhin wird der installierte Code auf dem orange markierten Server automatisch zurückgenommen.

Liefern die automatisierten Tests auf dem orange markierten Server und das Überwachungssystem positive Ergebnisse, kann das Team den Code mit größerer Sicherheit auch in allen blau markierten Server-Clustern bereitstellen. Zusammengefasst bietet das Release-Muster „Cluster Immune System“ Ihrem DevOps-Team:

• Zusätzliche Absicherung gegen Probleme, die bei automatisierten Tests übersehen werden könnten.
• Schnelle Rückmeldung und automatisches Rollback bei Produktionsproblemen.

Feature-Toggles

Mit Feature-Toggles schalten Sie Anwendungsfunktionen ein und aus. Sobald der gesamte Code für eine Funktion in Produktion bereitsteht, genügt es für ihre Freigabe, den Schalter zu aktivieren. Feature-Toggles sind meist Einstellungen in Konfigurationsdateien oder Konfigurationsdatenbanken des laufenden Systems.

Wenn ein Canary-Deployment Fehler oder ein schlechtes Nutzungserlebnis verursacht, kann das Team die Funktion per Toggle abschalten. Bei Skalierungsproblemen lassen sich auch ressourcenintensive, weniger wichtige Funktionen deaktivieren. So können Kunden die wichtigsten Funktionen mit bestmöglichem Durchsatz nutzen, selbst wenn das System mit allen Funktionen nicht ausreichend skaliert. In einem Onlineshop können Sie beispielsweise die Rechnungsanzeige vorübergehend abschalten, damit mehr CPU und Arbeitsspeicher für den Bestellvorgang verfügbar sind.

In einer serviceorientierten Architektur können DevOps-Teams verschiedene Dienstversionen bereitstellen, ohne sie zu aktivieren. Wenn alle neuen Versionen für eine Funktion oder einen Dienstablauf bereitstehen, aktivieren Sie die zugehörigen Toggles und schalten den neuen Ablauf frei.

Architektur für sicherere Releases

Es gibt keine perfekte Architektur, die für jedes Softwareprodukt und jeden Dienst in jeder Größenordnung passt.

Beim Aufbau der IT-Plattform eines Start-ups ist eine monolithische Architektur meist die erste Wahl, um schnell und günstig in den Markt einzutreten und den Business Case zu prüfen. Das Problem: Funktional unterscheidbare Bereiche wie Kernfunktionen, Zusatzfunktionen, Benutzer- und Systemschnittstellen und Integrationen sind miteinander verflochten, statt architektonisch getrennte Komponenten zu bilden. Viele große Organisationen wie Amazon, Google, Facebook und Ebay mussten ihre Monolithen im Laufe der Zeit aufgeben, um schnell zu skalieren und Funktionen risikoarm freizugeben und zu erweitern. Sie wechselten zu service- oder microserviceorientierten Architekturen und nutzten dabei das Strangler Application Pattern.

Risikoarm zu Microservices migrieren mit dem Strangler Application Pattern

Ein komplexes System vollständig zu ersetzen, kann eine enorme Aufgabe sein. Oft brauchen Sie eine schrittweise Migration und behalten das Altsystem für noch nicht übertragene Funktionen bei. Wenn zwei getrennte Versionen einer Anwendung laufen, müssen die Clients jedoch wissen, wo die jeweiligen Funktionen liegen. Bei jeder Migration einer Funktion oder eines Dienstes müssen die Clients auf den neuen Standort umgestellt werden.

Das Strangler Application Pattern ersetzt einzelne Funktionen schrittweise durch neue Anwendungen und Dienste. Sie erstellen eine Fassade, die Anfragen an das Altsystem im Backend abfängt und an die Altanwendung oder die neuen Dienste weiterleitet. Bestehende Funktionen lassen sich schrittweise migrieren. Die Nutzer verwenden dieselbe Schnittstelle weiter und merken von der Migration nichts.

Ebay war eines der ersten Unternehmen, das seine monolithische Altarchitektur mit dem Strangler Application Pattern in Microservices überführte. Zunächst wurden Anwendungen hinter klar definierten universellen APIs im Ebay-Ökosystem platziert. Dadurch musste der bestehende Code nicht bei einer einzigen Migration neu geschrieben werden. Die Entwicklung wurde in kleine Teams mit 6 bis 10 Ingenieuren gegliedert. Ein Team mit bis zu 10 Personen kann jetzt die universelle API für die Auktionsplattform betreuen, die am häufigsten genutzte Auktions-API der Welt.

FAZIT

In den meisten IT-Abteilungen sind Teams nicht dafür verantwortlich, zukunftsfähige, skalierbare und sicherere Deployment-Muster samt zugehöriger Architektur zu entwickeln. Doch eine Architektur und Funktionen, die schnelle und sichere Deployments ermöglichen, sind eine wesentliche Voraussetzung für den Erfolg mit DevOps.

Nur wenn Ihre Teams täglich schnell und risikoarm bereitstellen können, profitieren Sie von kontinuierlichen Deployments und reibungslosen Releases.