Cloudflare Flagship

 (developers.cloudflare.com)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Cloudflare Flagship adalah layanan feature flag dari Cloudflare untuk mengontrol eksposur fitur aplikasi tanpa redeploy kode
  • Flag didefinisikan dengan aturan penargetan dan rollout berbasis persentase, serta dapat dievaluasi langsung dari binding native Workers
  • Kompatibel dengan OpenFeature dan flag dapat dievaluasi di Workers, Node.js, dan browser dengan SDK @cloudflare/flagship
  • Penargetan mendukung atribut pengguna, 11 operator perbandingan, pengelompokan AND/OR, dan evaluasi berurutan, serta mempertahankan nilai dengan hashing konsisten
  • Variasi mendukung boolean, string, angka, dan objek JSON, serta dapat dibuat, diubah, dan dihapus per aplikasi di dashboard Cloudflare

Fitur utama

  • Binding Workers

    • Binding reference
    • Mengevaluasi flag dengan binding native di Workers
    • Menyediakan metode type-safe dan fallback otomatis ke nilai default

  • SDK OpenFeature

    • View SDK docs
    • Dengan provider OpenFeature @cloudflare/flagship, flag dapat dievaluasi di Workers, Node.js, dan browser
    • Saat berpindah dari penyedia flag lain, cukup ubah satu baris konfigurasi

  • Aturan penargetan

    • Learn about targeting
    • Menyediakan nilai flag yang berbeda berdasarkan atribut pengguna
    • Aturan mendukung 11 operator perbandingan, pengelompokan logis AND/OR, dan evaluasi berurutan

  • Rollout berbasis persentase

    • Learn about rollouts
    • Fitur dapat dirilis secara bertahap sesuai persentase pengguna
    • Hashing konsisten menjamin pengguna yang sama selalu menerima nilai flag yang sama

  • Variasi multi-tipe

    • Use Multi-type variations
    • Variasi flag dapat berupa boolean, string, angka, atau objek JSON terstruktur
    • Dengan variasi objek, satu blok konfigurasi utuh dapat dikirim melalui satu flag

  • Manajemen flag

    • Use Flag management
    • Flag dapat dibuat, diperbarui, dan dihapus di dashboard Cloudflare
    • Flag disusun sebagai aplikasi yang dipetakan ke proyek atau layanan
    • Feature flag pertama dapat dibuat melalui Get started guide

Layanan Cloudflare terkait

  • Workers: Membangun aplikasi serverless di jaringan global Cloudflare, dan Flagship terintegrasi secara native dengan Workers melalui binding
  • KV: Menyimpan data key-value di seluruh jaringan global Cloudflare, dan Flagship menggunakan infrastruktur ini untuk mendistribusikan konfigurasi flag

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Jangan meremehkan abstraksi dengan 0 network round-trip. Di atas f(feature_name, context), konteks bisa disesuaikan sangat rinci hingga inventaris tertentu, pemasok tertentu, pengguna tertentu dari pelanggan B2B tertentu, subtipe model bisnis tertentu, bahkan apakah sesuatu ditampilkan pada slot waktu tertentu
    Jika logikanya ditulis langsung dan bisa dijalankan secepat konstanta di dalam tight loop, kelincahan bisnis bisa meningkat besar. Jika terasa bahwa teks bisa berubah untuk sebagian pelanggan, cukup jadikan itu dapat dikonfigurasi lewat kode, lalu testing dan flag akan mengikuti secara alami
    Namun, konfigurasi 0-hop seperti ini memerlukan client execution engine yang canggih, dan tampaknya Cloudflare tidak benar-benar mengimplementasikannya di sini. Untuk Workers yang punya keterbatasan memori ini bisa dipahami, tetapi untuk infrastruktur tradisional terasa kurang meyakinkan
    Saya cukup suka pendekatan Statsig: “Server SDKs hold the entire ruleset of your project in memory...”
    https://docs.statsig.com/sdks/how-evaluation-works
    Ini juga bisa dibuat sendiri. Cukup sinkronkan kumpulan aturan ke beberapa struktur data dari background thread setiap beberapa detik lalu tukar referensinya secara atomik. Setelah itu, yang dibutuhkan hanya antarmuka CRUD untuk dimensi aturan yang berlaku
    Tapi, governance tentang siapa yang boleh menyentuh kandidat konstanta tertentu tetap wajib ada. Dengan kekuatan besar datang tanggung jawab besar

    • Membaca ini mengingatkan saya pada pola feature flag yang disalahgunakan sebagai konfigurasi/kustomisasi aplikasi. Ini antipola yang sudah saya lihat di banyak organisasi
      Feature flag lebih cocok untuk menyalakan fitur di lingkungan QA bersama trunk-based development, belum merilisnya ke production, dan memungkinkan pengujian oleh PO/PM. Trunk-based development memungkinkan DevOps yang cepat dan mudah tanpa strategi branching yang rumit
      Sebaliknya, konfigurasi aplikasi adalah bagian dari aplikasi itu sendiri, dan merupakan area untuk menyesuaikan aplikasi dengan konteks bisnis. Saya tidak tahu apakah ada framework atau alat terkait, tetapi keduanya harus dipisahkan dengan jelas
    • Implementasinya sendiri tidak sulit. Ini pada dasarnya hanya Mersenne Twister plus operasi modulo, dan dalam pekerjaan terbaru saya, Flipper bersama endpoint opsional “current flag table state” saja sudah cukup
      Karena kombinasi modulo+acak itu, alat seperti LaunchDarkly harus menyediakan SDK untuk banyak bahasa, dan SDK yang harus saya tangani sama sekali tidak terasa cocok untuk bahasa tersebut. Menurut saya, mendorong evaluasi ke edge membuat keseluruhan sistem menjadi lebih kompleks dari yang perlu
      Dalam praktiknya, cukup sesekali mengambil ulang tabel flag saat ini “untuk pelanggan ini”, dan itu jauh lebih tidak merepotkan. Untungnya sekarang ada Flipper jadi saya tidak perlu menangani hal seperti ini sendiri
    • Konfigurasi 0-hop itu juga tidak harus canggih, dan Cloudflare tidak perlu mengimplementasikannya sendiri. Dengan mengandalkan OpenFeature, engine evaluasi aturan targeting sederhana sudah terintegrasi ke library klien
    • Saran yang bagus. Sebagai tambahan, feature flag, A/B testing, dan authorization adalah tiga konsep yang berbeda. Framing di tulisan ini cukup membantu
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • Kami memakai Statsig dengan baik di perusahaan. Matang dan fiturnya kaya. Alatnya untuk menemukan flag yang tidak dipakai lagi sebagai kandidat penghapusan cukup bagus
      Secara kontrak, penagihan per seat memang agak berat, tapi masih bisa ditoleransi

  • Terasa seperti Boolean-as-a-service yang diberi lapisan emas

    • Saya pernah melihat seluruh tim gagal karena perusahaan tidak mampu menyediakan Boolean-as-a-service semacam ini dengan baik. Ada alasan mengapa perusahaan seperti LaunchDarkly eksis secara khusus
      Kalau disederhanakan seperti itu, semua layanan di dunia juga bisa direduksi menjadi bits-as-a-service. Kenyataannya, ada nilai bisnis yang sah dalam hal-hal seperti ini, dan ada kompleksitas dalam penyediaannya
    • Menurut saya ini masuk akal. Saya tidak ingin melacak ribuan feature flag di database dan membuat dashboard admin
      Alat SaaS apa pun bisa disebut “excel-as-a-service”, dan ungkapan itu efeknya cuma segitu
    • Mengirimkan Boolean itu ke tempat yang tepat pada waktu yang tepat secara andal bukan hal sepele

  • Di dokumentasi JS SDK ada peringatan seperti ini: “Client provider memerlukan API token untuk mengambil nilai flag. Token ini tidak dibatasi ke satu aplikasi, sehingga siapa pun yang memiliki token tersebut dapat mengevaluasi flag untuk semua aplikasi dalam akun. Gunakan dengan hati-hati pada aplikasi publik”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    Saya penasaran mengapa client SDK yang dirancang untuk didistribusikan ke browser memerlukan kehati-hatian seperti ini. Apakah ini berarti klien mana pun bisa mengirim permintaan dengan targetingKey baru dan mengamati flag milik pengguna lain?
    Flag tentu tidak seharusnya memuat informasi sensitif, tetapi ini tampak seperti pilihan desain yang menarik

    • Mungkin ini sesuatu yang dipakai internal di Cloudflare lalu seseorang berpikir akan menyenangkan jika dibuka ke publik
      Sulit membayangkan Cloudflare sungguh-sungguh memutuskan 6 bulan lalu untuk membuat pesaing LaunchDarkly
    • Saya engineer di tim Flagship. Token cakupan aplikasi sedang dikerjakan

  • Ini bagus, tetapi ironisnya saya mungkin masih menunggu fitur ini keluar, yang kemungkinan akan disediakan lewat Flagship
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    Sepertinya belum pernah ada contoh fitur khusus enterprise yang diturunkan ke akun berbayar tingkat bawah
    Yang terutama saya minati adalah ini:
    https://developers.cloudflare.com/speed/optimization/content...

    • Betul. Saya sangat membutuhkan fitur enterprise Zero Trust sampai akhirnya harus bicara langsung dengan staf sales enterprise. Kelihatannya akan makan banyak waktu dan menimbulkan stres yang ingin saya hindari

  • Akhir-akhir ini Cloudflare memang tampil bagus, tetapi kontrol izin yang rinci masih kurang. Saya masih harus membuat akun yang sepenuhnya terpisah untuk lingkungan produksi, dan karena satu domain hanya bisa terikat ke satu akun, SSO jadi berantakan

    • Produknya keren dan saya sudah lama puas memakainya, tetapi di blog mereka akhir-akhir ini ada beberapa kesalahan. Stabilitasnya juga sempat terasa goyah untuk sementara waktu, meski belakangan tampaknya membaik
    • Setelah beberapa tahun memakai AWS, saya sempat mencoba Cloudflare dan suka pengalaman penggunanya, tetapi akhirnya kembali karena kekhawatiran yang sama. Rasanya sudah hampir sampai, jadi sayang sekali
    • Beberapa tahun lalu saya memindahkan semua proyek ke Cloudflare dan tidak menyesal. Saya memakai Workers, D1, R2, Queues, Containers, KV
      Untuk pengiriman email saya masih memakai AWS, jadi akan bagus kalau Cloudflare punya itu juga
    • Saya juga hari ini membuka tiket dukungan untuk meminta izin yang lebih rinci
    • Inilah tepatnya alasan yang menghalangi saya memakai Cloudflare untuk pekerjaan nyata. Saya suka free tier-nya untuk hobi

  • Saya baru tahu OpenFeature, dan ini keren. Ada yang punya pengalaman mengintegrasikannya? https://openfeature.dev

    • Saya sudah banyak memakai OpenFeature, dan bahkan membuat commit awal di beberapa pustaka klien. Ini memang masa depan feature flag, dan ekosistemnya berkembang cepat
      Sebagai pengungkapan, saya adalah CTO Flagsmith. Selama beberapa tahun terakhir, saya melihat kurva adopsi OpenFeature yang jelas meningkat. Dulu kami yang menyarankan pelanggan untuk mencobanya, sekarang pelanggan datang dengan OpenFeature sebagai persyaratan
      Dukungan vendor sekarang juga sudah cukup matang dan mencakup hampir semua bahasa. Jika Anda sedang mengintegrasikan feature flag ke layanan baru, atau ingin berpindah dari implementasi internal ke solusi pihak ketiga, saya merekomendasikan OpenFeature
    • Cukup berguna. Saya memakainya di perusahaan sebelumnya, dan kami membuat backend kustom sambil memakai spesifikasi dan SDK OpenFeature
      Membuat backend kustom yang sepenuhnya fungsional memakan waktu sekitar 2 minggu. SDK untuk berbagai bahasa juga berjalan tanpa masalah. Saya memang menemukan satu bug, tetapi setelah dilaporkan, diperbaiki pada hari yang sama

  • Saya kurang paham feature flag. Secara mendasar apa bedanya dengan Boolean di database?

    • Apakah flag itu berupa Boolean, string, angka, atau apa pun lainnya, itu justru bagian yang mudah. Yang sulit adalah aturan targeting dan rollout, yaitu siapa yang melihat flag tertentu dan kebutuhan untuk mengevaluasi aturan itu dengan sangat cepat dan konsisten
      Tim yang membangunnya sendiri biasanya melihat masalah membesar dengan cepat ketika manajemen produk, pemasaran, dan sales ingin melakukan targeting dengan aturan yang makin kompleks
      Dari sisi tingkat kesulitan keseluruhan, ini bukan masalah yang sangat sulit, tetapi skalanya besar. Anda membutuhkan banyak fitur yang pada awalnya tidak terlihat
      Feature flag pada dasarnya bisa dianggap lebih dekat ke sistem izin. Intinya adalah memberi hanya pengguna tertentu akses ke fitur tertentu, dan siapa pun yang pernah menangani sistem izin tahu betapa rumitnya keanggotaan grup, grup hierarkis, peran, ACL, dan sebagainya. Elemen-elemen ini mirip dengan berbagai aturan targeting dalam sistem feature flag
    • Begitu masuk ke percentage rollout, RBAC, audit trail, A/B testing, dan konfigurasi multivariat, semuanya cepat menjadi kompleks. Satu Boolean itu berubah menjadi keseluruhan sistem yang harus dipelihara dan dioperasikan
    • Tulisan yang membahas detailnya ada di sini: https://martinfowler.com/articles/feature-toggles.html
    • Tidak selalu Boolean. Misalnya, feature flag sering dipakai untuk A/B rollout
      Cloudflare juga memakainya secara internal untuk lebih dulu merilis fitur atau build baru ke pelanggan gratis, lalu secara bertahap memperluasnya ke pelanggan yang lebih besar setelah masa stabilisasi
      Feature flag juga bisa dinyalakan secara acak, semacam fuzz test. Jangan hanya memikirkan “hal baru”, bisa juga berarti “perubahan perilaku”
      Anda bisa menganggapnya sebagai Boolean di atas semua klien, tetapi biasanya implementasinya tidak seperti itu
    • Anda memang bisa mengimplementasikannya dengan Boolean di database, jadi itu hanya detail implementasi
      Daya tarik utama feature flag adalah memungkinkan Anda mengerjakan fitur besar yang butuh berbulan-bulan dan banyak commit langsung di branch utama. Bagi saya ini menciptakan proses pengembangan yang lebih ringan dan iteratif
      Ini berbeda dengan harus memelihara branch terpisah dan bahkan target deployment terpisah untuk fitur selama pengembangan besar

  • Feature flag sering kali dibuat terlalu berlebihan
    Cukup periksa nilai konfigurasi, nilai database, atau environment variable lalu arahkan secara dinamis ke satu jalur atau jalur lain
    Hanya itu. Anda perlu membuat fitur kecil-kecil, atau me-refactor kode agar mudah dialihkan di level tinggi
    Jika itu tidak mudah dilakukan, implementasi feature flag yang kompleks bisa membantu untuk mengoordinasikan aktivasi fitur antar-microservice
    Jika fiturnya banyak, dashboard juga bisa berguna
    Tetapi saya melihat keduanya sebagai sinyal kuat bahwa Anda sebaiknya menghindari feature flag. Feature flag lebih cocok untuk perubahan yang lokal dan sementara; kalau tidak, kompleksitasnya akan menumpuk dan menyulitkan pengelolaan serta pemeliharaan

    • Masuk akal untuk menyalakan fitur bagi segmen tertentu, misalnya pengguna berpendapatan rendah di Italia, agar bisa melihat dampaknya terhadap bisnis atau performa
      Tentu saja, Anda tidak ingin pengguna kehilangan fitur hanya karena melewati ambang pendapatan atau melintasi perbatasan, jadi perlu ada semacam implementasi pelacakan. Analitik dan pelacakan error juga harus berkomunikasi dengan layanan feature flag
      Ini bukan rocket science, tetapi jelas lebih rumit daripada environment variable
    • Inti feature flag adalah disiplin. Buat dengan tujuan yang jelas, dan hapus segera ketika tidak lagi bernilai. KISS berlaku di sini

  • Selalu menaruh ekspektasi saat Cloudflare mulai menyediakan sesuatu yang sebelumnya harus memakai penyedia lain. Ada kepercayaan bahwa hasilnya akan solid
    Di Function kami memakai Statsig. Awalnya dua orang mulai memakainya pada satu produk, lalu dalam 12 bulan sebagian besar copy produk dan rollout dijalankan oleh Statsig
    Statsig punya evaluasi sisi klien, jadi aturan dan rollout bisa ditulis berdasarkan konsep internal tanpa server Statsig harus memproses data pengguna
    Semoga Cloudflare membuat produk yang matang di sini sehingga ke depannya tidak perlu memakai produk lain

    • Agak aneh menyerahkan feature flag ke pihak ketiga. Bukan berarti semuanya harus dibuat sendiri, tapi untuk feature flag tidak pernah ada masalah besar untuk membuatnya sendiri

  • Saya pengguna biasa yang tidak terlalu paham detail teknis, tetapi Cloudflare terasa relatif mudah digunakan. Semoga terus bekerja dengan baik

    • Sejauh ini ini registrar DNS terbaik yang pernah saya pakai