Erklär Blue-Green-Deployment gegenüber Canary Releases und wann du was nimmst.

Blue-Green fährt zwei komplette Umgebungen und schaltet den gesamten Traffic auf einen Schlag um. Rollback ist sofort, aber du zahlst doppelte Kapazität und alle Nutzer sehen die Änderung gleichzeitig. Ein Canary schickt einen kleinen Traffic-Anteil auf die neue Version, vergleicht deren Metriken mit der alten und rampt schrittweise hoch. Das begrenzt den Blast Radius, braucht aber Traffic Shaping und gute Telemetrie. Nimm Canary für Services mit hohem Traffic und Blue-Green für seltene, eng gekoppelte Releases.

Blue-Green heißt zwei vollständige Umgebungen. Green ist live, Blue bekommt die neue Version, du fährst deine Checks gegen Blue, dann kippst du den Router und alle wechseln auf einmal. Der Vorteil ist, dass Rollback nur ein Zurückkippen ist, also Sekunden. Die Nachteile sind, dass du zwei Produktionsumgebungen bezahlst und dass bei einem Fehler hundert Prozent der Nutzer ihn im selben Moment abbekommen. Ein Canary schickt vielleicht ein oder fünf Prozent des Traffics auf die neue Version, und du vergleichst Error Rate, Latenz und Business-Metriken mit der Kontrolle, bevor du auf fünfundzwanzig, fünfzig und dann alles hochrampst. Der Blast Radius ist winzig und die Rampe läuft automatisch weiter, solange der Vergleich sauber bleibt. Ein Canary braucht echte Telemetrie und eine Möglichkeit, Traffic aufzuteilen, also ein Service Mesh oder einen Load Balancer mit Gewichtung. In der Praxis ist Canary mein Default für alles Nutzersichtbare mit stetigem Traffic, und Blue-Green nehme ich, wo der Traffic für einen statistisch sinnvollen Canary zu gering ist. Keines von beiden rettet dich vor einer destruktiven Migration, das ist eine eigene Disziplin.