Die Bereitstellung neuer Funktionen oder Dienste für eine kleine Gruppe von Benutzern ist eine gute Entwicklungsstrategie, um Risiken zu verringern. [...]
Das Bereitstellungsparadigma von Entwicklung, Test, Produktion und Notfallwiederherstellung aus der Zeit vor der Cloud und den Microservices ist mir noch gut in Erinnerung. Damals war der Kauf, die Konfiguration und die Wartung der Infrastruktur teuer und komplex, sodass es unwahrscheinlich war, dass man das Team für den Betrieb des Rechenzentrums dazu bringen konnte, die Schaffung weiterer Umgebungen und flexibler Bereitstellungsmöglichkeiten zu genehmigen. Nach heutigen Maßstäben war die Bereitstellungshäufigkeit gering, sodass agile Entwicklungsteams Wege fanden, mit der verfügbaren Infrastruktur auszukommen.
Heute nutzen Devops-Organisationen CI/CD (Continuous Integration and Continuous Delivery), um die Bereitstellung zu automatisieren, Infrastructure as Code, um die Infrastruktur zu konfigurieren, Kubernetes, um Umgebungen zu containerisieren, Continuous Testing, um die Qualität zu verbessern, und AIops, um Überwachungs- und Beobachtungsalarme zu zentralisieren. Diese Praktiken ermöglichen es, die Bereitstellungshäufigkeit zu erhöhen und gleichzeitig die mit den Änderungen verbundenen Sicherheits-, Leistungs- und Zuverlässigkeitsrisiken zu minimieren.
Wenn Sie jedoch das Risiko senken und die Releases auf der Grundlage der Änderungen und des Zugriffs auf die Änderungen kontrollieren müssen, benötigen Sie zusätzliche Techniken zur Konfiguration und Verwaltung der Anwendung oder Bereitstellung.
Release-Pipelines erfordern flexible Kontrollen und Bereitstellungsoptionen
Eine Möglichkeit, kontrollierte Bereitstellungen zu erstellen, ist die Verwendung von Feature-Flags zum Umschalten, A/B-Testen und Segmentieren des Zugriffs auf Funktionen nach Benutzern. Devops-Teams können Feature-Flags verwenden, um überarbeitete Funktionen zu validieren, wenn sie Anwendungen in die Cloud verlagern oder monolithische Anwendungen in Microservices umwandeln.
Feature Flags sind nützlich für Entwicklungsteams und Produktmanager, die kontrollieren möchten, wer welche Funktionen in einer App oder einem Microservice sieht. Manchmal benötigen Devops– oder IT-Betriebsteams jedoch Flexibilität bei der Verwaltung von Bereitstellungen und der Kontrolle mehrerer Versionen einer in Produktion befindlichen Anwendung. Einige Beispiele:
- Validierung von Anwendungen und Microservices bei Patches oder Upgrades von kritischen Systemkomponenten wie Betriebssystemen, Datenbanken oder Middleware
- Testen von Anwendungen und Services bei der Bereitstellung in mehreren Clouds
- Überwachung der Benutzererfahrungen nach der Freigabe neuer Versionen von Modellen für maschinelles Lernen
Es gibt mehrere verschiedene Bereitstellungsstrategien für Microservices und Cloud-native Anwendungen. In den ersten Tagen der Entwicklung von Anwendungen für die Cloud verwendeten wir blau-grüne Bereitstellungen, bei denen es zwei Produktionsumgebungen gab: eine grüne Live-Umgebung und eine blaue Standby-Umgebung. Die Bereitstellung erfolgte in der blauen Umgebung, und Lastverteiler kontrollierten die Umschaltung, sodass die blaue Umgebung mit der neuesten Bereitstellung als Live-Umgebung und die neue grüne Umgebung als Backup-Umgebung fungierte.
Blue-Green-Bereitstellungen waren effektiv, da sie die Ausfallzeiten während der Bereitstellung minimierten und bei Bedarf die Möglichkeit eines Rollbacks boten. Sie waren jedoch ineffizient, da sie eine eigene Infrastruktur für die blaue Umgebung erforderten.
Was sind Canary-Bereitstellungen?
Die Weiterentwicklung von Blue-Green-Implementierungen umfasst Canary-Implementierungen oder Releases. Ich habe mit Rohan Gupta, Senior Product Manager bei Harness, darüber gesprochen, wie er Canary Releases definieren würde. Seine Antwort: „Ein Canary Release ist eine Bereitstellungsstrategie, bei der eine Anwendung oder ein Dienst schrittweise für eine Untergruppe von Benutzern freigegeben wird und der Umfang, die Auswirkungen und das Risiko der Bereitstellung neuer Software-Artefakte für die Produktion reduziert werden. Die gesamte Infrastruktur in einer Zielumgebung wird in kleinen Phasen aktualisiert (z. B. in Schritten von 2 %, 25 %, 75 %, 100 % der Traffic-Last), und aufgrund dieser Kontrolle ist ein Canary Release im Vergleich zu allen anderen Bereitstellungsstrategien der Ansatz mit dem geringsten Risiko.“
Es gibt mehrere Möglichkeiten, Canary-Bereitstellungen mit Virtualisierungs– und Cloud-Technologien zu implementieren, und Spinnaker ist ein Open-Source-Tool, das diese Option unterstützt. Der generalisierte Ansatz umfasst eine Produktionsumgebung, eine kleinere Basis-Produktionsreplik und eine Canary-Umgebung für neue Bereitstellungen. Intelligentes Routing steuert den Datenverkehr zu diesen Umgebungen dynamisch, und Regeln bestimmen, ob und wann eine neue Canary-Umgebung die Akzeptanzkriterien erfüllt.
Canary-Implementierungen sind ein Ansatz für Continuous Deployment, bei dem CI/CD-Pipelines auch Implementierungen in Produktionsumgebungen auslösen. Continuous Deployment erfordert einen soliden Softwareentwicklungsprozess, strenge Beobachtungspraktiken, zuverlässige CI/CD-Pipelines, robuste Testautomatisierungsfunktionen, umfassende AIops-Überwachung und intelligente Produktionsbereitstellungsmethoden.
Wie Devops-Teams Canary-Bereitstellungen nutzen können
John Kodumal, CTO und Mitbegründer von LaunchDarkly, erklärt, wie Devops-Teams das Feature Flagging mit Canary Deployments nutzen: „Bei einem Canary-Release werden neue Softwarefunktionen einer begrenzten Auswahl von Benutzern vor einem breiteren Release zur Verfügung gestellt. Ziel ist es, den Benutzern ein besseres Software-Erlebnis bei geringerem Gesamtrisiko zu bieten. Canary-Releases sind nützlich, um eine breit angelegte Überprüfung einer Version vorzunehmen, und sie arbeiten idealerweise mit Feature-Flags zusammen, die auf der Anwendungsebene ansetzen und einzelne Änderungen isolieren können.“
Laut Gupta besteht ein Hauptgrund für den Einsatz von Canary-Bereitstellungen darin, die Ergebnisse mehrerer Produktionsversionen zu vergleichen: „Canary-Implementierungen ermöglichen es Unternehmen, mit echten Benutzern und Anwendungsfällen in der Produktion zu testen und verschiedene Serviceversionen nebeneinander zu vergleichen. Es ist kostengünstiger als eine Blue-Green-Bereitstellung, da keine zwei Produktionsumgebungen erforderlich sind. Außerdem ist es schnell und sicher, ein Rollback auf eine frühere Version einer Anwendung auszulösen“.
Gupta räumt auch ein, dass Canary-Releases oft die Entwicklung einer Lösung und fortgeschrittenes Scripting erfordern: „Die Nachteile von Canary-Bereitstellungen sind das Testen in der Produktion und die für die Implementierung dieses Bereitstellungsmusters erforderlichen Fachkenntnisse. Die Erstellung eines Skripts für ein Canary-Release ist komplex, da die manuelle Überprüfung oder das Testen Zeit in Anspruch nimmt und die erforderliche Überwachung und Instrumentierung für das Testen in der Produktion zusätzlichen Aufwand bedeuten kann. Eine gute CD-Lösung sollte Vorlagen und Automatisierungen bieten, um all diese Herausforderungen zu lösen.“
Canary-Deployments sind vielleicht zu viel des Guten, wenn Sie Anwendungen und Microservices mit geringeren Anforderungen an Zuverlässigkeit und Skalierbarkeit entwickeln. Für Devops-Teams, die Continuous Deployment für hochvolumige, geschäftskritische Kundenerfahrungen und abhängige Microservices anstreben, können Canary-Deployments jedoch eine bahnbrechende Devops-Praxis sein.
Margaret Francis, Präsidentin und COO bei Armory, stimmt dem zu: „Die Möglichkeit, Canary-Releases auszuführen, ist besonders wichtig bei der Skalierung. Wenn Ihr Geschäft davon abhängt, dass Ihr Service verfügbar, performant und vorhersehbar ist, dann stellt die schrittweise Übergabe von Code an die Produktion sicher, dass Ihre Services performant sind und Sie zur gleichen Zeit Innovationen bereitstellen können. Mit einem Team von zwei Mitarbeitern und einem monatlichen Veröffentlichungsrhythmus ist dies nicht so wichtig. Aber Unternehmen, die von ihren digitalen Diensten abhängig sind, und Organisationen mit Hunderten von Entwicklern, die täglich oder stündlich Releases durchführen, sollten einem Canary-Release-Prozess Vorrang einräumen. Diese Unternehmen können es sich nicht leisten, die Geschwindigkeit der Innovation der Stabilität der Dienste zu opfern – oder umgekehrt.“
Setzen Sie auf Continuous Deployment, wenn Geschwindigkeit, Skalierbarkeit und Zuverlässigkeit wichtig sind
Wie bereits erwähnt, ist die kontinuierliche Bereitstellung eine hohe Hürde und setzt voraus, dass Devops-Teams über mehrere ausgereifte Test-, Automatisierungs- und Überwachungsverfahren verfügen. Für viele Unternehmen, Anwendungen und Services kann Continous Delivery ausreichend sein, und es kann zu kostspielig oder technisch komplex sein, Continuous Deployment-Funktionen zu verfolgen.
Bei der Entwicklung umfangreicher Anwendungen und Microservices und wenn das Ziel darin besteht, häufige Releases zu ermöglichen, ist der Einsatz von Canary-Releases jedoch eine wichtige Strategie zur Bereitstellung leistungsstarker, zuverlässiger Releases.
*Isaac Sacolick ist Präsident von StarCIO und Autor des Amazon-Bestsellers „Driving Digital: The Leader’s Guide to Business Transformation through Technology“, der viele Praktiken wie agile Planung, Devops und Data Science behandelt, die für erfolgreiche digitale Transformationsprogramme entscheidend sind. Sacolick ist ein anerkannter Top-Social-CIO und Influencer im Bereich der digitalen Transformation. Er hat mehr als 700 Artikel auf InfoWorld.com, CIO.com, seinem Blog Social, Agile, and Transformation und anderen Websites veröffentlicht.
Be the first to comment