- หลังจาก Fly.io ระดมทุนราว 25 ล้านดอลลาร์ ($25m) จาก A16Z และนักลงทุนเดิมอย่าง Intel Capital, Dell เป็นต้น ในเดือนกรกฎาคม 2023 ก็ได้รับเงินเพิ่มอีกราว 70 ล้านดอลลาร์ ($70m) ภายใต้การนำของ EQT Ventures
- โจทย์สำคัญคือ แม้แอปจะทำงานได้ดีขึ้นเมื่อรันใกล้ผู้ใช้ แต่สำหรับนักพัฒนาทั่วไปแล้ว การทำความเข้าใจการดีพลอยหลายเมืองให้ได้ภายใน 2 ชั่วโมง นั้นเป็นเรื่องยาก
- Fly.io มองว่าทั้งการดีพลอยระดับโลก, on-demand VM, ฟีเจอร์เรียลไทม์, user presence, การเข้ารหัสและซีเคร็ต, ฐานข้อมูลแบบคลัสเตอร์, รวมถึงการอนุมานด้วยฮาร์ดแวร์เร่งความเร็ว ล้วนเป็นปัญหาแบบ 2 ชั่วโมง เหมือนกัน
- เงินลงทุนจะถูกนำไปใช้กับ ฮาร์ดแวร์ฟลีต ของบริษัทเอง, เพิ่มจำนวนรีเจียน, การซัพพอร์ตและเสถียรภาพ, ฟีเจอร์สตอเรจและความปลอดภัยขั้นสูง, รวมถึงการทดลองฮาร์ดแวร์ใหม่
- Fly.io จะยังคงรักษาแนวทางเป็น แพลตฟอร์มที่เป็นมิตรกับนักพัฒนา ซึ่งทดลองได้รวดเร็วหลังสมัครใช้งานออนไลน์ และรันแอปได้ด้วยคำสั่ง
flyctlเพียง 1-2 คำสั่งพร้อมการแพ็กเกจเป็นคอนเทนเนอร์
การระดมทุนของ Fly.io
- Fly.io ระดมทุน 25 ล้านดอลลาร์ ในเดือนกรกฎาคม 2023 จากนักลงทุนที่รวมถึง A16Z และนักลงทุนเดิมอย่าง Intel Capital, Dell เป็นต้น
- หลังจากนั้นก็ได้รับเงินลงทุนเพิ่มเติม 70 ล้านดอลลาร์ ภายใต้การนำของ EQT Ventures
- หนึ่งในเป้าหมายเชิงปฏิบัติของการประกาศการลงทุนคือการหาลูกค้า
- มีทั้งลูกค้าที่สบายใจจะทำธุรกิจกับ Fly.io ที่ยังเล็กอยู่ และลูกค้าที่จะมั่นใจก็ต่อเมื่อเป็น Fly.io ที่เพิ่งได้รับเงินลงทุนเพิ่ม 70 ล้านดอลลาร์ภายใต้การนำของ EQT Ventures
- ตลอดหลายปีที่ผ่านมา Fly.io ได้พูดคุยกับผู้ใช้ แฟน ๆ และผู้วิจารณ์ใน ชุมชน เพื่อขัดเกลา วิสัยทัศน์ของแพลตฟอร์ม ที่พวกเขาต้องการสร้าง
“ปัญหา 2 ชั่วโมง” และการดีพลอยระดับโลก
- ความเชื่อพื้นฐานของ Fly.io ในปี 2020 คือ แอปจะทำงานได้ดีกว่าเมื่อรันอยู่ใกล้ผู้ใช้มากขึ้น
- แอปอย่างวิดีโอหรือ presence แบบเรียลไทม์ ถูกจัดเป็นประเภทที่ทำได้ยากหากไม่มี ความใกล้ชิดทางกายภาพ
- ใน เธรดเปิดตัวบน HN ช่วงแรก เดิมคาดว่าประเด็นหลักจะเป็น WebRTC, edge caching และเกมเซิร์ฟเวอร์ แต่ความสนใจจริงกลับไหลไปทางฐานข้อมูล
- จุดที่ Fly.io มองพลาดไปคือการคิดว่ามีเพียงแอป “สาย edge” บางประเภทเท่านั้นที่ต้องการการดีพลอยระดับโลก
- ความจริงคือแอปส่วนใหญ่ก็อยากรันบน edge เช่นกัน แต่จะลองก็ต่อเมื่อมันง่ายพอ
- เกมเซิร์ฟเวอร์จำเป็นต้องดีพลอยบน edge ทำให้ทีมเดินหน้าผลักดันต่อไปจนกว่าปัญหาจะถูกแก้
- แต่แอป CRUD อย่างร้านหนังสือออนไลน์ หากลองอยู่ราว 2 ชั่วโมง แล้วก็ยังไม่เห็นแนวทางที่ชัดเจน ก็จะถูกพักไว้แล้วไปทำอย่างอื่นแทน
ข้อจำกัดของแนวทางการดีพลอยอินเทอร์เน็ตในปัจจุบัน
- มีการชี้ว่าปัญหาคือแอป CRUD จำนวนมากทั่วโลกถูกโฮสต์อยู่ใกล้ Ashburn, Virginia ซึ่งเป็นที่ตั้งของ Amazon
us-east-1 - นักพัฒนาจำนวนมากเข้าใจว่าการรันใกล้ผู้ใช้ย่อมดีกว่า แต่ด้วยเครื่องมือทั่วไปแล้ว การทำความเข้าใจวิธีรันแอปพร้อมกันหลายเมืองให้ได้ภายใน 2 ชั่วโมง นั้นเป็นเรื่องยาก
- สิ่งที่ Fly.io เดิมพันไว้คือ หากมีแพลตฟอร์มและ toolchain ที่เหมาะสม แอปอย่างร้านหนังสือ แอปให้คะแนนแซนด์วิช ระบบแนะนำเพลง หรือระบบจัดการเมลลิงลิสต์ของโบสถ์ ก็สามารถรันได้อย่างรวดเร็วทั่วโลก
- พื้นที่เป้าหมายไม่ได้จำกัดแค่รอบ ๆ Ashburn แต่รวมถึงเมืองอย่าง Chicago, Sydney, Singapore และ São Paulo
- ความสามารถในการทำงานได้รวดเร็วพร้อมกันในหลายเมือง ถูกมองว่าเป็นฟีเจอร์สำคัญที่ช่วยยกระดับคุณภาพของแอป
Fly Machines และฟีเจอร์ “2 ชั่วโมง” อื่น ๆ
- ระบบ sandboxing, โค้ดเอดิเตอร์ และ REPL รวมถึงแอปพลิเคชัน CI/CD ต่างก็ต้องรันโค้ดของลูกค้าที่ไม่น่าเชื่อถือ
- ระบบเหล่านี้ล้วนต้องหาทางเปิด คอนเทนเนอร์ที่ถูกล็อกไว้ ขึ้นมาใช้งานเมื่อจำเป็นด้วยวิธีของตัวเอง
- แต่ on-demand VM เป็นฟีเจอร์ที่มีคุณค่ามากกับแอปหลากหลายประเภท ทั้งที่เส้นทางการพัฒนายังไม่ชัดเจนจากการค้นคว้าเพียง 2 ชั่วโมง
- เพราะแบบนั้น Fly.io จึงสร้าง Fly Machines ขึ้นมา และต้องการทำให้การเปิด VM ง่ายเหมือนการเรียกฟังก์ชัน
- เป้าหมายต่อไปก็อยู่ในแพตเทิร์นเดียวกัน
- ฟีเจอร์เรียลไทม์และ user presence
- การเข้ารหัสและการเก็บซีเคร็ต
- ฐานข้อมูลแบบคลัสเตอร์
- การอนุมานด้วยฮาร์ดแวร์เร่งความเร็ว
- บริษัทอื่นในด้านฐานข้อมูลแบบกระจาย, data locality, สตอเรจ, AI และเฟรมเวิร์กแอปพลิเคชัน ก็กำลังพยายามแก้ปัญหา “หน้าต่าง 2 ชั่วโมง” ของนักพัฒนาเช่นกัน
- หาก Fly.io ทำงานได้ตามที่ตั้งใจไว้ แพลตฟอร์มเหล่านั้นก็จะสามารถสร้าง primitive ใหม่บนมัน ส่งไอเดียใหม่ให้ผู้ใช้ได้เร็วขึ้น และเพิ่มคุณภาพของแอปได้
เหตุผลที่ต้องใช้เงินลงทุน
- Fly.io มองว่าการสร้างแพลตฟอร์มลักษณะนี้จำเป็นต้องมีองค์ประกอบที่ ใช้เงินลงทุนสูง
-
ฮาร์ดแวร์ฟลีตของตัวเอง
- Fly.io รันอยู่บนฮาร์ดแวร์ของตัวเองมาโดยตลอด
- การนำฮาร์ดแวร์ไปติดตั้งในแร็กด้วยตัวเองแทนการสร้างทับบนคลาวด์ทั่วไป มีทั้งเหตุผลด้านเทคนิคและเหตุผลด้านการควบคุม
- แต่เหตุผลสำคัญที่สุดคือเรื่องความคุ้มค่าทางเศรษฐศาสตร์
- หากต้องการให้ผู้คนสร้างแอปบนแพลตฟอร์ม ก็ต้องแสดงให้เห็นว่าบริษัทมีโอกาสยังอยู่ต่อไปอีก 10 ปี และมองว่าฮาร์ดแวร์ช่วยให้เกิดมาร์จินที่จำเป็น
-
รีเจียนที่มากขึ้น
- Fly.io เริ่มต้นด้วย 19 รีเจียน และมองว่าหากโฟกัสเฉพาะนักพัฒนาแอปแต่ละรายก็ถือว่าเพียงพอ
- แต่ Fly.io ต้องการให้แพลตฟอร์มอื่นอย่างฐานข้อมูลแบบ managed และเครื่องมือสำหรับนักพัฒนา มารันอยู่บน Fly.io ด้วย
- บริษัทเหล่านั้นต้องการรีเจียนมากกว่านี้
- ปัจจุบัน Fly.io เพิ่มเป็น 33 รีเจียน แล้ว และความเร็วในการเปิดรีเจียนใหม่ก็ดีขึ้นเรื่อย ๆ
-
การซัพพอร์ตและเสถียรภาพ
- Fly.io ตระหนักดีว่าแพลตฟอร์มยังมีโจทย์เรื่องเสถียรภาพขนาดใหญ่
- พวกเขาไม่ได้มองว่าเป็นปัญหาที่แก้ได้ด้วยวิธีฉลาด ๆ เพียงอย่างเดียว
- บริษัทยังต้องการลงทุนเพิ่มกับสตอเรจขั้นสูง ฟีเจอร์ความปลอดภัย และฮาร์ดแวร์รูปแบบใหม่
ทิศทางของแพลตฟอร์มที่ไม่เปลี่ยนไป
- ทิศทางของบริษัทแพลตฟอร์มที่ Fly.io อยากเป็นนั้นไม่ได้เปลี่ยนไปตั้งแต่ปี 2020
- เป้าหมายคือเป็น แพลตฟอร์มที่ลองใช้ได้ภายใน 5 นาที หลังสมัครออนไลน์
- อีกด้านหนึ่งคือแพลตฟอร์มที่หลังสมัครออนไลน์แล้วจะมีเซลส์ติดต่อมา เสนอราคา และนัดเดโม
- พวกเขาต้องการแพลตฟอร์มที่เข้าใจได้โดยไม่ต้องอ่านคู่มือ
- ตรงข้ามกับแพลตฟอร์มที่มีหนังสือสอนใช้งานออกมาแข่งขันกัน และต้องมีใบรับรองเฉพาะทางถึงจะรันแอปได้
- ต้องสามารถรันโค้ด Python, Rust, Julia ได้อย่างเป็นธรรมชาติ
- ตรงข้ามกับแนวทางที่ต้องคอมไพล์โค้ดกลับไปเป็น JavaScript ใหม่
- ฟีเจอร์ของ Fly.io ส่วนใหญ่ใช้งานได้ด้วยคำสั่ง
flyctlเพียง 1-2 คำสั่ง และถ้าแอปสามารถแพ็กเกจเป็นคอนเทนเนอร์ได้ก็ใช้งานได้ - หากมี Docker container ที่รันได้อยู่แล้ว ก็สามารถทดลองบน Fly.io ได้ทันที
- ต่อให้เริ่มจากศูนย์ ก็ควรทำให้รันบน Fly.io ได้ภายในเวลาไม่กี่นาทีระดับเลขหลักเดียว
- ส่วนการรันในทุกทวีปอาจใช้เวลาเพิ่มจากนั้นอีกราว 1-2 นาที
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สำนวนว่า "ระดมทุนได้เยอะ" เดี๋ยวนี้ในมุมลูกค้าของบริการไหน ๆ กลับทำให้กังวลก่อน
มันให้ความรู้สึกว่าบริษัทนั้นขับเคลื่อนด้วยเงิน VC ล้วน ๆ และราคาที่ฉันใช้อยู่หรือจ่ายอยู่นั้นไม่ใช่ต้นทุนในอนาคตที่สมจริง อีกทั้งแพลตฟอร์มก็โตต่อไปเรื่อย ๆ โดยไม่เกี่ยวกับรายได้
ในฐานะลูกค้า การได้ยินว่าบริษัท ทำกำไรได้ จากการดำเนินงานและฐานลูกค้าที่จ่ายเงินจริง ฟังดูน่าเชื่อถือกว่าในแง่ความมั่นคง
ไม่ได้คัดค้านตัวบทความนะ แต่ในมุมลูกค้า มันยากจะมองเป็นสัญญาณบวกเหมือนเมื่อก่อนแล้ว
แล้ววันหนึ่งก็อ้างว่าฉันกำลังใช้แพลตฟอร์มสุดยอดแบบฟรี ๆ อยู่ เลยขึ้นราคาแบบหลุดโลก
มันคล้ายกับการจ้างคนมาตัดหญ้า แล้วอีกไม่กี่ปีเขาขับรถตัดหญ้าขนาดใหญ่มา 3 คัน บอกว่าต้องขึ้นราคาเพื่อให้คุ้มกับต้นทุนบริการที่ฉันได้รับ
พวกเขาขยายธุรกิจเพื่อรองรับลูกค้าสนามหญ้า 10 เอเคอร์ แล้วก็ตั้งสมมติฐานว่าฉันเองก็ต้องการบริการระดับเดียวกัน สุดท้ายคนที่เสียประโยชน์เรื่องการดูแลสนามหญ้าก็คือฉัน
ถ้าเป็นนักลงทุนก็คงกังวลเรื่องการพึ่งพา VC ได้ แต่ในฐานะผู้ใช้ การได้กินอาหารราคาถูกจากบริการอย่าง Hello Fresh ที่มี เงินลงทุนช่วยอุดหนุน ก็ไม่ได้แย่อะไร
ดูแล้วคงขายกิจการเพื่อ exit ได้ในอีกไม่นาน แต่ถ้ามีความอึดพอจะไปต่อในฐานะบริษัทอิสระได้ก็น่ายินดีมาก
มันทำให้รู้สึกว่าผลิตภัณฑ์ได้รับการพิสูจน์แล้ว มีโอกาสสำเร็จสูงกว่าคู่แข่ง ไม่น่าหายไปไหนในเร็ว ๆ นี้ และคงพัฒนาผลิตภัณฑ์ได้เร็วขึ้นด้วย
มุกที่ว่า “แอป CRUD ทั่วโลกไปกองอยู่ที่ Loudoun County, VA หรือก็คือ Ashburn ของ Amazon us-east-1 และในเมืองนั้นมีแอป Rails เยอะมากจนมีหนึ่งแอปได้รับเลือกตั้งเข้าเป็นกรรมการกำกับดูแลของเคาน์ตี” มันจริงเกินไปจนเจ็บ
พอมองดี ๆ พาราไดม์เรื่อง region เองก็ออกจะเก่าไม่น้อยในภาพรวม AWS เองก็มีความพยายามบางอย่าง แต่สุดท้ายก็ยังติดกับแนวคิด region อยู่มาก ทั้ง control plane ความประหลาดของ VPC การคิดค่าบริการที่เข้าใจยาก ปัญหาเรื่องความพร้อมใช้งาน รวมถึงสารพัดแฮ็ก สแตก และความพยายามที่ต้องใช้เพื่อจัดการหลาย region/AZ
ผู้เล่นทีหลังอย่าง Fly และ Cloudflare ที่ใช้แนวทางรันคอมพิวต์บน edge โดยไม่ยึดกับแนวคิด region กำลังค่อย ๆ ครองพื้นที่คลาวด์มากขึ้น ส่วนแนวทางแบบ region ของ AWS ก็น่าจะเหลือไว้สำหรับแอป legacy ที่ติดอยู่ในกรอบนั้น
แนวทางแบบ region ใกล้เคียงกับ ดาต้าเซ็นเตอร์แบบยืดหยุ่นที่มีคนโฮสต์ให้ มากกว่าจะเป็น “คลาวด์จริง ๆ” คลาวด์ที่แท้ควรอยู่ทุกที่จนแทบไม่ต้องเอามาคิดด้วยซ้ำ
ผลคือแบรนด์มาร์เก็ตติ้งแทบไร้ที่ติ ทุกโพสต์บนบล็อกสื่อสารได้ชัดเจนและมีน้ำเสียงประชดนิด ๆ
ถ้าอยากเป็นแฮ็กเกอร์ที่มีชื่อเสียง ก็ควรเป็นนักเขียนที่วงการพอรู้จักด้วย
คอมเมนต์เชิงรู้ตัวเอง แบบนี้ต้องใช้อย่างประหยัดถึงจะได้ผล แต่บทความนี้ทำได้ดีมาก
มันยอมรับทั้งแรงจูงใจเชิงรับจ้าง ความหน้าซื่อใจคดโดยนัย และการโอ้อวดตัวเองของประกาศลักษณะนี้ ขณะเดียวกันก็ยังส่งข้อมูลสำคัญครบถ้วน และอธิบายปัญหาจริงที่แพลตฟอร์มแก้ได้อย่างกระชับ
การใช้เงินลงทุนอย่างชอบธรรมก็อธิบายไว้ชัด เลยตอบคำถามได้ทั้งว่า “ทำไม” และ “มากแค่ไหน”
เรื่อง “ทำไมสตาร์ทอัพถึงเขียนประกาศแบบนี้?” จากที่เคยผ่านการระดมทุนมาหลายรอบ ในบริษัทเหล่านั้นเหตุผลคือ 100% เพื่อ ให้สื่อหยิบไปลง
ตราบใดที่ไม่ใช่ข่าวประเภท “CEO ถูกจับพร้อมกันทั้งข้อหายักยอกและคุกคาม” ถ้ามีข้ออ้างให้สื่อสายเทคเขียนถึงได้ ก็เท่ากับได้โฆษณาฟรี
ยิ่งดีถ้าลูกค้าเป้าหมายเป็นคนที่อ่านสื่อเทคอยู่แล้ว ไม่ได้บอกว่ามันผิด แต่ก็น่าแปลกที่ยอมรับเหตุผลเชิงรับจ้างนั้นแล้วกลับไม่พูดถึงเหตุผลที่เห็นกันบ่อยที่สุด
นักข่าวเข้าใจผู้อ่านตัวเองดี และตีความว่าบทความที่มีประกาศลงทุนพ่วงอยู่เท่านั้นถึงจะมีคนคลิก
เพราะงั้นหลังระดมทุนเสร็จ เรามักเงียบไว้ได้นานถึง 6 เดือน แล้วค่อยประกาศพร้อมฟีเจอร์ใหม่หรือการเปิดตัวผลิตภัณฑ์
ถ้าบทความเทคที่ไม่มีประกาศลงทุนได้คลิกมากกว่านี้ วงจรนี้อาจเปลี่ยนได้ แต่ตอนนี้มันดูเหมือนภาวะนักโทษ ไม่มีคนเขียนข่าวแบบนั้น ไม่มีคนคลิก แล้วก็เลยไม่มีใครเขียนอีก
โดยมากก็เป็นเพราะ เป้าหมายเชิงรับจ้าง ที่อยากทิ้งสารและภาพลักษณ์บางอย่างไว้ อย่างที่บทความอธิบาย
แน่นอนว่าก็มีเป้าหมายเพื่อให้คนรู้จักชื่อบริษัทด้วย และนั่นอาจเป็นแรงจูงใจเชิงรับจ้างอีกข้อที่บทความพูดถึงน้อยกว่า
ถ้าจำไม่ผิด ในเชิงเทคนิคมันน่าจะเป็นข้อมูลสาธารณะอยู่แล้ว ตอนก่อตั้งบริษัทฉันเคยถูกอธิบายแบบนั้น แต่มันก็นานมากแล้ว
ถ้าเราไม่ประกาศเอง เดี๋ยวคนอื่นก็ประกาศอยู่ดี ดังนั้นโพสต์เองก่อนให้คนมาอ่านบทความของเราแทนที่จะไปอ่านของคนอื่นย่อมดีกว่ามาก
ถ้าระดมทุนได้ 100 ล้านดอลลาร์ ก็ต้องมุ่งไปสู่ exit 1 พันล้านดอลลาร์ เพื่อรักษาโมเมนตัมตอนนี้ไว้ ค่าใช้จ่ายด้านวิจัยและพัฒนาจะเพิ่มขึ้นมหาศาล
ต้องสร้างทั้งสแตกขึ้นมาเอง และสุดท้ายก็ต้องทำทุกอย่างให้แข็งแกร่งมาก จึงเป็นงานวิศวกรรมขนาดใหญ่
Fly อาจดูเหมือนทำกำไรได้บนหน้าบัญชี เพราะคิดค่าบริการการประมวลผล และฮาร์ดแวร์กับแบนด์วิดท์มีราคาถูก
แต่ต้นทุนจริงคือการวิจัยและพัฒนา การตลาด และ ค่าตอบแทนเป็นหุ้น ซึ่งต้นทุนเหล่านี้สามารถขัดขวางความสามารถในการทำกำไรได้ไม่ว่าจะขนาดไหน
มันไม่ใช่ค่าใช้จ่ายครั้งเดียว แต่เป็นเงินที่ต้องใช้ต่อเนื่อง และถ้าไม่ใช้ ลูกค้าก็จะหนีไป
นี่ไม่ใช่แค่กรณีของ Heroku แต่เป็นโศกนาฏกรรมของสตาร์ทอัปสายแพลตฟอร์ม/อินฟราทั่วไป
มีเหตุผลที่เราไม่ค่อยเห็นผู้ให้บริการคลาวด์รายเล็กมากนัก เพราะเศรษฐศาสตร์มันคุ้มก็ต่อเมื่อมีขนาด
Fly ดูเหมือนจะมีมุมมองต่อวิศวกรรมซอฟต์แวร์ที่เท่มากและทันสมัย และก็ดูเหมือนเป็นที่ทำงานที่ดี แต่รู้สึกว่ามีความไม่สอดคล้องกันอย่างมากระหว่างการตลาดกับตัวผลิตภัณฑ์
การตลาดและเอกสารเน้นว่าการเปิดใช้งาน app server แบบกระจายทั่วโลกนั้นง่ายมาก แต่ลูกค้าที่ต้องการ app server แบบกระจายทั่วโลก จริง ๆ น่าจะมีแพลตฟอร์มที่โตเต็มที่พร้อมที่เก็บข้อมูลแบบกระจายทั่วโลกอยู่แล้ว จึงไม่น่าจะกังวลเรื่องการเปิด app server
เลยรู้สึกเหมือนตัวเองอาจกำลังเข้าใจสถาปัตยกรรมอินเทอร์เน็ตแอปพลิเคชันผิดไปในระดับพื้นฐานบางอย่าง
การรันได้หลายรีเจียนมีประโยชน์มาก ชุมชน Splatoon ไม่ได้กระจุกอยู่ที่เดียว แต่กระจายทั่วโลก ถ้าโฮสต์แค่ในสหรัฐฯ ผู้เล่นญี่ปุ่นจะช้า และถ้าทำกลับกันก็เหมือนกัน
ต่อให้โปรเจกต์ไม่เวิร์ก สุดท้ายมันก็น่าจะเป็นประสบการณ์ที่มีประโยชน์มากหลังจากออกจากโรงเรียนแล้ว
ตอนนี้รันอยู่ที่ US East, Amsterdam, Tokyo เดือนละประมาณ 10 ดอลลาร์
แค่เปลี่ยนเป้าหมายไปเป็น Kubernetes, single-page app, GraphQL, edge deployment อะไรทำนองนั้น
ตอนยุคตื่นทอง แค่ขายจอบก็พอ
ประโยคที่ว่า “มีบริษัทแพลตฟอร์มที่ทำให้โค้ด Python, Rust, Julia รันได้ดี และก็มีบริษัทแพลตฟอร์มที่ทำให้คุณต้องหาวิธีคอมไพล์มันกลับไปเป็น JavaScript” ดูเหมือนเป็นการแซว Cloudflare กับ Deno แบบขำ ๆ
ถ้า Fly ไปโฮสต์ WASM container ได้ด้วยนอกเหนือจาก Docker container ก็น่าจะน่าสนใจ
ส่วนที่แซว Cloudflare ผมว่าอยู่ตรง “ทำให้เซลส์โทรมา” มากกว่า
ชอบที่ Fly ยอมรับว่าถึงจะคาดว่าจะถูกใช้กับเกม/edge caching ฯลฯ แต่ในความเป็นจริงทุกคนกลับใช้มันเหมือน Heroku ตัวใหม่ สำหรับ deploy แอป Rails+PostgreSQL CRUD
เท่าที่เข้าใจ เป้าหมายถัดไปคือทำให้การทำแอป Rails+PostgreSQL ให้เป็น edge กลายเป็นเรื่องจิ๊บจ๊อย หรือเป็น “ปัญหาสองชั่วโมง”
ถือว่ากล้ามาก ในอดีตมักต้องมีการผูกกันแบบเฉพาะแอปพลิเคชัน/เฟรมเวิร์ก/โดเมน เช่น “ควร shard domain model นี้อย่างไรถึงจะดีที่สุด”
การบอกว่าจะแก้ด้วย PaaS/IaaS แทบจะหมายถึงการเขียนและปฏิบัติการ distributed Cloud SQL/Aurora เอง
แต่ถ้าแค่ทำให้สิ่งอย่าง Aurora clone หรือ Neon รันอยู่ในสแตกได้อย่างลื่นไหล ก็ดูเป็นไปได้ และมูลค่าผลิตภัณฑ์ก็น่าจะสูงพอสมควร
เมื่อพิจารณาว่ามาร์จินของคลาวด์สำหรับ SMB/งานอดิเรกค่อนข้างต่ำ ก็ยังนึกไม่ออกว่า fly.io จะทำกำไรได้อย่างไร
อาจเอาคนทั้งโลกขึ้น free tier ได้ แต่พอถึงเวลาที่ EQT ต้องถอนทุน จะเกิดอะไรขึ้น
พวกเขาจะสร้างฟีเจอร์ได้มากพอให้บริษัทต่าง ๆ เลือกใช้อย่างจริงจังได้ไหม จากที่ผมเคยทำงานมา ถ้าไม่ใช่ทีมเล็กกว่า 5 คนและไม่มีความต้องการสเกลเลย ก็ดูยากที่จะใช้หรือผลักดันให้ใช้
พวกเรามี unit economics ที่ดี สิ่งที่เสี่ยงและน่ากลัวที่สุดที่เราเคยทำคือเริ่มจากฮาร์ดแวร์ของตัวเอง
ในอินฟราที่เน้นนักพัฒนา คุณต้องดึงนักพัฒนาจำนวนมากเข้ามา ให้พวกเขาพาเราเข้าไปในที่ทำงาน แล้วช่วยให้นายจ้างของพวกเขาสร้างสิ่งที่ดีกว่าได้ในระยะยาว
งานนี้ใช้เวลานานมาก เพราะบริษัทที่มีกระบวนการจัดซื้อนั้นถูกออกแบบมาไม่ให้ซื้ออินฟราสำคัญจากสตาร์ทอัป
ถึงตอนนี้มันอาจยังไม่เหมาะกับทุกคน แต่สำหรับเราจนถึงตอนนี้มันเวิร์ก
[0] https://community.fly.io/t/funding-and-longevity/1957
สงสัยว่า fly.io ต่างจากหรือดีกว่าวิธีที่เอาทั้งแอป รวมถึง dynamic content ไปวางไว้หลัง CloudFront หรือ CDN อื่น ๆ อย่างไร
CDN อยู่ใกล้ไคลเอนต์กว่า จึงให้การตั้งค่า SSL ที่มี latency ต่ำกว่า และความต่างนี้อาจมากพอสมควร
มันไม่ใช่การผลัก app server ออกไปที่ edge แต่ถึงทำแบบนั้น คุณก็ยังต้องจ่ายต้นทุนด้าน latency จากการไปแตะฐานข้อมูลที่อยู่ในบังเกอร์ที่ Virginia อยู่ดี
หลายแอปมีการไปกลับฐานข้อมูลหลายรอบต่อหนึ่ง web request เลยยิ่งดูแย่กว่าเดิม ผมมองว่าควรจ่ายต้นทุนด้าน latency ตอน web request และให้ app server เข้าถึงฐานข้อมูลได้เร็วจะดีกว่า
ลูกค้าเป้าหมายของ Fly ดูเหมือนจะไปทาง static content เป็นหลัก