Zero Downtime Deployments – Blue Green und Canary in der Praxis

Du willst Updates ausrollen, ohne dass Nutzer Ausfälle spüren. Genau darum geht es bei Zero Downtime Deployments. Das Ziel ist einfach: neue Version live nehmen, alte Version sicher bereithalten und bei Problemen sofort zurückspringen.

Zwei Strategien haben sich dafür bewährt. Mit Blue Green betreibst du zwei vollständige Umgebungen parallel und wechselst den Traffic in einem Schritt. Mit Canary führst du die neue Version schrittweise ein, beobachtest Metriken und erhöhst den Anteil nach und nach. Beides lässt sich mit einfachen Mitteln umsetzen, wenn du ein paar Grundlagen beachtest.

Was Zero Downtime wirklich bedeutet

Zero Downtime heißt nicht nur, dass der Webserver antwortet. Es bedeutet, dass Funktionen, Sessions und Daten während des Deployments konsistent bleiben. Dafür brauchst du kompatible Schnittstellen, sauberes Routing und eine klare Rollback-Option. Wichtig ist auch, dass du technische Metriken wie Fehlerquote und Latenz und Geschäftsmetriken wie Conversion im Blick hast.

Blue Green – umschalten ohne Risiko

Idee in einem Satz

Du betreibst zwei identische Stacks: Blue (aktiv) und Green (inaktiv). Du deployst die neue Version auf Green, prüfst sie und leitest dann den gesamten Traffic von Blue auf Green um. Blue bleibt als sofortiges Rollback stehen.

So gehst du vor

Baue auf Green die neue Version. Führe Smoke-Tests aus und prüfe Health-Checks. Stelle sicher, dass Datenbank-Migrationen rückwärts kompatibel sind. Schalte den Traffic am Load Balancer oder Ingress von Blue auf Green. Beobachte Fehlerquote, Latenz und Logins. Wenn alles stabil ist, nutze Green weiter und bereite Blue als nächstes Ziel vor.

Wofür es sich eignet

Blue Green passt, wenn du schnell zurückrollen willst und genug Kapazität für zwei parallele Umgebungen hast. Es ist ideal bei state­losen Webdiensten oder wenn du Datenbank-Änderungen im Expand-Contract Muster planst.

Canary – sicher einführen in kleinen Schritten

Idee in einem Satz

Du gibst der neuen Version zuerst wenig Traffic und erhöhst schrittweise. Fällt etwas auf, drehst du sofort zurück.

So gehst du vor

Starte mit 1-5 Prozent Traffic für die neue Version. Überwache HTTP 5xx, P95 Latenz und User-Flows wie Login oder Checkout. Erhöhe auf 10-25-50 Prozent, wenn die Metriken stabil sind. Halte pro Stufe Beobachtungsfenster ein. Wenn eine Metrik kippt, setze den Traffic sofort auf 0 und analysiere.

Wofür es sich eignet

Canary ist perfekt, wenn Risiken schwer abschätzbar sind oder wenn du viele Nutzerpfade hast. Es reduziert die Auswirkung von Fehlern und gibt dir klare Daten für die Entscheidung.

Voraussetzungen für beide Strategien

Sessions und Zustände

Halte Services möglichst state­los. Lege Sessions in einen externen Store wie Redis oder nutze Token-basierte Authentifizierung. So kannst du Instanzen nahtlos austauschen.

Datenbank-Änderungen

Nutze das Expand-Contract Muster. Füge neue Spalten zuerst hinzu, schreibe alt und neu parallel, räume später auf. Vermeide breaking changes während des Rollouts. So bleiben alte und neue Version kompatibel.

Feature-Flags

Aktiviere neue Funktionen per Feature-Flag. So kannst du selektiv einschalten, bei Bedarf deaktivieren und im Notfall ohne Redeploy reagieren.

Monitoring und Metriken

Definiere vorab Schwellenwerte für Fehlerquote, Latenz und SLA. Ohne klare Metriken ist jede Freigabe ein Bauchgefühl. Nutze Health-Checks auf Readiness und Liveness, damit nur gesunde Instanzen Traffic bekommen.

Routing-Optionen in der Praxis

DNS und Load Balancer

Für Blue Green reicht häufig ein Load Balancer-Switch oder eine neue Zielgruppe. DNS ist möglich, aber TTL kann Rollbacks verzögern. Ein Application Load Balancer oder NGINX Ingress reagiert sofort.

Service Mesh

Mit einem Service Mesh wie Istio oder Linkerd regelst du Traffic-Splits in Prozent und kannst feingranular Canary fahren. Du bekommst Retries, Circuit Breaking und Observability gleich dazu.

Kubernetes kurz und klar

In Kubernetes kannst du RollingUpdate nutzen oder mit zwei Deployments Blue und Green betreiben. Für Canary helfen Ingress-Anmerkungen, Service Mesh oder Argo Rollouts für prozentuale Verteilung.

Mini-Beispiele zum Anfassen

Blue Green mit NGINX Ingress – Umschalten per Service

Du betreibst zwei Deployments app-blue und app-green. Der Service app zeigt entweder auf blue oder green. Umschalten heißt: Selector ändern und Health beobachten.

apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  selector:
    version: green   # auf blue oder green umschalten
  ports:
    - port: 80
      targetPort: 8080

Canary mit zwei Backends – 10 Prozent Traffic neu

Mit einem Ingress Controller oder Mesh kannst du Gewichte setzen. Beispielhaft als Idee:

# sinngemäß: 90 Prozent alt, 10 Prozent neu
backendWeights:
  - service: app-v1
    weight: 90
  - service: app-v2
    weight: 10

Erhöhe die Gewichte nur, wenn Metriken im grünen Bereich bleiben.

Rollback ohne Drama

Entscheidungsregeln

Lege fest, wann ein Rollback Pflicht ist. Beispiele sind Fehlerquote über Schwellwert, stark steigende Latenz oder kritische Geschäftsaktionen schlagen fehl. Entscheide automatisierbar, nicht ad hoc.

Durchführung

Bei Blue Green leitest du den Traffic zurück auf die vorherige Farbe. Bei Canary setzt du den Traffic-Split auf 100 Prozent alt. Dokumentiere Zeitpunkt, Version und Ursache und sichere Logs zur Analyse.

Typische Stolpersteine vermeiden

Sticky Sessions

Wenn der Load Balancer Sticky Sessions nutzt, landet ein Teil der Nutzer weiterhin auf der alten Version. Deaktiviere Stickiness oder lagere Session-Zustand aus.

Caches und Assets

Versioniere statische Assets wie CSS und JS. Sonst lädt der Browser alte Dateien gegen neuen Code. Ein Asset-Hash löst das Problem.

Schatten-Tests vergessen

Nutze Shadow Traffic oder Testpfade, um die neue Version mit echten Anfragen ohne Nutzerwirkung zu speisen. So entdeckst du Schwachstellen, bevor du umschaltest.

Dein Startplan in kurz

Beginne mit einer kleinen App, trenne Zustand aus, füge Health-Checks hinzu und definiere Metrik-Schwellen. Baue Blue Green mit zwei Deployments und einem klaren Switch. Wenn das sitzt, ergänze Canary mit prozentualem Routing und automatisierten Stufen. Mit Feature-Flags und Expand-Contract bist du auch bei Datenbank-Änderungen auf der sicheren Seite.

Fazit

Zero Downtime Deployments sind erreichbar, wenn du Zustand trennst, kompatible Datenbank-Änderungen planst und sauberes Routing nutzt. Blue Green liefert den schnellen Switch und ein sofortiges Rollback. Canary gibt dir Kontrolle in Stufen und klare Daten für Entscheidungen. Mit Monitoring, Feature-Flags und klaren Regeln für Rollbacks bringst du Releases ruhig, vorhersehbar und ohne Ausfälle live.