Implementierung von Feature Flags mit niedriger Latenzzeit und dynamischen Funktionen

Wenn die Logik Ihrer Codebasis vom Rückgabewert eines Feature Flags, z.B. einer Funktion isFeatureEnabled, abhängt, müssen Sie sicherstellen, dass isFeatureEnabled seine Entscheidung so schnell wie möglich zurückgibt.

Wenn Sie sich auf eine externe Datenbank verlassen, um zu speichern, ob die Funktion aktiviert ist, riskieren Sie im schlimmsten Fall, dass sich die Latenzzeit Ihrer Anwendung erhöht, weil eine externe Netzwerkanfrage über das Internet erforderlich ist, selbst wenn die neue Funktion nicht aktiviert ist.

Im besten Fall wird die Funktion isFeatureEnabled entweder als Variable oder als Umgebungsvariable fest auf true oder false kodiert, aber dann verlieren Sie die Möglichkeit, den Wert des Feature Flags dynamisch zu ändern, ohne dass Sie Code implementieren oder Ihre Anwendung neu konfigurieren müssen.

In meinem Erlebnis als Ingenieur und technischer Leiter habe ich mehrere Methoden gesehen, um ein Gleichgewicht zwischen schnellen und dynamischen Feature Flags zu erreichen, das den Bedürfnissen und Funktionen der verschiedenen Anwendungen entspricht. Im Folgenden gehe ich auf eine Beispielarchitektur aus meinem kostenlosen E-Book Ship Confidently with Progressive Delivery and Experimentieren ein, die dieses Gleichgewicht gut herstellt und für viele Plattformen geeignet ist.

Eine Architektur, die ein Gleichgewicht zwischen schnellen und dynamischen Feature Flags herstellt, wird:

• Holen Sie die neueste Feature Flags-Konfiguration, wenn die Anwendung gestartet wird
• die Konfiguration der Feature Flags im Arbeitsspeicher und auf der Festplatte zwischenspeichern, so dass Entscheidungen mit geringer Latenz getroffen werden können und nachfolgende Anwendungsstarts schnell sind
• Warten Sie auf Aktualisierungen der Feature Flag-Konfiguration, damit diese so schnell wie möglich an die Anwendung weitergegeben werden.
• Abfrage der Feature Flag-Konfiguration in regelmäßigen Abständen, so dass die Anwendung auch bei einem fehlgeschlagenen Push innerhalb eines genau definierten Intervalls garantiert über die neueste Feature-Konfiguration verfügt

Das Abrufen und Zwischenspeichern der Konfiguration beim Start stellt sicher, dass Sie eine API wie isFeatureEnabled auswerten können, ohne langsame, blockierende Netzwerkanfragen nach dem Status eines Feature Flags stellen zu müssen, während ein Benutzer Ihre Anwendung verwendet. Das Speichern der Konfiguration auf der Festplatte sorgt dafür, dass nachfolgende Anwendungsstarts nicht auf den Abschluss des ersten Abrufs warten müssen.

Das Abhören und Abfragen von Aktualisierungen stellt sicher, dass Ihre Feature Flags dynamisch bleiben, auch wenn Ihre Anwendung nicht oft neu gestartet wird.

Das folgende Diagramm zeigt, wie sich diese Architektur in einer Zeitachse zwischen einem Admin-Panel, das den Status Ihrer Feature Flags kontrolliert, und den Client-Apps oder Anwendungsservern, die auf diese Feature Flag-Informationen angewiesen sind, abspielt. Lesen Sie das Diagramm als Zeitleiste von oben nach unten:

Beispiel einer Feature Flags Service-Architektur

Ein Beispiel: Eine mobile Anwendung könnte zunächst versuchen, (1) die Konfiguration der Feature Flags zu laden, wenn diese bereits im Cache des Telefons gespeichert ist. Unabhängig davon, ob eine Feature Flag-Konfiguration vorhanden war, holt das Telefon (2) die neueste Feature Flag-Konfiguration, wenn die App gestartet wird, und speichert dann (3) diese neueste Feature Flag-Konfiguration im Speicher des Telefons. Die Mobile App kann dann (4) in regelmäßigen 10-Minuten-Intervallen abfragen, ob die Feature Flags noch aktuell sind, und (5) Push-Benachrichtigungen über Änderungen an den Feature Flags in Echtzeit empfangen. Jedes Mal, wenn das Telefon Aktualisierungen der Feature Flags erhält, kann es diese Änderungen (3) im Speicher und auf der Festplatte zwischenspeichern, damit die nachfolgenden (1) Starts schneller erfolgen.

Auf diese Weise wird die Leistung des Anwendungsstarts minimiert, Entscheidungen über Feature Flags werden schnell auf der Grundlage von Daten im Speicher getroffen und Feature Flags bleiben immer auf dem neuesten Stand, wenn Änderungen an ihrer Konfiguration vorgenommen werden, sei es durch einen Echtzeit-Push oder durch regelmäßige Abfragen.

Für ein Anwendungsserver-Beispiel ist jeder Schritt derselbe, außer dass Sie anstelle von Push-Benachrichtigungen (5) Webhooks oder serverseitige Ereignisse verwenden würden, um in Echtzeit auf Aktualisierungen zu warten.

Für das Beispiel einer Frontend-Anwendung ist jeder Schritt derselbe, außer dass Sie statt Push-Benachrichtigungen oder Webhooks (5) Websockets oder serverseitige Ereignisse verwenden, um in Echtzeit auf Aktualisierungen zu warten.

Für Entwickler ist diese Architektur interessant, weil sie relativ einfach einzurichten ist, schnelle und dynamische Feature Flags liefert und leicht an eine Vielzahl von Anwendungen angepasst werden kann. Wenn Sie keine Zeit für den Aufbau einer solchen Infrastruktur aufwenden möchten, sollten Sie unbedingt das kostenlose Feature Flag-Angebot von Optimizely checken, das eine ähnliche Architektur als kostenlosen Service anbietet!

Lassen Sie mich wissen, was Sie davon halten!

Wie richten Sie eine Infrastruktur für Feature Flags ein, um schnelle und dynamische Entscheidungen auszugleichen? Schreiben Sie mir eine Nachricht in unserer Slack-Community oder finden Sie mich auf Twitter unter @asametrical.

Dies ist Teil einer Reihe von Erfolgsmethoden, die Ihrem Unternehmen helfen, Progressive Delivery und Experimentieren erfolgreich zu implementieren, um schneller und sicherer zu liefern.

Wenn Ihnen dieser Inhalt gefällt, sollten Sie sich mein kostenloses E-Book ansehen: Mit Progressive Delivery und Experimentieren zuversichtlich ausliefern. Darin finden Sie weitere Erfolgsmethoden vom Einstieg bis zur unternehmensweiten Skalierung dieser Techniken.

Und wenn Sie auf der Suche nach einer Plattform für den Einstieg sind, sollten Sie sich das kostenlose Angebot von Optimizely ansehen. Vielen Dank!