Cloudflare Flagship

 (developers.cloudflare.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare Flagship Cloudflare की feature flag service है, जो code को दोबारा deploy किए बिना application में features की visibility को नियंत्रित करती है
  • flags को targeting rules और percentage-based rollout से परिभाषित किया जाता है, और इन्हें Workers native binding में सीधे evaluate किया जा सकता है
  • यह OpenFeature के साथ compatible है, और @cloudflare/flagship SDK की मदद से Workers, Node.js, और browser में flags evaluate किए जा सकते हैं
  • targeting user attributes, 11 comparison operators, AND/OR grouping, और sequential evaluation को support करता है, और consistent hashing से values स्थिर रखी जाती हैं
  • variations boolean, string, number, और JSON objects को support करती हैं, और Cloudflare dashboard में app unit के आधार पर create, modify, और delete की जाती हैं

मुख्य विशेषताएँ

  • Workers binding

    • Binding reference
    • Workers की native binding के रूप में flags evaluate किए जाते हैं
    • type-safe methods और default value के लिए automatic fallback प्रदान किया जाता है

  • OpenFeature SDK

    • View SDK docs
    • @cloudflare/flagship OpenFeature provider के रूप में Workers, Node.js, और browser में flags evaluate कर सकता है
    • किसी दूसरे flag provider से switch करते समय केवल configuration की एक line बदलनी होती है

  • Targeting rules

    • Learn about targeting
    • user attributes के आधार पर अलग-अलग flag values दी जाती हैं
    • rules 11 comparison operators, logical AND/OR grouping, और sequential evaluation को support करते हैं

  • Percentage-based rollout

    • Learn about rollouts
    • features को user percentage के हिसाब से धीरे-धीरे release किया जा सकता है
    • consistent hashing यह सुनिश्चित करता है कि एक ही user को हमेशा वही flag value मिले

  • Multi-type variations

    • Use Multi-type variations
    • flag variations boolean, string, number, और structured JSON object हो सकती हैं
    • object variation का उपयोग करके पूरे configuration block को एक ही flag के रूप में pass किया जा सकता है

  • Flag management

    • Use Flag management
    • Cloudflare dashboard में flags को create, update, और delete किया जा सकता है
    • flags को apps के रूप में व्यवस्थित किया जाता है, जो project या service से map होते हैं
    • पहला feature flag Get started guide में बनाया जा सकता है

संबंधित Cloudflare सेवाएँ

  • Workers: Cloudflare के global network पर serverless applications बनाए जाते हैं, और Flagship binding के रूप में Workers के साथ native integration देता है
  • KV: Cloudflare के global network में key-value data store किया जाता है, और Flagship इसी infrastructure का उपयोग flag configurations पहुँचाने के लिए करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • 0 network round-trip वाला abstraction को कम करके नहीं आंकना चाहिए। f(feature_name, context) में context को बहुत बारीकी से ट्यून किया जा सकता है—जैसे किसी खास inventory, किसी खास supplier, किसी खास B2B customer के किसी खास user, किसी खास business model subtype, या किसी खास time slot में दिखाना है या नहीं
    अगर आप logic सीधे लिख सकते हैं और उसे constant की तरह तेज़ी से tight loop में चला सकते हैं, तो business agility काफ़ी बढ़ जाती है। अगर लगता है कि कुछ ग्राहकों के लिए copy बदल सकती है, तो उसे configurable code की तरह बनाया जा सकता है, और testing व flags भी स्वाभाविक रूप से साथ आ जाते हैं
    लेकिन ऐसे 0-hop setup के लिए एक परिष्कृत client execution engine चाहिए, और Cloudflare ने यहाँ ऐसा कुछ implement किया है, ऐसा नहीं लगता। memory constraints वाले Workers में यह समझ आता है, लेकिन पारंपरिक infrastructure में यह कम तर्कसंगत लगता है
    Statsig का तरीका काफ़ी पसंद है: यह “Server SDKs hold the entire ruleset of your project in memory...” वाला approach है
    https://docs.statsig.com/sdks/how-evaluation-works
    इसे खुद भी बनाया जा सकता है। हर कुछ सेकंड में background thread में ruleset को कुछ data structures में sync करके reference को atomically swap कर दें। फिर सिर्फ applicable rule dimensions के लिए CRUD interface चाहिए
    लेकिन कौन किस constant candidate को छू सकता है, इस पर governance ज़रूरी है। बड़ी ताकत के साथ बड़ी ज़िम्मेदारी आती है

    • यह पढ़कर वही pattern याद आता है जिसमें feature flags का दुरुपयोग application configuration/customization के रूप में होने लगता है। कई संगठनों में यह anti-pattern पहले से देखा गया है
      feature flags को मैं trunk-based development के साथ QA environment में feature on करने, production में अभी rollout न करने, और PO/PM testing संभव बनाने वाले साधन के रूप में देखता हूँ। trunk-based development बिना जटिल branching strategy के तेज़ और आसान DevOps को सक्षम बनाता है
      दूसरी ओर application configuration, application का हिस्सा है, और business context के अनुसार app को customize करने का क्षेत्र है। इसके लिए कोई framework या tool है या नहीं, पता नहीं, लेकिन दोनों को स्पष्ट रूप से अलग रखना चाहिए
    • implementation खुद मुश्किल नहीं है। Mersenne Twister जैसी किसी चीज़ पर modulo operation चढ़ाने जितना ही है, और हाल के काम में Flipper तथा वैकल्पिक “current flag table state” endpoint ही काफ़ी था
      उसी modulo+random combination की वजह से LaunchDarkly जैसे tools को कई भाषाओं के लिए SDK देने पड़े, और जिन SDKs से मुझे काम करना पड़ा वे उस भाषा के हिसाब से बिल्कुल उपयुक्त नहीं थे। evaluation को edge तक धकेलने के कारण पूरा system ज़रूरत से ज़्यादा जटिल हो गया, ऐसा मुझे लगता है
      व्यवहार में “इस customer के लिए” current flag table को कभी-कभार फिर से fetch कर लेना ही काफ़ी होता है, और यह काफ़ी कम झंझट वाला है। Flipper होने से अब यह सब खुद संभालना नहीं पड़ता, यह अच्छी बात है
    • वह 0-hop setup ज़रूरी नहीं कि बहुत sophisticated हो, और Cloudflare को इसे खुद implement करने की भी ज़रूरत नहीं है। OpenFeature पर निर्भर रहें तो client libraries में एक साधारण targeting rule evaluation engine integrated मिलता है
    • अच्छी सलाह है। मैं यह भी जोड़ूँगा कि feature flags, A/B testing, और authorization—ये तीन अलग concepts हैं। इस लेख की framing उपयोगी लगी
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • हम कंपनी में Statsig का अच्छा उपयोग कर रहे हैं। यह polished है और features भी बहुत हैं। जो tool unused flags को removal candidates के रूप में ढूँढता है, वह काफ़ी अच्छा है
      contract के हिसाब से per-seat pricing थोड़ी कड़ी है, लेकिन संभालने लायक है

  • यह gold-plated Boolean-as-a-service जैसा लगता है

    • मैंने कंपनी में देखा है कि इस तरह का Boolean-as-a-service ठीक से उपलब्ध न कराने पर पूरी टीम असफल हो जाती है। LaunchDarkly जैसी कंपनियाँ अलग से मौजूद हैं, उसके पीछे वजह है
      अगर इस तरह सरल बना दें, तो दुनिया की हर service को bits-as-a-service कहकर घटाया जा सकता है। असल में इन चीज़ों की वैध business value होती है, और इन्हें उपलब्ध कराने की प्रक्रिया में जटिलता भी होती है
    • मुझे यह ठीक लगता है। मैं database में हज़ारों feature flags track नहीं करना चाहता, और न ही admin dashboard बनाना चाहता हूँ
      किसी भी SaaS tool को “excel-as-a-service” कहा जा सकता है, और यह उसी तरह का बेअसर वर्णन है
    • उस Boolean को सही समय पर सही जगह तक विश्वसनीय तरीके से पहुँचाना कोई मामूली बात नहीं है

  • JS SDK docs में यह warning है: “क्लाइंट provider को flag values लाने के लिए API token चाहिए। यह token किसी एक app तक सीमित नहीं है, इसलिए token रखने वाला कोई भी व्यक्ति account के सभी apps के flags evaluate कर सकता है। public applications में इसे सावधानी से इस्तेमाल करें”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    browser में deploy होने के लिए डिज़ाइन किए गए client SDK के लिए यह सावधानी क्यों ज़रूरी है, यह जानना दिलचस्प है। क्या इसका मतलब यह है कि कोई भी client नया targetingKey भेजकर दूसरे users के flags देख सकता है?
    flags में महत्वपूर्ण जानकारी नहीं होनी चाहिए, लेकिन यह एक दिलचस्प design choice लगती है

    • शायद यह Cloudflare के अंदर इस्तेमाल हो रहा था और किसी ने सोचा होगा कि इसे public कर दिया जाए तो मज़ेदार होगा
      ऐसा नहीं लगता कि 6 महीने पहले Cloudflare ने गंभीरता से तय किया होगा कि LaunchDarkly का competitor बनाना है
    • मैं Flagship टीम का engineer हूँ। app-scoped token पर काम चल रहा है

  • यह अच्छा है, लेकिन विडंबना यह है कि शायद Flagship के ज़रिए मिलने वाली इस सुविधा का मैं अभी भी इंतज़ार कर रहा हूँ
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    अभी तक ऐसा लगता है कि enterprise-only सुविधाएँ नीचे के paid accounts तक आई ही नहीं हैं
    खास तौर पर मेरी रुचि इसमें है:
    https://developers.cloudflare.com/speed/optimization/content...

    • सही है। Zero Trust enterprise features की इतनी ज़रूरत है कि अब शायद enterprise sales प्रतिनिधि से सीधे बात करनी पड़ेगी। इसमें बहुत समय जाएगा और ऐसा stress पैदा होगा जिससे बचना चाहता हूँ

  • आजकल Cloudflare अच्छा काम कर रहा है, लेकिन granular permission management की कमी है। अभी भी production environment के लिए पूरी तरह अलग account बनाना पड़ता है, और एक domain सिर्फ एक ही account से बंध सकता है, इसलिए SSO उलझ जाता है

    • प्रोडक्ट शानदार है और मैं लंबे समय तक इसे संतोष के साथ इस्तेमाल करता रहा हूँ, लेकिन हाल के blog posts में कुछ बार गलतियाँ हुई हैं। reliability भी कुछ समय तक डगमगाती लगी, हालांकि हाल में थोड़ा बेहतर हुआ है
    • कई साल AWS इस्तेमाल करने के बाद Cloudflare आज़माया था और user experience पसंद आया, लेकिन इसी चिंता की वजह से आखिरकार वापस लौट गया। सच में लगभग वहाँ तक पहुँच चुके हैं, बस थोड़ी कमी रह गई
    • कुछ साल पहले मैंने अपने सभी projects Cloudflare पर migrate कर दिए थे और उसका पछतावा नहीं है। मैं Workers, D1, R2, Queues, Containers, KV इस्तेमाल कर रहा हूँ
      email भेजने के लिए अभी भी AWS इस्तेमाल करता हूँ, इसलिए अच्छा होगा अगर Cloudflare की तरफ़ से भी यह आ जाए
    • मैंने भी आज more granular permissions के लिए support ticket खोला है
    • यही बिल्कुल वह कारण है जो मुझे असली काम में Cloudflare इस्तेमाल करने से रोकता है। hobby के लिए free tier पसंद है

  • OpenFeature के बारे में पहली बार सुन रहा हूँ, बढ़िया लग रहा है। क्या किसी ने इसे integrate किया है? https://openfeature.dev

    • मैंने OpenFeature काफ़ी इस्तेमाल किया है, और कुछ client libraries में शुरुआती commits भी किए थे। यह feature flags का भविष्य है, और इसका ecosystem भी तेज़ी से बढ़ रहा है
      पारदर्शिता के लिए बता दूँ, मैं Flagsmith का CTO हूँ। पिछले कुछ वर्षों में OpenFeature adoption का काफ़ी स्पष्ट बढ़ता हुआ curve देखा है। पहले हम ग्राहकों को इसे आज़माने की सलाह देते थे, लेकिन अब ग्राहक खुद OpenFeature को requirement के रूप में लेकर आते हैं
      अब vendor support भी काफ़ी mature हो चुका है और लगभग सभी भाषाओं को cover करता है। अगर आप किसी नई service में feature flags integrate करना चाहते हैं, या अपने in-house implementation से third-party solution पर जाना चाहते हैं, तो मैं OpenFeature की सिफारिश करूँगा
    • काफ़ी उपयोगी है। पिछली कंपनी में हमने इसका इस्तेमाल किया था, और custom backend बनाया था लेकिन spec और SDK के लिए OpenFeature इस्तेमाल किया था
      पूरी तरह custom backend बनाने में लगभग 2 हफ़्ते लगे। कई भाषाओं के SDK भी बिना समस्या के काम कर रहे थे। एक bug मिला था, लेकिन report करते ही उसी दिन ठीक कर दिया गया

  • मैं feature flags को ठीक से समझ नहीं पा रहा हूँ। database के Boolean से मूल रूप से यह अलग कैसे है?

    • flag खुद Boolean हो, string हो, number हो या कुछ और — वह आसान हिस्सा है। मुश्किल हिस्सा है targeting और rollout rules, यानी किसे कौन सा flag दिखेगा, और उन rules को बहुत तेज़ी और लगातार एकसमान तरीके से evaluate करने की ज़रूरत
      जो टीमें इसे खुद बनाती हैं, वे आम तौर पर तब जल्दी मुश्किल में फँस जाती हैं जब product management, marketing, और sales ज़्यादा जटिल rules के साथ targeting करना चाहते हैं
      कुल मिलाकर यह कोई असाधारण रूप से कठिन समस्या नहीं है, लेकिन इसका scale बड़ा है। शुरुआत में बहुत सी ऐसी चीज़ें चाहिए होती हैं जो दिखाई नहीं देतीं
      feature flags को मूल रूप से permissions system के क़रीब समझा जा सकता है। यह कुछ खास users को कुछ खास features तक पहुँच देने की बात है, और जिसने भी permissions system संभाला है, वह जानता है कि group membership, hierarchical groups, roles, ACL आदि कितने जटिल हो सकते हैं। ये सब feature flag system के अलग-अलग targeting rules जैसे ही हैं
    • percentage rollout, RBAC, audit history, A/B testing, और multivariate configuration जुड़ते ही चीज़ें तेज़ी से जटिल हो जाती हैं। वह एक Boolean जल्दी ही एक पूरे system में बदल जाता है जिसे maintain और operate करना पड़ता है
    • विस्तार से यहाँ लिखा है: https://martinfowler.com/articles/feature-toggles.html
    • यह हमेशा Boolean नहीं होता। उदाहरण के लिए feature flags का इस्तेमाल अक्सर A/B rollout में होता है
      Cloudflare भी आंतरिक रूप से नए features या builds को पहले free customers तक rollout करता है, और stabilization period के बाद धीरे-धीरे बड़े customers तक फैलाता है
      feature flags को एक तरह के fuzz test की तरह random तरीके से भी on किया जा सकता है। इसे सिर्फ “कुछ नया” मत समझिए, यह “व्यवहार में बदलाव” भी हो सकता है
      आप इसे सभी clients के ऊपर एक Boolean की तरह सोच सकते हैं, लेकिन आम तौर पर इसे उस तरह implement नहीं किया जाता
    • इसे database के Boolean से implement किया जा सकता है, इसलिए वह सिर्फ implementation detail है
      feature flags की मुख्य खूबी यह है कि वे कई महीनों और बहुत सारे commits लेने वाले बड़े features पर भी main branch में काम करना संभव बनाते हैं। मेरे लिए यह एक हल्का और ज़्यादा iterative development process बनाता है
      यह अलग branch बनाए रखने और बड़े development-in-progress features के लिए अलग deployment targets रखने के तरीके के विपरीत है

  • feature flags को अक्सर ज़रूरत से ज़्यादा overengineer किया जाता है
    बस configuration value, database value, या environment variable देखकर dynamic रूप से एक path या दूसरे path पर जाना होता है
    बात इतनी ही है। features को छोटा बनाना चाहिए, या code को इस तरह refactor करना चाहिए कि ऊँचे स्तर पर आसानी से switch किया जा सके
    अगर ऐसा आसानी से नहीं हो सकता, तो microservices के बीच feature activation coordinate करने के लिए जटिल feature flag implementation मददगार हो सकता है
    अगर features बहुत ज़्यादा हों, तो dashboard भी उपयोगी हो सकता है
    लेकिन मेरे हिसाब से ये दोनों ही इस बात के मज़बूत संकेत हैं कि feature flags से बचना चाहिए। feature flags local और temporary बदलावों के लिए ज़्यादा उपयुक्त हैं, वरना complexity जमा होती जाती है और management व maintenance कठिन हो जाते हैं

    • किसी खास segment, जैसे इटली के low-revenue users, के लिए feature on करके business या performance impact देखना वाजिब है
      बेशक, आप यह नहीं चाहेंगे कि user revenue threshold पार करते ही या border पार करते ही feature खो दे, इसलिए किसी न किसी तरह का tracking implementation चाहिए। analytics और error tracking को भी feature flag service से बात करनी होगी
      यह rocket science नहीं है, लेकिन environment variable से निश्चित रूप से ज़्यादा जटिल है
    • feature flags की असली कुंजी है discipline। इन्हें उद्देश्य के साथ बनाइए, और जब इनकी value ख़त्म हो जाए तो तुरंत हटा दीजिए। यहाँ KISS लागू होता है

  • जब Cloudflare उन चीज़ों को देना शुरू करता है जिनके लिए पहले दूसरे provider का इस्तेमाल करना पड़ता था, तो हमेशा उत्साह होता है। इस बात पर भरोसा रहता है कि यह मज़बूत होगा
    Function में Statsig का इस्तेमाल किया था। शुरुआत में एक product में दो लोगों ने इसका इस्तेमाल शुरू किया था, लेकिन 12 महीनों के भीतर product copy और rollout का बड़ा हिस्सा Statsig से चलने लगा
    Statsig में client-side evaluation है, इसलिए Statsig server को user data process किए बिना भी internal concepts के आधार पर rules और rollout लिखे जा सकते हैं
    उम्मीद है Cloudflare यहाँ एक परिष्कृत product बनाएगा ताकि आगे दूसरे products का इस्तेमाल न करना पड़े

    • feature flags को third party को सौंपना अजीब लगता है। मैं हर चीज़ खुद बनाने वाला नहीं हूँ, लेकिन feature flags को खुद बनाने में कोई बड़ी समस्या नहीं थी

  • मैं तकनीकी बारीकियाँ अच्छी तरह नहीं जानने वाला एक सामान्य user हूँ, लेकिन Cloudflare मुझे इस्तेमाल करने में काफ़ी आसान लगता है। उम्मीद है यह अच्छा काम जारी रखेगा

    • अब तक इस्तेमाल किए गए DNS registrar में सबसे अच्छा है