Cloudflare Flagship

 (developers.cloudflare.com)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Cloudflare Flagship est le service de feature flags de Cloudflare qui permet de contrôler l’exposition des fonctionnalités d’une application sans redéployer le code
  • Les flags sont définis par des règles de ciblage et des rollouts progressifs basés sur un pourcentage, et peuvent être évalués directement depuis les bindings natifs de Workers
  • Compatible avec OpenFeature, il est possible d’évaluer les flags dans Workers, Node.js et le navigateur avec le SDK @cloudflare/flagship
  • Le ciblage prend en charge les attributs utilisateur, 11 opérateurs de comparaison, le groupement AND/OR, l’évaluation séquentielle, et conserve les valeurs grâce au hachage cohérent
  • Les variations prennent en charge les booléens, chaînes, nombres et objets JSON, et peuvent être créées, modifiées ou supprimées par application depuis le tableau de bord Cloudflare

Fonctionnalités principales

  • Bindings Workers

    • Binding reference
    • Évalue les flags via les bindings natifs de Workers
    • Fournit des méthodes type-safe et un repli automatique vers une valeur par défaut

  • SDK OpenFeature

    • View SDK docs
    • Le provider OpenFeature @cloudflare/flagship permet d’évaluer les flags dans Workers, Node.js et le navigateur
    • Lors d’une migration depuis un autre fournisseur de feature flags, il suffit de changer une seule ligne de configuration

  • Règles de ciblage

    • Learn about targeting
    • Fournit des valeurs de flag différentes selon les attributs utilisateur
    • Les règles prennent en charge 11 opérateurs de comparaison, le groupement logique AND/OR et l’évaluation séquentielle

  • Rollouts basés sur un pourcentage

    • Learn about rollouts
    • Permet de déployer progressivement une fonctionnalité auprès d’un pourcentage d’utilisateurs
    • Le hachage cohérent garantit qu’un même utilisateur reçoit toujours la même valeur de flag

  • Variations multi-types

    • Use Multi-type variations
    • Les variations de flag peuvent être des booléens, des chaînes, des nombres ou des objets JSON structurés
    • Les variations d’objet permettent de transmettre un bloc de configuration complet avec un seul flag

  • Gestion des flags

    • Use Flag management
    • Vous pouvez créer, mettre à jour et supprimer des flags depuis le tableau de bord Cloudflare
    • Les flags sont organisés en applications mappées à des projets ou services
    • Vous pouvez créer votre premier feature flag via le guide de démarrage

Services Cloudflare associés

  • Workers : permet de créer des applications serverless sur le réseau mondial de Cloudflare, et Flagship s’intègre nativement à Workers via des bindings
  • KV : stocke des données clé-valeur sur l’ensemble du réseau mondial de Cloudflare, et Flagship utilise cette infrastructure pour distribuer la configuration des flags

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • Il ne faut pas sous-estimer une abstraction sans aller-retour réseau. Au-dessus de f(feature_name, context), le contexte peut être ajusté de façon extrêmement fine : inventaire précis, fournisseur précis, utilisateur précis d’un client B2B précis, sous-type précis de modèle économique, jusqu’à l’affichage ou non selon une tranche horaire précise
    Si on peut écrire la logique directement et l’exécuter comme une constante dans une boucle serrée, l’agilité métier augmente fortement. Si l’on pense qu’un libellé peut changer pour certains clients, il suffit de l’implémenter dans le code de façon configurable, et les tests ainsi que les flags suivent naturellement
    En revanche, ce type de configuration 0-hop nécessite un moteur d’exécution client sophistiqué, et Cloudflare ne semble pas avoir implémenté cela ici. C’est compréhensible dans des Workers avec des contraintes mémoire, mais moins convaincant dans une infrastructure traditionnelle
    J’aime assez l’approche de Statsig : « Server SDKs hold the entire ruleset of your project in memory... »
    https://docs.statsig.com/sdks/how-evaluation-works
    On peut aussi le construire soi-même. Il suffit qu’un thread en arrière-plan synchronise l’ensemble de règles dans quelques structures de données toutes les quelques secondes, puis remplace les références de façon atomique. Ensuite, il ne reste qu’à fournir une interface CRUD sur les dimensions des règles applicables
    Il faut toutefois absolument de la gouvernance sur qui peut modifier quels candidats de constantes. Avec de grands pouvoirs viennent de grandes responsabilités

    • En lisant cela, je pense au schéma où les feature flags sont détournés pour servir de configuration / personnalisation applicative. C’est un anti-pattern déjà observé dans plusieurs organisations
      Les feature flags servent plutôt, à mon avis, avec le développement trunk-based, à activer des fonctionnalités en environnement de QA, sans les livrer encore en production, tout en permettant les tests PO/PM. Le trunk-based development permet un DevOps rapide et simple, sans stratégie de branches complexe
      À l’inverse, la configuration applicative fait partie de l’application et concerne sa personnalisation selon le contexte métier. Je ne sais pas s’il existe des frameworks ou outils adaptés, mais il faut clairement distinguer les deux
    • L’implémentation en elle-même n’est pas difficile. C’est du niveau d’un Mersenne Twister avec une opération modulo, et dans un travail récent, Flipper avec un endpoint optionnel « état actuel de la table des flags » suffisait largement
      C’est cette combinaison modulo + aléatoire qui a obligé des outils comme LaunchDarkly à fournir des SDK pour plusieurs langages, et ceux que j’ai dû utiliser étaient très mal adaptés à leur langage. En poussant l’évaluation jusqu’à l’edge, on a rendu l’ensemble du système plus complexe que nécessaire
      En pratique, il suffit de recharger de temps en temps la table de flags courante « pour ce client », et c’est bien moins pénible. Heureusement qu’il y a Flipper, ça évite d’avoir à gérer cela soi-même désormais
    • Cette configuration 0-hop n’a pas forcément besoin d’être sophistiquée, et Cloudflare n’a pas besoin de l’implémenter lui-même. En s’appuyant sur OpenFeature, un moteur simple d’évaluation de règles de ciblage est déjà intégré à la bibliothèque cliente
    • Bon conseil. J’ajouterais que les feature flags, les tests A/B et les autorisations sont trois notions différentes. Le cadrage de cet article était utile
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • Nous utilisons bien Statsig dans l’entreprise. C’est abouti et riche en fonctionnalités. L’outil qui repère les flags inutilisés pour proposer leur suppression est plutôt bon
      La facturation contractuelle par siège est un peu rude, mais reste supportable

  • On dirait un Boolean-as-a-service doré à l’or fin

    • J’ai vu toute une équipe échouer parce que l’entreprise n’arrivait pas à fournir correctement ce type de Boolean-as-a-service. S’il existe des sociétés comme LaunchDarkly, ce n’est pas pour rien
      En simplifiant à ce point, on pourrait réduire tous les services du monde à du bits-as-a-service. En réalité, il y a une vraie valeur métier derrière ce genre de produit, ainsi qu’une complexité réelle dans sa fourniture
    • Je trouve ça très bien. Je n’ai aucune envie de suivre des milliers de feature flags dans une base de données ni de construire un tableau de bord d’administration
      On pourrait appeler n’importe quel outil SaaS « excel-as-a-service », et ce serait du même niveau comme formule
    • Acheminer ce Boolean au bon endroit au bon moment, de façon fiable, n’a rien de trivial

  • Dans la documentation du SDK JS, il y a cet avertissement : « Le provider client a besoin d’un token API pour récupérer les valeurs des flags. Ce token n’est pas limité à une seule application ; toute personne qui possède le token peut donc évaluer les flags de toutes les applications du compte. À utiliser avec précaution dans les applications publiques »
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    Je me demande pourquoi un SDK client conçu pour être déployé dans le navigateur nécessite une telle prudence. Est-ce que cela signifie que n’importe quel client peut envoyer des requêtes avec un nouveau targetingKey et observer les flags d’autres utilisateurs ?
    Les flags ne devraient évidemment pas contenir d’informations sensibles, mais cela ressemble à un choix de conception intéressant

    • On dirait sans doute quelque chose qu’ils utilisaient en interne chez Cloudflare et que quelqu’un s’est dit qu’il serait amusant de publier
      Il paraît peu probable que Cloudflare ait sérieusement décidé il y a six mois de construire un concurrent à LaunchDarkly
    • Je suis ingénieur dans l’équipe Flagship. Les tokens scoped à l’application sont en cours de développement

  • C’est bien, mais ironiquement j’attends toujours la sortie de cette fonctionnalité qui sera probablement proposée via Flagship
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    Je crois qu’il n’y a encore eu aucun cas où une fonctionnalité réservée à l’Enterprise est redescendue vers les offres payantes inférieures
    Celle qui m’intéresse particulièrement, c’est celle-ci :
    https://developers.cloudflare.com/speed/optimization/content...

    • Oui. J’ai tellement besoin des fonctionnalités Enterprise de Zero Trust que je vais probablement devoir finir par parler directement à un commercial Enterprise. Ça risque de prendre du temps et d’ajouter un stress dont je me passerais bien

  • En ce moment, Cloudflare fait du bon travail, mais il manque une gestion fine des permissions. Il faut toujours créer un compte totalement séparé pour la production, et comme un domaine ne peut être lié qu’à un seul compte, ça complique le SSO

    • Les produits sont super et j’en ai été satisfait pendant longtemps, mais le blog a récemment accumulé quelques ratés. La stabilité semblait aussi vaciller depuis un moment, même si ça a l’air de s’être amélioré dernièrement
    • Après avoir utilisé AWS pendant quelques années, j’ai essayé Cloudflare et j’ai aimé l’expérience utilisateur, mais je suis finalement revenu en arrière à cause des mêmes inquiétudes. C’était vraiment tout proche, dommage
    • J’ai migré tous mes projets vers Cloudflare il y a quelques années et je ne le regrette pas. J’utilise Workers, D1, R2, Queues, Containers, KV
      J’utilise encore AWS pour l’envoi d’e-mails, donc j’aimerais bien voir ça arriver chez Cloudflare
    • Moi aussi, j’ai ouvert aujourd’hui un ticket de support pour demander des permissions plus granulaires
    • C’est exactement la raison qui m’empêche d’utiliser Cloudflare pour un vrai travail. En revanche, j’aime bien le free tier pour les projets perso

  • Je découvre OpenFeature, et ça a l’air cool. Quelqu’un a déjà de l’expérience avec une intégration ? https://openfeature.dev

    • J’ai beaucoup utilisé OpenFeature et j’ai même fait les commits initiaux sur quelques bibliothèques clientes. C’est clairement l’avenir des feature flags, et l’écosystème grandit vite
      Pour être transparent, je suis le CTO de Flagsmith. Ces dernières années, j’ai vu une courbe de croissance très nette de l’adoption d’OpenFeature. Avant, c’était nous qui recommandions à nos clients de l’essayer ; maintenant, ce sont les clients qui arrivent avec OpenFeature comme exigence
      Le support côté éditeurs est désormais assez mature et couvre presque tous les langages. Si vous intégrez des feature flags dans un nouveau service ou si vous passez d’une implémentation maison à une solution tierce, je recommande OpenFeature
    • C’est assez utile. Je l’ai utilisé dans ma précédente boîte, en construisant un backend personnalisé tout en utilisant la spec et les SDK d’OpenFeature
      Il nous a fallu environ deux semaines pour créer un backend entièrement sur mesure. Les SDK pour plusieurs langages ont fonctionné sans problème. J’ai trouvé un bug, mais après l’avoir signalé, il a été corrigé le jour même

  • J’ai du mal à bien comprendre les feature flags. En quoi est-ce fondamentalement différent d’un booléen en base de données ?

    • Que le flag lui-même soit un booléen, une chaîne, un nombre ou autre, c’est la partie facile. La difficulté, ce sont les règles de ciblage et de déploiement progressif : qui voit quel flag, et l’exigence d’évaluer ces règles de façon très rapide et cohérente
      Les équipes qui les construisent elles-mêmes voient souvent le problème grossir très vite quand le produit, le marketing ou les ventes veulent cibler avec des règles de plus en plus complexes
      Dans l’ensemble, ce n’est pas un problème particulièrement difficile, mais c’est un problème d’ampleur. Il faut beaucoup de choses invisibles au départ
      On peut voir les feature flags comme un système d’autorisations : permettre à certains utilisateurs seulement d’accéder à certaines fonctionnalités. Tous ceux qui ont déjà géré des systèmes de permissions savent à quel point l’appartenance à des groupes, les groupes hiérarchiques, les rôles, les ACL, etc. deviennent complexes. Ces éléments ressemblent aux différentes règles de ciblage d’un système de feature flags
    • Dès qu’on ajoute les déploiements par pourcentage, le RBAC, l’historique d’audit, les tests A/B et la configuration multivariée, ça devient vite complexe. Ce booléen se transforme en tout un système qu’il faut exploiter et maintenir
    • Un article détaillé ici : https://martinfowler.com/articles/feature-toggles.html
    • Ce n’est pas toujours un booléen. Par exemple, les feature flags servent souvent aux déploiements A/B
      Cloudflare les utilise aussi en interne pour déployer d’abord de nouvelles fonctionnalités ou de nouveaux builds aux clients gratuits, puis les étendre progressivement aux plus gros clients après une période de stabilisation
      Les feature flags peuvent aussi être activés de manière aléatoire, un peu comme une forme de fuzz testing. Il ne faut pas penser seulement à quelque chose de « nouveau », ça peut aussi être un « changement de comportement »
      On peut voir ça comme un booléen au-dessus de tous les clients, mais en général ce n’est pas implémenté ainsi
    • On peut l’implémenter avec un booléen en base de données, donc ce n’est qu’un détail d’implémentation
      Le principal intérêt des feature flags, c’est qu’ils permettent de travailler sur de grosses fonctionnalités qui demanderaient des mois et de nombreux commits, tout en restant sur la branche principale. Pour moi, ça permet un processus de développement plus léger et plus itératif
      Par opposition au fait de maintenir une branche séparée, voire une cible de déploiement distincte, pour une grosse fonctionnalité en cours de développement

  • Les feature flags sont souvent trop surconçus
    Il suffit de vérifier une valeur de configuration, une valeur en base de données ou une variable d’environnement, puis d’emprunter dynamiquement un chemin ou un autre
    C’est tout. Il faut soit découper les fonctionnalités plus finement, soit refactorer le code pour pouvoir les basculer facilement à un niveau élevé
    Si ce n’est pas facile à faire, alors une implémentation complexe de feature flags peut aider à coordonner l’activation d’une fonctionnalité entre plusieurs microservices
    Un dashboard peut aussi être utile s’il y a beaucoup de fonctionnalités
    Mais je considère les deux comme des signaux forts qu’il vaudrait mieux éviter les feature flags. Ils sont plus adaptés à des changements locaux et temporaires ; sinon, la complexité s’accumule et finit par rendre la gestion et la maintenance difficiles

    • Il y a un vrai intérêt à activer une fonctionnalité pour un segment précis, par exemple des utilisateurs italiens à faible revenu, afin d’en mesurer l’impact business ou les performances
      Bien sûr, on ne veut pas qu’un utilisateur perde une fonctionnalité parce qu’il dépasse un seuil de revenu ou traverse une frontière, donc il faut une forme de suivi. L’analytics et le suivi d’erreurs doivent aussi communiquer avec le service de feature flags
      Ce n’est pas de la science des fusées, mais c’est clairement plus complexe qu’une variable d’environnement
    • Le cœur des feature flags, c’est la discipline. Il faut les créer avec un objectif précis, et les supprimer dès qu’ils n’apportent plus de valeur. Le principe KISS s’applique

  • C’est toujours enthousiasmant quand Cloudflare commence à proposer quelque chose pour lequel il fallait auparavant passer par un autre fournisseur. Il y a cette confiance que ce sera solide
    Chez Function, nous utilisions Statsig. Au départ, deux personnes ont commencé à l’utiliser sur un produit, mais en moins de 12 mois, une grande partie du texte produit et des déploiements était pilotée par Statsig
    Statsig propose une évaluation côté client, ce qui permet d’écrire des règles et des déploiements basés sur des concepts internes sans que les serveurs de Statsig aient à traiter les données des utilisateurs
    J’espère que Cloudflare construira ici un produit sophistiqué pour qu’à l’avenir on n’ait plus besoin d’utiliser d’autres produits

    • Je trouve étrange de confier les feature flags à un tiers. Je ne suis pas du genre à vouloir tout construire soi-même, mais les feature flags n’ont jamais posé de gros problèmes à implémenter en interne

  • Je suis un utilisateur ordinaire qui ne connaît pas bien les détails techniques, mais je trouve que Cloudflare est relativement facile à utiliser. J’espère qu’ils continueront sur cette lancée

    • C’est le meilleur bureau d’enregistrement DNS que j’aie utilisé jusqu’à présent