Eine effiziente Bereitstellungsstrategie auszuwählen, ist für jedes DevOps-Team eine wichtige Entscheidung. An Optionen mangelt es nicht, aber Sie möchten die Strategie finden, die am besten auf Ihre Arbeit abgestimmt ist.
Ist Ihre Organisation agil? Setzen Sie Continuous Integration und Continuous Delivery (CI/CD) ein? Entwickeln Sie eine Webapplikation? Eine mobile App? Eine lokale Desktop- oder eine Cloud-basierte Applikation? All diese Faktoren und viele weitere bestimmen über die Effizienz einer Bereitstellungsstrategie.
Aber ganz unabhängig von der Strategie dürfen Sie nicht vergessen, dass sich Probleme bei der Bereitstellung nicht vermeiden lassen. Ein „Merge“ kann schief gehen, es können Bugs auftreten oder ein menschlicher Fehler kann in der Produktion problematisch werden. Der Punkt ist, dass Sie sich von der Suche nach der perfekten Bereitstellungsstrategie nicht verrückt machen lassen sollten. Denn diese Strategie gibt es nicht.
Versuchen Sie stattdessen, eine Strategie zu finden, die äußerst belastbar ist und sich an Ihre Arbeitsweise anpassen lässt. Anstatt zu versuchen, unvermeidliche Fehler zu vermeiden, sollten Sie den Code so bereitstellen, dass Fehler minimiert werden und Sie schnell reagieren können, wenn sie dann doch auftreten. Für viele Teams liegt die Lösung dieses Problems in Canary Deployments.
Canary Deployments können Ihnen helfen, Ihren besten Code so effizient wie möglich in die Produktion zu geben. In diesem Artikel werden wir erklären, was Canary Deployments sind und was nicht. Wir gehen auf die Pros und Kontras von Canary Deployments ein, vergleichen sie mit anderen Bereitstellungsstrategien und zeigen Ihnen, wie Sie mit Ihrem Team ganz einfach Canary Deployments durchführen können.
In diesem Artikel greifen wir folgende Punkte auf:
[toc]
Was ist ein Canary Deployment?
Canary Deployments sind Best Practice für Teams, die sich für den Prozess Continuous Delivery entschieden haben. Bei einem Canary Deployment wird ein neues Feature zunächst einer kleinen Teilgruppe von UserInnen zur Verfügung gestellt. Das neue Feature wird je nach Traffic einige Minuten bis mehrere Stunden lang überwacht, oder zumindest so lange, bis aussagekräftige Daten vorhanden sind. Wenn das Team ein Problem feststellt, wird das neue Feature schnell zurückgezogen. Werden keine Probleme festgestellt, wird das Feature für alle UserInnen freigeschaltet.
Der Begriff „Canary Deployment“ hat eine faszinierende Geschichte. Er ist auf die englische Redewendung „Canary in a coal mine“ (Kanarienvogel im Kohlebergwerk) zurückzuführen, als Kanarienvögel oder andere kleine Singvögel in Kohlebergwerken als Frühwarnsystem eingesetzt wurden. Die Bergleute brachten Vögel in Käfigen unter Tage. Wenn die Vögel erkrankten oder starben, war dies ein Warnhinweis dafür, dass sich geruchlose giftige Gase, wie Kohlenmonoxid, ausbreiteten. Ein unmenschliches, aber wirksames Verfahren in Großbritannien und den USA, bis die Kanarienvögel 1986 durch elektronische Sensoren ersetzt wurden.
Ein Canary Deployment macht aus einer Teilgruppe von UserInnen – idealerweise eine fehlertolerante Menge – ein eigenes Frühwarnsystem. Diese Gruppe von UserInnen identifiziert Bugs, fehlerhafte Features und nicht-intuitive Features, bevor Ihre Software einer größeren Zielgruppe zugänglich gemacht wird.
Ihre Canary UserInnen können selbst identifizierte Early Adopters sein, ein demografisch festgelegtes Zielsegment, eine zufallsbedingte Stichprobe, d. h. ein Mix aus UserInnen, der am sinnvollsten ist, um Ihr neues Feature in der Produktion zu überprüfen.
Bei den Überlegungen zu Canary Deployments kann es hilfreich sein, an das Risikomanagement zu denken. Sie können neue, interessante Features regelmäßiger einführen, ohne sich Sorgen machen zu müssen, ob sich eins der neuen Features auf die User Experience aller UserInnen negativ auswirkt.
Canary Releases vs. Canary Deployments
Die Begriffe „Canary Release“ und „Canary Deployment“ werden gelegentlich auch wie Synonyme gebraucht. Aber in DevOps müssen sie unterschieden werden. Eine Canary Release ist ein Test Build einer vollständigen Applikation. Beispielsweise ein nächtlicher Release oder eine Beta-Version.
Manche Teams veröffentlichen Canary Releases oft in der Hoffnung, dass Early Adopters und Power UserInnen, die mit Entwicklungsprozessen besser vertraut sind, die neue Applikation herunterladen, um sie in der Praxis zu testen. Die Browser-Teams von Mozilla und Google und viele andere sind von dieser Release-Strategie begeistert.
Canary Deployments ihrerseits sind das, was wir bereits beschrieben haben. Ein Team veröffentlicht neue Features in der Produktion für Early Adopters oder verschiedene Teilgruppen von UserInnen, die über einen Load Balancer oder ein Feature Flag auf die neue Software geleitet werden. Der Großteil der UserInnen sieht weiterhin die aktuelle, stabile Software.
Canary Deployment – Pros und Kontras
Canary Deployments können als Release Strategie erfolgversprechend und effektiv sein. Aber sie sind nicht für jedes mögliche Szenario die richtige Strategie. Gehen wir auf einige Pros und Kontras von Canary Deployments ein, damit Sie besser entscheiden können, ob sie für Ihr DevOps-Team sinnvoll sind.
Pros
Unterstützung von CI/CD-Prozessen
Canary Deployments bewirken ein schnelleres Feedback zu neuen Features in Produktion. DevOps-Teams erhalten reale Nutzungsdaten schneller, wodurch sie die nächsten Features schneller und deutlich effektiver verfeinern und integrieren können. Solche kurzen Entwicklungsschleifen sind eines der Markenzeichen von Continuous Integration/Continuous Delivery.
Granulare Kontrolle über Feature-Bereitstellungen
Wenn Ihr Team zu kleineren, regelmäßigen Feature-Bereitstellungen schreitet, verringern Sie die Gefahr, dass Ihr Arbeitsablauf durch Fehler unterbrochen wird. Nicht viele UserInnen werden von einem Fehler im Canary Deployment betroffen sein. Diesen Fehler zu beheben, wird nur eine geringfügige Angelegenheit sein. Nicht alle Ihre UserInnen sind betroffen und Sie müssen keine KollegInnen von der geplanten Arbeit abziehen, um ein größeres Produktionsproblem zu lösen.
Realitätsnahe Tests
Interne Tests haben ihre Berechtigung, sind aber kein Ersatz für Test von Applikationen bei realen UserInnen. Canary Deployments sind eine ausgezeichnete Strategie für Tests in einem kleineren Umfang unter realen Bedingungen, ohne die erheblichen Risiken, die Sie eingehen, wenn Sie eine völlig neue Applikation in Produktion geben.
Schnell verbessertes Engagement
Neben besseren technischen Tests können Sie mit Canary Deployments auch schnell feststellen, wie UserInnen mit Ihren neuen Features umgehen. Werden die Sessions länger? Steigen die Kennzahlen für ihr Engagement in diesem Canary Deployment? Wenn keine Fehler gefunden werden, können Sie das Feature allen UserInnen anzeigen.
Sie müssen nicht warten, bis der Test einer umfangreichen Bereitstellung abgeschlossen ist. Binden Sie diese UserInnen ein und fahren Sie mit den nächsten Features fort.
Mehr Daten für Business Cases
Entwickler mögen zwar den Wert ihres Codes erkennen, DevOps-Teams aber müssen gegenüber der Geschäftsleitung und dem gesamten Unternehmen begründen, warum sie mehr Ressourcen brauchen.
Canary Deployments geben schnell Aufschluss darüber, welche Nachfrage für neue Features bestehen könnte. Führen Sie ein Canary Deployment für ein überzeugendes neues Feature bei einer kleinen Gruppe einflussreicher UserInnen durch, damit sie darüber sprechen können. Nutzen Sie Kennzahlen für Engagement und Werbung, um Argumente vorzubringen, warum Sie eine größere neue Initiative in Verbindung mit diesem Feature vorantreiben wollen.
Stärkeres Risikomanagement
Canary Deployments sind im Grunde genommen eine Reihe von Mikrotests. Wenn Sie schrittweise neue Features einführen und sie sukzessive mit Canary-Tests überprüfen, können Sie die Gesamtkosten von Fehlern oder größere Systemprobleme erheblich reduzieren. Sie werden niemals eine größere Version zurücknehmen müssen, einen PR-Schaden erleiden und eine große und komplizierte Codebase überarbeiten müssen.
Kontras
Mehr Betriebskosten
Wie jeder komplexe Prozess haben auch Canary Deployments einige Nachteile. Wenn Sie einen Load Balancer zur Aufteilung von UserInnen für ein Canary Deployment verwenden möchten, brauchen Sie eine zusätzliche Infrastruktur und müssen einen zusätzlichen Verwaltungsaufwand betreiben.
In diesem Szenario erstellen Sie eine zweite Produktionsumgebung und ein zweites Backend neben Ihrer primären Umgebung. Sie haben dann zwei Codebases, zwei App-Server, u. U. zwei Webserver und eine Netzwerkinfrastruktur, die gewartet werden muss.
Alternativ dazu verwenden viele DevOps-Teams Feature Flags, um ihre Canary Deployments auf einem einzigen System zu verwalten. Ein Feature Flag kann UserInnen in einen Canary-Test während der Laufzeit innerhalb einer einzigen Codebasis aufteilen. Canary-UserInnen sehen das neue Feature, während alle anderen den existierenden Code ausführen.
Die Bereitstellung lokaler Applikationen: keine leichte Aufgabe
Wenn Sie eine lokal installierte Applikation entwickeln, laufen Sie Gefahr, dass die UserInnen ein manuelles Update vornehmen müssen, um die neueste Version Ihrer Software zu erhalten. Wenn Ihr Canary Deployment in diesem letzten Update enthalten ist, wird Ihr neues Feature möglicherweise nicht auf allen Client-Systemen installiert, die Sie aber für gute Testergebnisse brauchen.
Mit anderen Worten: Je mehr Ihre Software clientseitig läuft, desto weniger ist sie für Canary Deployments geeignet. Ein vollständiges Canary-Release könnte sich hier besser eignen, um reale Testergebnisse zu erhalten.
UserInnen werden weiterhin mit Softwareproblemen konfrontiert
Ein Canary Deployment soll ein neues Feature zwar nur einigen wenigen UserInnen präsentieren und die breitere User Base auslassen, konfrontiert aber End-UserInnen weiterhin mit einem Code, der nicht ausgiebig getestet wurde. Wenn ein Ausfall eines bestimmten Features bei nur wenigen UserInnen schon zu große negative Auswirkungen für Ihr Unternehmen hat, sollten Sie auf ein Canary Deployment verzichten und strengere interne Tests durchführen.
Wann sollte man auf Canary Deployments verzichten?
Canary Deployments sind zwar eine ausgezeichnete Strategie für Unternehmen, die ständig auf Experimente und Innovationen setzen, sind aber nicht für jeden geeignet. Canary Deployments sind möglicherweise nicht die richtige Strategie, wenn:
- Fehler selbst in kleinen Bereitstellungen zu Regelverstößen bei einem bestimmten System beitragen können. Zum Beispiel im Gesundheitswesen, wenn es um Patientendaten bei einem Produktionssystem geht.
- Der Ausfall eines Dienstes lebensbedrohliche Folgen haben kann, wie z. B. bei Applikationen zur Verwaltung des Stromnetzes oder von Notdiensten.
- Die finanziellen oder organisatorischen Folgen des Ausfalls einer Applikation Ihrem Unternehmen irreparablen Schaden zufügen könnten.
Canary Deployments im Vergleich zu anderen Bereitstellungsstrategien
Canary Deployments sind nur eine mögliche Bereitstellungsstrategie für Ihr Team. Sie werden auch oft mit anderen ähnlichen, aber unterschiedlichen Prozessen wie A/B-Tests verwechselt. Sehen wir uns an, wie sich Canary Deployments mit anderen Bereitstellungsstrategien und ähnlichen Prozessen vergleichen lassen, mit denen sie oft verwechselt werden.
Canary Deployments vs. A/B-Tests
Sowohl bei Canary Deployments als auch bei A/B-Tests werden mehrere Produktionsumgebungen oder mehrere mit Flags versehene Codepfade zum Testen verwendet, wobei aber jedes Mal ein anderes Ziel verfolgt wird. DevOps-Teams nutzen Canary Deployments, um festzustellen, ob bei einer neuen Software technische Probleme vorliegen oder bei der Usability Schwierigkeiten bestehen. Bei einem A/B-Test werden zwei verschiedene funktionierende Varianten für bestimmte Punkte wie Usability und Engagement sowie andere UX-Kennzahlen verglichen, um festzustellen, welche unter bestimmten Bedingungen besser abschneidet.
Canary Deployments vs. Blue-Green Deployments
Canary Deployments werden auch mit Blue-Green Deployments verwechselt. In beiden Fällen können parallele Produktionsumgebungen verwendet werden – die mit einem Load Balancer oder Feature Flag verwaltet werden – um das Risiko von Softwareproblemen zu mindern.
Bei einem Blue-Green Deployment starten diese Umgebungen identisch, aber nur eine empfängt Traffic (der blaue Server). Ihr Team veröffentlicht ein neues Feature für die Hot Backup-Umgebung (den grünen Server). Dann verlagert der Router, das Feature Flag usw. nach und nach neue UserInnen Sessions von dem blauen auf den grünen Server, bis der gesamte Traffic zu 100 % auf dem grünen Server liegt. Nach dem Cutover aktualisiert das Team den jetzt alten blauen Server mit dem neuen Feature, der dann zur Hot Backup-Umgebung wird.
Wie die Umstellung bei den beiden Strategien gehandhabt wird, hängt vom gewünschten Ergebnis ab. Blue-Green Deployments sollen Ausfallzeiten vermeiden. Canary Deployments werden verwendet, um ein neues Feature in einer Produktionsumgebung mit minimalem Risiko zu testen. Canary Deployments sind gezielter.
Wie wird ein Canary Deployment durchgeführt?
Für ein Canary Deployment sind nur wenige Schritte erforderlich:
Identifizieren Sie Ihre Canary-Gruppe
Es gibt verschiedene Möglichkeiten, wie Sie UserInnen als Canary-Gruppe auswählen können.
Zufallsbedingte Teilgruppe
Wählen Sie verschiedene UserInnen wirklich nach dem Zufallsprinzip aus, zum Beispiel mit einem Load Balancer. Aber auch eine Flag Management Software kann einen bestimmten Prozentsatz des gesamten Traffics über ein einfaches Modulo an einen Canary-Test weiterleiten.
Early Adopter
Wenn Sie ein Early Adopter-Programm für besonders engagierte UserInnen durchführen, nutzen Sie diese als Canary-Gruppe. Machen Sie es zum Vorteil ihres Programms. Als Gegenleistung, die Bugs zu tolerieren, auf die sie bei einem Canary Deployment stoßen könnten, bieten Sie ihnen Treueprämien an.
Nach Region
Vielleicht möchten Sie bei Ihrem Canary Deployment auf eine bestimmte Region setzen. Legen Sie zum Beispiel fest, dass Ihr Canary Deployment in den späten Abendstunden an europäische IPs geleitet wird. So vermeiden Sie, dass UserInnen tagsüber Ihre neuen Features sehen, erhalten aber eine Handvoll UserInnen Sessions nach Feierabend.
Interne Testpersonen
Sie können jederzeit Sessions aus Ihren internen Subnetzen als Canary Deployment konfigurieren.
Entscheiden Sie sich für Ihre Canary-Kennzahlen
Zweck eines Canary Deployments ist, eine klare Antwort mit „Ja“ oder „Nein“ auf die Frage zu erhalten, ob Ihr Feature sicher ist, um es in die Produktion zu geben. Um diese Frage zu beantworten, müssen Sie zunächst entscheiden, welche Kennzahlen Sie verwenden wollen, und dann die Mittel zur Überwachung der Performance installieren.
Sie können zum Beispiel Folgendes überwachen:
- die Anzahl der internen Fehler
- CPU-Auslastung
- Speicherauslastung
- Latenzzeit
Sie können die Feature Management-Software schnell und einfach anpassen, um die Performance-Analyse zu überwachen. Diese Plattformen können sich als ausgezeichnete Tools erweisen, um die Experimentierkultur anzuregen.
Entscheiden Sie, wie sich der Übergang vom Canary Deployment zum vollständigen Deployment darstellen soll
Wie bereits erwähnt, sollten Canary-Releases nur einige Minuten bis Stunden dauern. Sie sind nicht für lange Experimente bestimmt. Aufgrund dieser knappen Zeit sollte Ihr Team bereits am Anfang entscheiden, wie viele UserInnen oder Sessions in die Canary-Phase eingebunden werden und wie zur vollständigen Bereitstellung übergegangen werden soll, sobald die Kennzahlen positive Benchmarks erreicht haben.
Sie können zum Beispiel ein zufälliges Canary Deployment von 5/95 wählen. Konfigurieren Sie ein Feature Flag, um 5 Prozent Ihrer UserInnen zufallsbedingt in den Canary-Test zu verschieben, während die restlichen 95 Prozent auf der stabilen Produktionsversion bleiben. Sind die Ergebnisse positiv, entfernen Sie das Flag und stellen das Feature vollständig bereit.
Vielleicht möchten Sie aber auch einen eher konservativen Ansatz wählen. Bei einer weiteren beliebten Canary-Strategie wird ein Canary-Test logarithmisch bereitgestellt, d. h. man geht von einer Stichprobe von einem Prozent auf zehn Prozent, sieht, wie das neue Feature einer höheren Last standhält, und erhöht dann auf 100 Prozent.
Bestimmen Sie die Infrastruktur
Sobald sich Ihr Team einig ist, müssen Sie sicherstellen, dass die gesamte Infrastruktur passt, damit Ihr Canary Deployment reibungslos verläuft.
Sie brauchen ein System zur Aufteilung der User Base und zur Leistungsüberwachung. Sie können die Aufteilung mit einem Router oder Load Balancer vornehmen, aber auch direkt in Ihrem Code mit einem Feature Flag. Feature Flags sind oft kostengünstiger und schneller einzurichten und können leistungsfähiger sein.
Verwenden Sie Feature Flags für bessere Canary Deployments
Auf den Punkt gebracht ist ein Feature Flag nichts anderes als eine „if“-Anweisung, ab der UserInnen während der Laufzeit verschiedenen Codepfaden abhängig von einer oder mehreren Bedingungen folgen. Bei einem Canary Deployment lautet diese Bedingung, ob der oder die UserIn der Canary-Gruppe angehört oder nicht.
Feature Flag – Beispiel
Angenommen, wir betreiben eine vollkommen neue Social Network Website für E-Sport-Fans. Unser DevOps-Team hat hart an einer Content-Empfehlungsfunktion gearbeitet, die UserInnen basierend auf den angeschauten Livestreams Empfehlungen in Echtzeit gibt. Das Team hat dieses Empfehlungsfeature so verbessert, dass es deutlich schneller ist. In internen Tests hat es sich gut bewährt. Jetzt wollen sie sehen, wie es sich unter realen Bedingungen schlägt.
Das Team möchte für ein Canary Deployment keine Zeit und kein Geld in die Installation einer neuen physischen Infrastruktur investieren. Stattdessen beschließt das Team, ein Feature Flag zu verwenden, um die neue Empfehlungsmaschine zufallsbedingt 5 % der UserInnen-Base zugänglich zu machen.
Das Feature Flag teilt die UserInnen mit einem einfachen Modulo in zwei Gruppen auf, wenn sie einen Livestream laden. Innerhalb weniger Minuten erhält Ihr Team die Ergebnisse von einigen Tausend User Sessions mit dem neuen Code. Tatsächlich wird der Stream schneller geladen und das Engagement der UserInnen verbessert. Aber es kommt zu einem unerwarteten Spike bei der CPU-Auslastung auf dem Produktionsserver. Das Ops-Team erkennt, dass die Leistung sinkt und „killt“ das Canary-Flag.
Das Team beschließt, mit dem Rollout erst fortzufahren, wenn es bei dem neuen Code die Ursache für die unerwartete Spitze der CPU-Auslastung auf dem Server beheben kann. Dank der realen Testergebnisse des Canary Deployments hat das Team eine relativ gute Vorstellung davon, was passiert ist, und macht sich wieder an die Arbeit.
Canary Deployments sind ein wesentlicher Bestandteil Ihres DevOps-Toolkits
Die Strategien der Softwarebereitstellung haben sich in den letzten Jahrzehnten rasant weiterentwickelt. Canary Deployments zählen zu den leistungsstärksten Strategien, die nun für Teams verfügbar sind, die DevOps-Methoden wie CI/CD folgen möchten.
Canary Deployments sind effiziente Strategien, da sie aussagekräftige Daten schnell bereitstellen und liefern können und für nahezu jede App oder jedes Feature eingesetzt werden können, die getestet werden sollen. Sie bieten Ihrem Team schnelles Feedback, wodurch Entwicklungszyklen verkürzt und neuer Code schneller in Produktion gegeben werden kann. Tests des Canary Deployments bieten aussagekräftige Ergebnisse, die Ihnen helfen, dem Unternehmen Business Cases für neue Initiativen aufzustellen.
In diesem Artikel haben wir erklärt, was Canary Deployments sind, welche Vor- und Nachteile sie haben, wie sie im Vergleich zu anderen Bereitstellungsstrategien abschneiden und wie Sie bei der Planung eines Canary Deployments in Ihrem Team vorgehen können. Es gibt viele Management-Tools für Deployments, aber Feature Flags sind möglicherweise die effektivste Option, die Ihr DevOps-Team schon heute nutzen kann.
Feature Flags optimieren und vereinfachen das Testen von Canary Deployments. Features Flags verringern den Bedarf einer zweiten Produktionsumgebung. Mit einer Feature Management Software wie Flagship sind anspruchsvolle Tests und Analysen möglich. Ganz gleich, für welche Methode Sie sich entscheiden, Canary Deployments helfen Ihnen, Ihren UserInnen die beste Software schnell zur Verfügung zu stellen.
