Cloudflare ซื้อ Deno แต่ผู้ใช้ต้องเริ่มวางแผนย้าย

Deno Deploy จะปิดหลังให้บริการต่ออีก 6 เดือน แปลว่าผู้ใช้มีช่วงเตรียมย้ายระบบจำกัด เมื่อทีม Deno ทั้งหมดประกาศเข้าร่วม Cloudflare ตามประกาศ Deno วันที่ 9 ตุลาคม ครับ TechCrunch รายงานการซื้อกิจการโดยระบุว่าไม่มีการเปิดเผยมูลค่าดีล

สำหรับคนที่จ้างทำระบบร้านค้า ข่าวนี้ควรนำไปสู่การเช็กว่าแอปทำงานอยู่ที่ไหน สำหรับคนเขียนโปรแกรมเอง ต้องแยกให้ออกระหว่าง Deno ตัวรันโปรแกรม กับ Deno Deploy บริการนำโปรแกรมขึ้นใช้งานออนไลน์ เพราะประกาศ Denoให้กรอบเวลาดูแลสองอย่างนี้ต่างกัน

สรุป 30 วินาที: เกิดอะไรขึ้น

Cloudflare ประกาศว่าจะให้ Ryan Dahl และ Bert Belder นำงานทำให้รูปแบบการสร้างแอปของ Cloudflare Workers ใช้บนระบบที่ผู้ใช้ดูแลเองได้สะดวกขึ้น Workers คือแพลตฟอร์มสร้างและรันซอฟต์แวร์บนเครือข่าย Cloudflare ตามคำอธิบายของTechCrunch เป้าหมายของดีลจึงมุ่งไปที่แพลตฟอร์มร่วม มากกว่าขยายผลิตภัณฑ์ Deno เดิมทุกตัว

ทีม Deno ระบุว่าจะดูแล Deno runtime ต่ออีก 1 ปี แปลว่ายังมีช่วงแก้ข้อผิดพลาดและอัปเดตความปลอดภัยก่อนทีมเดิมหยุดพัฒนา คำว่า runtime หมายถึงซอฟต์แวร์ที่ทำให้คำสั่งในโปรแกรมทำงานได้จริง ระหว่างช่วงดังกล่าวจะมีรุ่นอัปเดตรายเดือน แต่ประกาศไม่ได้รับปากว่าจะเดินหน้าพัฒนาฟีเจอร์ใหม่เหมือนเดิม

ส่วน Deno Deploy จะทำงานต่ออีก 6 เดือน แปลว่าบริการฝากรันแอปมีช่วงเปลี่ยนผ่านสั้นกว่าตัว runtime ตามประกาศเดียวกัน บริษัทจะช่วยลูกค้าที่จ่ายเงินย้ายไป Cloudflare Workers ขณะที่ JSR ซึ่งเป็นแหล่งรวมแพ็กเกจหรือชุดโค้ดให้โปรแกรมอื่นนำไปใช้ จะดำเนินงานต่อโดยย้ายโครงสร้างพื้นฐานไป Cloudflare ตามThe New Stack

ดีลนี้จึงมีทั้งงานที่จะพัฒนาต่อ งานที่จะปิด และงานที่จะเปลี่ยนผู้ดูแล หากชื่อ Deno ยังปรากฏในระบบที่คุณใช้ แค่นั้นพอจะบอกได้ไหมว่าต้องย้ายอะไร? ต้องตรวจทั้งตัวรันโปรแกรมและสถานที่ฝากรันครับ เพราะสองอย่างนี้มีผลต่อแผนงานคนละแบบ

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นเจ้าของร้านที่จ้างเอเจนซีทำระบบรับออร์เดอร์ สิ่งที่ควรตรวจคือบริการเบื้องหลังเว็บไซต์ ไม่จำเป็นต้องจำชื่อภาษาโปรแกรมทั้งหมด ขอให้ผู้รับจ้างตอบว่าระบบใช้ Deno หรือ Deno Deploy หรือไม่ และใครรับผิดชอบการย้าย คำแนะนำนี้เป็นการเตรียมตัวจากกรอบปิดบริการที่ Deno ประกาศ ไม่ได้หมายความว่าร้านค้าไทยทุกแห่งใช้บริการนี้

ตัวอย่างที่ควรนำไปตรวจ ได้แก่ LINE bot โปรแกรมตอบข้อความอัตโนมัติ ระบบหลังร้านที่จัดการข้อมูล และโครงงานนักเรียนที่เปิดให้คนอื่นใช้งานจริง ทั้งหมดนี้เป็นตัวอย่างงานของผู้อ่าน ไม่ใช่รายชื่อลูกค้าที่แหล่งข่าวยืนยัน ถ้างานของคุณฝากรันบน Deno Deploy กรอบปิดบริการย่อมเกี่ยวข้องกับแผนเปิดใช้งานต่อ ตามประกาศ Deno

สำหรับฟรีแลนซ์หรือทีมพัฒนาขนาดเล็ก ควรแยกงานที่ส่งลูกค้าแล้วออกจากงานที่ยังเริ่มต้นอยู่ งานที่ส่งแล้วต้องมีผู้รับผิดชอบต่อเนื่อง ส่วนงานใหม่ควรประเมินทิศทางแพลตฟอร์มก่อนเลือกเครื่องมือ เพราะทีม Deno ประกาศว่าจะนำแรงพัฒนาในอนาคตไปลงแพลตฟอร์มร่วม แทนการพัฒนา runtime และบริการฝากรันแยกต่างหาก

ถ้าคุณเป็นพนักงานที่เพียงเปิดเว็บใช้งาน ไม่ต้องเปลี่ยนเครื่องหรือหยุดใช้งานจากข่าวนี้ทันที สิ่งที่ควรทำคือส่งข่าวให้คนดูแลระบบตรวจสอบ ไม่มีแหล่งที่อ่านระบุว่าประกาศนี้ทำให้แอปทุกตัวหยุดทันที และประกาศต้นทางก็ยังให้ช่วงดำเนินงานต่อ การตรวจให้ตรงระบบจึงมีประโยชน์กว่าตื่นตระหนกจากชื่อบริษัท

ทำงานยังไง

Deno เป็น runtime สำหรับ JavaScript และ TypeScript ซึ่งเป็นภาษาที่ใช้เขียนโปรแกรม ตามThe New Stack ส่วน Deno Deploy เป็นบริการนำโปรแกรมไปทำงานออนไลน์ ดังนั้นการมีไฟล์โปรแกรมอยู่ในมือ กับการมีบริการเปิดให้ลูกค้าเข้าถึงได้ เป็นคนละเรื่อง การหยุดพัฒนาตัวรันกับการปิดบริการฝากรันจึงต้องจัดการแยกกัน

Workers ใช้แนวทาง serverless หมายถึงนักพัฒนาใช้บริการรันแอปโดยไม่ต้องจัดการโครงสร้างพื้นฐานข้างใต้เอง ตามคำอธิบายของThe New Stack ไม่ได้หมายถึงไม่มีเครื่องเซิร์ฟเวอร์ แต่เปลี่ยนว่าใครดูแลส่วนนั้น ส่วน self-hosting คือการนำซอฟต์แวร์ไปทำงานบนโครงสร้างพื้นฐานที่เราเลือกและดูแลเอง ซึ่งเป็นจุดที่Cloudflare ต้องการพัฒนาให้สะดวกขึ้น

ลองนึกถึงทีมครัวของร้านเดลิเวอรีที่ย้ายไปทำงานกับเครือศูนย์อาหารใหญ่ครับ สูตรอาหารคือโปรแกรม ชุดอุปกรณ์ที่ทำให้ปรุงได้คือ runtime และร้านที่รับออร์เดอร์ออนไลน์คือบริการฝากรัน ถ้าใช้ร้านที่มีคนจัดการครัวให้ ก็คล้าย serverless แต่ถ้าจัดพื้นที่และดูแลครัวเอง ก็คล้าย self-hosting การจ้างทีมครัวเดิมไป ไม่ได้แปลว่าหน้าร้านเดิมจะเปิดตลอดไป อุปมานี้ช่วยแยกบทบาท ไม่ได้หมายความว่าระบบย้ายง่ายเท่าขนหม้อไปอีกตึก

Cloudflare ระบุว่า workerd เป็น runtime แบบโอเพนซอร์สของ Workers คำว่าโอเพนซอร์สหมายถึงเปิดโค้ดให้ตรวจและนำไปใช้ตามเงื่อนไขใบอนุญาต บริษัทบอกว่านี่เป็นโค้ดเดียวกับที่ใช้ในระบบให้บริการจริง ไม่ใช่ตัวเลียนแบบที่ทำขึ้นแยกต่างหาก แต่ยอมรับว่าเครื่องมือและบริการประกอบสำหรับคนที่รันเองยังพัฒนาได้ไม่ดีพอ

จุดที่บริษัทระบุว่าเป็นข้อจำกัดคือ Durable Objects ซึ่งช่วยจัดการส่วนของแอปที่ต้องเก็บสถานะและประสานงานต่อเนื่อง Cloudflare อธิบายว่าใน workerd ตอนนี้ส่วนดังกล่าวทำงานแบบอินสแตนซ์เดียว หรือชุดทำงานเดียว เหมาะกับการทดสอบบนเครื่อง แต่ยังขยายการทำงานไม่ได้ตามที่ผู้รันระบบจริงต้องการ นี่คือข้อจำกัดที่บริษัทเปิดเผยเอง ไม่ใช่ผลทดสอบของเรา

โครงการ celld ของ Deno ทำ Workers และ Durable Objects ในรูปแบบที่เน้นรันเองและขยายระบบได้ ตามCloudflare แผนต่อไปคือรวมโค้ดและแนวคิดจาก celld กลับเข้า workerd ทีมจึงเปลี่ยนจากดูแลผลิตภัณฑ์เดิมแยกกัน มาแก้ปัญหาการนำรูปแบบ Workers ไปใช้ในสถานที่อื่น แต่รายละเอียดงานที่เสร็จสมบูรณ์ยังต้องรอประกาศต่อไป

จุดหักมุม: ซื้อกิจการแล้ว แต่ผู้ใช้ต้องเริ่มนับเวลา

คำว่าซื้อกิจการฟังเหมือนมีคนมาช่วยขยายงาน แต่ทีม Deno บอกตรงๆว่าตัดสินใจเลือกจุดลงแรง และจะไม่พัฒนา runtime กับบริการฝากรันแยกต่อไป ผู้ใช้เดิมจึงต้องมองทั้งโอกาสของแพลตฟอร์มใหม่และภาระเปลี่ยนผ่านของตัวเอง

ตัว runtime จะยังเป็นโอเพนซอร์ส และเปิดรับคนมาพัฒนาต่อ ตามประกาศ Deno แต่คำว่าเปิดโค้ดไม่ได้เป็นคำรับประกันว่าจะมีทีมใหม่รับช่วง พร้อมตารางอัปเดตและบริการช่วยเหลือเหมือนเดิม เรื่องหลังนี้ยังไม่มีรายละเอียดในแหล่งที่อ่านครับ

เรื่องเงิน / ผลกระทบ

TechCrunch ระบุว่าไม่ได้เปิดเผยมูลค่าซื้อกิจการ และThe New Stackรายงานตรงกัน เราจึงบอกไม่ได้ว่าดีลนี้ใหญ่แค่ไหนในแง่เงิน และไม่ควรใช้ตัวเลขเงินลงทุนในอดีตแทนราคาซื้อจริง สำหรับลูกค้า คำถามเรื่องงบย้ายแอปมีประโยชน์กว่าการเดาราคาบริษัท

ประกาศ Denoรับปากให้ความช่วยเหลือย้ายไป Workers แก่ลูกค้าที่จ่ายเงิน แต่ไม่ได้ระบุขอบเขตงาน เวลาให้บริการ หรือเงื่อนไขค่าใช้จ่ายทั้งหมด คำว่าให้ความช่วยเหลือจึงยังไม่พอจะสรุปว่าฟรีทุกขั้นตอน ผู้ใช้แบบไม่จ่ายเงินก็ยังไม่มีคำรับปากเรื่องความช่วยเหลือแบบเดียวกันในข้อความที่อ่าน

สำหรับเจ้าของกิจการ ผมแนะนำให้ขอใบประเมินงานย้ายที่แยกค่าพัฒนาออกจากค่าบริการหลังย้าย ถามด้วยว่าใครทดสอบ ใครแก้ปัญหา และใครดูแลต่อหลังส่งงาน นี่เป็นคำแนะนำจัดการงาน ไม่ใช่ราคาที่บริษัทประกาศ แหล่งข่าวชุดนี้ยังไม่มีข้อมูลให้คำนวณบิลใหม่ของร้านคุณ หรือยืนยันว่าจะถูกลงหลังย้าย

สำหรับทีมพัฒนา ควรเปรียบเทียบการย้ายไป Workers กับทางเลือกที่ดูแลระบบเองตามความพร้อมของทีม Cloudflare เสนอทิศทางให้ workerd รันเองได้ดีขึ้น แต่ไม่ได้ให้ตารางต้นทุนครบทุกแบบในประกาศ การเลือกทางที่เปิดโค้ดไม่ได้ทำให้ภาระดูแลหายไปโดยอัตโนมัติ จึงควรเขียนรายการงานที่ต้องรับผิดชอบก่อนประเมินว่าแบบใดเหมาะ

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

กรอบเวลาสอดคล้องกัน แต่ยังไม่มีวันปิดแบบระบุวันที่ Denoบอกว่าดูแล runtime ต่ออีก 1 ปี แปลว่าเป็นช่วงสนับสนุนก่อนทีมเดิมยุติการพัฒนา The New Stackรายงานช่วงเดียวกัน พร้อมการอัปเดตรายเดือน ทั้งคู่ระบุว่า Deploy จะปิดหลังอีก 6 เดือน แปลว่าเป็นเวลาสำหรับเตรียมย้ายบริการ ไม่ใช่วันปิดที่แจ้งเป็นวันที่ชัดเจน

หากนับจากวันที่ประกาศ กรอบ Deploy ชี้ไปแถวเดือนเมษายนปีหน้า ส่วน runtime ชี้ไปแถวเดือนตุลาคมปีหน้า นี่เป็นการคำนวณช่วงเวลาโดยผู้เขียนจากประกาศวันที่ 9 ตุลาคม ไม่ใช่กำหนดปิดอย่างเป็นทางการ อย่าตั้งวันส่งงานจากการบวกเดือนเพียงอย่างเดียว ควรขอให้ผู้ให้บริการยืนยันกำหนดที่ใช้กับบัญชีของคุณอีกครั้ง

เสียงสนับสนุนมาจากผู้ทำดีล Ryan Dahl อธิบายในบล็อก Denoว่าต้องการทำให้รูปแบบ Workers เป็นวิธีหลักในการสร้างเซิร์ฟเวอร์ ทั้งบน Cloudflare และระบบของผู้ใช้เอง Kenton Varda อธิบายในบล็อก Cloudflareว่าการเปิดทางให้ย้ายออกเป็นผลดีต่อธุรกิจ จึงมีแรงจูงใจทำให้รูปแบบนี้ใช้ได้กว้างขึ้น

ข้อกังวลเรื่องผูกติดผู้ให้บริการมีอยู่ แต่ยังไม่มีเสียงค้านดีลที่ระบุชื่อในชุดแหล่งนี้ Cloudflareยกข้อกล่าวหาว่า Workers ต่างจากแพลตฟอร์มอื่นเพื่อทำให้ย้ายออกยาก แล้วปฏิเสธข้อกล่าวหานั้น ส่วนThe New Stackถาม Dahl โดยตรงเรื่องหลักประกันไม่ให้ผู้ใช้ติดกับผู้ขายรายเดียว เขาตอบโดยชี้ไปที่การเปิดโค้ดและความตั้งใจของทีม เราจึงมีคำตอบของบริษัทต่อข้อกังวล แต่ไม่มีบุคคลหรือองค์กรฝ่ายคัดค้านให้ยกคำพูดเป็นตัวแทน และไม่ควรแต่งขึ้นมา

อนาคตโค้ดเปิดกับอนาคตทีมดูแลยังเป็นคนละเรื่อง Dahl บอกThe New Stackว่าชุมชนสามารถพัฒนา Deno ต่อได้ โดยตัว runtime ยังใช้ใบอนุญาต MIT สำหรับโครงการรวม เขาคาดว่าจะยังเปิดโค้ด และน่าจะใช้ Apache 2.0 ตามรายงานเดียวกัน คำว่าน่าจะต้องคงไว้ เพราะยังไม่ใช่ข้อยืนยันใบอนุญาตสุดท้ายของงานทั้งหมด

หากมีชุมชนแยกโค้ดไปพัฒนาต่อ ใครจะรับผิดชอบอัปเดตความปลอดภัยให้ระบบร้านค้า? ในแหล่งที่อ่านยังไม่มีชื่อทีมใหม่หรือแผนสนับสนุนที่รับประกันได้ Denoเพียงเปิดรับผู้ที่ต้องการพัฒนาต่อ ส่วน JSR ได้รับคำยืนยันว่าจะดำเนินงานต่อ แต่รายละเอียดการเปลี่ยนผ่านและเงื่อนไขในอนาคตยังไม่ได้อธิบายครบในประกาศนี้

แล้วเราควรทำอะไร

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

เจ้าของร้าน ผู้จัดการ หรือคนที่จ้างเอเจนซี

1. ส่งชื่อเว็บไซต์หรือแอปให้ผู้รับจ้าง แล้วขอคำตอบเป็นข้อความว่าใช้ Deno runtime หรือ Deno Deploy หรือไม่ ขอแยกคำตอบ เพราะการใช้ตัวรันไม่ได้ยืนยันว่าฝากรันบนบริการเดียวกัน
2. ถ้าใช้ Deploy ให้ขอชื่อผู้ถือบัญชี สถานะการจ่ายเงิน และผู้ประสานงานย้ายระบบ การช่วยย้ายที่บริษัทประกาศระบุเฉพาะลูกค้าที่จ่ายเงิน จึงควรตรวจสิทธิ์ก่อนตั้งความคาดหวัง
3. ขอแผนงานที่ระบุวันทดสอบ วันเปลี่ยนระบบ และวิธีรับมือหากงานจริงมีปัญหา ให้ผู้รับจ้างแยกค่าบริการใหม่ออกจากค่าทำงานย้าย เพื่อพิจารณางบได้ชัดเจน

ฟรีแลนซ์ ทีมพัฒนา และฝ่าย IT

1. ทำรายการแอปที่ใช้ Deno พร้อมที่รันจริงและคนดูแล แยกแอปบน Deploy ออกจากแอปที่รันบนระบบอื่น อย่าเริ่มเปลี่ยนทุกโครงการเพียงเพราะค้นเจอคำว่า Deno ในไฟล์
2. ถ้าเป็นลูกค้าจ่ายเงิน ติดต่อเรื่องความช่วยเหลือไป Workers ตามประกาศ Deno แล้วขอรายละเอียดขอบเขตก่อนรับปากลูกค้า ยังไม่มีหลักฐานในชุดนี้ว่าบริษัทจะย้ายงานทุกแบบให้เสร็จแทนทีมคุณ
3. ทดลองระบบปลายทางด้วยงานที่ลูกค้าใช้จริง เช่น รับข้อความหรือบันทึกออร์เดอร์ตามหน้าที่ของแอป ตรวจผลก่อนเปลี่ยนงานจริง และบันทึกส่วนที่ต้องแก้ไว้ในแผนส่งมอบ
4. ถ้าจะรัน workerd เอง ให้อ่านข้อจำกัดที่Cloudflare เปิดเผย โดยเฉพาะการขยาย Durable Objects อย่านับความสามารถที่บริษัทกำลังจะพัฒนาเป็นความสามารถที่พร้อมแล้ว
5. สำหรับแอปที่ยังใช้ runtime เดิม วางรอบติดตามอัปเดตช่วงที่ทีม Deno ยังดูแล พร้อมตัดสินใจล่วงหน้าว่าจะทำอย่างไรเมื่อการพัฒนาทางการสิ้นสุด อย่าฝากแผนธุรกิจไว้กับชุมชนที่ยังไม่มีผู้รับช่วงชัดเจน

นักเรียน นักศึกษา และคนทำโครงงาน

1. ถ้าโครงงานเปิดให้คนอื่นใช้บน Deploy ให้แจ้งอาจารย์หรือทีมว่าต้องตรวจแผนย้ายบริการ แยกประเด็นนี้จากการเรียนภาษา เพราะข่าวนี้ไม่ได้ประกาศให้เลิกเรียน JavaScript หรือ TypeScript
2. เก็บคำอธิบายวิธีรันและผู้รับผิดชอบให้คนอื่นอ่านต่อได้ หากใช้โปรแกรมเฉพาะบนเครื่อง ให้ตรวจว่าพึ่งพาบริการออนไลน์ใดอยู่บ้างก่อนสรุปว่าต้องย้ายหรือไม่
3. ติดตามประกาศต้นทางแทนการเชื่อวันที่ปิดจากโพสต์ส่งต่อ กรอบเดือนที่คำนวณในบทความนี้ใช้เตรียมงานได้ แต่ยังแทนกำหนดทางการไม่ได้

ผมมองว่า…

ผมมองว่าเรื่องนี้ไม่ใช่การแข่งขันว่าค่ายไหนชนะ แต่คือการตรวจว่าใครจะดูแลระบบที่เราฝากงานไว้ต่อจากนี้ การรวมทีมอาจช่วยแก้ปัญหา self-hosting ตามที่Cloudflare วางแผน แต่ประโยชน์นั้นไม่ได้ลบงานย้ายของผู้ใช้เดิม เจ้าของร้านจึงควรขอแผนที่ตรวจได้ มากกว่ารับคำตอบกว้างๆ ว่ามีบริษัทใหญ่แล้วสบายใจได้

ผมมองว่าทีมเล็กควรเลือกทางที่ตัวเองรับผิดชอบได้จริง การรอแพลตฟอร์มร่วม การย้ายบริการ หรือการใช้โค้ดที่ชุมชนดูแล ล้วนต้องมีเจ้าของงานชัดเจน เราไม่จำเป็นต้องทำนายว่าโครงการใหม่จะสำเร็จแค่ไหน เพื่อเริ่มตรวจบัญชีและประเมินงบวันนี้ ข่าวยังมีช่องว่าง แต่รายการระบบของเราไม่ควรมีช่องว่างตามไปด้วยครับ

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่เปลี่ยนสำหรับผู้ใช้คือระยะเวลาที่มีทีมเดิมดูแล ไม่ใช่เพียงชื่อบริษัทบนประกาศ สิ่งแรกที่ควรติดตามคือกำหนดปิด Deploy และรายละเอียดช่วยย้ายจากDeno อีกเรื่องคือความคืบหน้าทำ workerd ให้รันเองได้ครบขึ้น ซึ่งCloudflare บอกว่าจะมีประกาศเพิ่มเติมในเดือนต่อๆ ไป

ถ้าคุณจ้างทำแอปหรือเว็บไซต์ไว้ ตอนนี้คุณมีชื่อคนที่รับผิดชอบแผนย้ายระบบนั้นแล้วหรือยัง?

Recap

• เกิดอะไรขึ้น: ทีม Deno ทั้งหมดไป Cloudflare และนำงานพัฒนาไปลงแพลตฟอร์มร่วม ตามประกาศ Deno
• ตัวเลขที่ต้องจำ: Deploy ทำงานต่ออีก 6 เดือน แปลว่าต้องเตรียมเปลี่ยนบริการก่อนปิด ตามDeno
• แยก runtime ออกมา: สนับสนุนอีก 1 ปี แปลว่ายังมีอัปเดตแก้บั๊กและความปลอดภัยก่อนทีมเดิมหยุดพัฒนา ตามDeno
• ใครเห็นต่าง: Cloudflare ปฏิเสธข้อกล่าวหาเรื่องทำให้ย้ายออกยาก แต่ชุดแหล่งนี้ไม่มีฝ่ายค้านดีลที่ระบุชื่อ ดูคำชี้แจง Cloudflareและคำถามของ The New Stack
• ยังไม่รู้: วันปิดแบบระบุวันที่ ค่าใช้จ่ายหลังย้าย ขอบเขตช่วยย้าย และทีมชุมชนที่จะรับช่วง runtime
• ผลต่อคุณ: ตรวจว่าแอปร้านค้า bot หรือโครงงานใช้บริการใด ขอแผนย้ายและงบจากผู้ดูแลก่อนตัดสินใจ
• จับตา: รายละเอียดเปลี่ยนผ่าน Deploy และความพร้อมของ workerd สำหรับระบบที่ผู้ใช้ดูแลเอง
• แหล่งอ้างอิง: 1 — Cloudflare · 2 — TechCrunch · 3 — The New Stack · 4 — Deno