Zero-Downtime Deployment Strategien für Cloud-Anwendungen
Zurück zum Blog
von Stefan Sørensen

Zero-Downtime Deployment Strategien für Cloud-Anwendungen

Blue-Green, Canary oder Rolling Updates? Die richtige Deployment-Strategie für Ihre Cloud-Anwendung.

CloudDevOpsCI/CD

Überblick

Moderne Cloud-Anwendungen müssen rund um die Uhr verfügbar sein – Wartungsfenster mit Ausfallzeiten gehören der Vergangenheit an. Kontinuierliche Deployments sind heute Standard, aber sie bringen eine entscheidende Herausforderung mit sich: Wie aktualisiert man eine laufende Anwendung, ohne dass Nutzer auch nur eine Sekunde Downtime spüren?

In diesem Artikel vergleiche ich die drei wichtigsten Zero-Downtime Deployment Strategien – Blue-Green Deployments, Canary Releases und Rolling Updates – und zeige, wann welche Strategie die richtige Wahl ist.

1. Blue-Green Deployment

Grundprinzip

Beim Blue-Green Deployment betreibt man zwei identische Produktionsumgebungen parallel: die aktive „Blue"-Umgebung und die neue „Green"-Umgebung. Das Update wird vollständig in der Green-Umgebung ausgerollt und getestet, bevor ein Load Balancer oder DNS-Switch den gesamten Traffic auf einen Schlag umschwenkt.

[Traffic] ──► [Load Balancer]
                    │
          ┌─────────┴─────────┐
          │                   │
     [Blue - v1.0]       [Green - v2.0]
     (aktiv)             (bereit)
          │
     SWITCH ──────────────────►

Ablauf

  1. Green-Umgebung mit neuer Version deployen und vollständig testen
  2. Smoke Tests und Integration Tests in Green ausführen
  3. Load Balancer auf Green umschwenken (zero downtime)
  4. Blue-Umgebung als Fallback für schnelles Rollback bereithalten
  5. Nach Bestätigung: Blue-Umgebung abbauen oder für nächste Version nutzen

Vorteile

  • Sofortiges Rollback: Bei Problemen einfach zurück auf Blue schalten – in Sekunden
  • Vollständiges Testing vor Go-Live: Die neue Version wird in produktionsgleicher Umgebung validiert
  • Kein partieller Zustand: Zu jedem Zeitpunkt läuft genau eine Version in Production
  • Kalte Backups: Blue bleibt als Warm-Standby verfügbar

Nachteile

  • Doppelte Infrastrukturkosten: Beide Umgebungen müssen gleich groß dimensioniert sein
  • Datenbankmigrationen heikel: Schema-Änderungen müssen rückwärtskompatibel sein oder separat behandelt werden
  • Zustandsmanagement: Session-Daten und Caches müssen zwischen beiden Umgebungen synchronisiert werden

Wann einsetzen?

Blue-Green Deployments eignen sich besonders für kritische, monolithische Anwendungen mit klar definierten Release-Zyklen, bei denen ein sauberer Cut-Over wichtiger ist als Ressourceneffizienz. In Azure bieten sich Azure Traffic Manager oder Azure Front Door für den Traffic-Switch an.

2. Canary Releases

Grundprinzip

Der Begriff stammt aus dem Bergbau: Kanarienvögel wurden früher zur Früherkennung von Gaslecks eingesetzt. Beim Canary Release wird die neue Version zunächst nur einem kleinen Prozentsatz der echten Nutzer ausgeliefert – typischerweise 1–5%. Zeigt sich kein Problem, wird der Traffic schrittweise erhöht, bis 100% auf der neuen Version laufen.

[Traffic 100%]
       │
  [Router/Ingress]
       │
  ┌────┴──────────────┐
  │                   │
[v1.0 - 95%]    [v2.0 - 5%]  ← Canary
  │                   │
  └─── schrittweise weiter ──►
       [v2.0 - 100%]

Ablauf

  1. Canary-Version deployen (parallel zur stabilen Version)
  2. Anfangs 1–5% des Traffics auf Canary routen
  3. Metriken beobachten: Error Rate, Latency, Business KPIs
  4. Traffic-Prozentsatz schrittweise erhöhen (5% → 25% → 50% → 100%)
  5. Bei Anomalien: sofortiger Rollback auf 0% Canary-Traffic

Kubernetes-Implementierung mit Argo Rollouts

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: {duration: 10m}
        - setWeight: 25
        - pause: {duration: 20m}
        - setWeight: 50
        - pause: {duration: 30m}
        - setWeight: 100
      canaryMetadata:
        labels:
          deployment: canary
      stableMetadata:
        labels:
          deployment: stable

Vorteile

  • Echtes User-Feedback: Probleme werden mit realem Traffic entdeckt, nicht nur in Testumgebungen
  • Geringes Risiko: Im Worst Case sind nur wenige Prozent der Nutzer betroffen
  • Automatisierbar: Metriken-basiertes Auto-Promotion oder Auto-Rollback möglich
  • A/B-Testing-kompatibel: Canary Releases lassen sich mit Feature Flags kombinieren

Nachteile

  • Komplexere Infrastruktur: Intelligentes Traffic-Routing (z. B. via Istio, NGINX Ingress, Azure API Management) notwendig
  • Gleichzeitig mehrere Versionen: Datenbank und APIs müssen beide Versionen unterstützen
  • Längere Deployment-Dauer: Ein vollständiges Rollout kann Stunden dauern
  • Observability notwendig: Ohne gute Metriken und Alerting verliert man die Kontrolle

Wann einsetzen?

Canary Releases sind ideal für Microservices und APIs mit hohem Traffic-Volumen, wo echte Nutzerdaten für die Validierung entscheidend sind. Sie sind die bevorzugte Strategie bei Teams, die Continuous Deployment mit hoher Deploymentfrequenz betreiben.

3. Rolling Updates

Grundprinzip

Rolling Updates sind die native Deployment-Strategie in Kubernetes. Dabei werden Pods der alten Version schrittweise durch Pods der neuen Version ersetzt – immer eine festgelegte Anzahl gleichzeitig. Zu keinem Zeitpunkt laufen alle Instanzen auf der neuen Version, aber der Service bleibt durchgehend verfügbar.

Vorher:  [v1] [v1] [v1] [v1] [v1]
Schritt 1: [v2] [v1] [v1] [v1] [v1]
Schritt 2: [v2] [v2] [v1] [v1] [v1]
Schritt 3: [v2] [v2] [v2] [v1] [v1]
Schritt 4: [v2] [v2] [v2] [v2] [v1]
Nachher:  [v2] [v2] [v2] [v2] [v2]

Kubernetes-Konfiguration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # Max. 1 Pod gleichzeitig unavailable
      maxSurge: 1          # Max. 1 zusätzlicher Pod während Update
  template:
    spec:
      containers:
        - name: my-app
          image: my-app:v2.0
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5

Wichtig: readinessProbe ist bei Rolling Updates kritisch! Kubernetes leitet erst dann Traffic auf den neuen Pod, wenn die Probe erfolgreich ist.

Vorteile

  • Ressourceneffizient: Kein Bedarf an doppelter Infrastruktur
  • Nativ in Kubernetes: Out-of-the-box ohne zusätzliche Tools
  • Automatisches Rollback: kubectl rollout undo deployment/my-app genügt
  • Fein konfigurierbar: maxUnavailable und maxSurge steuern Geschwindigkeit und Risiko

Nachteile

  • Zwei Versionen gleichzeitig aktiv: Während des Updates laufen v1 und v2 parallel – APIs und Datenbanken müssen das abkönnen
  • Kein sofortiger Cutover: Kein sauberer Zeitpunkt, ab dem garantiert alle Nutzer die neue Version sehen
  • Langsameres Rollback: Rollback bedeutet erneutes Rolling Update in die andere Richtung
  • Kompatibilitätsanforderungen: Besonders kritisch bei Datenbankschema-Änderungen

Wann einsetzen?

Rolling Updates sind die Go-to-Strategie für die meisten Kubernetes-Workloads – vor allem bei zustandslosen Anwendungen (Stateless Services) mit mehreren Replicas. Sie funktionieren gut in Kombination mit Azure Kubernetes Service (AKS) und einem CI/CD-System wie Azure DevOps oder GitHub Actions.

Strategievergleich auf einen Blick

Kriterium Blue-Green Canary Release Rolling Update
Komplexität Mittel Hoch Niedrig
Infrastrukturkosten Hoch (2x) Mittel Niedrig
Rollback-Geschwindigkeit Sofort (Sekunden) Schnell (Traffic-Shift) Mittel (neues Update)
Risiko bei Fehlern Niedrig Sehr niedrig Mittel
Datenbankkompatibilität Kritisch Kritisch Kritisch
Kubernetes-nativ Nein Nein (via Argo/Istio) Ja
Ideal für Monolithen, kritische Systeme Microservices, hohes Traffic-Volumen Stateless Kubernetes-Workloads

Datenbankmigrationen – der blinde Fleck

Alle drei Strategien teilen ein gemeinsames Problem: Datenbankschema-Änderungen. Während einer Zero-Downtime-Deployment laufen immer mindestens kurzzeitig zwei Versionen der Anwendung gleichzeitig – beide müssen mit demselben Datenbankschema funktionieren.

Die bewährte Lösung ist das Expand-Contract-Pattern (auch bekannt als „Parallel Change"):

  1. Expand: Neues Schemafeld hinzufügen (abwärtskompatibel), alte Felder behalten
  2. Migrate: Beide App-Versionen deployen, Datenmigration im Hintergrund
  3. Contract: Alte Felder entfernen, nachdem alle Instanzen auf neue Version migriert sind

Tools wie Flyway oder Liquibase helfen dabei, Migrationen versioniert und nachvollziehbar zu halten.

Empfehlung für die Praxis

Es gibt keine universell „beste" Strategie – die Wahl hängt von Anwendungstyp, Teamgröße und Risikobereitschaft ab:

  • Einstieg und einfache Kubernetes-Workloads → Rolling Updates mit konfigurierten Readiness Probes
  • Kritische Anwendungen mit Compliance-Anforderungen → Blue-Green für saubere, auditierbare Cut-Overs
  • Hohes Deploymentvolumen und Datengetriebene Validierung → Canary Releases mit Argo Rollouts und Prometheus-basiertem Auto-Promotion

In der Praxis kombinieren reife Teams oft alle drei Strategien: Rolling Updates für den Alltag, Canary für Feature-Launches und Blue-Green für Major Releases oder kritische Sicherheitspatches.

Stefan Sørensen
Stefan Sørensen
Cloud Enterprise Architect
← Alle Artikel