Cloudflare Flagship

 (developers.cloudflare.com)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Cloudflare Flagship, kodu yeniden dağıtmadan uygulamadaki özelliklerin görünürlüğünü kontrol eden Cloudflare özellik bayrağı hizmetidir
  • Bayraklar, hedefleme kuralları ve oran tabanlı rollout ile tanımlanır; Workers yerel binding’i içinden doğrudan değerlendirilebilir
  • OpenFeature ile uyumludur ve @cloudflare/flagship SDK’sı ile Workers, Node.js ve tarayıcıda bayraklar değerlendirilebilir
  • Hedefleme; kullanıcı özellikleri, 11 karşılaştırma operatörü, AND/OR gruplama ve sıralı değerlendirmeyi destekler; tutarlı hashing ile değerleri sabit tutar
  • Varyasyonlar boolean, string, sayı ve JSON nesnesi destekler; Cloudflare Dashboard’da uygulama bazında oluşturulur, düzenlenir ve silinir

Başlıca özellikler

  • Workers binding

    • Binding reference
    • Bayraklar, Workers’ın yerel binding’i ile değerlendirilir
    • Tip güvenli metotlar ve varsayılan değere otomatik fallback sunar

  • OpenFeature SDK

    • View SDK docs
    • @cloudflare/flagship OpenFeature provider’ı ile Workers, Node.js ve tarayıcıda bayraklar değerlendirilebilir
    • Başka bir bayrak sağlayıcısından geçerken yalnızca tek satırlık yapılandırma değişikliği yeterlidir

  • Hedefleme kuralları

    • Learn about targeting
    • Kullanıcı özelliklerine göre farklı bayrak değerleri sunar
    • Kurallar, 11 karşılaştırma operatörü, mantıksal AND/OR gruplama ve sıralı değerlendirmeyi destekler

  • Oran tabanlı rollout

    • Learn about rollouts
    • Özellikleri kullanıcı oranına göre kademeli olarak yayına alabilirsiniz
    • Tutarlı hashing, aynı kullanıcının her zaman aynı bayrak değerini almasını garanti eder

  • Çok tipli varyasyonlar

    • Use Multi-type variations
    • Bayrak varyasyonları boolean, string, sayı veya yapılandırılmış JSON nesnesi olabilir
    • Nesne varyasyonları kullanıldığında tüm ayar bloğu tek bir bayrak üzerinden aktarılabilir

  • Bayrak yönetimi

    • Use Flag management
    • Bayraklar Cloudflare Dashboard üzerinden oluşturulabilir, güncellenebilir ve silinebilir
    • Bayraklar, projelere veya servislere eşlenen uygulamalar olarak düzenlenir
    • İlk özellik bayrağı Get started guide üzerinden oluşturulabilir

İlgili Cloudflare hizmetleri

  • Workers: Cloudflare’in küresel ağı üzerinde sunucusuz uygulamalar oluşturur; Flagship, binding aracılığıyla Workers ile yerel olarak entegredir
  • KV: Cloudflare’in küresel ağı genelinde anahtar-değer verisi depolar; Flagship, bayrak yapılandırmalarını dağıtmak için bu altyapıyı kullanır

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • 0 ağ gidiş-dönüşlü bir soyutlamayı küçümsememek gerekir. f(feature_name, context) üzerinde bağlam; belirli bir envantere, belirli bir tedarikçiye, belirli bir B2B müşterisinin belirli bir kullanıcısına, belirli bir iş modeli alt türüne, hatta belirli bir zaman diliminde gösterilip gösterilmeyeceğine kadar çok ince ayarlanabilir
    Mantığı doğrudan yazıp bunu sıkı döngüler içinde sabitmiş gibi hızlı çalıştırabilirseniz, iş çevikliği ciddi biçimde artar. Bazı müşteriler için metnin değişebileceğini düşünüyorsanız, bunu yapılandırılabilir olacak şekilde kodlayabilirsiniz; testler ve bayraklar da doğal olarak beraberinde gelir
    Ancak bu tür 0-hop yapılarda gelişmiş bir istemci yürütme motoru gerekir; Cloudflare'ın burada bunu uygulamış gibi görünmediğini düşünüyorum. Bellek kısıtlı Workers için anlaşılır, ama geleneksel altyapıda daha az ikna edici
    Statsig yaklaşımını epey beğeniyorum: “Server SDKs hold the entire ruleset of your project in memory...” yaklaşımını benimsiyor
    https://docs.statsig.com/sdks/how-evaluation-works
    Bunu kendiniz de yapabilirsiniz. Arka plan iş parçacığında her birkaç saniyede bir kural kümesini birkaç veri yapısına senkronize edip referansı atomik olarak değiştirmek yeterli. Sonrasında sadece uygulanan kural boyutu için bir CRUD arayüzüne ihtiyaç var
    Ancak kimlerin hangi sabit adaylarına dokunabileceğine dair yönetişim mutlaka gerekli. Büyük güç büyük sorumluluk getirir

    • Bunu okuyunca, özellik bayraklarının uygulama yapılandırması/özelleştirmesi olarak kötüye kullanıldığı örüntü aklıma geliyor. Bunu birçok organizasyonda gözlemledim; bilinen bir anti-pattern
      Bana göre özellik bayrakları daha çok trunk tabanlı geliştirmeyle birlikte, QA ortamında özellikleri açmak, üretime henüz çıkarmamak ve PO/PM testini mümkün kılmak içindir. Trunk tabanlı geliştirme, karmaşık dal stratejileri olmadan hızlı ve kolay DevOps sağlar
      Buna karşılık uygulama yapılandırması, uygulamanın bir parçasıdır ve iş bağlamına göre uygulamayı özelleştirme alanıdır. Bununla ilgili çerçeveler ya da araçlar var mı bilmiyorum, ama ikisini net biçimde ayırmak gerekir
    • Uygulamanın kendisi zor değil. Mersenne Twister gibi bir şeyin üstüne modüler aritmetik eklemek kadar basit; son işimde Flipper ve isteğe bağlı bir “mevcut bayrak tablosu durumu” endpoint'i yeterli olmuştu
      İşte bu modüler aritmetik + rastgelelik kombinasyonu yüzünden LaunchDarkly gibi araçların birçok dil için SDK sunması gerekti ve benim uğraştığım SDK'ler ilgili dillere hiç iyi uymuyordu. Değerlendirmeyi edge'e itmenin tüm sistemi gereğinden fazla karmaşıklaştırdığını düşünüyorum
      Gerçekte arada sırada “bu müşteri için” geçerli olan mevcut bayrak tablosunu yeniden çekmek yeterli oluyor ve çok daha az can sıkıcı. Flipper olduğu için artık bunlarla elle uğraşmak zorunda olmamak güzel
    • O 0-hop yapının ille de gelişmiş olması gerekmez ve Cloudflare'ın bunu bizzat uygulaması da şart değil. OpenFeature kullanırsanız, istemci kütüphanelerine basit bir hedefleme kuralı değerlendirme motoru entegre edilmiş durumda
    • İyi bir tavsiye. Şunu da ekleyeyim: özellik bayrakları, A/B testleri ve yetkilendirme birbirinden farklı üç kavramdır. Bu yazının çerçevelemesi faydalıydı
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • Şirkette Statsig'i verimli kullanıyoruz. Olgun ve özellik açısından zengin bir ürün. Kullanılmayan bayrakları kaldırma adayı olarak bulan araçları oldukça iyi
      Sözleşmeye bağlı koltuk başı ücretlendirme biraz sert ama yönetilebilir düzeyde

  • yaldızlı bir Boolean-as-a-service gibi duruyor

    • Şirkette böyle bir Boolean-as-a-service'i düzgün sunamadıkları için tüm ekibin başarısız olduğunu gördüm. LaunchDarkly gibi şirketlerin ayrı bir iş olarak var olmasının bir nedeni var
      Böyle basitleştirirseniz dünyadaki tüm servisleri bits-as-a-service'e indirgemek mümkün. Gerçekte bunların meşru bir iş değeri var ve sunulmaları da karmaşık
    • Bence gayet makul. Veritabanında binlerce özellik bayrağını takip etmek ve bir yönetici panosu yapmak istemem
      Herhangi bir SaaS aracına “excel-as-a-service” diyebilirsiniz; etkisi ancak o kadar olur
    • O Boolean'ı doğru zamanda doğru yere güvenilir biçimde ulaştırmak hiç de önemsiz değil

  • JS SDK belgelerinde şu uyarı var: “İstemci provider'ı, bayrak değerlerini almak için bir API token'ına ihtiyaç duyar. Bu token tek bir uygulamayla sınırlı değildir, dolayısıyla token'a sahip olan herkes hesaptaki tüm uygulamaların bayraklarını değerlendirebilir. Herkese açık uygulamalarda dikkatli kullanın”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    Tarayıcıya dağıtılmak üzere tasarlanmış bir istemci SDK'sının neden dikkat gerektirdiğini merak ediyorum. Bu, herhangi bir istemcinin yeni bir targetingKey ile istek gönderip başka kullanıcıların bayraklarını gözlemleyebileceği anlamına mı geliyor?
    Bayraklar önemli bilgi taşımamalı elbette, ama ilginç bir tasarım tercihi gibi görünüyor

    • Muhtemelen Cloudflare içinde kullanılan bir şeyi birilerinin kamuya açmasının eğlenceli olacağını düşündüler
      6 ay önce Cloudflare'ın LaunchDarkly rakibi yapmaya ciddi ciddi karar vermiş olması bana pek olası gelmiyor
    • Flagship ekibinden bir mühendisim. Uygulama kapsamlı token'lar üzerinde çalışıyoruz

  • Bu iyi, ama ironik bir şekilde muhtemelen Flagship kullanılarak sunulacak bu özelliğin çıkmasını hâlâ bekliyorum
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    Kurumsala özel özelliklerin alt ücretli hesaplara indiği tek bir örnek bile henüz yok gibi görünüyor
    Özellikle ilgilendiğim şey şu:
    https://developers.cloudflare.com/speed/optimization/content...

    • Aynen. Zero Trust kurumsal özelliklerine o kadar çok ihtiyacım var ki sonunda doğrudan kurumsal satış temsilcisiyle konuşmak zorunda kalacağım. Zaman alacak ve kaçınmak istediğim bir stres yaratacak gibi duruyor

  • Cloudflare son zamanlarda iyi işler çıkarıyor, ama ayrıntılı yetki yönetimi eksik. Hâlâ üretim ortamı için tamamen ayrı bir hesap oluşturmak gerekiyor ve bir alan adı yalnızca tek bir hesaba bağlı olabildiği için SSO karışıyor

    • Ürün harika ve uzun süre memnuniyetle kullandım, ama son blog yazılarında birkaç kez hata oldu. Güvenilirlik de bir süre sallanıyor gibiydi, ama son zamanlarda biraz düzelmiş gibi görünüyor
    • AWS’yi birkaç yıl kullandıktan sonra Cloudflare’ı denedim ve kullanıcı deneyimini beğendim, ama aynı endişeler yüzünden sonunda geri döndüm. Gerçekten neredeyse olmuş, ama eksik kalıyor
    • Birkaç yıl önce tüm projelerimi Cloudflare’a taşıdım ve pişman değilim. Workers, D1, R2, Queues, Containers, KV kullanıyorum
      E-posta gönderimi için hâlâ AWS kullanıyorum; Cloudflare tarafında da gelirse güzel olur
    • Ben de bugün daha ayrıntılı yetkiler istemek için bir destek talebi açtım
    • Bu, Cloudflare’ı gerçek işte kullanamamamın tam nedeni. Hobi amaçlı ücretsiz katmanını seviyorum

  • OpenFeature’ı ilk kez görüyorum, harika görünüyor. Bunu entegre etme deneyimi olan var mı? https://openfeature.dev

    • OpenFeature’ı epey kullandım ve birkaç istemci kütüphanesine ilk commit’leri de attım. Özellik bayraklarının geleceği gerçekten bu ve ekosistem de hızla büyüyor
      Şeffaf olmak gerekirse Flagsmith’in CTO’suyum. Son birkaç yılda OpenFeature benimsenmesinde net bir artış eğrisi gördüm. Eskiden müşterilere denemelerini biz önerirdik, şimdi ise müşteriler OpenFeature’ı gereksinim olarak getiriyor
      Artık üretici desteği de oldukça olgun ve neredeyse tüm dilleri kapsıyor. Yeni bir servise özellik bayrakları entegre ediyorsanız ya da kendi çözümünüzden üçüncü taraf bir çözüme geçmeyi düşünüyorsanız OpenFeature’ı tavsiye ederim
    • Oldukça kullanışlı. Önceki şirkette kullandık; özel bir backend oluşturduk ama spesifikasyon ve SDK olarak OpenFeature kullandık
      Tamamen özel bir backend oluşturmak yaklaşık 2 hafta sürdü. Farklı diller için SDK’lar da sorunsuz çalıştı. Bir hata buldum ama bildirince aynı gün düzeltildi

  • Özellik bayraklarını pek anlayamıyorum. Veritabanındaki bir Boolean’dan temelde farkı ne?

    • Bayrağın kendisinin Boolean, string, sayı ya da başka bir şey olması kolay kısmı. Zor olan, hedefleme ve rollout kuralları; yani kimin hangi bayrağı göreceği ve bu kuralların çok hızlı ve tutarlı biçimde değerlendirilmesi gerekliliği
      Kendi sistemini yapan ekipler genelde ürün yönetimi, pazarlama ve satışın daha karmaşık kurallarla hedefleme yapmak istemesiyle işlerin hızla büyüdüğünü görüyor
      Genel zorluk seviyesi açısından özellikle zor bir problem değil, ama kapsamı büyük. Başta görünmeyen çok sayıda özellik gerekiyor
      Özellik bayrakları özünde bir yetkilendirme sistemine daha yakın sayılabilir. Belirli kullanıcıların belirli özelliklere erişmesine izin verirsiniz ve yetkilendirme sistemiyle uğraşmış olan herkes grup üyeliği, hiyerarşik gruplar, roller, ACL’ler gibi şeylerin ne kadar karmaşıklaşabildiğini bilir. Bunlar, özellik bayrağı sistemindeki çeşitli hedefleme kurallarına benzer
    • Yüzdesel rollout, RBAC, denetim geçmişi, A/B testi ve çok değişkenli yapılandırmalar işin içine girince konu hızla karmaşıklaşıyor. O tek Boolean, işletmeniz ve bakımını yapmanız gereken bir sistemin tamamına dönüşüyor
    • Ayrıntılı bir yazı burada: https://martinfowler.com/articles/feature-toggles.html
    • Her zaman Boolean olmaz. Örneğin özellik bayrakları sıkça A/B rollout için kullanılır
      Cloudflare da içeride yeni özellikleri ya da build’leri önce ücretsiz müşterilere verip, bir stabilizasyon döneminden sonra daha büyük müşterilere kademeli olarak genişletmek için kullanıyor
      Özellik bayrakları bir tür fuzz testi gibi rastgele de açılabilir. Bunu yalnızca “yeni bir şey” olarak değil, “davranış değişikliği” olarak da düşünebilirsiniz
      Bunu tüm istemcilerin üstünde duran bir Boolean gibi düşünebilirsiniz, ama genelde uygulama böyle olmaz
    • Bunu veritabanındaki bir Boolean ile uygulayabilirsiniz; bu sadece bir uygulama detayıdır
      Özellik bayraklarının asıl çekiciliği, aylar ve çok sayıda commit gerektiren büyük bir özelliğin bile ana branch üzerinde geliştirilebilmesini sağlamasıdır. Benim için daha hafif ve yinelemeli bir geliştirme süreci yaratıyor
      Bu, ayrı branch’ler sürdürmeye ve büyük geliştirmeler sırasındaki özellikler için ayrı dağıtım hedefleri bulundurmaya kıyasla daha iyi

  • Özellik bayrakları çoğu zaman gereğinden fazla mühendislik ürünü hâline getiriliyor
    Bir yapılandırma değerine, veritabanı değerine ya da ortam değişkenine bakıp dinamik olarak bir yola ya da diğerine gitmeniz yeterli
    Hepsi bu. Özellikleri küçük yapmalı ya da kodu üst seviyede kolayca açılıp kapatılabilecek şekilde refactor etmelisiniz
    Bunu kolayca yapamıyorsanız, mikroservisler arasında özellik etkinleştirmesini koordine etmek için karmaşık özellik bayrağı uygulamaları yardımcı olabilir
    Çok sayıda özelliğiniz varsa bir dashboard da faydalı olabilir
    Ama bence bunların ikisi de özellik bayraklarından kaçınmanız gerektiğine dair güçlü işaretlerdir. Özellik bayrakları yerel ve geçici değişiklikler için daha uygundur; aksi hâlde karmaşıklık birikir ve yönetimiyle bakımı zorlaşır

    • Belirli bir segment için, örneğin İtalya’daki düşük gelirli kullanıcılar için özelliği açıp iş ya da performans etkisini görmek mantıklı olabilir
      Tabii kullanıcı gelir eşiğini geçti diye ya da sınırı aştı diye özelliği kaybetmesini istemezsiniz; dolayısıyla bir tür izleme uygulaması gerekir. Analitik ve hata takibi de özellik bayrağı servisiyle iletişim kurmak zorundadır
      Bu roket bilimi değil, ama ortam değişkenlerinden kesinlikle daha karmaşık
    • Özellik bayraklarının anahtarı disiplindir. Amaca yönelik oluşturulmalı ve artık değer üretmiyorsa hemen kaldırılmalıdır. KISS burada da geçerlidir

  • Cloudflare daha önce mevcutta başka sağlayıcıların kullanılması gereken bir şeyi sunmaya başladığında her zaman heyecan verici oluyor. Sağlam olacağına dair bir güven var
    Function tarafında Statsig kullandık. Başta tek bir üründe iki kişi kullanmaya başlamıştı, ancak 12 ay içinde ürün metninin ve rollout’ların önemli bir kısmı Statsig tarafından çalışır hale geldi
    Statsig’de istemci tarafı değerlendirme var; bu sayede Statsig sunucuları kullanıcı verilerini işlemeden de dahili kavramlara dayalı olarak kurallar ve rollout’lar yazılabiliyor
    Umarım Cloudflare burada sofistike bir ürün ortaya koyar da bundan sonra başka bir ürün kullanmak zorunda kalmayız

    • Özellik bayraklarını üçüncü bir tarafa emanet etmek bana garip geliyor. Her şeyi kendimiz yapalım tarafında değilim ama özellik bayraklarını kendimiz yapmak büyük bir sorun olmamıştı

  • Teknik ayrıntıları çok bilmeyen sıradan bir kullanıcıyım ama Cloudflare bana görece kullanımı kolay geliyor. Umarım böyle devam eder

    • Şimdiye kadar kullandığım DNS kayıt operatörleri arasında en iyisi