4 Bereitstellungsstrategien für belastbare Microservices

Das Erstellen von Apps mit Microservices bietet Entwicklern eine höhere Geschwindigkeit und Flexibilität als herkömmliche Architekturen. Jede Codeänderung birgt jedoch weiterhin Risiken und schafft die Voraussetzungen für potenzielle Fehler, wenn Probleme mit der Codequalität nicht erkannt und behoben werden. Um diese Risiken zu minimieren, sollten Anwendungsteams moderne, Cloud-native Routing-Strategien implementieren, die das Testen auf Gefahren erleichtern und sicherstellen, dass Anwendungen wirklich für die Bereitstellung in Produktionsumgebungen bereit sind.

Die folgenden vier Bereitstellungsstrategien verwenden Routing-Techniken, um neue Dienste und Funktionen sicher einzuführen, Funktionen zu testen und iterative Verbesserungen vorzunehmen, Schwachstellen zu identifizieren und zu beseitigen und vieles mehr. Zusammen bilden diese Ansätze eine virtuelle Toolbox, auf die Anwendungsteams zugreifen können, um das Risiko bei der Entwicklung und Bereitstellung von Anwendungen mit Mikrodiensten zu verringern. Das Verständnis ihrer Unterschiede und Ähnlichkeiten ist der Schlüssel, um zu wissen, wie Sie sie in Ihrer eigenen Umgebung optimal nutzen können.

Kanarische Einsätze

Benannt nach der historischen Praxis, tatsächliche Vögel in Kohlengruben zu schicken, um festzustellen, ob die Luftqualität für den Menschen sicher ist, sind kanarische Einsätze eine Möglichkeit, tatsächliche Produktionseinsätze mit minimalen Auswirkungen oder Risiken zu testen. Der sogenannte Kanarienvogel ist eine Kandidatenversion eines Dienstes, der einen Teilprozentsatz der eingehenden Anforderungen (z. B. 1%) erfasst, um neue Funktionen oder Builds auszuprobieren. Die Teams können dann die Ergebnisse überprüfen und bei reibungslosem Ablauf die Bereitstellung schrittweise auf 100% der Server oder Knoten erhöhen. Und wenn nicht? Der Datenverkehr kann schnell von den kanarischen Bereitstellungen umgeleitet werden, während der fehlerhafte Code überprüft und debuggt wird.

Kanarische Bereitstellungen können über Integrationen mit Edge-Routing-Komponenten implementiert werden, die für die Verarbeitung des eingehenden Benutzerverkehrs verantwortlich sind. In einer Kubernetes-Umgebung kann eine kanarische Bereitstellung beispielsweise auf die Ingress-Controller-Konfiguration tippen, um den stabilen und kanarischen Bereitstellungen bestimmte Prozentsätze der Verkehrsanforderungen zuzuweisen. Durch das Weiterleiten des Datenverkehrs auf diese Weise wird sichergestellt, dass sich neue Dienste vor dem vollständigen Rollout bewähren können. Wenn dies nicht der Fall ist, werden sie zurückgeschickt, um Probleme zu beheben, und dann, wenn sie bereit sind, eine weitere Runde kanarischer Bereitstellungstests durchlaufen.

A / B-Tests

A / B-Tests ähneln kanarischen Bereitstellungen, mit einem wichtigen Unterschied. Während sich kanarische Bereitstellungen in der Regel darauf konzentrieren, Fehler und Leistungsengpässe zu identifizieren, konzentrieren sich A / B-Tests darauf, die Akzeptanz neuer Anwendungsfunktionen durch den Benutzer zu messen . Beispielsweise möchten Entwickler möglicherweise wissen, ob neue Funktionen bei Benutzern beliebt sind, ob sie leicht zu entdecken sind oder ob die Benutzeroberfläche ordnungsgemäß funktioniert.

Dieses Muster verwendet Software-Routing, um bestimmte Funktionen mit unterschiedlichen Verkehrssegmenten zu aktivieren und zu testen und neue Funktionen einem bestimmten Prozentsatz des Verkehrs oder begrenzten Gruppen auszusetzen. Die A- und B-Routing-Segmente senden möglicherweise Datenverkehr an verschiedene Builds der Software, oder die Dienstinstanzen verwenden möglicherweise sogar denselben Software-Build, jedoch mit unterschiedlichen Konfigurationsattributen (wie im Orchestrator oder anderswo angegeben).

Blaugrüne Bereitstellungen

Das blaugrüne Bereitstellungsmuster umfasst den parallelen Betrieb von zwei Produktionsumgebungen: eine für die aktuelle stabile Version (blau) und eine für die Bereitstellung und Durchführung von Tests für die nächste Version (grün). Mit dieser Strategie können aktualisierte Softwareversionen auf leicht wiederholbare Weise veröffentlicht werden. Devops-Teams können diese Technik verwenden, um Rollouts neuer Versionen mithilfe einer CI / CD-Pipeline zu automatisieren.

Mit der blau-grünen Strategie stellen Entwickler neben der vorhandenen Instanz, die derzeit den Produktionsverkehr verarbeitet, eine neue Serviceversion bereit. Die CI / CD-Pipeline sollte so eingestellt sein, dass automatisierte Rauchtests durchgeführt werden, um zu überprüfen, ob die neue Version ihre Schlüsselfunktionalität erfüllt. Sobald der neue Dienst die letzten Tests bestanden hat, kann der Datenverkehr sicher und automatisch auf ihn umgeleitet werden. Mithilfe von Software-Routing kann die Verkehrsumschaltung nahtlos von blau nach grün verwaltet werden. Ebenso wichtig ist, dass es bei kritischen Problemen in letzter Minute einfach ist, die Bereitstellung auf die blaue Version zurückzusetzen, wenn kritische Probleme auftreten.

Verkehrsbeschattung

Traffic Shadowing ähnelt blau-grünen Bereitstellungen, aber anstatt synthetische Tests zur Validierung der „grünen“ Umgebung zu verwenden, dupliziert die Routing-Technologie den gesamten eingehenden Produktionsverkehr und spiegelt ihn in einer separaten Testbereitstellung wider, die noch nicht öffentlich ist. Auf diese Weise wird ein genaues Bild davon erstellt, was passieren würde, wenn die neue Version bereitgestellt würde, basierend auf echtem Datenverkehr. Gleichzeitig stellt Traffic Shadowing sicher, dass Tests keinen Einfluss auf die tatsächliche Produktion haben. In der Praxis können Entwickler einen festgelegten Prozentsatz der Anforderungen an einen Testdienst duplizieren, um dann Integrationstests und Leistungsbenchmarking durchzuführen (entweder manuell oder im Rahmen einer automatisierten CI / CD-Pipeline).

Unternehmensentwickler nutzen bereits eine Reihe von Testtechniken, um sicherzustellen, dass neuer Anwendungscode bestimmte Anforderungen erfüllt. Beispielsweise bleiben Einheits- und Funktionstests wesentliche Maßnahmen, die der Code löschen muss. Aufgrund der Natur von Microservices-basierten Architekturen sind End-to-End-Integrationstests jedoch wichtiger denn je. Angesichts des Volumens der Interdependenzen und des Risikos einer langfristigen Drift der Schnittstelle, die mit Microservices-Architekturen verbunden ist, sind synthetische Tests immer noch wertvoll, werden jedoch letztendlich nicht alle Interaktionen zwischen Services in Produktionsumgebungen genau wiedergeben.

Vier Strategien, ein Ziel

Diese Routing-Techniken bieten alle unterschiedliche, jedoch verwandte Methoden zur Unterstützung bei der Entdeckung, Minderung und Prüfung von Fehlern in Anwendungen auf der Basis von Mikrodiensten. Sie sind leistungsstarke Tools zur Behebung von Fehlern, Leistungsproblemen und Sicherheitslücken, insbesondere wenn sie als Teil einer durchgängigen CI / CD-Pipeline (Continuous Integration and Delivery) bereitgestellt werden.

Welche dieser Methoden für Ihren Fall am besten geeignet ist, hängt weitgehend davon ab, welche Bedenken am wichtigsten sind. Beispielsweise kann eine umfassende Überarbeitung der Benutzeroberfläche von A / B-Tests erheblich profitieren, während eine blau-grüne Bereitstellung von unschätzbarem Wert sein kann, um festzustellen, wie sich eine neue Funktion auf die Leistung eines vorhandenen Datenspeichers auswirken kann.

Oft bietet eine Kombination dieser Techniken die beste Abdeckung. Es ist jedoch wichtig zu überlegen, wie gut sich jedes Modell in Ihr vorhandenes Entwicklungsmodell integrieren lässt. Kanarische Bereitstellungen einzelner Funktionen eignen sich möglicherweise besser für agile Entwicklungsmethoden als beispielsweise blaugrüne Bereitstellungen von Vollversionen. Während Traffic Shadowing einen hervorragenden Einblick in die Anwendungsleistung vor der Bereitstellung bietet, kann die Implementierung schwierig und zeitaufwändig sein und hinsichtlich der Rechenressourcen kostspielig sein.

Wie auch immer Sie sie einsetzen, Routing-Techniken wie diese können ein unschätzbarer Teil des Softwareentwicklungsprozesses sein, insbesondere wenn die Branche von traditionellen monolithischen Anwendungen zu Cloud-nativen Systemen auf der Basis von Microservices übergeht. Durch die Anwendung einer, einiger oder aller dieser Techniken unter Berücksichtigung ihrer spezifischen Vorteile können Anwendungsteams die Integrität und den Erfolg ihrer Projekte besser sicherstellen und sicherer in die Produktion einsteigen.

Manuel Zapf ist Produktleiter OSS bei Containous, einem Cloud-nativen Netzwerkunternehmen, das hinter den Open-Source-Projekten Traefik und Maesh steht.

- -

Das New Tech Forum bietet einen Ort, an dem Sie neue Unternehmenstechnologien in beispielloser Tiefe und Breite erkunden und diskutieren können. Die Auswahl ist subjektiv, basierend auf unserer Auswahl der Technologien, die wir für wichtig und für die Leser von größtem Interesse halten. akzeptiert keine Marketingmaterialien zur Veröffentlichung und behält sich das Recht vor, alle eingebrachten Inhalte zu bearbeiten. Senden Sie alle Anfragen an [email protected]