Cloudflare Flagship

 (developers.cloudflare.com)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cloudflare Flagship คือบริการฟีเจอร์แฟล็กของ Cloudflare สำหรับควบคุมการเปิดเผยความสามารถของแอปพลิเคชันโดยไม่ต้องนำโค้ดขึ้นใช้งานใหม่
  • แฟล็กถูกกำหนดด้วย กฎการกำหนดเป้าหมาย และการทยอยเปิดใช้งานตามสัดส่วน และสามารถประเมินได้โดยตรงจาก Workers native binding
  • รองรับ OpenFeature และสามารถใช้ SDK @cloudflare/flagship เพื่อประเมินแฟล็กได้บน Workers, Node.js และเบราว์เซอร์
  • การกำหนดเป้าหมายรองรับแอตทริบิวต์ผู้ใช้, ตัวดำเนินการเปรียบเทียบ 11 แบบ, การจัดกลุ่มแบบ AND/OR และการประเมินตามลำดับ พร้อมคงค่าด้วย consistent hashing
  • รูปแบบค่าของ variation รองรับบูลีน, สตริง, ตัวเลข และ ออบเจ็กต์ JSON และสามารถสร้าง·แก้ไข·ลบได้ในระดับแอปจากแดชบอร์ด Cloudflare

ฟีเจอร์หลัก

  • Workers Binding

    • Binding reference
    • ประเมินแฟล็กผ่าน native binding ของ Workers
    • มีเมธอดที่ปลอดภัยด้านชนิดข้อมูลและ fallback ไปยังค่าเริ่มต้นโดยอัตโนมัติ

  • OpenFeature SDK

    • View SDK docs
    • ใช้ @cloudflare/flagship OpenFeature provider เพื่อประเมินแฟล็กบน Workers, Node.js และเบราว์เซอร์ได้
    • เมื่อต้องการย้ายมาจากผู้ให้บริการแฟล็กรายอื่น เปลี่ยนเพียงการตั้งค่าหนึ่งบรรทัดก็พอ

  • กฎการกำหนดเป้าหมาย

    • Learn about targeting
    • ให้ค่าแฟล็กที่แตกต่างกันตามแอตทริบิวต์ของผู้ใช้
    • กฎรองรับ ตัวดำเนินการเปรียบเทียบ 11 แบบ, การจัดกลุ่มเชิงตรรกะแบบ AND/OR และการประเมินตามลำดับ

  • การทยอยเปิดใช้งานตามสัดส่วน

    • Learn about rollouts
    • สามารถค่อย ๆ เปิดตัวฟีเจอร์ตามสัดส่วนของผู้ใช้ได้
    • consistent hashing ช่วยรับประกันว่าผู้ใช้คนเดิมจะได้รับค่าแฟล็กเดิมเสมอ

  • Variation หลายชนิดข้อมูล

    • Use Multi-type variations
    • variation ของแฟล็กสามารถเป็นบูลีน, สตริง, ตัวเลข หรือออบเจ็กต์ JSON แบบมีโครงสร้าง
    • การใช้ variation แบบออบเจ็กต์ช่วยให้ส่งบล็อกการตั้งค่าทั้งชุดผ่านแฟล็กเดียวได้

  • การจัดการแฟล็ก

    • Use Flag management
    • สามารถสร้าง อัปเดต และลบแฟล็กได้จากแดชบอร์ด Cloudflare
    • จัดโครงสร้างแฟล็กเป็นแอปที่แมปกับโปรเจกต์หรือบริการ
    • สามารถสร้างฟีเจอร์แฟล็กตัวแรกได้จาก Get started guide

บริการ Cloudflare ที่เกี่ยวข้อง

  • Workers: สร้างแอปพลิเคชันแบบ serverless บนเครือข่ายระดับโลกของ Cloudflare และ Flagship ทำงานผสานกับ Workers แบบ native ผ่าน binding
  • KV: จัดเก็บข้อมูลคีย์-ค่าไว้ทั่วทั้งเครือข่ายระดับโลกของ Cloudflare และ Flagship ใช้โครงสร้างพื้นฐานนี้ในการส่งมอบการตั้งค่าแฟล็ก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ไม่ควรประเมิน abstraction ที่มี network round-trip เป็น 0 ต่ำเกินไป บน f(feature_name, context) นั้น context สามารถปรับให้ละเอียดมากได้ ตั้งแต่สินค้าคงคลังเฉพาะราย, ซัพพลายเออร์เฉพาะราย, ผู้ใช้เฉพาะของลูกค้า B2B เฉพาะราย, ประเภทย่อยของโมเดลธุรกิจเฉพาะแบบ ไปจนถึงการแสดงผลตามช่วงเวลาเฉพาะ
    ถ้าสามารถเขียน logic เองและรันใน tight loop ได้เร็วราวกับค่าคงที่ ความคล่องตัวทางธุรกิจก็จะเพิ่มขึ้นมาก ถ้าคิดว่าอาจต้องเปลี่ยนข้อความให้ลูกค้าบางราย ก็ทำให้ตั้งค่าได้ในโค้ด และเรื่องการทดสอบกับ flag ก็จะตามมาอย่างเป็นธรรมชาติ
    แต่การจัดแบบ 0-hop นี้ต้องมี client execution engine ที่ซับซ้อนพอสมควร ซึ่งดูเหมือนว่า Cloudflare จะไม่ได้ทำไว้แบบนั้น เข้าใจได้ถ้าอยู่บน Workers ที่มีข้อจำกัดด้านหน่วยความจำ แต่กับอินฟราดั้งเดิมจะรู้สึกสมเหตุสมผลน้อยกว่า
    แนวทางของ Statsig ค่อนข้างถูกใจ: เป็นแนวคิดแบบ “Server SDKs hold the entire ruleset of your project in memory...”
    https://docs.statsig.com/sdks/how-evaluation-works
    จะทำเองก็ได้ แค่ซิงก์ชุดกฎเป็นโครงสร้างข้อมูลไม่กี่แบบจาก background thread ทุก ๆ ไม่กี่วินาที แล้วสลับ reference แบบ atomic จากนั้นก็ต้องมีเพียงอินเทอร์เฟซ CRUD สำหรับมิติของกฎที่ใช้บังคับ
    แต่จำเป็นต้องมี governance ว่าใครสามารถแตะต้องตัวเลือกค่าคงที่ใดได้บ้าง พลังที่มากย่อมมาพร้อมความรับผิดชอบที่มาก

    • พออ่านแล้วทำให้นึกถึงแพตเทิร์นที่นำ feature flag ไปใช้ผิดวัตถุประสงค์เป็นการตั้งค่า/คัสตอมแอปพลิเคชัน ซึ่งเป็น anti-pattern ที่พบมาแล้วในหลายองค์กร
      ผมมองว่า feature flag มีไว้ใช้คู่กับ trunk-based development เพื่อเปิดฟีเจอร์ในสภาพแวดล้อม QA โดยยังไม่ปล่อยสู่ production และเปิดทางให้ PO/PM ทดสอบได้ trunk-based development ทำให้ DevOps ทำงานได้เร็วและง่ายโดยไม่ต้องพึ่งกลยุทธ์ branching ที่ซับซ้อน
      ในทางกลับกัน การตั้งค่าแอปพลิเคชันเป็นส่วนหนึ่งของตัวแอปเอง และเป็นพื้นที่สำหรับคัสตอมแอปให้เข้ากับบริบทธุรกิจ ไม่แน่ใจว่ามี framework หรือเครื่องมือเฉพาะไหม แต่ทั้งสองอย่างควรถูกแยกจากกันอย่างชัดเจน
    • ตัว implementation เองไม่ได้ยากอะไร เป็นแค่เอา modulo ไปวางบนอะไรอย่าง Mersenne Twister และในงานช่วงหลัง ๆ มีเพียง Flipper กับ endpoint สำหรับ “สถานะตาราง flag ปัจจุบัน” แบบเลือกใช้ก็เพียงพอแล้ว
      เพราะการผสม modulo+random นี้เอง เครื่องมืออย่าง LaunchDarkly เลยต้องมี SDK สำหรับหลายภาษา และ SDK ที่ผมต้องใช้ก็ไม่ได้เข้ากับภาษานั้น ๆ ดีเลย ผมคิดว่าการผลัก evaluation ไปไว้ที่ edge ทำให้ทั้งระบบซับซ้อนเกินความจำเป็น
      ในทางปฏิบัติ แค่ดึงตาราง flag ปัจจุบัน “สำหรับลูกค้ารายนี้” กลับมาใหม่เป็นครั้งคราวก็พอ และน่ารำคาญน้อยกว่ามาก ดีที่มี Flipper เลยไม่ต้องมาจัดการเรื่องพวกนี้เองแล้ว
    • การจัดแบบ 0-hop นั้นไม่จำเป็นต้องซับซ้อนมาก และ Cloudflare ก็ไม่จำเป็นต้องทำเองด้วย ถ้าอาศัย OpenFeature ก็มี integration ของ engine ประเมินกฎ targeting แบบง่ายอยู่ในไลบรารีฝั่ง client แล้ว
    • เป็นคำแนะนำที่ดี และขอเสริมว่า feature flag, A/B testing, และ authorization เป็นคนละแนวคิดกันทั้งหมดสามอย่าง กรอบการอธิบายในบทความนี้ช่วยได้มาก
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • ที่บริษัทใช้ Statsig ได้ดีมาก งานเนียนและฟีเจอร์ก็เยอะ เครื่องมือที่ช่วยหา flag ที่ไม่ได้ใช้แล้วเพื่อเสนอเป็นผู้เข้าข่ายลบออกนั้นค่อนข้างดี
      ค่าบริการแบบคิดตามจำนวนที่นั่งในสัญญาจะค่อนข้างแรงหน่อย แต่ก็ยังพอรับได้

  • มันดูเหมือน Boolean-as-a-service ที่เอาทองมาปิดทับ

    • ผมเคยเห็นทั้งทีมล้มเหลวเพราะบริษัทส่งมอบ Boolean-as-a-service แบบนี้ได้ไม่ดีพอ มีเหตุผลที่บริษัทอย่าง LaunchDarkly แยกออกมาอยู่ต่างหาก
      ถ้าจะลดทอนแบบนี้ บริการทุกอย่างบนโลกก็เรียกได้ว่าเป็น bits-as-a-service เหมือนกัน แต่ในความจริง สิ่งพวกนี้มีคุณค่าทางธุรกิจที่ชอบธรรม และขั้นตอนการให้บริการก็มีความซับซ้อนอยู่
    • ผมว่าโอเคนะ ผมไม่อยากตามดู feature flag หลายพันตัวในฐานข้อมูล และก็ไม่อยากสร้างแดชบอร์ดแอดมินด้วย
      เครื่องมือ SaaS อะไรก็ตามจะเรียกว่า “excel-as-a-service” ก็ได้ และก็เป็นคำเรียกที่มีพลังเท่านั้นเอง
    • การส่ง Boolean นั้น ไปยังตำแหน่งที่ถูกต้องในเวลาที่ถูกต้อง อย่างเสถียร ไม่ใช่เรื่องเล็กน้อย

  • ในเอกสาร JS SDK มีคำเตือนนี้: “client provider ต้องใช้ API token เพื่อดึงค่า flag โทเค็นนี้ไม่ได้จำกัดอยู่แอปเดียว ดังนั้นใครก็ตามที่มีโทเค็นจะสามารถประเมิน flag ของทุกแอปในบัญชีได้ ใช้อย่างระมัดระวังในแอปพลิเคชันแบบ public”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    เลยสงสัยว่าทำไม client SDK ที่ออกแบบมาให้แจกจ่ายไปยังเบราว์เซอร์ถึงต้องมีคำเตือนนี้ หมายความว่า client ใด ๆ ก็สามารถส่งคำขอด้วย targetingKey ใหม่เพื่อสังเกต flag ของผู้ใช้คนอื่นได้อย่างนั้นหรือ?
    แม้ว่า flag ไม่ควรเก็บข้อมูลสำคัญ แต่ก็ดูเป็นการออกแบบที่น่าสนใจ

    • น่าจะเป็นของที่ Cloudflare ใช้ภายใน แล้วมีใครบางคนคิดว่าน่าเอาออกมาเปิดสาธารณะ
      ดูไม่ค่อยน่าเชื่อว่าเมื่อ 6 เดือนก่อน Cloudflare จะตัดสินใจอย่างจริงจังว่าจะสร้างคู่แข่งของ LaunchDarkly
    • ผมเป็นวิศวกรในทีม Flagship ตอนนี้ token แบบกำหนดขอบเขตต่อแอป กำลังอยู่ระหว่างพัฒนา

  • อันนี้ก็ดี แต่ก็น่าขำตรงที่น่าจะต้องรอฟีเจอร์นี้ ซึ่งคงจะให้บริการผ่าน Flagship ออกมาก่อน
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    ดูเหมือนว่ายังไม่เคยมีกรณีที่ฟีเจอร์สำหรับ Enterprise เท่านั้นถูกลดระดับลงมาสู่บัญชีแบบเสียเงินที่ต่ำกว่าเลย
    อันที่สนใจเป็นพิเศษคืออันนี้:
    https://developers.cloudflare.com/speed/optimization/content...

    • ใช่เลย ต้องการ ฟีเจอร์ Enterprise ของ Zero Trust มากจนสุดท้ายคงต้องไปคุยกับฝ่ายขาย Enterprise โดยตรง ซึ่งน่าจะเสียเวลาและเพิ่มความเครียดที่อยากหลีกเลี่ยง

  • ช่วงนี้ Cloudflare ทำได้ดี แต่ยังขาดการจัดการสิทธิ์แบบละเอียด ตอนนี้ก็ยังต้องสร้างบัญชีแยกสำหรับสภาพแวดล้อม production อยู่ดี และโดเมนหนึ่งก็ผูกได้กับบัญชีเดียวเท่านั้น ทำให้ SSO ยุ่งเหยิง

    • ตัวผลิตภัณฑ์ยอดเยี่ยมและใช้อย่างพอใจมานาน แต่บล็อกช่วงหลังก็มีพลาดไปหลายครั้ง ความเสถียรก็ดูแกว่งอยู่พักหนึ่ง แต่ช่วงนี้เหมือนจะดีขึ้นแล้ว
    • ใช้ AWS มาหลายปีแล้วลองย้ายมา Cloudflare ประสบการณ์ใช้งานชอบมาก แต่สุดท้ายก็กลับไปเพราะกังวลเรื่องเดียวกัน น่าเสียดายเพราะมันเกือบจะพร้อมอยู่แล้วจริงๆ
    • เมื่อหลายปีก่อนย้ายทุกโปรเจกต์ไป Cloudflare และไม่เสียใจเลย ตอนนี้ใช้ Workers, D1, R2, Queues, Containers, KV
      การส่งอีเมลยังใช้ AWS อยู่ เลยอยากให้ Cloudflare มีตรงนี้บ้าง
    • วันนี้ฉันก็เพิ่งเปิดซัพพอร์ตทิกเก็ตขอ สิทธิ์แบบละเอียด เพิ่มเหมือนกัน
    • นี่แหละคือเหตุผลตรงๆ ที่ทำให้ใช้ Cloudflare กับงานจริงไม่ได้ แต่ชอบฟรีทีเออร์สำหรับงานอดิเรก

  • เพิ่งรู้จัก OpenFeature เป็นครั้งแรก ดูเจ๋งดี มีใครเคยลองรวมเข้าระบบบ้างไหม? https://openfeature.dev

    • ใช้ OpenFeature มาเยอะพอสมควร และเคยเป็นคนทำ initial commit ให้ client library บางตัวด้วย มันคืออนาคตของ feature flags จริงๆ และ ecosystem ก็โตเร็วมาก
      เพื่อความโปร่งใส ผมเป็น CTO ของ Flagsmith ตลอดหลายปีที่ผ่านมาเห็นเส้นการยอมรับ OpenFeature ที่ชัดเจนมาก แต่ก่อนเราต้องแนะนำลูกค้าว่าควรลองใช้ เดี๋ยวนี้ลูกค้ากลับเอา OpenFeature มาเป็น requirement เอง
      ตอนนี้การรองรับจาก vendor ก็ถือว่าสุกงอมพอสมควรแล้ว และครอบคลุมแทบทุกภาษา ถ้าคุณกำลังจะรวม feature flags เข้ากับบริการใหม่ หรือกำลังย้ายจากระบบทำเองไปใช้โซลูชัน third-party ก็แนะนำ OpenFeature
    • ค่อนข้างมีประโยชน์ เคยใช้ที่บริษัทก่อนหน้า โดยทำ backend แบบ custom เอง แต่ใช้สเปกและ SDK ของ OpenFeature
      ใช้เวลาประมาณ 2 สัปดาห์ในการทำ backend แบบ custom ที่สมบูรณ์ และ SDK สำหรับหลายภาษาก็ทำงานได้ไม่มีปัญหา เจอบั๊กหนึ่งจุด แต่พอรายงานไปก็ถูกแก้ภายในวันนั้นเลย

  • ยังไม่ค่อยเข้าใจ feature flags เท่าไร โดยพื้นฐานแล้วมันต่างจาก Boolean ในฐานข้อมูลยังไง?

    • ตัว flag เองจะเป็น Boolean, string, number หรืออะไรก็ตามนั้นเป็นส่วนที่ง่าย ส่วนยากคือ กฎการกำหนดเป้าหมายและการ rollout, หรือก็คือใครจะเห็น flag ไหน และข้อกำหนดที่ว่าต้องประเมินกฎเหล่านั้นได้อย่างรวดเร็วและสม่ำเสมอมาก
      ทีมที่ทำเองมักเจอว่าปัญหามันโตเร็วมากเมื่อฝั่ง product, marketing และ sales อยากทำ targeting ด้วยกฎที่ซับซ้อนขึ้น
      ถ้ามองภาพรวมมันไม่ใช่ปัญหาที่ยากเป็นพิเศษ แต่ขนาดของมันใหญ่ และต้องมีสิ่งที่มองไม่เห็นจำนวนมากตั้งแต่แรก
      โดยแก่นแล้ว feature flags ค่อนข้างใกล้กับระบบสิทธิ์ คือให้ผู้ใช้บางคนเข้าถึงฟีเจอร์บางอย่างได้ และใครก็ตามที่เคยจัดการระบบสิทธิ์จะรู้ว่าการเป็นสมาชิกกลุ่ม, กลุ่มแบบลำดับชั้น, role, ACL ฯลฯ ซับซ้อนได้แค่ไหน องค์ประกอบเหล่านี้คล้ายกับกฎ targeting หลายแบบในระบบ feature flags
    • พอมี percentage rollout, RBAC, audit log, A/B testing, และการตั้งค่าแบบ multivariate ก็ซับซ้อนขึ้นอย่างรวดเร็ว Boolean ตัวนั้นจะกลายเป็นทั้งระบบที่ต้องดูแลและปฏิบัติการ
    • มีบทความอธิบายละเอียดอยู่ที่นี่: https://martinfowler.com/articles/feature-toggles.html
    • มันไม่ได้เป็น Boolean เสมอไป ตัวอย่างเช่น feature flags มักถูกใช้กับ A/B rollout
      Cloudflare เองก็ใช้ภายในเพื่อปล่อยฟีเจอร์หรือบิลด์ใหม่ให้ลูกค้าฟรีก่อน แล้วค่อยๆ ขยายไปหาลูกค้ารายใหญ่ขึ้นหลังผ่านช่วงทำให้เสถียร
      feature flags ยังสามารถเปิดแบบสุ่มได้ คล้ายการทำ fuzz testing อย่าคิดแค่ว่าเป็นเรื่องของ “ของใหม่” มันอาจเป็น “การเปลี่ยนพฤติกรรมการทำงาน” ก็ได้
      คุณอาจมองว่ามันเป็น Boolean ที่ครอบอยู่เหนือ client ทั้งหมด แต่โดยทั่วไปแล้วไม่ได้ถูก implement แบบนั้น
    • คุณจะ implement ด้วย Boolean ในฐานข้อมูลก็ได้ ดังนั้นนั่นเป็นแค่ รายละเอียดของการ implement
      เสน่ห์หลักของ feature flags คือมันทำให้คุณทำงานกับฟีเจอร์ใหญ่ๆ ที่ต้องใช้เวลาหลายเดือนและหลายคอมมิตบน main branch ได้ สำหรับผมมันทำให้กระบวนการพัฒนาเบาและทำซ้ำได้มากขึ้น
      ต่างจากการต้องรักษา branch แยก และมีเป้าหมายการ deploy แยกสำหรับฟีเจอร์ที่กำลังพัฒนาขนาดใหญ่

  • feature flags มักถูกออกแบบเกินความจำเป็น
    แค่เช็กค่า config, ค่าในฐานข้อมูล, หรือ environment variable แล้วเลือกวิ่งไปทางหนึ่งหรืออีกทางหนึ่งแบบไดนามิกก็พอแล้ว
    เท่านั้นเอง คุณควรทำให้ฟีเจอร์มีขนาดเล็ก หรือรีแฟกเตอร์โค้ดให้สลับได้ง่ายในระดับสูง
    ถ้าทำแบบนั้นไม่ได้ การทำระบบ feature flags ที่ซับซ้อนก็อาจช่วยได้สำหรับการประสานการเปิดใช้ฟีเจอร์ข้าม microservices
    ถ้ามีฟีเจอร์เยอะ dashboard ก็อาจมีประโยชน์
    แต่ผมมองว่าทั้งสองอย่างเป็นสัญญาณแรงๆ ว่าควรหลีกเลี่ยง feature flags เพราะมันเหมาะกับการเปลี่ยนแปลงที่เป็น local และชั่วคราวมากกว่า ไม่อย่างนั้นความซับซ้อนจะสะสมจนจัดการและบำรุงรักษายาก

    • มันสมเหตุสมผลสำหรับการเปิดฟีเจอร์ให้บางเซกเมนต์ เช่น ผู้ใช้รายได้ต่ำในอิตาลี เพื่อดูผลกระทบทางธุรกิจหรือด้านประสิทธิภาพ
      แน่นอนว่าคุณคงไม่อยากให้ผู้ใช้เสียฟีเจอร์ไปเพียงเพราะรายได้เกินเกณฑ์หรือข้ามพรมแดน ดังนั้นจึงต้องมีการทำระบบติดตามบางอย่าง ทั้ง analytics และ error tracking ก็ต้องสื่อสารกับบริการ feature flags ด้วย
      มันไม่ถึงกับเป็นวิทยาศาสตร์จรวด แต่ก็ซับซ้อนกว่า environment variable แน่นอน
    • แก่นของ feature flags คือ วินัย ต้องสร้างมันอย่างมีเป้าหมาย และเมื่อมันไม่สร้างคุณค่าแล้วก็ควรถอดออกทันที หลัก KISS ใช้ได้เสมอ

  • รู้สึกคาดหวังเสมอเมื่อ Cloudflare เริ่มให้บริการสิ่งที่ก่อนหน้านี้ต้องไปใช้ผู้ให้บริการรายอื่น มีความเชื่อมั่นว่ามันน่าจะแข็งแกร่ง
    ที่ Function เคยใช้ Statsig ตอนแรกเริ่มจากมีคนสองคนใช้ในโปรดักต์เดียว แต่ภายใน 12 เดือน ข้อความในโปรดักต์และการทยอยปล่อยใช้งานส่วนใหญ่ก็ขับเคลื่อนด้วย Statsig
    Statsig มีการประเมินผลฝั่งไคลเอนต์ จึงเขียนกฎและการทยอยปล่อยใช้งานตามแนวคิดภายในได้โดยที่เซิร์ฟเวอร์ของ Statsig ไม่ต้องประมวลผลข้อมูลผู้ใช้
    หวังว่า Cloudflare จะทำผลิตภัณฑ์ที่ละเอียดประณีตในด้านนี้ออกมา เพื่อที่ต่อไปจะได้ไม่ต้องใช้ผลิตภัณฑ์อื่นอีก

    • รู้สึกแปลกที่ต้องฝากฟีเจอร์แฟลกไว้กับบุคคลที่สาม ไม่ได้ถึงกับเป็นสายที่บอกว่าต้องสร้างทุกอย่างเอง แต่ ฟีเจอร์แฟลก เป็นสิ่งที่สร้างเองได้โดยไม่มีปัญหาใหญ่อะไร

  • ผมเป็นแค่ผู้ใช้ทั่วไปที่ไม่ค่อยรู้รายละเอียดทางเทคนิค แต่รู้สึกว่า Cloudflare ใช้งานค่อนข้างง่าย หวังว่าจะทำได้ดีต่อไป

    • เป็น ผู้รับจดทะเบียนโดเมน DNS ที่ดีที่สุดเท่าที่เคยใช้มา