Verwendung von Blue-Green Deployments und Canary Releases

(Originalartikel von Steve Chambers, übersetzt von Alexandra Ordeanu (Dezember 2021)):

Der Einsatz von Blue-Green Deployments und Canary Releases in DevOps ist bekannt und wird praktiziert. Aber könnte dies auch durch IT-Service-Management-Tools (ITSM) vorangetrieben werden? Und könnten diese beiden Praktiken durch ITSM-Tools auf Non-Cloud-Szenarien ausgeweitet werden? In diesem Artikel erkläre ich zwei Erweiterungen von Blue-Green Deployments und Canary Releases, die durch ITSM-Tools sowohl für Cloud- als auch für Nicht-Cloud-Szenarien gesteuert werden können.

Mit Blue-Green Deployment können Sie Green-User auf ein neues Blue-System umstellen, um zu sehen, ob es funktioniert. Wenn es nicht funktioniert, schalten Sie die User einfach schnell wieder auf Green um. Wenn es funktioniert, lassen Sie sie auf dem neuen Blue-System. Nach einer Zeit machen Sie Green zum Staging und zum Ziel eines zukünftigen neuen Systems. Banken machen das mit teuren Mainframe-Systemen mindestens seit den 1990er Jahren.

Sie schalten die End User “an der Eingangstür” um, die ein Netzwerk-Router, ein Load Balancer, ein Webserver oder eine andere Art von verkehrsverarbeitendem Gerät sein kann. Wenn Sie diese Technik verwenden, ist es ratsam, Datenbankschema- und Anwendungsänderungen voneinander zu trennen. So vermeiden Sie den Verlust von Transaktionen beim Rollback und Komplikationen beim Vorwärts-/Rückwärtsrollen.

Ein Blue-Green Deployment ist ein Big-Bang-Ansatz, wenn auch mit einem schnellen und einfachen Rollback. Ein ähnlicher, aber vorsichtigerer Ansatz zum Blue-Green Deployment ist das Canary Release. Dabei werden lediglich einige Green-User auf ein Blue-System umgestellt und nur dann zurückgerollt, wenn es ein Problem gibt.

Führende Cloud-Service-Provider wie AWS bieten diese Art von Einrichtungen in ihren “PaaS”-ähnlichen Services wie AWS Elastic Beanstalk an. Dabei handelt es sich um ein automatisiertes und von AWS verwaltetes System für die Durchführung von Blue-Green-Deployments. Andere Services wie EC2 (virtuelle Maschine) Auto Scaling und Load Balancer helfen Ihnen ebenfalls, diese Art von Cloud-basierten Deployments durchzuführen.

Um sie zu nutzen, müssen Sie jedoch Cloud-Expert:in sein. Aber was wäre, wenn sie über vertraute ITSM-Tools verfügbar wären?

Cloud-Services wie AWS können Blue-Green Deployments und Canary Releases durchführen. Die Services, die dies tun, haben APIs, die von überall gesteuert werden können. Zum Beispiel von einem ITSM-Tool aus.

Plötzlich gibt dies Nicht-Cloud-Experten die Möglichkeit, Systeme und Änderungen selbst zu implementieren – und Rollbacks durchzuführen – ohne Cloud-Ingenieure hinzuziehen zu müssen.

Dies ist das ultimative “Getting Things Done” für die Cloud, da es die “Theory of Constraints“-Probleme löst, indem es sowohl die Cloud-Experten als Engpass beseitigt als auch sicherstellt, dass die ITSM-Best-Practice- und Governance-Richtlinien verwendet werden. Außerdem ist es auf DevOps ausgerichtet, denn um zu funktionieren, muss alles automatisiert und über Self-Service mit Feedback angeboten werden.

Eine Möglichkeit, dies zu tun, sieht folgendermaßen aus:

1. Ein:e Entwickler:in aktualisiert eine Anwendung mit einer Änderung, die für ein Self-Service Blue-Green Deployment oder Canary Release freigegeben ist. Ein Beispiel ist die Änderung der Benutzeroberfläche einer Anwendung – wobei es sich um eine nicht störende, geringfügige Änderung der Benutzeroberfläche handelt, die als Standardänderung eingestuft wird. Sie eignet sich ideal für das Deployment über eine automatisierte Pipeline und Canary Release für eine Minderheit von Benutzer:innen mit automatischem Rollback bei erkannten Fehlern und erhöhtem Rollout bei Erfolg.
2. Ein:e Entwickler:in lädt ihr aktualisiertes Artefakt über das ITSM-Tool hoch, das die Continuous-Integration/Continuous-Delivery-Pipeline (CI/CD) bis zum Stadium “Ready to deploy to production” anstößt.
3. Ein:e Entwickler:in (oder jemand anderes) gibt diesen Schritt frei.
4. Das ITSM-Tool stößt das Blue-Green Deployment oder Canary Release an.
5. Testen und Verifizieren.
6. Rollback oder Acceptance.

Und das alles, ohne dass der Anwender das ITSM-Tool verlassen muss. Dies ist aus mehreren Gründen wichtig:

1. So wenige User wie möglich sollten Zugriff auf Cloud-Systeme haben. Die Business-as-usual-Nutzung der Cloud sollte über das ITSM-Tool gesteuert werden.
2. Tool-Proliferation ist schlecht, also ist es schlecht, noch ein weiteres Tool zu haben, um die Blue-Green Deployments zu betreiben, anstatt die bestehenden Tools zu integrieren.
3. Das ITSM-Tool ist der richtige Ort für die Wertschöpfungskette der Organisation. Die Cloud ist der richtige Ort für die cloudspezifische technische Automatisierung. Sie sollten sich an das halten, wofür sie entwickelt wurden, und sich integrieren, um den Prozess zu vervollständigen.

Die Integration von ITSM-Tools und Cloud-Betrieb bietet enorme Vorteile für Organisationen, da sie Leitlinien hinzufügen und die sichere Nutzung von Cloud-Diensten erhöhen. Wenn Anwender:innen sichere Blue-Green Deployments und Canary Releases aus dem vertrauten ITSM-Tool heraus steuern können, ist das ein solider Schritt für einen erfolgreichen Cloud-Einführungsprozess und einen sicheren, produktiven Betrieb.

This article was originally published in English on ITSM.tools.