Wie Sie bei Progressive Delivery erfolgreich sind

In letzter Zeit wird viel über Progressive Delivery geredet. Und das zu Recht, denn es ist eine großartige Ergänzung zur kontinuierlichen Bereitstellung. Indem Sie neue Versionen schrittweise einer Untergruppe von Benutzern zur Verfügung stellen, verringern Sie die Risiken weiter. Wie immer, wenn es um neue und glänzende Dinge geht, sind viele von uns begierig darauf, sie auszuprobieren, die Tools kennenzulernen und auf diese Arbeitsweise umzustellen. Aber wie so oft gibt es Gründe, die dafür sprechen, Gründe, die dagegen sprechen, und Gründe, die dafür sprechen, dass Sie damit keinen Erfolg haben. Lassen Sie mich Ihnen ein paar dieser Gründe nennen, um Ihnen die Mühe zu ersparen.

Rückwärts- und Vorwärtskompatibilität

Der wahrscheinlich häufigste Fehler in der progressiven Auslieferungspraxis tritt beim Umgang mit Daten jeglicher Art auf. Wenn die Anwendung zustandslos ist, ist dies relativ einfach zu bewältigen. Wenn jedoch zustandsbehaftete Dienste beteiligt sind (und das sind sie oft), wird der Umgang mit Daten immer schwieriger. Das bedeutet, dass die Dienste rückwärts und vorwärts kompatibel sein müssen.

Im Allgemeinen gibt es eine einfache Regel. Ist Ihre App horizontal skalierbar und können Sie derzeit rollierende Updates ohne Ausfallzeiten durchführen? Dann sind Sie wahrscheinlich bereit, auch die progressive Bereitstellung Ihrer App zu versuchen. Hier sind einige praktische Beispiele für diese Regel:

Nehmen wir an, Sie stellen die Version 2 eines Microservices bereit und leiten den Datenverkehr von 10 % Ihrer Benutzer auf diese neue Version um. Hoffentlich sind alle Daten außerhalb des Dienstes selbst gespeichert, d.h. in einer Datenbank oder einem Ereignisspeicher und nicht in einem ephemeren Speicher. Alle Daten haben ein Schema, das zusammen mit Ihrer Anwendung versioniert werden sollte. In diesem Szenario hat sich auch die Datenstruktur geändert; jetzt haben Sie auch Schema Version 1 und Version 2. Da die verbleibenden 90% der Anfragen immer noch auf Schema v1 beruhen, müssen Sie dies berücksichtigen. Zum Beispiel, indem Sie v2 des Dienstes Daten aus Schema v1 lesen lassen, während Sie Daten in Schema v2 schreiben.

Nehmen wir nun an, es gibt ein Problem mit dieser neuen Version. Sie möchten ein Rollback durchführen und die 10% des Datenverkehrs auf v1 zurücksetzen. In der Zwischenzeit gab es wahrscheinlich einige Datenmutationen, so dass alle Daten, die mit Schema v2 geschrieben wurden, verloren sind, es sei denn, Sie berücksichtigen auch dies. Möglicherweise möchten Sie alle Daten aus dem neuen Schema zurück in das alte Schema migrieren. Entweder das oder Sie beschließen, keine Rollbacks durchzuführen, wenn Daten betroffen sind. Stattdessen beheben Sie das Problem und stellen eine neue Version für dieselben 10 % der Benutzer bereit. Dabei gehen Sie das Risiko ein, dass für 90 % Ihrer Benutzer nun zwei Versionen voneinander abweichen.

Wenn dieser Dienst zustandsbehaftet ist und Daten in einem lokalen ephemeren Speicher hat, wie z.B. im Arbeitsspeicher (und eine Änderung des Dienstes, um seine Daten nach außen zu verschieben, ist keine Option), gelten dieselben Vorbehalte. Außerdem sollten Sie sicherstellen, dass eine Instanz ihren Zustand an andere Instanzen dieses Dienstes delegiert, wenn sie ein Signal zum Herunterfahren erhält, oder ihren Zustand in einen temporären externen Speicher flusht, um später von einer neuen Version gelesen zu werden.

Und selbst wenn es keine nennenswerten gespeicherten Daten gibt und ein Dienst nur Anfragen sendet und empfängt, gibt es immer noch ein Datenschema. Eine REST-API muss beispielsweise die Versionsendpunkte erhöhen und die alten Endpunkte beibehalten, bis sie vollständig abgeschafft werden. Jeder andere Dienst, der diese API verwendet, muss gleichzeitig auf die neue Version umgestellt werden, oder die 10 % des Datenverkehrs werden nur die Frage beantworten: "Macht die neue Version die alte Version kaputt?" und nicht: "Tut die neue Version, was sie soll?

Überwachung relevanter Bits

Sie haben die Abwärtskompatibilität gelöst und Ihre neue Version ist für 10% Ihrer Endbenutzer live. Alles scheint zu funktionieren. Aber wie können Sie sicher sein?

Eine häufige Kennzahl, die in allen möglichen Beispielen für Progressive Delivery erwähnt wird, ist die Anzahl der Anfragefehler. Die Idee dahinter ist, dass die HTTP-Statuscodes Aufschluss darüber geben, ob etwas korrekt funktioniert oder nicht. Das ist zwar eine hilfreiche Kennzahl, aber sie ist bei weitem nicht ideal, um sie als Basis zu verwenden. Sie sagt zum Beispiel nichts darüber aus, ob die Fehlercodes korrekt implementiert wurden. Ein Dienst könnte fröhlich den Status 200 senden, während alles in Flammen steht, wenn die Fehlerbehandlung nicht richtig implementiert wurde. Noch wichtiger ist, dass Sie damit nicht erfahren, was Ihre Benutzer erleben.

Es ist sinnvoller, die Geschäftskennzahlen zu überwachen, z. B. abgeschlossene Transaktionen, bearbeitete Bestellungen oder den Service, den Sie Ihren Endbenutzern anbieten. Wenn bei diesen 10 % der Benutzer die Anzahl der Transaktionen ungewöhnlich stark zurückgeht, gibt es wahrscheinlich ein Problem.

Mit geeigneten Tests

Es ist verlockend, Progressive Delivery als eine Möglichkeit zu betrachten, automatisierte Tests zu überspringen. Ein kleiner Teil Ihres Endbenutzerverkehrs wird nun als Ihre Tests fungieren, richtig?

Ja und nein.

Wenn Sie, wie oben beschrieben, die richtigen Dinge überwachen, werden diese Benutzer Ihnen Rückmeldung darüber geben, ob Ihre Änderungen selbst funktionieren und ob sie etwas anderes kaputt gemacht haben. Vorausgesetzt, sie nutzen diese Funktionen tatsächlich zu diesem Zeitpunkt. Oder im Falle von Lasttests gibt es gerade ein hohes Verkehrsaufkommen. Aber was ist, wenn Sie mehrmals am Tag neue Versionen herausbringen? Sie wollen nicht davon abhängig sein, ob Ihre Endbenutzer Ihnen helfen wollen. Daher sollten Sie neben der Überwachung auch etwas Zeit in automatisierte Tests investieren, die in der Produktion laufen.

Dies hilft auch bei der Umstellung auf eine vollautomatisierte Progressive Delivery. Wenn Sie die App für 10 % Ihrer Benutzer freigegeben haben, Sie keine größeren Fehler beobachten und Ihre automatisierten Tests erfolgreich sind, gibt es keinen Grund, nicht automatisch auf 100 % zu skalieren.

Ich bin ein Spezialist bei Qxperts. Wir unterstützen Unternehmen dabei, zuverlässige und hochwertige Software zu entwickeln. Haben Sie Fragen? Wir sind für Sie da! www.qxperts.io