Cloudflare Flagship

 (developers.cloudflare.com)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Cloudflare Flagship ist Cloudflares Feature-Flag-Service zur Steuerung der Funktionsfreigabe von Anwendungen ohne erneute Code-Bereitstellung
  • Flags werden über Targeting-Regeln und prozentbasierte Rollouts definiert und können direkt in nativen Workers-Bindings ausgewertet werden
  • Kompatibel mit OpenFeature; mit dem SDK @cloudflare/flagship lassen sich Flags in Workers, Node.js und Browsern auswerten
  • Das Targeting unterstützt Benutzereigenschaften, 11 Vergleichsoperatoren, AND/OR-Gruppierung, sequenzielle Auswertung und behält Werte per konsistentem Hashing bei
  • Varianten unterstützen Boolesche Werte, Strings, Zahlen und JSON-Objekte und werden pro App im Cloudflare-Dashboard erstellt, geändert und gelöscht

Hauptfunktionen

  • Workers-Binding

    • Binding reference
    • Wertet Flags über das native Binding von Workers aus
    • Bietet typsichere Methoden und automatischen Fallback auf Standardwerte

  • OpenFeature SDK

    • View SDK docs
    • Mit dem OpenFeature-Provider @cloudflare/flagship lassen sich Flags in Workers, Node.js und Browsern auswerten
    • Beim Wechsel von einem anderen Flag-Anbieter muss nur eine Konfigurationszeile geändert werden

  • Targeting-Regeln

    • Learn about targeting
    • Liefert unterschiedliche Flag-Werte abhängig von Benutzereigenschaften
    • Regeln unterstützen 11 Vergleichsoperatoren, logische AND/OR-Gruppierung und sequenzielle Auswertung

  • Prozentbasierte Rollouts

    • Learn about rollouts
    • Funktionen können schrittweise für einen bestimmten Benutzeranteil eingeführt werden
    • Konsistentes Hashing stellt sicher, dass derselbe Benutzer immer denselben Flag-Wert erhält

  • Varianten mit mehreren Typen

    • Use Multi-type variations
    • Flag-Varianten können Boolesche Werte, Strings, Zahlen oder strukturierte JSON-Objekte sein
    • Mit Objektvarianten kann ein ganzer Konfigurationsblock über ein einzelnes Flag übergeben werden

  • Flag-Verwaltung

    • Use Flag management
    • Flags können im Cloudflare-Dashboard erstellt, aktualisiert und gelöscht werden
    • Flags werden als Apps organisiert, die Projekten oder Services zugeordnet sind
    • Das erste Feature-Flag kann im Get started guide erstellt werden

Verwandte Cloudflare-Services

  • Workers: Erstellt serverlose Anwendungen im globalen Netzwerk von Cloudflare; Flagship ist über ein Binding nativ in Workers integriert
  • KV: Speichert Schlüssel-Wert-Daten im globalen Netzwerk von Cloudflare; Flagship nutzt diese Infrastruktur zur Verteilung von Flag-Konfigurationen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Abstraktionen mit 0 Netzwerk-Roundtrips sollte man nicht unterschätzen. Auf f(feature_name, context) kann der Kontext sehr fein abgestimmt werden, bis hin zur Sichtbarkeit für einen bestimmten Lagerbestand, einen bestimmten Lieferanten, einen bestimmten Nutzer eines bestimmten B2B-Kunden, einen bestimmten Untertyp des Geschäftsmodells und eine bestimmte Tageszeit
    Wenn man die Logik direkt schreiben und in einer tight loop so schnell wie Konstanten ausführen kann, steigt die geschäftliche Agilität enorm. Wenn man denkt, dass sich Formulierungen für einige Kunden ändern könnten, kann man es als konfigurierbaren Code anlegen, und Tests sowie Flags folgen dann ganz natürlich
    Allerdings braucht so eine 0-Hop-Konfiguration eine ausgefeilte Client-Ausführungs-Engine, und es wirkt nicht so, als hätte Cloudflare das hier implementiert. Bei speicherbeschränkten Workers ist das nachvollziehbar, in traditioneller Infrastruktur aber weniger
    Der Ansatz von Statsig gefällt mir ziemlich gut: „Server SDKs hold the entire ruleset of your project in memory...“
    https://docs.statsig.com/sdks/how-evaluation-works
    Man kann das auch selbst bauen. Ein Hintergrund-Thread synchronisiert alle paar Sekunden das Regelwerk in einige Datenstrukturen und tauscht Referenzen atomar aus. Danach braucht man nur noch eine CRUD-Schnittstelle für die Dimensionen der anwendbaren Regeln
    Allerdings braucht man unbedingt Governance dafür, wer welche Kandidaten für Konstanten anfassen darf. Mit großer Macht kommt große Verantwortung

    • Beim Lesen davon kommt mir das Muster in den Sinn, dass Feature Flags als Ersatz für Anwendungskonfiguration/-anpassung missbraucht werden. Das ist ein Antipattern, das ich bereits in mehreren Organisationen beobachtet habe
      Ich sehe Feature Flags eher im Zusammenspiel mit trunk-basierter Entwicklung: Features in QA-Umgebungen aktivieren, aber noch nicht in Produktion ausrollen, und so Tests durch PO/PM ermöglichen. Trunk-basierte Entwicklung erlaubt schnelles und einfaches DevOps ohne komplexe Branching-Strategien
      Anwendungskonfiguration dagegen ist Teil der Anwendung und der Bereich, in dem die App an den geschäftlichen Kontext angepasst wird. Ich weiß nicht, ob es dafür relevante Frameworks oder Tools gibt, aber beides sollte klar getrennt werden
    • Die Implementierung selbst ist nicht schwierig. Im Grunde ist es nur Mersenne Twister mit einer Modulo-Operation darüber; in meiner jüngsten Arbeit reichten Flipper und ein optionaler Endpunkt für den „aktuellen Zustand der Flag-Tabelle“ völlig aus
      Wegen dieser Modulo+Zufalls-Kombination mussten Tools wie LaunchDarkly SDKs für viele Sprachen bereitstellen, und die SDKs, mit denen ich arbeiten musste, passten überhaupt nicht gut zur jeweiligen Sprache. Dadurch, dass die Auswertung an den Edge verlagert wurde, ist das Gesamtsystem meiner Meinung nach unnötig komplex geworden
      In der Praxis reicht es völlig, gelegentlich die aktuelle Flag-Tabelle „für diesen Kunden“ erneut abzurufen, und das ist viel weniger lästig. Gut, dass es Flipper gibt, sodass man sich darum nicht mehr selbst kümmern muss
    • Diese 0-Hop-Konfiguration muss nicht einmal besonders ausgefeilt sein, und Cloudflare muss sie auch nicht selbst implementieren. Wenn man auf OpenFeature setzt, ist in die Client-Bibliothek bereits eine einfache Engine zur Auswertung von Targeting-Regeln integriert
    • Guter Hinweis. Ergänzend dazu sind Feature Flags, A/B-Tests und Berechtigungen drei unterschiedliche Konzepte. Das Framing in diesem Artikel fand ich hilfreich
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • Wir nutzen Statsig im Unternehmen sehr erfolgreich. Es ist ausgereift und funktionsreich. Das Tool, das ungenutzte Flags als Kandidaten zur Entfernung identifiziert, ist ziemlich gut
      Vertraglich ist die Abrechnung pro Sitz etwas happig, aber noch tragbar

  • Wirkt wie vergoldetes Boolean-as-a-service

    • Ich habe erlebt, wie ein ganzes Team daran gescheitert ist, so ein Boolean-as-a-service intern nicht vernünftig bereitzustellen. Dass es Firmen wie LaunchDarkly eigens dafür gibt, hat seinen Grund
      Wenn man es so vereinfacht, lässt sich am Ende jeder Dienst der Welt auf bits-as-a-service reduzieren. In Wirklichkeit steckt darin legitimer geschäftlicher Wert, und auch die Bereitstellung ist komplex
    • Ich finde das schon okay. Ich möchte nicht Tausende Feature Flags in einer Datenbank nachverfolgen und ein Admin-Dashboard dafür bauen
      Jedes SaaS-Tool könnte man als „excel-as-a-service“ bezeichnen, und das ist ungefähr genauso aussagekräftig
    • Dieses Boolean zur richtigen Zeit an den richtigen Ort zuverlässig zu liefern, ist alles andere als trivial

  • In den JS-SDK-Dokumenten steht folgende Warnung: „Der Client-Provider benötigt ein API-Token, um Flag-Werte abzurufen. Dieses Token ist nicht auf eine einzelne App beschränkt, daher kann jeder mit dem Token die Flags aller Apps im Konto auswerten. In öffentlichen Anwendungen mit Vorsicht verwenden.“
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    Ich frage mich, warum ein Client SDK, das für den Einsatz im Browser gedacht ist, so eine Warnung braucht. Bedeutet das, dass irgendein Client Anfragen mit einem neuen targetingKey senden und so die Flags anderer Nutzer beobachten kann?
    Flags sollten natürlich keine sensiblen Informationen enthalten, aber es wirkt wie eine interessante Designentscheidung

    • Vermutlich ist das etwas, das intern bei Cloudflare genutzt wurde und bei dem jemand dachte, es wäre interessant, es zu veröffentlichen
      Es wirkt nicht so, als hätte Cloudflare vor sechs Monaten ernsthaft entschieden, einen LaunchDarkly-Konkurrenten zu bauen
    • Ich bin Ingenieur im Flagship-Team. App-scoped Tokens sind in Arbeit

  • Das ist gut, aber ironischerweise warte ich gerade noch darauf, dass genau diese Funktion erscheint, die vermutlich über Flagship angeboten wird
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    Es scheint noch keinen einzigen Fall zu geben, in dem eine reine Enterprise-Funktion in niedrigere Bezahlkonten heruntergereicht wurde
    Besonders interessiert mich das hier:
    https://developers.cloudflare.com/speed/optimization/content...

    • Stimmt. Ich brauche die Zero-Trust-Enterprise-Funktionen so dringend, dass ich am Ende wohl direkt mit einem Enterprise-Vertriebsmitarbeiter sprechen muss. Das wird vermutlich viel Zeit kosten und Stress verursachen, den ich gern vermeiden würde

  • Cloudflare macht im Moment vieles richtig, aber es fehlt an feingranularer Rechteverwaltung. Man muss immer noch komplett getrennte Konten für Produktionsumgebungen anlegen, und weil eine Domain nur an ein einziges Konto gebunden sein kann, gerät SSO durcheinander

    • Die Produkte sind großartig und ich war lange sehr zufrieden damit, aber im Blog gab es zuletzt ein paar Patzer. Auch die Zuverlässigkeit wirkte eine Zeit lang etwas wackelig, obwohl es in letzter Zeit wieder besser zu sein scheint
    • Ich habe nach einigen Jahren mit AWS Cloudflare ausprobiert, und die User Experience hat mir gefallen, bin aber wegen genau dieser Bedenken wieder zurückgegangen. Es fehlt wirklich nicht mehr viel
    • Ich habe vor ein paar Jahren alle Projekte zu Cloudflare migriert und bereue es nicht. Ich nutze Workers, D1, R2, Queues, Containers, KV
      Für den E-Mail-Versand nutze ich noch AWS, daher wäre es schön, wenn es dafür etwas von Cloudflare gäbe
    • Ich habe heute auch ein Support-Ticket für feingranularere Berechtigungen eröffnet
    • Genau das ist der Grund, warum ich Cloudflare nicht für echte Arbeit einsetzen kann. Die kostenlose Hobby-Tier gefällt mir aber

  • Von OpenFeature höre ich zum ersten Mal, sieht cool aus. Hat jemand Erfahrung mit der Integration? https://openfeature.dev

    • Ich habe OpenFeature viel verwendet und sogar die ersten Commits für einige Client-Bibliotheken beigetragen. Es ist definitiv die Zukunft von Feature Flags, und das Ökosystem wächst schnell
      Der Transparenz halber: Ich bin CTO von Flagsmith. In den letzten Jahren habe ich bei der Einführung von OpenFeature eine klar steigende Kurve gesehen. Früher haben wir unseren Kunden empfohlen, es auszuprobieren, inzwischen kommen Kunden mit OpenFeature als Anforderung zu uns
      Der Vendor-Support ist inzwischen ziemlich ausgereift und deckt fast alle Sprachen ab. Wenn du Feature Flags in einen neuen Service integrieren oder von einer Eigenimplementierung auf eine Drittanbieterlösung umsteigen willst, würde ich OpenFeature empfehlen
    • Ziemlich nützlich. Ich habe es in meiner vorherigen Firma verwendet und ein Custom-Backend gebaut, dabei aber die Spezifikation und SDKs von OpenFeature genutzt
      Ein vollständig eigenes Backend hat ungefähr zwei Wochen gedauert. Die SDKs für mehrere Sprachen haben problemlos funktioniert. Ich habe zwar einen Bug gefunden, aber nachdem ich ihn gemeldet hatte, wurde er noch am selben Tag behoben

  • Ich verstehe Feature Flags nicht wirklich. Was unterscheidet sie grundsätzlich von einem Boolean in der Datenbank?

    • Ob das Flag selbst ein Boolean, ein String, eine Zahl oder etwas anderes ist, ist der einfache Teil. Schwierig sind Targeting- und Rollout-Regeln: also wer welches Flag sieht, und die Anforderung, diese Regeln sehr schnell und konsistent auszuwerten
      Teams mit Eigenbau-Lösungen erleben meist, dass das Problem schnell wächst, sobald Produktmanagement, Marketing oder Vertrieb komplexeres Targeting wollen
      Insgesamt ist es kein besonders schwieriges Problem, aber ein großes. Man braucht am Anfang viele unsichtbare Funktionen
      Feature Flags sind im Kern eher mit einem Berechtigungssystem verwandt. Bestimmte Nutzer bekommen Zugriff auf bestimmte Funktionen, und jeder, der schon einmal mit Berechtigungssystemen zu tun hatte, weiß, wie schnell Gruppenmitgliedschaften, hierarchische Gruppen, Rollen, ACLs usw. komplex werden. Diese Elemente ähneln den verschiedenen Targeting-Regeln in Feature-Flag-Systemen
    • Mit prozentualen Rollouts, RBAC, Audit-Historie, A/B-Tests und multivariaten Konfigurationen wird es schnell komplex. Aus diesem einen Boolean wird dann ein ganzes System, das betrieben und gepflegt werden muss
    • Einen ausführlichen Artikel dazu gibt es hier: https://martinfowler.com/articles/feature-toggles.html
    • Es ist nicht immer ein Boolean. Feature Flags werden zum Beispiel oft für A/B-Rollouts verwendet
      Cloudflare nutzt sie intern auch, um neue Funktionen oder Builds zuerst an kostenlose Kunden auszurollen und sie nach einer Stabilisierungsphase schrittweise auf größere Kunden auszuweiten
      Feature Flags können auch quasi wie eine Form von Fuzz-Testing zufällig aktiviert werden. Denk also nicht nur an etwas „Neues“, sondern auch an eine „Verhaltensänderung“
      Man kann es sich zwar als Boolean über allen Clients vorstellen, aber so wird es normalerweise nicht implementiert
    • Man kann sie mit einem Boolean in der Datenbank umsetzen, also ist das nur ein Implementierungsdetail
      Der Hauptvorteil von Feature Flags ist, dass man auch an großen Funktionen, die Monate und viele Commits brauchen, direkt im Main-Branch arbeiten kann. Für mich führt das zu einem leichteren, iterativeren Entwicklungsprozess
      Im Gegensatz dazu steht die Pflege separater Branches und eigener Deployment-Ziele für Funktionen, die noch in größerer Entwicklung sind

  • Feature Flags sind oft übermäßig overengineert
    Man prüft einen Konfigurationswert, einen Datenbankwert oder eine Umgebungsvariable und geht dann dynamisch den einen oder den anderen Pfad
    Mehr ist es nicht. Man sollte Funktionen klein halten oder den Code so refaktorieren, dass sie sich auf höherer Ebene leicht umschalten lassen
    Wenn das nicht so einfach geht, kann eine komplexe Feature-Flag-Implementierung helfen, um die Aktivierung von Funktionen zwischen Microservices zu koordinieren
    Wenn es viele Funktionen gibt, kann auch ein Dashboard nützlich sein
    Beides ist für mich aber ein starkes Signal, dass man Feature Flags eher vermeiden sollte. Sie eignen sich besser für lokale und temporäre Änderungen; sonst sammelt sich Komplexität an, die Verwaltung und Wartung erschwert

    • Es ist legitim, eine Funktion für ein bestimmtes Segment zu aktivieren, zum Beispiel für umsatzschwache Nutzer in Italien, um die geschäftlichen oder Performance-Auswirkungen zu sehen
      Natürlich möchte man nicht, dass Nutzer die Funktion wieder verlieren, nur weil sie eine Umsatzschwelle überschreiten oder eine Grenze überqueren, also braucht man irgendeine Form von Tracking-Implementierung. Auch Analyse- und Fehlerverfolgungssysteme müssen mit dem Feature-Flag-Service kommunizieren
      Es ist keine Raketenwissenschaft, aber definitiv komplexer als eine Umgebungsvariable
    • Der Kern von Feature Flags ist Disziplin. Man sollte sie zielgerichtet einführen und sie sofort entfernen, sobald sie keinen Wert mehr bringen. KISS gilt auch hier

  • Es ist immer spannend, wenn Cloudflare anfängt, etwas anzubieten, wofür man bisher andere Anbieter brauchte. Man vertraut darauf, dass es solide sein wird
    Bei Function haben wir Statsig genutzt. Anfangs wurde es in einem Produkt von zwei Personen verwendet, aber innerhalb von 12 Monaten lief ein großer Teil der Produkttexte und Rollouts über Statsig
    Statsig bietet clientseitige Auswertung, sodass man Regeln und Rollouts auf Basis interner Konzepte schreiben kann, ohne dass die Statsig-Server Nutzerdaten verarbeiten müssen
    Hoffentlich baut Cloudflare hier ein ausgereiftes Produkt, sodass man künftig keine anderen Produkte mehr verwenden muss

    • Ich finde es seltsam, Feature Flags an Dritte auszulagern. Ich bin nicht grundsätzlich dafür, alles selbst zu bauen, aber bei Feature Flags gab es keine großen Probleme damit, sie selbst umzusetzen

  • Ich bin ein ganz normaler Nutzer und kenne mich mit den technischen Details nicht besonders aus, aber Cloudflare wirkt auf mich vergleichsweise einfach zu benutzen. Hoffentlich machen sie weiter so

    • Der beste DNS-Registrar, den ich bisher genutzt habe