- แม้ผลประกอบการจะแข็งแกร่ง แต่เมื่ออัตลักษณ์ทางธุรกิจเริ่มสั่นคลอน Fly.io จึงระดมทุนเพิ่มและมอบการบริหารให้ Scott Johnston อดีต CEO ของ Docker พร้อมเปลี่ยนไปให้ Sprites เป็นธุรกิจหลัก
- เมื่อ AI ทำให้ใครก็สร้างซอฟต์แวร์แบบปรับแต่งเฉพาะได้ ความแตกต่างด้วยเพียงพับลิกคลาวด์ที่ deploy ใกล้ผู้ใช้ หรือความสะดวกที่เน้นนักพัฒนามนุษย์เป็นศูนย์กลาง ก็ยิ่งทำได้ยากขึ้น
- Sprites คือ คอมพิวเตอร์สำหรับเอเจนต์ ที่สามารถสร้างได้เป็นร้อยเป็นพันเมื่อจำเป็นและคงอยู่ได้นาน โดยแต่ละตัวมีดิสก์ถาวร 100GB และคิดค่าบริการตามการใช้งานที่หยุดคิดเงินเมื่อ idle
- Sprites รุ่นใหม่เพิ่ม Sprite Block Device ที่เร็วและเสถียรกว่าเดิม, การ fork ดิสก์ และ Connectors ที่เรียกระบบภายนอกได้โดยไม่เปิดเผยข้อมูลรับรอง
- Fly.io จะไม่ไล่ตามทั้งแพลตฟอร์มแอปพลิเคชันฟังก์ชันคงที่ที่มนุษย์ออกแบบ กับอนาคตที่เอเจนต์เป็นศูนย์กลางพร้อมกัน แต่จะโฟกัสที่อย่างหลัง โดย ยังคงรักษา Fly Machines และความสามารถ PaaS เดิมไว้
วิกฤตด้านอัตลักษณ์ที่เผยออกมาท่ามกลางผลประกอบการอันแข็งแกร่ง
- Theo Browne กล่าวถึง Fly.io ในเชิงบวกขณะประเมิน สถานที่ที่ดีที่สุดสำหรับโฮสต์แอปพลิเคชันใหม่ในปี 2026 แต่ก็ประเมินว่าเป็นผู้ให้บริการที่เขามั่นใจได้ยากที่สุดว่าจะยังคงอยู่จนสิ้นปีในบรรดาผู้ให้บริการที่เขาติดตามอยู่
- ตอนนั้น Fly.io ยังคงทำ ผลงานรายไตรมาสได้แข็งแกร่ง รวมถึงผลการเงินที่ดีที่สุดในประวัติศาสตร์บริษัท แต่ปัญหาเรื่องอัตลักษณ์ว่าจะสร้างอะไรและจะมุ่งหน้าไปทางไหนยังไม่ได้รับการแก้ไข
- Fly.io ระดมทุนเพิ่มอีกพอสมควร เปิดตัว Sprites เวอร์ชันใหม่เพื่อรวมพลังของบริษัทให้โฟกัสชัดเจนขึ้น และแต่งตั้ง Scott Johnston เป็น CEO
สมมติฐานของ product-market fit เดิมเปลี่ยนไป
- Fly.io เริ่มต้นจากหลักการสองข้อ
- แอปพลิเคชันอินเทอร์เน็ตยิ่ง deploy ใกล้ผู้ใช้มากเท่าไร ก็ยิ่งเร็วขึ้น
- แทนที่จะให้โครงสร้างพื้นฐานคลาวด์ที่ซับซ้อน ควรมอบทั้ง ความยืดหยุ่นแบบ AWS และ การใช้งานง่ายแบบ Heroku ให้กับนักพัฒนา
- หลักการทั้งสองยังสำคัญอยู่ แต่เมื่อ AI เปลี่ยนการพัฒนาซอฟต์แวร์ ปัจจัยเหล่านี้ก็ไม่ชี้ขาดเหมือนเดิมอีกต่อไป
- หากมองเพียงการผสาน coding agent เข้ากับกระบวนการพัฒนาเดิมให้คล้ายคอมไพเลอร์ที่ฉลาดขึ้น ก็ยากจะจับขนาดของการเปลี่ยนแปลงนี้ได้
- ก่อนการมาถึงของสเปรดชีต งานที่ทุกวันนี้เทียบได้กับเอกสาร Excel ก็ต้องเป็นโปรแกรมที่โปรแกรมเมอร์สร้างขึ้น แต่สูตรในสเปรดชีตได้เปลี่ยนผู้รับผิดชอบงานจำนวนมากให้กลายเป็นโปรแกรมเมอร์
- AI กำลังก่อให้เกิดการเปลี่ยนแปลงที่ใหญ่กว่านั้น โดยมุ่งไปสู่โลกที่แทบทุกคนสามารถสร้างโปรแกรมแทบทุกประเภทได้
- พับลิกคลาวด์แบบเดิมถูกออกแบบมาเพื่อ deploy แอปพลิเคชันฟังก์ชันคงที่ให้ผู้ใช้หลายล้านคน โดยผ่านมาตรฐานที่เข้มงวดและขั้นตอน CI/CD
- ต่อไปก็ยังจะมีโปรแกรมที่มีผู้ใช้หลายล้านคนอยู่ แต่รูปแบบทั่วไปอาจไม่ใช่แบบเดียวกับสเปรดชีตที่มีผู้อ่านหลายล้านคน
- การเดิมพันต่อไปกับการออกแบบพับลิกคลาวด์แบบปี 2020 ก็แทบไม่ต่างจากการเดิมพันสวนทางกับการแพร่หลายของ ซอฟต์แวร์ที่เป็นส่วนตัวและปรับตัวได้
- Fly.io เลือกโลกที่เพื่อนและครอบครัวสามารถให้คอมพิวเตอร์ทำสิ่งที่ต้องการได้ด้วยตัวเอง โดยไม่ต้องรอนักพัฒนา
ความต้องการของเอเจนต์เหนือประสบการณ์นักพัฒนามนุษย์
- ปัญหาที่โครงสร้างพื้นฐานคลาวด์ยังยากสำหรับนักพัฒนายังคงอยู่ แต่เมื่อเอเจนต์เข้ามาทำงานแทน ความสำคัญของประสบการณ์นักพัฒนาสำหรับมนุษย์ที่ออกแบบมาอย่างพิถีพิถันก็ลดลง
- สำหรับเอเจนต์ที่ทำงานได้ดีกว่าในสภาพแวดล้อมที่ชัดเจน ค่าเริ่มต้นที่มีความเห็นแรงกล้าและประสบการณ์นักพัฒนาที่ถูกคัดสรรมาแล้วอาจกลับกลายเป็นข้อเสีย
- ผู้คนเริ่มมอบหมายให้เอเจนต์ทำแทน แทนที่จะอ่านเอกสารแล้วลองผิดลองถูกกับ CLI ใหม่ด้วยตัวเอง
- เอเจนต์สามารถจัดการคำขอให้ deploy เว็บไซต์ที่สร้างบนเครื่อง local ไปยัง Fly.io ได้ในครั้งเดียว แต่ก็สามารถ deploy ไปยัง AWS ได้ในครั้งเดียวเช่นกัน ทำให้ยากจะสร้างความแตกต่างด้วยเรื่อง usability เดิมเพียงอย่างเดียว
- หลังจากสังเกตว่าลูกค้าที่เติบโตเร็วที่สุดคือหุ่นยนต์ Fly.io จึงเริ่มมองหาสภาพแวดล้อมที่เอเจนต์ต้องการจริง ๆ แทนการตีความผลิตภัณฑ์เดิมใหม่ให้เหมาะกับเอเจนต์
คอมพิวเตอร์ที่เอเจนต์ต้องการ
- coding agent โดยพื้นฐานแล้วถูกสร้างมาให้รันบนเวิร์กสเตชันของนักพัฒนา
- แม้จะเป็น sandbox ที่เชื่อถือได้ แต่ถ้ารันอยู่บนโน้ตบุ๊กจริง งานก็จะหยุดทันทีที่ปิดฝาเครื่อง ทำให้ผู้ใช้สุดท้ายต้องย้าย sandbox ของเอเจนต์ขึ้นคลาวด์
- เซิร์ฟเวอร์พับลิกคลาวด์แบบเดิมต้องการคำมั่นสัญญาที่ใหญ่เกินไปสำหรับงานของเอเจนต์
- ต้องชั่วคราวยิ่งกว่าเซิร์ฟเวอร์แบบสัตว์เลี้ยงหรือแบบฝูงปศุสัตว์ตามแนวคิดดั้งเดิม
- ต้องสร้างได้ทันทีในเวลาที่ต้องการ คงไว้ได้นานเท่าที่จำเป็น และรันได้ด้วยต้นทุนต่ำ
- Sprites คือ คอมพิวเตอร์กึ่งชั่วคราว ที่ออกแบบมาตามความต้องการเหล่านี้
- สามารถสร้างได้อย่างรวดเร็วเป็นหลักร้อยหรือหลักพัน
- แต่ละ Sprite มีดิสก์ถาวร 100GB
- คิดค่าบริการตามการใช้งาน แต่จะหยุดนับเมื่อไม่มีงานทำ และสามารถตัดสินสถานะ idle ได้เอง
- สามารถโฮสต์แอปพลิเคชันและแชร์กับเพื่อนร่วมงานผ่านอินเทอร์เน็ตได้
- อุตสาหกรรมกำลังโฟกัสที่ sandbox แต่สิ่งที่เอเจนต์ต้องการไม่ใช่ sandbox หากเป็น คอมพิวเตอร์ ที่มีทั้งความต่อเนื่องและนำไปใช้งานได้จริง
- สามารถ สร้าง Sprites ได้ทันที เพื่อทดลองใช้ด้วยตนเอง
เปลี่ยน Sprites ให้เป็นศูนย์กลางของบริษัท
- Sprites ช่วงแรกเป็นโปรเจ็กต์ที่สร้างโดยทีมเล็ก ๆ แบบไม่เป็นทางการภายใน Fly.io และยังไม่ได้โฮสต์อยู่บนเว็บไซต์หลักของ Fly.io ด้วยซ้ำ
- จากนี้ไป คอมพิวเตอร์สำหรับเอเจนต์ (Computers for Agents) จะเป็นจุดโฟกัสหลักของบริษัท และ Sprites ก็จะไม่ใช่โปรเจ็กต์ที่มีคนดูแลเพียงไม่กี่คนอีกต่อไป
- Fly Machines และความสามารถ platform-as-a-service (PaaS) เดิมจะไม่ถูกยกเลิกและยังให้บริการต่อไป
- Sprites ใหม่ปรับปรุงด้านการขยายระบบและ orchestration พร้อมเพิ่มสองระบบย่อยหลักเพื่อให้ชุดความสามารถตามเป้าหมายสมบูรณ์
Sprite Block Device และการ fork ดิสก์
- สแตกสตอเรจเดิมสร้างขึ้นบน JuiceFS และเชื่อมต่อกับ Litestream
- Sprite Block Device (SBD) ที่ Ben Johnson และ Tim Newsham สร้างสแตกสตอเรจขึ้นใหม่ตั้งแต่พื้นฐานนั้น เร็วและเสถียรกว่าเดิม พร้อมคงความสามารถ checkpoint และ restore แบบทันทีไว้เช่นเดิม
- ด้วย drive forking ซึ่งเป็นความสามารถขยายหลักของ SBD สามารถสร้าง Sprite ต้นแบบหนึ่งตัว แล้วโคลนออกไปอย่างมีประสิทธิภาพได้อีกหลายล้านครั้ง
Connectors ที่ป้องกันการเปิดเผยข้อมูลรับรอง
- Connectors สร้างขึ้นบนพื้นฐานของ tokenized tokens ที่พัฒนาขึ้นเพื่อปกป้องแพลตฟอร์มหลักของ Fly.io
- ถูกออกแบบมาเพื่อให้ Sprite ส่งคำขอที่ยืนยันตัวตนไปยังระบบอื่นได้ โดยไม่ต้องมอบข้อมูลรับรองที่เอเจนต์อาจทำรั่วไหลได้โดยตรง
- ใช้งานสะดวกกว่าวิธีจัดการบัญชีและ API key ด้วยตนเอง
- ความสามารถในการโคลนของ SBD และ Connectors คือฟีเจอร์ที่ลูกค้าร้องขอมากที่สุด และยังเป็นเหตุผลที่หลายบริษัทด้านเอเจนต์ยังคงใช้ Fly Machines ต่อไปแม้หลังเปิดตัวผลิตภัณฑ์สำหรับเอเจนต์โดยเฉพาะแล้ว
- ตราบใดที่ยังไม่มีการเปลี่ยนแปลงทางเทคโนโลยีที่แปลกใหม่ยิ่งกว่าโมเดล Transformer ก็ประเมินว่า Sprites เหมาะกับทั้งลูกค้าในอนาคตและลูกค้าปัจจุบันจำนวนมาก จึงเปิด เบต้าใหม่
การลงจากตำแหน่งของผู้ก่อตั้งที่เป็น CEO
- ตลอด 8 ปีแรกของการก่อตั้ง Fly.io ดำเนินงานในฐานะองค์กรทดลองที่ค้นหา product-market fit
- ทดลองมาหลายสิบอย่าง เช่น Postgres แบบไม่จัดการให้, global CDN และ user-mode WireGuard
- สร้างองค์กรวิศวกรรมแบบ bottom-up เลี่ยง product roadmap และจัดทีม fully remote ที่ทำงานอยู่ในมากกว่า 12 ประเทศ
- การทดลองบางอย่างให้ผลลัพธ์ที่ดี และบางอย่างก็กลายเป็นโอกาสในการเรียนรู้ แต่ Fly.io ในระยะปัจจุบันไม่ต้องการ science project ลักษณะนี้อีกต่อไป
- ผู้ก่อตั้งตัดสินใจว่าตนได้ใช้จุดแข็งที่มีในบทบาท CEO ไปเกือบหมดแล้ว จึงลงจากตำแหน่ง
Scott Johnston เข้ารับตำแหน่ง CEO
- ตั้งแต่ปี 2025 เป็นเวลาหลายเดือนที่มีการหารือเรื่องการมอบการตัดสินใจของ Fly.io ให้ Scott Johnston
- Scott เคยนำ Docker ผ่านช่วงเวลาที่ยากลำบากซึ่งเริ่มต้นจากวิกฤตด้านอัตลักษณ์ระหว่างตลาดองค์กรกับตลาดนักพัฒนาในสมัยที่เป็น CEO ของ Docker และหลังจากนั้นก็ทำให้ธุรกิจเติบโตอย่างมาก
- ผู้ก่อตั้งซึ่งเป็นทั้งผู้ถือหุ้นและ CEO ของ Fly.io ในขณะนั้น เห็นว่าวิธีการบริหารของ Scott เหมาะกับช่วงปัจจุบันของบริษัทมากกว่าวิธีของตน จึงร่วมกับบอร์ดโน้มน้าวให้เขารับตำแหน่ง
- ผู้ก่อตั้งจะยังคงเป็น ที่ปรึกษาและกรรมการบริษัท มีส่วนร่วมในการพูดคุยเรื่องการออกแบบผลิตภัณฑ์ ส่วน Scott จะรับผิดชอบการดำเนินธุรกิจและการลงมือทำ
เงินทุนเพิ่มเติมสำหรับกลยุทธ์ใหม่
- Fly.io ไม่ได้ประกาศการระดมทุนรอบใหม่มาหลายปีแล้ว แต่ก่อนหน้านี้ก็ระดมทุนก้อนใหญ่ไว้ ทำให้ดำเนินงานมาใกล้จุดที่ตามแผนเดิมแล้วไม่จำเป็นต้องระดมทุนเพิ่ม
- เมื่อ AI เปลี่ยนแผนเดิม บริษัทจึงระดม เงินทุนเพิ่มเติม เพื่อขับเคลื่อนกลยุทธ์ใหม่ แต่ไม่ได้เปิดเผยมูลค่าหรือเงื่อนไขโดยละเอียด
- Scott Johnston จะกล่าวถึงเรื่องการระดมทุนในอนาคตแยกต่างหาก
เลือกหนึ่งในสองอนาคต
- Fly.io มองว่าในอีกไม่กี่ปี เอเจนต์จะเป็นตัวกำหนดวิธีสร้างและ deploy ซอฟต์แวร์เกือบทั้งหมด
- ซอฟต์แวร์จะมีความเป็นส่วนตัวมากขึ้น กลุ่มผู้ใช้เป้าหมายจะเล็กลง และรูปแบบจะยืดหยุ่นและเปลี่ยนแปลงได้มากขึ้น
- การเปลี่ยนแปลงนี้ให้ทั้งความคาดหวังและความอึดอัดกับผู้คนในอุตสาหกรรม
- บริษัทมีทางเลือกอยู่สองทาง
- เดินหน้าขยายและปรับปรุงแพลตฟอร์มแอปพลิเคชัน full-stack ฟังก์ชันคงที่ที่มนุษย์ออกแบบต่อไป
- ทำผลิตภัณฑ์ให้สมบูรณ์ยิ่งขึ้นสำหรับอนาคตอันใกล้ที่เอเจนต์เป็นศูนย์กลาง
- หากสตาร์ทอัพพยายามทำทั้งสองทางพร้อมกัน ก็ยากจะโฟกัสได้เต็มที่กับทางใดทางหนึ่ง ดังนั้น Fly.io จึงเลือก ผลิตภัณฑ์ที่เอเจนต์เป็นศูนย์กลาง
- การตัดสินใจเรื่องลำดับความสำคัญที่ถูกเลื่อนมาหลายเดือนได้รับการคลี่คลายด้วย Sprites และ Scott Johnston จะรับหน้าที่เปลี่ยนสิ่งนี้ให้กลายเป็นธุรกิจหลักของ Fly.io
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
abstraction ของ Sprites นั้นสวยงาม แต่ในประสบการณ์ทำงานพัฒนา 30 ปี นี่เป็นผลิตภัณฑ์โครงสร้างพื้นฐานที่บั๊กเยอะที่สุดเท่าที่เคยเจอ
ข้อมูลหายไปเรื่อย ๆ และกลายเป็นสถานะซอมบี้ที่เชื่อมต่อไม่ได้ โดยครึ่งหนึ่งของระบบรายงานว่า Sprite ปกติ แต่อีกครึ่งตัดสินว่าตายแล้ว จนโหลดแม้แต่ snapshot ก็ไม่ได้
ผลลัพธ์หายไปตอนพักเที่ยง ตอนข้ามคืน หรือแม้แต่ระหว่างทำงาน จนต้องยอมแพ้ใน 2 สัปดาห์ และต้องไล่ดูประวัติเทอร์มินัลเพื่อคัดลอกงานออกมาจาก Sprite ที่ตายแล้ว
ดูเหมือนว่ามากกว่าครึ่งของ Sprites ที่รันจะมีปัญหา แนวคิดนั้นยอดเยี่ยม จึงหวังว่าจะทำให้ เสถียรภาพ ดีขึ้นได้
แต่ราว 2 เดือนหลังมานี้ดูเหมือนว่าจะเสถียรขึ้นมาก
เมื่อหลายปีก่อน Fly.io เองก็มีบั๊กมากจนแทบใช้ทำงานจริงไม่ได้ แต่ตอนนี้ผมรัน production workloads บางส่วนได้อย่างเสถียรมาก จึงคิดว่า Sprites ก็น่าจะเดินตามเส้นทางเดียวกัน และตอนนี้ก็ดูเหมือนกำลังเป็นแบบนั้น
ในแง่ที่ CEO บริหารได้แย่มาก การลาออกอาจจะดีกว่าเสียอีก
เหตุผลคือบั๊กอินเทอร์เฟซร้ายแรง, ข้อมูลสูญหาย และซัพพอร์ตที่ย่ำแย่
อย่างไรก็ตาม ระหว่างช่วงทดลองพวกเขาไม่ได้ใช้โดเมนจริงของบริษัท และไม่ได้เปิดเผยว่าเป็นบริษัทในกลุ่ม Fortune 200 ซึ่งอาจมีผลต่อคุณภาพของการซัพพอร์ต
ในฐานะนักพัฒนา Elixir ผมอยากให้ Fly.io ประสบความสำเร็จ แต่พวกเขาหาจุดสมดุลระหว่างวิศวกรรมที่เท่กับ ความเสถียรในการปฏิบัติการ ไม่เจอ จนผมต้องเลิกใช้ไปสองครั้ง
อยู่ช่วงหนึ่งที่เกิด outage ทั่วโลก แต่ status page ยังแสดงว่าทุกอย่างปกติ และต้องไปอ่านโพสต์ในฟอรัมถึงจะรู้ว่ามีปัญหา โดยบริษัทตอบว่าเอาแต่แก้ปัญหาจนไม่มีเวลาอัปเดตสถานะ
หลังจากนั้นพวกเขาเริ่มอัปเดต status page แต่ก็ยังเกิดกรณีที่หลังจากแจ้งว่า “บางรีเจียนมีปัญหา” แล้วก็เงียบไปอีกหลายชั่วโมง
พอมีซัพพอร์ตแบบเสียเงินออกมาก็สมัครทันที แต่ที่อยู่อีเมลที่สัญญาว่าจะตอบเร็วกลับแทบไม่มีใครดู และแม้แต่ตอนรายงาน outage ใหญ่ ก็มักได้คำตอบว่า “มีปัญหาอะไรครับ?” ในวันถัดไปหรืออีกหลายวันให้หลัง
ถ้าเรื่องพวกนี้เกิดไม่บ่อยก็คงเป็นแค่ปัญหาฝ่ายบริการลูกค้า แต่ช่วงหนึ่งเคยมี outage ร้ายแรงแทบทุกเดือน แล้วพอดูเหมือนจะนิ่งได้พักหนึ่งก็กลับมาพังซ้ำอีก
สุดท้ายผมย้ายทุกบริการกลับไป self-host เอง แม้จะยุ่งยากกว่าแต่ uptime ดีขึ้นมาก และถ้ามีปัญหาก็รู้สาเหตุเองได้ จึงทรมานน้อยกว่ามาก
ถ้าจะทำธุรกิจโฮสติ้งต่อ ก็ต้องยอมรับความรับผิดชอบและ ทุ่มงบให้กับ operations ไม่อย่างนั้นก็เลิกทำโฮสติ้งไปแล้วกลายเป็น HashiCorp รายถัดไปจะดีกว่า
การทุ่มทั้งบริษัทไปที่ Sprites ทำให้ Fly.io ดูเหมือนเลือกฆ่าตัวตาย
AI sandbox แข่งขันกันดุเดือดอยู่แล้วและแทบจะกลายเป็นสินค้าโภคภัณฑ์ ส่วน CEO คนใหม่ก็น่าจะโฟกัสรายได้โดยแลกกับวิสัยทัศน์ที่สร้างสรรค์
หวังว่าผมจะคิดผิด
คอนเทนเนอร์เป็นของใช้แล้วทิ้ง และรันงานซ้ำได้ง่าย จึงไม่ค่อยสำคัญนักว่าจะเก็บข้อมูลไว้ได้ไหม อีกทางหนึ่งก็ให้เอเจนต์ขึ้น environment บน bare metal เองได้
เอเจนต์ส่วนใหญ่รอ GPU กันอยู่แล้ว ดังนั้นถ้าใช้ memory deduplication กับ workloads ที่คล้ายกัน ก็อาจรันได้หลายร้อยตัวบนฮาร์ดแวร์น้อยชิ้น
AWS เป็นคลาวด์สำหรับเอเจนต์อยู่แล้ว และเมื่อใช้เอเจนต์กับ infrastructure as code (IaC) ความซับซ้อนของ AWS ก็ลดลงมาก
ตอนนี้มูลค่าไม่ได้อยู่ที่การแย่งกันทำ orchestration หรือ margin ฮาร์ดแวร์ไม่กี่ bp ในชั้น model serving แต่อยู่ที่การสร้าง เครื่องมือที่ช่วยให้เอเจนต์ตัดสินใจได้ดีขึ้น
จากความก้าวหน้าของ LLM ช่วงหลัง ไม่ใช่แค่คนแต่รวมถึงบริษัทและองค์กรก็เผชิญ วิกฤตอัตลักษณ์ และบทความนี้ก็เป็นตัวอย่างที่ดี
น่าสงสัยว่ามันยังคุ้มไหมที่จะสร้างผลิตภัณฑ์หรือบริษัทที่ AI สามารถสร้างขึ้นได้ในคราวเดียว
ในทางกลับกัน มันก็มีผลลัพธ์ที่น่าสนใจคือกดดันให้คนไปทำสิ่งที่ใหญ่กว่าและทะเยอทะยานกว่าซึ่งแต่ก่อนทำไม่ได้
หวังว่าจะมีคนหันไปทำงานในด้านอย่างพลังงานสะอาดมากขึ้น ซึ่งแม้มีคนนับร้อยทำเรื่องเดียวกันก็ยังสร้างผลดีสุทธิต่อมนุษยชาติได้อย่างต่อเนื่อง
สงสัยว่าที่บอกว่า Docker เติบโตแบบระเบิด จริง ๆ หมายถึงธุรกิจโตพรวด หรือหมายถึงแบบ Boeing ที่ประตูปลิวกันแน่
ความเห็นที่เกี่ยวข้องของ Bryan Cantrill ก็น่าสนใจ: https://news.ycombinator.com/item?id=28460504
Sprites ดูเหมาะกับ ธุรกิจขนาดเล็กที่มั่นคง ที่เพื่อนไม่กี่คนช่วยกันทำ มากกว่าสตาร์ตอัปที่ระดมทุนมา
ถ้าเป็นนักพัฒนาอยู่แล้ว Docker หรือ Podman ก็มักแก้ปัญหาได้ดีพอ
ตลาดใหม่มหาศาลที่แม้แต่คุณตาคุณยายก็สร้างแอปได้ น่าจะเป็นของบริการอย่าง Lovable มากกว่า และคนที่ไม่ใช่นักพัฒนาก็คงไม่ใช้ Sprites
สุดท้ายก็คงได้แค่ส่วนหนึ่งของนักพัฒนาที่มีอยู่เดิม
มีข่าวทุกวันว่า OpenCode หรือ Claude Code เป็นต้น เป็นหายนะด้านความปลอดภัย ถ้าการแยก sandbox ทำได้ง่ายขนาดนั้น ก็สงสัยว่าทำไมนักพัฒนาถึงไม่ใช้คอนเทนเนอร์กันมากกว่านี้ และทำไมเหตุพวกนี้ยังเกิดอยู่
ผมหลีกเลี่ยง agent coding เพราะไม่อยากเปิดสภาพแวดล้อมในบ้านให้ LLM ของบริษัทภายนอกเข้ามายุ่ง แค่เพื่อจะเขียนโค้ดให้เร็วขึ้น แต่ก็ชัดเจนว่าพอถึงงานที่ต้องวิเคราะห์ไฟล์ซอร์สหลายไฟล์พร้อมกัน ผมก็เสียเปรียบจริง ๆ
การเปลี่ยนทิศทางทั้งบริษัทไปที่ Sprites แล้วจากไปทันทีหลังจากนั้น ดูห้วนพอสมควร
อย่างน้อยก็ควรให้ CEO คนใหม่มี โอกาสได้ลุยเอง ในการกำหนดทิศทางนี้
ยังไม่แน่ใจว่า Sprites คุ้มพอจะเดิมพันอนาคตของบริษัทหรือไม่ และการตัดสินใจสุดท้ายก็เป็นหน้าที่ของ CEO คนใหม่
ในระยะยาวมีโอกาสสูงที่ สภาพแวดล้อมรันแบบแยกขาด ลักษณะนี้จะถูกรวมเข้าไปใน Claude Code หรือ Codex หรือไม่ก็บริษัท AI จะให้บริการเองโดยตรง
Git worktree ก็แก้ปัญหาคล้ายกันได้ แต่ถ้าใช้ Sprites คุณสามารถสตาร์ตอินสแตนซ์ขึ้นมาอย่างรวดเร็ว รันบริการ แล้วส่งต่อให้ coding agent ไปปรับปรุงฟีเจอร์ได้
สามารถรันหลายเอเจนต์แบบขนานแล้วเลือกผลลัพธ์สักอันหนึ่งได้ และไม่ติดข้อจำกัดเรื่องจำนวนพอร์ตหรือ CPU ในเครื่องตัวเอง
เมื่อคิดด้วยว่าแรมจะยังขาดแคลนต่อไปอีกพักใหญ่ ก็ยิ่งทำให้บน Sprites สามารถรัน เอเจนต์ได้หลายร้อยตัว
สิ่งที่ Fly.io ต้องแก้และต้องโฟกัสคือ ความน่าเชื่อถือ
ผมชอบวิธีที่แอปรันได้ทันทีหลังสตาร์ต Docker container แต่บริการล่มหลายครั้งและราคาก็แพงมาก
ตอนนี้เลยใช้แค่ VPS ธรรมดา