Cloudflare Flagship

 (developers.cloudflare.com)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Cloudflare Flagship là dịch vụ feature flag của Cloudflare, dùng để kiểm soát việc bật hiển thị tính năng của ứng dụng mà không cần triển khai lại mã
  • Các flag được định nghĩa bằng quy tắc nhắm mục tiêu và rollout theo tỷ lệ, có thể được đánh giá trực tiếp từ binding gốc của Workers
  • Tương thích với OpenFeature và có thể dùng SDK @cloudflare/flagship để đánh giá flag trên Workers, Node.js và trình duyệt
  • Việc nhắm mục tiêu hỗ trợ thuộc tính người dùng, 11 toán tử so sánh, nhóm AND/OR, đánh giá tuần tự và duy trì giá trị bằng consistent hashing
  • Biến thể hỗ trợ boolean, chuỗi, số và đối tượng JSON, được tạo, sửa, xóa theo từng ứng dụng trong bảng điều khiển Cloudflare

Tính năng chính

  • Binding cho Workers

    • Binding reference
    • Đánh giá flag bằng binding gốc của Workers
    • Cung cấp các phương thức an toàn kiểu dữ liệu và tự động fallback về giá trị mặc định

  • SDK OpenFeature

    • View SDK docs
    • Có thể dùng provider OpenFeature @cloudflare/flagship để đánh giá flag trên Workers, Node.js và trình duyệt
    • Khi chuyển từ nhà cung cấp flag khác sang, chỉ cần đổi một dòng cấu hình

  • Quy tắc nhắm mục tiêu

    • Learn about targeting
    • Cung cấp các giá trị flag khác nhau tùy theo thuộc tính người dùng
    • Quy tắc hỗ trợ 11 toán tử so sánh, nhóm logic AND/OR và đánh giá tuần tự

  • Rollout theo tỷ lệ

    • Learn about rollouts
    • Có thể phát hành tính năng dần dần theo tỷ lệ người dùng
    • Consistent hashing đảm bảo cùng một người dùng luôn nhận cùng một giá trị flag

  • Biến thể đa kiểu

    • Use Multi-type variations
    • Biến thể của flag có thể là boolean, chuỗi, số hoặc đối tượng JSON có cấu trúc
    • Dùng biến thể đối tượng để truyền cả một khối cấu hình chỉ với một flag

  • Quản lý flag

    • Use Flag management
    • Có thể tạo, cập nhật và xóa flag trong bảng điều khiển Cloudflare
    • Tổ chức flag theo các app được ánh xạ tới dự án hoặc dịch vụ
    • Có thể tạo feature flag đầu tiên trong Get started guide

Các dịch vụ Cloudflare liên quan

  • Workers: Xây dựng ứng dụng serverless trên mạng lưới toàn cầu của Cloudflare; Flagship được tích hợp gốc với Workers thông qua binding
  • KV: Lưu trữ dữ liệu key-value trên toàn bộ mạng lưới toàn cầu của Cloudflare; Flagship sử dụng hạ tầng này để phân phối cấu hình flag

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Không nên đánh giá thấp một lớp trừu tượng có 0 lần round-trip mạng. Trên f(feature_name, context), phần context có thể được tinh chỉnh rất chi tiết tới mức hiển thị theo tồn kho cụ thể, nhà cung cấp cụ thể, người dùng cụ thể của một khách hàng B2B cụ thể, một phân loại phụ cụ thể của mô hình kinh doanh, thậm chí cả khung giờ cụ thể
    Nếu có thể viết logic trực tiếp và chạy nó như hằng số trong tight loop với tốc độ cao, độ linh hoạt của doanh nghiệp sẽ tăng lên đáng kể. Nếu nghĩ rằng câu chữ có thể thay đổi với một số khách hàng, chỉ cần biến nó thành mã có thể cấu hình được, rồi test và cờ cũng sẽ tự nhiên đi kèm
    Tuy vậy, kiểu cấu hình 0-hop này cần một client execution engine tinh vi, và có vẻ Cloudflare không triển khai phần đó ở đây. Với Workers bị giới hạn bộ nhớ thì có thể hiểu được, nhưng với hạ tầng truyền thống thì kém thuyết phục hơn
    Tôi khá thích cách làm của Statsig: đây là hướng tiếp cận kiểu “Server SDKs hold the entire ruleset of your project in memory...”
    https://docs.statsig.com/sdks/how-evaluation-works
    Cũng có thể tự xây. Chỉ cần đồng bộ tập quy tắc vào một vài cấu trúc dữ liệu trong một background thread mỗi vài giây rồi thay thế tham chiếu một cách nguyên tử. Sau đó chỉ cần một giao diện CRUD cho chiều của các quy tắc áp dụng
    Tuy nhiên, nhất định phải có governance về việc ai được đụng vào những ứng viên hằng số nào. Quyền lực lớn đi kèm trách nhiệm lớn

    • Đọc đoạn này làm tôi nghĩ ngay tới một mô thức lạm dụng feature flag như cấu hình/tùy biến ứng dụng. Đây là một anti-pattern tôi đã thấy ở nhiều tổ chức
      Theo tôi, feature flag gần với mục đích dùng cùng phát triển theo trunk để bật tính năng trong môi trường QA, chưa đưa ra production, đồng thời cho phép PO/PM kiểm thử. Trunk-based development giúp DevOps nhanh và đơn giản mà không cần chiến lược branch phức tạp
      Trong khi đó, cấu hình ứng dụng là một phần của chính ứng dụng, thuộc lĩnh vực tùy biến app theo bối cảnh kinh doanh. Tôi không biết có framework hay công cụ phù hợp nào cho việc đó không, nhưng hai thứ này cần được tách bạch rõ ràng
    • Bản thân việc triển khai không khó. Nó chỉ ở mức lấy thứ gì đó như Mersenne Twister rồi thêm phép modulo lên trên, và trong công việc gần đây thì chỉ cần Flipper cùng một endpoint tùy chọn kiểu “trạng thái hiện tại của bảng flag” là đủ
      Chính tổ hợp modulo + số ngẫu nhiên đó là lý do các công cụ như LaunchDarkly phải cung cấp SDK cho nhiều ngôn ngữ, và các SDK tôi từng phải đụng tới đều hoàn toàn không hợp với ngôn ngữ tương ứng. Vì đẩy việc đánh giá ra edge mà cả hệ thống trở nên phức tạp hơn mức cần thiết
      Thực tế chỉ cần thỉnh thoảng lấy lại bảng flag hiện tại “cho khách hàng này” là đủ, và đỡ phiền hơn nhiều. May là có Flipper nên giờ không còn phải tự xử lý chuyện này nữa
    • Cấu hình 0-hop đó cũng không nhất thiết phải tinh vi, và Cloudflare cũng không cần tự triển khai. Nếu dựa vào OpenFeature thì đã có sẵn một engine đánh giá quy tắc nhắm mục tiêu đơn giản được tích hợp trong thư viện client
    • Lời khuyên hay. Xin bổ sung rằng feature flag, A/B testing và authorization là ba khái niệm khác nhau. Cách bài viết này framing vấn đề khá hữu ích
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • Công ty tôi đang dùng Statsig rất tốt. Sản phẩm hoàn thiện và giàu tính năng. Công cụ giúp tìm các flag không dùng tới để đưa vào diện loại bỏ khá ổn
      Việc tính phí theo số ghế trong hợp đồng hơi chát một chút nhưng vẫn ở mức chấp nhận được

  • Trông như Boolean-as-a-service được mạ vàng

    • Tôi đã thấy cả một team thất bại vì công ty không thể cung cấp loại Boolean-as-a-service này cho ra hồn. Có lý do để những công ty như LaunchDarkly tồn tại riêng
      Nếu đơn giản hóa theo kiểu đó thì mọi dịch vụ trên đời đều có thể bị quy về bits-as-a-service. Thực tế, những thứ này có giá trị kinh doanh chính đáng và việc cung cấp chúng cũng có độ phức tạp riêng
    • Tôi thấy ổn. Tôi không muốn phải theo dõi hàng nghìn feature flag trong cơ sở dữ liệu rồi còn làm dashboard quản trị
      Bất kỳ công cụ SaaS nào cũng có thể bị gọi là “excel-as-a-service”, và đó là kiểu diễn đạt hầu như chẳng mang lại tác dụng gì
    • Việc chuyển Boolean đó đến đúng nơi vào đúng thời điểm một cách ổn định không phải chuyện tầm thường

  • Trong tài liệu JS SDK có cảnh báo như sau: “Client provider requires an API token in order to fetch flag values. This token is not scoped to a single app, so anyone with the token could evaluate flags for every app in your account. Use caution in public applications”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    Tôi thắc mắc vì sao một client SDK được thiết kế để triển khai lên trình duyệt lại cần cảnh báo như vậy. Có phải điều đó có nghĩa là bất kỳ client nào cũng có thể gửi request với targetingKey mới để quan sát flag của người dùng khác không?
    Dù flag không nên chứa thông tin nhạy cảm, đây vẫn có vẻ là một lựa chọn thiết kế thú vị

    • Có lẽ đây là thứ Cloudflare dùng nội bộ, rồi ai đó nghĩ rằng mang ra công khai sẽ vui
      Khó tin là 6 tháng trước Cloudflare đã thực sự nghiêm túc quyết định làm một đối thủ của LaunchDarkly
    • Tôi là kỹ sư của team Flagship. App-scoped token đang được triển khai

  • Cái này thì tốt, nhưng trớ trêu là có lẽ tôi vẫn đang chờ chính tính năng này, thứ có thể sẽ được cung cấp thông qua Flagship, ra mắt
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    Có vẻ đến giờ vẫn chưa có trường hợp nào mà tính năng chỉ dành cho Enterprise được đưa xuống các gói trả phí thấp hơn
    Thứ tôi đặc biệt quan tâm là cái này:
    https://developers.cloudflare.com/speed/optimization/content...

    • Đúng vậy. Tôi rất cần các tính năng Enterprise của Zero Trust, đến mức cuối cùng có lẽ sẽ phải nói chuyện trực tiếp với nhân viên kinh doanh Enterprise. Việc đó có vẻ sẽ tốn nhiều thời gian và mang lại kiểu căng thẳng mà tôi muốn tránh

  • Dạo này Cloudflare làm khá tốt, nhưng vẫn thiếu quản lý quyền chi tiết. Tôi vẫn phải tạo một tài khoản hoàn toàn riêng cho môi trường production, và vì một domain chỉ có thể gắn với một tài khoản nên SSO bị rối tung

    • Sản phẩm rất ấn tượng và tôi đã dùng rất hài lòng trong thời gian dài, nhưng blog gần đây đã có vài lần sơ suất. Độ ổn định cũng có vẻ chao đảo một thời gian, dù gần đây hình như đã khá hơn
    • Tôi đã dùng AWS vài năm rồi thử Cloudflare, và dù rất thích trải nghiệm người dùng, cuối cùng vẫn quay lại vì đúng những lo ngại đó. Thật sự là chỉ còn thiếu một chút nữa thôi
    • Vài năm trước tôi đã chuyển toàn bộ dự án sang Cloudflare và không hề hối hận. Tôi đang dùng Workers, D1, R2, Queues, Containers, KV
      Gửi email thì tôi vẫn đang dùng AWS, nên sẽ rất tốt nếu Cloudflare có thứ gì đó ở mảng này
    • Hôm nay tôi cũng đã mở một ticket hỗ trợ để yêu cầu quyền hạn chi tiết hơn
    • Đây chính xác là lý do khiến tôi không thể dùng Cloudflare cho công việc thực tế. Còn gói miễn phí cho dự án cá nhân thì tôi rất thích

  • Tôi mới biết đến OpenFeature và thấy nó khá hay. Có ai đã từng tích hợp nó chưa? https://openfeature.dev

    • Tôi đã dùng OpenFeature khá nhiều, thậm chí còn có những commit đầu tiên cho một vài thư viện client. Đây đúng là tương lai của feature flag, và hệ sinh thái cũng đang phát triển rất nhanh
      Nói rõ để minh bạch thì tôi là CTO của Flagsmith. Trong vài năm qua tôi đã thấy xu hướng áp dụng OpenFeature tăng lên rất rõ. Trước đây chúng tôi phải khuyên khách hàng thử dùng, còn bây giờ chính khách hàng mang OpenFeature đến như một yêu cầu
      Giờ mức độ hỗ trợ từ các vendor cũng đã khá trưởng thành và bao phủ gần như mọi ngôn ngữ. Nếu bạn đang tích hợp feature flag vào một dịch vụ mới, hoặc chuyển từ hệ thống tự xây sang giải pháp bên thứ ba, tôi khuyên dùng OpenFeature
    • Khá hữu ích. Tôi đã dùng nó ở công ty trước, xây backend tùy chỉnh nhưng dùng đặc tả và SDK của OpenFeature
      Chúng tôi mất khoảng 2 tuần để làm một backend tùy chỉnh hoàn chỉnh. SDK cho nhiều ngôn ngữ đều hoạt động ổn. Tôi có tìm ra một lỗi, nhưng sau khi báo thì nó được sửa ngay trong ngày

  • Tôi không thực sự hiểu rõ feature flag. Nó khác gì về bản chất so với một giá trị Boolean trong cơ sở dữ liệu?

    • Bản thân flag là Boolean, chuỗi, số hay thứ gì khác thì đó là phần dễ. Phần khó là quy tắc nhắm mục tiêu và rollout, tức là ai sẽ nhìn thấy flag nào, và yêu cầu phải đánh giá các quy tắc đó thật nhanh và nhất quán
      Những đội tự xây thường sẽ thấy vấn đề phình ra rất nhanh khi phía quản lý sản phẩm, marketing và sales muốn nhắm mục tiêu bằng các quy tắc ngày càng phức tạp hơn
      Xét về độ khó tổng thể thì đây không phải bài toán đặc biệt hóc búa, nhưng quy mô của nó lớn. Có rất nhiều thứ cần thiết mà ban đầu không nhìn ra
      Về bản chất, feature flag có thể xem là khá gần với một hệ thống phân quyền. Nó cho phép chỉ một số người dùng nhất định truy cập một số tính năng nhất định, và ai từng làm hệ thống phân quyền đều biết membership theo nhóm, nhóm phân cấp, vai trò, ACL, v.v. có thể trở nên phức tạp đến mức nào. Những yếu tố đó tương tự với các quy tắc nhắm mục tiêu khác nhau trong hệ thống feature flag
    • Khi thêm rollout theo phần trăm, RBAC, lịch sử kiểm toán, A/B testing, thậm chí cả cấu hình đa biến, mọi thứ sẽ nhanh chóng trở nên phức tạp. Một giá trị Boolean đó biến thành cả một hệ thống cần được duy trì và vận hành
    • Có bài viết chi tiết ở đây: https://martinfowler.com/articles/feature-toggles.html
    • Không phải lúc nào cũng là Boolean. Ví dụ feature flag thường được dùng cho A/B rollout
      Cloudflare cũng dùng nội bộ theo cách tung tính năng mới hoặc bản build mới cho khách hàng miễn phí trước, rồi sau một thời gian ổn định mới mở rộng dần sang các khách hàng lớn hơn
      Feature flag cũng có thể được bật ngẫu nhiên như một dạng fuzz test. Đừng chỉ nghĩ đến “thứ mới”, nó cũng có thể là “thay đổi hành vi”
      Bạn có thể xem nó như một Boolean nằm phía trên mọi client, nhưng thông thường nó không được triển khai theo cách đó
    • Có thể triển khai bằng một giá trị Boolean trong cơ sở dữ liệu, nên đó chỉ là chi tiết triển khai
      Điểm hấp dẫn chính của feature flag là nó cho phép các tính năng lớn, vốn cần nhiều tháng và rất nhiều commit, vẫn có thể được phát triển ngay trên nhánh chính. Với tôi, điều đó tạo ra một quy trình phát triển nhẹ hơn và lặp nhanh hơn
      Nó trái ngược với việc phải duy trì các nhánh riêng, thậm chí có cả mục tiêu triển khai riêng cho tính năng đang được phát triển lớn

  • Feature flag thường hay bị thiết kế quá mức
    Chỉ cần kiểm tra giá trị cấu hình, giá trị trong cơ sở dữ liệu hoặc biến môi trường, rồi động chuyển sang nhánh này hay nhánh kia
    Vậy là đủ. Bạn nên làm tính năng nhỏ lại, hoặc refactor mã để có thể chuyển đổi dễ dàng ở mức cao hơn
    Nếu điều đó không dễ làm, thì một hệ thống feature flag phức tạp có thể hữu ích để điều phối việc kích hoạt tính năng giữa các microservice
    Nếu có nhiều tính năng, một dashboard cũng có thể hữu ích
    Nhưng tôi xem cả hai điều đó đều là tín hiệu mạnh cho thấy nên tránh feature flag. Feature flag phù hợp hơn với các thay đổi cục bộ và tạm thời; nếu không, độ phức tạp sẽ chồng chất và khiến việc quản lý, bảo trì trở nên khó khăn

    • Việc bật tính năng cho một phân khúc cụ thể, ví dụ người dùng doanh thu thấp ở Ý, để xem tác động về kinh doanh hay hiệu năng là hợp lý
      Tất nhiên bạn sẽ không muốn người dùng mất tính năng chỉ vì họ vượt ngưỡng doanh thu hoặc đi qua biên giới, nên sẽ cần một kiểu triển khai theo dõi nào đó. Phân tích và theo dõi lỗi cũng phải giao tiếp với dịch vụ feature flag
      Nó không phải khoa học tên lửa, nhưng chắc chắn phức tạp hơn biến môi trường
    • Cốt lõi của feature flag là kỷ luật. Hãy tạo chúng có mục đích, và loại bỏ ngay khi chúng không còn giá trị nữa. KISS áp dụng ở đây

  • Luôn thấy hào hứng khi Cloudflare bắt đầu cung cấp những thứ mà trước đây phải dùng nhà cung cấp khác. Có niềm tin rằng nó sẽ rất vững chắc
    Ở Function thì đã dùng Statsig. Ban đầu chỉ có hai người trong một sản phẩm bắt đầu dùng, nhưng trong vòng 12 tháng, phần lớn câu chữ trong sản phẩm và việc rollout đã được vận hành bằng Statsig
    Statsig có đánh giá phía client, nên có thể viết quy tắc và rollout dựa trên các khái niệm nội bộ mà không cần máy chủ Statsig xử lý dữ liệu người dùng
    Mong Cloudflare sẽ tạo ra một sản phẩm tinh vi ở đây để sau này không cần dùng sản phẩm khác nữa

    • Thấy lạ khi giao feature flag cho bên thứ ba. Không phải kiểu cái gì cũng phải tự xây, nhưng feature flag thì tự làm cũng không có vấn đề gì lớn

  • Tôi chỉ là người dùng bình thường, không rành chi tiết kỹ thuật, nhưng cảm thấy Cloudflare tương đối dễ dùng. Mong họ tiếp tục làm tốt

    • Là nhà đăng ký DNS tốt nhất trong số những cái tôi từng dùng đến nay