Jede Softwareauslieferung ist ein Risikomoment. Das Update, das gestern im Staging einwandfrei lief, kann in Produktion kritische Fehler auslösen – unter Last, mit echten Nutzerdaten oder in Kombination mit anderen Diensten, die im Staging nicht vorhanden waren. SRE-Teams wissen das. Deshalb ist die Wahl der richtigen Deployment-Strategie keine rein technische Entscheidung, sondern ein Risikomanagementtool.
Dieser Artikel erklärt die drei wichtigsten Strategien – Rolling Update, Blue-Green und Canary Release – und zeigt, wann welche Methode sinnvoll ist.
Das Rolling Update: Schrittweiser Ersatz ohne Parallelbetrieb
Das Rolling Update ist die Standardstrategie vieler Orchestrierungsplattformen, darunter Kubernetes. Das Prinzip ist denkbar einfach: Instanzen der alten Version werden nacheinander durch Instanzen der neuen Version ersetzt. Während des Deployments laufen kurzzeitig beide Versionen gleichzeitig.
Das Rolling Update hat klare Stärken:
- Kein zusätzlicher Infrastrukturaufwand: Es sind keine doppelten Umgebungen notwendig. Das Deployment läuft auf der vorhandenen Infrastruktur.
- Kein vollständiger Neustart: Der Dienst bleibt während des gesamten Deployments verfügbar, sofern genug gesunde Instanzen vorhanden sind.
- Einfach rückgängig zu machen: Ein Rollback besteht darin, die neue Version in derselben Reihenfolge wieder durch die alte zu ersetzen.
Die Schwäche des Rolling Updates liegt in der Parallelität: Für einen kurzen Zeitraum laufen alte und neue Versionen gleichzeitig. Wenn die neue Version eine inkompatible API oder ein verändertes Datenbankschema mitbringt, kann das zu inkonsistentem Verhalten führen. Rolling Updates setzen daher voraus, dass Versionen miteinander kompatibel sind.
Blue-Green Deployment: Harte Umschaltung mit voller Kontrolle
Beim Blue-Green Deployment existieren zwei identische Produktionsumgebungen: die aktive (Blue) und die neue (Green). Die neue Version wird vollständig in der Green-Umgebung deployed und getestet, bevor der Load Balancer den Traffic schlagartig von Blue auf Green umschaltet.
Blue-Green ist keine Deployment-Methode für knappe Budgets. Sie verdoppelt den Infrastrukturbedarf – zumindest für die Dauer des Deployments. Aber genau das ist ihr größter Vorteil: Ein vollständiges Rollback ist in Sekunden möglich, indem der Load Balancer einfach zurückschaltet.
Praktische Stärken des Blue-Green Ansatzes:
- Zero-Downtime-Deployments: Der Traffic-Wechsel passiert ohne merkliche Unterbrechung für die Nutzer.
- Vollständige Vortests: Die Green-Umgebung kann unter produktionsnahen Bedingungen getestet werden, bevor irgendein echter Nutzer sie sieht.
- Sofortiger Rollback: Treten Probleme auf, reicht ein einziger Load-Balancer-Switch, um zur alten Version zurückzukehren.
Die Hauptnachteile: Der doppelte Infrastrukturaufwand verursacht Kosten. Außerdem ist Blue-Green bei Datenbankmigrationen komplex – wenn beide Umgebungen dieselbe Datenbank nutzen, muss das Schema mit beiden Versionen kompatibel sein.
Canary Release: Kontrollierte schrittweise Auslieferung
Der Canary Release – benannt nach der historischen Praxis, Kanarienvögel in Bergwerke mitzunehmen, um Gase frühzeitig zu erkennen – ist die subtilste der drei Strategien. Statt den gesamten Traffic auf einmal umzuleiten, erhält zunächst nur ein kleiner Prozentsatz der Nutzer die neue Version. Typischerweise 1 %, dann 5 %, dann 10 %, bis schließlich alle Nutzer auf der neuen Version sind.
Was diese Strategie besonders wertvoll macht: Sie erlaubt es, die neue Version unter realem Produktionstraffic zu beobachten, bevor sie zum Standard wird. Fehler werden sichtbar, solange sie nur einen Bruchteil der Nutzer betreffen.
Canary Releases sind besonders sinnvoll bei:
- Funktionen mit unbekanntem Nutzungsverhalten: Wenn unklar ist, wie Nutzer auf eine neue Funktion reagieren oder welche Last sie erzeugt.
- Kritischen Services: Bei Diensten, bei denen auch eine kurze Beeinträchtigung erhebliche Auswirkungen hätte.
- A/B-Testing: Canary-Traffic kann gezielt auf bestimmte Nutzergruppen gelenkt werden, um Feature-Varianten zu vergleichen.
Der Nachteil: Canary Releases erfordern gutes Monitoring und eine Infrastruktur, die Traffic-Splits zuverlässig umsetzen kann. Ohne ausreichende Observability kann man nicht erkennen, ob der 5 %-Canary tatsächlich stabiler ist als die Baseline.
Feature Flags als ergänzendes Werkzeug
Feature Flags sind keine Deployment-Strategie im technischen Sinne, ergänzen aber alle drei Ansätze sinnvoll. Sie trennen das Deployment einer Funktion von deren Aktivierung. Code kann deployed werden, ohne dass neue Funktionen für Nutzer sichtbar werden – die Aktivierung erfolgt per Konfiguration, jederzeit und ohne neues Deployment.
In Kombination mit Canary Releases erlauben Feature Flags eine granulare Steuerung: Neue Funktionen werden zunächst nur für ausgewählte Nutzergruppen oder interne Tester freigegeben, dann schrittweise ausgerollt.
Die SRE-Perspektive: Deployment-Strategien und Error Budgets
Aus SRE-Sicht sind Deployments eine der häufigsten Ursachen für Störungen. Viele Teams messen deshalb direkt, wie viele Incidents auf Deployments zurückzuführen sind – und nutzen das als Signal für die Reife ihrer Deployment-Prozesse.
Error Budgets geben SRE-Teams einen objektiven Rahmen: Wenn das Error Budget noch reichlich vorhanden ist, können aggressivere Rolling Updates oder häufige Deployments akzeptiert werden. Ist das Budget knapp, empfiehlt sich der vorsichtigere Canary-Ansatz mit langen Beobachtungsphasen.
Eine gut definierte Deployment-Strategie sollte immer auch die Frage beantworten: Wie lange dauert ein Rollback? Zwei Minuten oder zwei Stunden machen im Störungsfall den Unterschied zwischen einem kontrollierten Incident und einem ausgewachsenen Outage.
Welche Strategie für welchen Kontext?
Es gibt keine universell richtige Antwort, aber klare Leitlinien:
- Rolling Update eignet sich für Services mit rückwärtskompatiblen Änderungen, wo Infrastrukturkosten eine Rolle spielen und kurze Parallelität toleriert wird.
- Blue-Green ist die richtige Wahl, wenn vollständige Rollback-Fähigkeit in Sekunden gefordert ist – etwa bei kritischen Geschäftsanwendungen oder regulierten Systemen.
- Canary Release empfiehlt sich immer dann, wenn das Verhalten der neuen Version unter Reallast unbekannt ist und Schäden durch frühzeitige Fehlererkennung begrenzt werden sollen.
Viele Teams kombinieren alle drei: Rolling Updates als Standard, Blue-Green für größere Releases, Canary für neue kritische Funktionen. Was zählt, ist nicht die Eleganz der Strategie, sondern die Verlässlichkeit des Ergebnisses.
Bildquelle: Pexels, Foto von Luis Gomes (pexels.com/photo/2004161) – Lizenz: Pexels License (kostenlos nutzbar)
Quellen:
Martin Fowler: BlueGreenDeployment – martinfowler.com
Google SRE Book: Release Engineering – sre.google/sre-book/release-engineering
Kubernetes Dokumentation: Deployments – kubernetes.io/docs/concepts/workloads/controllers/deployment
