Dynamische Cloud-Umgebungen und agile DevOps-Praktiken erfordern neue Deployment-Strategien. Einen Überblick über die gängigsten Methoden und welche Auswirkungen sie auf die Software-Entwicklung haben, betrachtet dieser Gastbeitrag.
Tracking aller Requests und prozentuale Veränderungen von Service Errors im Canary Deployment.
(Bild: Datadog)
In den Pre-Cloud-Zeiten monolithischer Umgebungen und der Wasserfall-Softwareentwicklung waren Code-Implementierungen isolierte, überschaubare Ereignisse. Code wurde in einem bestimmten Teil der Infrastruktur bereitgestellt und das Betriebsteam überwachte die Auswirkungen des Codes, sobald er in Produktion war.
In vielerlei Hinsicht war dieses Vorgehen einschränkend, aber es bedeutete, dass die Auswirkungen leicht zu verstehen waren – die Operations-Teams wussten, wo sie nachschauen mussten und was zu tun war, wenn ein neues Code-Deployment fehlschlug. Anstelle eines Monolithen können die Teams aber heutzutage auch einzelne, gut identifizierte Microservice einsetzen.
Ein solcher Microservice bedient möglicherweise Dutzende von Upstream-Diensten, die über eine automatisch skalierte Flotte von zehn oder Hunderten von Containern oder Hosts bereitgestellt werden. Dies ermöglicht zwar eine bessere Kontrolle über Funktionalität, Leistung und Betriebskosten, aber der Grad der Vernetzung und Komplexität erhöht das Gesamtrisiko, einen Fehler zu machen.
Diese Dynamik hat zu einer Welle moderner Deployment-Strategien geführt – und angesichts des Innovationstempos sind diese Strategien in den meisten modernen softwaregestützten Unternehmen von „nice-to-have“ zu „need-to-have“ geworden. Wie können also technische Teams diese neue Welt mit Zuversicht betreten und die Vorteile nutzen, gleichzeitig aber die Risiken unter Kontrolle halten?
Schnell und skalierbar
Zwischen diesen neuen Deployment-Strategien gibt es zwar wesentliche Unterschiede; aber sie alle spiegeln den verteilten, dynamischen und kollaborativen Charakter der Software-Entwicklung in der Cloud wider, der eine kontinuierliche Verbesserung der Anwendungen im Laufe der Zeit ermöglicht.
Die gängigsten modernen Deployment-Strategien sind:
Gradual Deployment: Hier wird der Code schrittweise, in teilweise Kleinstschritten in die Infrastruktur gespielt – zum Beispiel anfangs nur wenige Container – um sicherzustellen, dass nichts schief geht, bevor eine breitere Verteilung erfolgt.
Canary Deployment: In diesem Fall wird der Code auf bestimmte Instanzen verteilt. Diese funktionieren wie der Kanarienvogel (Canary) im Bergwerk. Das Team kann so überprüfen, was passieren könnte, wenn der Code auf eine größere Anzahl ähnlicher Instanzen verteilt wird.
Blue/Green Deployment: Hierbei wird der alte Code im Hintergrund ausgeführt, während gleichzeitig der neue Code verteilt wird. Der alte Code dient als Backup, falls etwas schief geht.
A/B-Deployment: Bei diesem Vorgehen werden zwei neue Verteilungen gleichzeitig ausgeführt, so dass sie hinsichtlich ihrer jeweiligen Performance verglichen werden können.
Tracking aller Requests und prozentuale Veränderungen von Service Errors im Canary Deployment.
(Bild: Datadog)
Jede dieser Strategien ermöglicht eine schnellere Entwicklung neuer Anwendungen und Funktionen, da sie die Möglichkeit bieten, neue Deployments zu analysieren und gegebenenfalls zurückzunehmen und zu überarbeiten. Wenn Teams ihren Code schnell auf einer bestimmten Infrastruktur ausliefern können, können sie die Auswirkungen unsichtbarer Probleme auf ein Minimum reduzieren, diese Probleme identifizieren und beheben und dann schnell erneut deployen, um ihren Code weiter zu verfeinern.
Das klingt in der Praxis einfach, birgt in der Realität aber Herausforderungen. Tatsächlich können mehrere Teams oder sogar einzelne Mitarbeiter entscheiden, verschiedene Services parallel zu implementieren. Das macht es schwierig, den Überblick zu behalten. Schauen wir uns also ein konkretes Beispiel an, um zu sehen, wie dies in der Praxis funktioniert.
Blue/Green-Deployment in Aktion
Stellen wir uns ein Blue/Green-Deployment eines kritischen Updates für eine Anwendung vor. Der neue Code wird in getrennten Containern bereitgestellt, während der vorhandene Code ununterbrochen läuft. Dann wird der Traffic auf den neuen Code umgeschaltet.
Die zuständigen DevOps- oder SRE-Teams (Site Reliability Engineering) beobachten was passiert, testen die Performance des Codes unter realen Bedingungen und greifen bei Bedarf auf den vorhandenen alten Code als Backup zurück. Wenn der neue Code vollständig validiert (auf Performance, Fehler und Funktionalität geprüft) ist, kann der alte Code entfernt oder für einen zukünftigen Einsatz liegengelassen werden.
Deployment Tracking im Blue/Green-Deployment.
(Bild: Datadog)
Bei einer traditionellen Deployment-Strategie müssen die Teams nur Daten aus einem einzelnen Einsatz über einen begrenzten Zeitraum konsultieren. Bei der oben beschriebenen Blue/Green-Strategie ist die Überwachung jedoch komplexer. Um mit dieser Komplexität umgehen zu können, benötigen die Teams ein robustes Monitoring, so dass alle relevanten Daten – über alle Deployments hinweg, solange sie laufen – sowohl für Echtzeit- als auch für Post-Mortem-Untersuchungen gesammelt und organisiert werden.
Es beginnt mit den Daten
Die meisten Teams verfügen bereits über Monitoring-Lösungen und -Prozesse, um Daten zu sammeln, zu organisieren und zu visualisieren. Um die Sichtbarkeit moderner Deployment-Strategien zu verbessern, müssen die einzelnen Deployments mit Tags versehen werden, die Vergleiche zwischen ihnen ermöglichen.
Kein Deployment darf ohne Monitoring bleiben, um Troubleshooting inmitten mehrerer Deployments und unterschiedlicher Code-Versionen anzustoßen. Die gesammelten Daten sollten außerdem maximal granular sein. Vergleichsdaten aus der Vergangenheit müssen zudem unverändert und insbesondere nicht aggregiert vorliegen.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
Um den Kern eines Problems zu identifizieren, muss die Tiefe die Breite ergänzen. Metriken, Logs und Traces sollten von einzelnen Endpunkten und Anfragen gesammelt werden, so dass auf bestimmte Probleme gezoomt werden kann und diese im Zusammenhang mit der gesamten Umgebung und den unterschiedlichen Deployments betrachten können.
Sobald Daten auf granularer Ebene gesammelt werden und das Monitoring für jedes Deployment implementiert ist, ist eine detaillierte Fehlersuche und -behebung möglich, unabhängig von der Summe der Deployments.
Überwachung moderner Deployment-Strategien in der Praxis
Neue Fehler während eines Blue/Green-Deployments.
(Bild: Datadog)
Reichhaltige Daten in der Breite für alle Deployments zu haben, ist aber erst der Anfang. Die Art und Weise, wie diese Daten zur Fehlerbehebung genutzt werden, ist auch für die Verwaltung moderner Deployment-Strategien wichtig.
Zunächst muss eine Reihe von „goldenen Signalen“ identifiziert werden – gesammelte Daten, die den stärksten Hinweis auf die Performance eines Deployments liefern. Requests, Latenzzeiten und Fehlerraten sind hierbei am gängigsten, während Infrastrukturmetriken und Performance-Anforderungen auf Code-Ebene aus Anwendungs-Traces ebenfalls wichtig sind.
Als Nächstes muss die Monitoring-Praxis darauf ausgerichtet werden, mehrere gleichzeitig laufende Deployment-Versionen zu beobachten. Dieser Monitoring-Ansatz sollte sich nicht auf bestimmte zeitliche Ereignisse konzentrieren, sondern vielmehr auf die laufende Beobachtung der unterschiedlichen Deployments.
Bei der Fehlerbehebung von Problemen, die sich aus neuen oder parallelen laufenden Deployments ergeben, sollte schnell zwischen Informationen aus verschiedenen Quellen gewechselt werden können, um Unterschiede zwischen allen Microservice-Diensten erkennen zu können. Auf diese Weise können Protokolle, Traces und Codeprofile zur Behebung eines Problems im laufenden Betrieb verglichen und gegenübergestellt werden.
Und schließlich benötigen Unternehmen ein robustes Set von vordefinierten Warnmeldungen und Dashboards, damit Teams über die wichtigsten Probleme benachrichtigt werden und in Echtzeit visualisieren können, was geschieht.
Neue Zuversicht
Code-Implementierungen sind nicht länger diskrete Ereignisse mit begrenzten Auswirkungen – der Prozess des Code-Deployments und der Überwachung seiner Auswirkungen ist kontinuierlich. Um diese neuen Strategien mit Zuversicht anwenden zu können, benötigen Unternehmen einen gut strukturierten Monitoring-Ansatz.
Stefan Marx, DataDog
(Bild: Erika Martins (http://erikamartins.de))
Ein solcher ermöglicht schnelle Vergleiche der goldenen Signale in jeder einzelnen Service-Version und bietet reichhaltige Untersuchungsdaten, wenn etwas nicht in Ordnung zu sein scheint. Mit der richtigen Grundlagenarbeit werden die Vorteile des modernen Code-Deployments allmählich zum Tragen kommen – Funktionen werden schneller ausgeliefert, Fehler werden vermieden und die Kunden bleiben zufrieden.
* Stefan Marx ist Director Product Management für die EMEA-Region beim Cloud-Monitoring-Anbieter Datadog. Marx ist seit über 20 Jahren in der IT-Entwicklung und -Beratung tätig. In den vergangenen Jahren arbeitete er mit verschiedenen Architekturen und Techniken wie Java Enterprise Systemen und spezialisierten Webanwendungen. Seine Tätigkeitsschwerpunkte liegen in der Planung, dem Aufbau und dem Betrieb der Anwendungen mit Blick auf die Anforderungen und Problemstellungen hinter den konkreten IT-Projekten.