Sprites - แซนด์บ็อกซ์แบบคงสถานะ

 (fly.io)
5 คะแนน โดย GN⁺ 2026-01-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Fly.io เปิดตัว ‘Sprites’ ใหม่ในฐานะแนวคิดของ คอมพิวเตอร์คลาวด์แบบคงอยู่ ที่มาแทนแซนด์บ็อกซ์แบบใช้ครั้งเดียวเดิม
  • สร้างได้ภายใน 1~2 วินาที, รองรับ การเข้าสู่โหมดว่างอัตโนมัติ, การกู้คืนจากเช็กพอยต์, และ สตอเรจถาวร 100GB
  • ชี้ให้เห็นว่า โมเดลคอนเทนเนอร์แบบไร้สถานะ เดิมไม่มีประสิทธิภาพสำหรับ AI agent (เช่น Claude) และย้ำถึงความจำเป็นของ สภาพแวดล้อมแบบคงอยู่
  • ยกกรณีใช้งานจริงที่ Claude สร้างและรัน แอป Go บน SQLite (MDM) บน Sprite เป็นเวลานาน
  • บทสรุปของบทความ: “ยุคของแซนด์บ็อกซ์จบลงแล้ว และยุคของคอมพิวเตอร์ใช้แล้วทิ้งได้มาถึงแล้ว”

Sprites: คอมพิวเตอร์คลาวด์แบบคงอยู่ - https://sprites.dev/

  • Fly.io ระบุว่า โมเดลแซนด์บ็อกซ์แบบอ่านอย่างเดียวล้าสมัย แล้ว และเปิดตัว ‘Sprite’ เพื่อมาแทน
    • คำสั่ง sprite create สามารถสร้าง Linux root shell ได้ภายใน 1 วินาที
    • Sprite มี สตอเรจถาวร 100GB และเมื่อว่างงานจะพักเครื่องอัตโนมัติแล้วกลับมาทำงานต่อได้
  • ใช้ sprite-env checkpoints create เพื่อสร้าง เช็กพอยต์ของทั้งระบบ ได้ทันที
    • ใช้ sprite checkpoint restore v1 เพื่อกู้คืนได้ภายใน 1 วินาที และทำ การจัดการเวอร์ชันระดับระบบแบบเดียวกับ Git ได้
  • คุณสมบัติหลัก
    • สร้าง อินสแตนซ์หลายร้อยตัว ได้อย่างง่ายดาย
    • ลดต้นทุนด้วย การหยุดคิดค่าบริการอัตโนมัติเมื่อ idle (Idle metering)
    • ให้ URL แบบ HTTPS ผ่าน การเชื่อมต่อเครือข่าย Anycast
    • คงทนถาวรอย่างสมบูรณ์ และจะคงอยู่จนกว่าจะลบอย่างชัดเจน

Claude และข้อจำกัดของคอนเทนเนอร์แบบไร้สถานะ

  • ปัจจุบันสภาพแวดล้อมคลาวด์ส่วนใหญ่ยังยึดโครงสร้างแบบ คอนเทนเนอร์ไร้สถานะ (stateless)
    • ข้อมูลถูกเก็บไว้เฉพาะในฐานข้อมูลภายนอก เพื่อความเรียบง่ายและการขยายระบบ
  • แต่ AI agent อย่าง Claude ไม่เหมาะกับโครงสร้างนี้
    • มักพยายามเลี่ยงหรือหลุดออกจากคอนเทนเนอร์ เพราะต้องการเข้าถึง “คอมพิวเตอร์” ทั้งเครื่อง
  • ผู้เขียนนิยาม “คอมพิวเตอร์” ว่าต้องมี ความคงทนถาวร (durability) และ สภาพแวดล้อมที่ไม่หายไปหลังจบงาน
    • แซนด์บ็อกซ์ในปัจจุบันขาดทั้งสองอย่างนี้

ความเรียบง่ายชนะเสมอ (Simple Wins)

  • ในสภาพแวดล้อมแบบคงอยู่ ไม่จำเป็นต้อง สร้างสภาพแวดล้อมพัฒนาใหม่ (เช่น node_modules) ซ้ำแล้วซ้ำอีก
    • อุตสาหกรรมกำลังทุ่มเงินหลายสิบล้านดอลลาร์กับเทคโนโลยีสแนปช็อตเพื่อแก้ปัญหานี้
  • มีกรณีที่ต้องจัดโครงสร้างอินฟราจริงเพื่อให้ agent เข้าถึงทรัพยากรภายนอก เช่น S3, Redis, RDS
    • สิ่งนี้เป็นเพียงวิธีชั่วคราวเพื่อเลี่ยงปัญหาความไม่คงอยู่ของแซนด์บ็อกซ์
  • Sprites ตัดความซับซ้อนเหล่านี้ออกไป และให้ สภาพแวดล้อมที่เมื่อเขียนไฟล์แล้ว ไฟล์จะคงอยู่ตามเดิม
  • ตัวอย่างเช่น ในโปรเจกต์ Phoenix.new agent บน Fly Machine สามารถ สังเกต log ของแอปได้โดยตรง แล้วแก้ข้อผิดพลาด

Galaxy Brain Win: การหลอมรวมระหว่างการพัฒนาและการปฏิบัติการ

  • ผู้เขียนร่วมกับ Claude สร้าง แอป Go บน SQLite (MDM) บน Sprite
    • ใช้ URL แบบ Anycast เป็น URL สำหรับลงทะเบียน MDM
    • Claude จัดการแม้กระทั่ง การตั้งค่าใบรับรอง APNS ให้อัตโนมัติ
  • แอปนี้ทำงานได้อย่างเสถียรบน Sprite มานานกว่าหนึ่งเดือน
    • เป็นการทำให้แนวคิด “สภาพแวดล้อมพัฒนาคือระบบ production และ production ก็คือสภาพแวดล้อมพัฒนา (dev is prod, prod is dev)” เกิดขึ้นจริง
  • ผู้เขียนมองว่าแอปส่วนใหญ่ไม่จำเป็นต้องรองรับทราฟฟิกขนาดมหาศาล และ แอปแบบคงอยู่ที่ปรับให้เหมาะกับผู้ใช้แต่ละคน มีความสำคัญมากกว่า
    • เป็นโครงสร้างที่ผู้ใช้สามารถขอฟีเจอร์ได้โดยตรงและสะท้อนผลได้ทันที

จุดจบของแซนด์บ็อกซ์และยุคของคอมพิวเตอร์ใช้แล้วทิ้ง

  • Fly.io พัฒนาแพลตฟอร์ม micro-VM แบบขยายแนวนอนมานาน แต่โมเดลแซนด์บ็อกซ์ได้มาถึงขีดจำกัดแล้ว
  • Sprites คล้ายกับ Fly Machines แต่ใช้ สแตกสตอเรจใหม่และโครงสร้าง orchestration ใหม่ และ ไม่ต้องใช้ Dockerfile
  • คำถามหลักที่ถูกโยนออกมาคือ:
    > “ถ้าคุณสามารถรัน agent ได้อยู่แล้ว ทำไมจะไม่เลือก EC2 instance ที่เรียกใช้งานได้ทันที แทนแซนด์บ็อกซ์แบบอ่านอย่างเดียว?”
  • บทสรุป: “ยุคของแซนด์บ็อกซ์จบลงแล้ว และยุคของคอมพิวเตอร์ใช้แล้วทิ้งได้มาถึงแล้ว”

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

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

 
GN⁺ 2026-01-11
ความคิดเห็นบน Hacker News

  • ตอนแรกชอบมากจริงๆ แต่เหมือนกับประสบการณ์อื่นๆ ที่เคยเจอกับ Fly API คราวนี้ก็รู้สึกว่ายังพังๆ อยู่
    ถ้ารันคำสั่งตัวอย่างจากเอกสาร https://sprites.dev/api ตรงๆ จะได้คำตอบเป็น {"error":"name is required"}
    แต่ถ้าใช้ request body แบบเต็มจาก เอกสาร Create Sprite ก็จะทำงานได้ปกติ
    ถ้าเป็น workflow ส่วนตัวก็คงพอยอมรับ รอยคมๆ ของระบบ แบบนี้ได้ แต่ถ้าเป็น CI/CD ที่กระทบทั้งทีมก็ทำให้ลังเล
    อยากขอทีม Fly ว่า — ตัวอย่างในเอกสารควรมีการตรวจด้วย ระบบทดสอบอัตโนมัติ ให้แน่ใจว่าใช้ได้จริง

    • น่าจะเป็นเพราะไม่ได้ใส่ Content-Type header
    • น่าจะดีถ้าสามารถรายงานปัญหาแบบนี้ใน public issue tracker ได้ ไม่จำเป็นต้องเป็น GitHub ก็ได้ แต่ควรมีพื้นที่ให้ผู้ใช้คุยกันแบบสาธารณะ

  • https://sprites.dev/ น่าสนใจมาก
    มันแก้สองปัญหาที่ผมชอบได้พร้อมกัน

    1. development environment sandbox — สภาพแวดล้อม VM ที่ราคาถูกและคงอยู่ได้ เพื่อรัน Claude Code หรือ Codex CLI อย่างปลอดภัย
    2. Sandbox API — รันโค้ดที่ไม่น่าเชื่อถือในสภาพแวดล้อมแยกได้ด้วยการเรียก JSON API แบบง่ายๆ
      ยังมีฟีเจอร์ snapshot ด้วย ทำให้ย้อนกลับไปสถานะก่อนรันได้ง่าย
      ผมเขียนรายละเอียดไว้ในบล็อกแล้ว → บทความบน simonwillison.net
    • ถ้าเป็นผู้อ่าน น่าจะสนใจกระทู้ที่เกี่ยวข้องนี้ด้วย: Fly’s Sprites.dev addresses dev environment sandboxes and API sandboxes together
    • ผมใช้ container-use กับงานลักษณะนี้ได้ดีมาก → https://container-use.com/quickstart
      และก็ดีใจที่ได้ยินว่า Simon กำลังพยายาม สร้างรายได้ จากงานของตัวเองมากขึ้น ยิ่งเขาได้ผลตอบแทนมาก โลกก็น่าจะยิ่งดีขึ้น

  • ในเชิงปรัชญา ผมชอบ Fly และเป็นลูกค้ามาตั้งแต่แรกๆ
    แต่พองานเกี่ยวกับ CLI ก็ยังรู้สึก กลัวๆ อยู่ดี ถึงจะใช้แค่ไม่กี่สัปดาห์ครั้ง การอัปเดตอัตโนมัติก็เด้งมาบ่อยจนเสียจังหวะ
    เลยกังวลว่า Sprite CLI จะซ้ำรอยเดิม

    • ผมก็เลิกใช้ Fly ด้วยเหตุผลนี้แล้วไป Digital Ocean แทน ของที่บอกว่า “just works” ดันไม่เวิร์กบ่อยเกินไป

  • อันนี้น่าสนใจมาก!
    ที่บริษัทเราใช้ persistent development server ที่เชื่อม Claude ผ่าน SSH แต่พอ git repo หรือ environment หายไปก็ลำบาก
    Sprite ดูเหมือนจะใช้เก็บข้อมูลด้วยอะไรอย่าง SQLite และทำแอปง่ายๆ ที่เข้าผ่าน URL ได้
    ถ้ามันเป็นโครงสร้างที่หายไปเองอัตโนมัติหลังเวลาสั้นๆ ก็น่าจะเหมาะกับ ซอฟต์แวร์ส่วนตัวแบบง่ายๆ มาก
    ถ้ามีฟีเจอร์ให้ดู URL ได้หลังผ่านการยืนยันตัวตนด้วยบัญชี Fly แบบ Vercel preview environment ก็น่าจะยิ่งดี

  • ดูเท่มาก แต่ผลิตภัณฑ์อื่นๆ ของ Fly ไม่ได้เป็นตัวอย่างที่ดีนักในแง่ ความเสถียร หรือ ความสมบูรณ์ของงาน
    API ล่มและ error ชั่วคราวเกิดบ่อย แถม ปัญหาเรื่องบิล ก็แก้ช้า
    เช่น instance ที่ลบไปแล้วก็ยังแสดงว่าใช้งานอยู่ และค่าบริการรายชั่วโมงถูกคิดเป็นสองเท่าของที่ควรจะเป็น
    แม้จะออกผลิตภัณฑ์ AI ใหม่อย่าง Phoenix.new และ Sprites มา แต่ก็ดูเหมือนจะโฟกัสของใหม่มากกว่าปรับปรุงคุณภาพของของเดิม

    • ถ้าดูเฉพาะเรื่องความน่าเชื่อถือและการซัพพอร์ต ผมคิดว่าไม่มีเหตุผลให้ใช้ตัวนี้

  • ผมอยากได้ sandbox สำหรับงานพัฒนา แบบนี้มานานแล้ว — ต่อให้ลืมปิดก็ไม่เสียเงินเยอะ
    แต่ก็เจอปัญหาอยู่บ้าง

    1. error manpath: can't set the locale — น่าจะเพราะค่า locale จากเครื่อง local ถูกส่งต่อมาด้วย
    2. $SHELL ถูกตั้งเป็น /opt/homebrew/bin/fish ดูเหมือนตัวแปรสภาพแวดล้อมจากเครื่อง local ถูก ส่งไปยังเครื่อง remote โดยไม่ได้ตั้งใจ เลยรู้สึกไม่ค่อยสบายใจนิดหน่อย

  • อันนี้เจ๋งมาก เป็นสภาพแวดล้อมรัน sandbox แบบ DX และ API ที่ผมรออยู่
    ผมอยาก custom image หรือ VM ตั้งต้น เพื่อให้มีเฉพาะ binary ที่ต้องใช้โดยไม่มีเครื่องมือเกินจำเป็น
    หรือถ้ามีฟีเจอร์ clone sprite จาก checkpoint ได้ก็น่าจะดี ตอนนี้ยังไม่เห็นตัวเลือกแบบนั้น

    • อยากให้มีความสามารถแบบ Docker deployment ที่ผมอัปโหลด base sprite image ตามที่ต้องการ แล้วทำงานต่อบนภาพนั้นได้

  • ช่วงไม่กี่เดือนที่ผ่านมา การทำงานกับ Sprites สนุกมากจริงๆ
    เร็วๆ นี้จะปล่อยบางส่วนฝั่ง Elixir ออกมาเป็น โอเพนซอร์ส
    มีวิดีโอเดโม 5 นาทีด้วย → YouTube เดโม

    • จุดที่น่าสนใจคือ Claude ควบคุม Sprites ได้ด้วยตัวเอง พอคุณสั่งรันเซิร์ฟเวอร์ มันจะลงทะเบียนเป็น local service ให้อัตโนมัติ และถ้ามีการเปลี่ยนแปลงใหญ่ก็จะสร้าง checkpoint เอง
      sprite ที่ไม่ได้ใช้งานแทบไม่มีค่าใช้จ่าย ดังนั้นทุกครั้งที่จะเริ่มงานใหม่ก็แค่สร้างใหม่ได้เลย
      มันให้ความรู้สึกแปลกๆ ดีที่มีสภาพแวดล้อมพร้อมรันได้ทุกเมื่อโดยไม่ต้องตัดสินใจอะไร

  • เพราะโดเมนเป็น fly.io ตอนแรกผมนึกว่าจะเป็น โซลูชันแบบ local
    ต่อให้ไม่ใช่ self-hosted ก็ยังคาดหวังว่าจะเป็น wrapper ของ local VM ที่ครอบ Docker หรือ bubblewrap อะไรทำนองนั้น

    • ถ้าจะใช้ในแนวนั้น ลองดู โครงการ LXC/Incus ได้ → https://linuxcontainers.org/incus/
      ถ้ารัน IncusOS ที่ใช้ ZFS บนฮาร์ดแวร์ local ก็จะได้สภาพแวดล้อม sandbox ที่ทรงพลังมาก

  • อาจเป็นเพราะผมดูเอกสารพลาดไป แต่สงสัยว่าสามารถ fork/clone sprite หรือ restore checkpoint ไปเป็น sprite ใหม่ได้ไหม
    เช่น ใช้ sprite หนึ่งตัวเป็นเทมเพลตสำหรับสร้างหลายตัว หรือให้ Claude code ลองหลายวิธีแล้วเก็บไว้แค่วิธีที่ดีสุด ที่เหลือค่อยลบทิ้ง

    • ฟีเจอร์นั้นกำลังจะมาเร็วๆ นี้ สัปดาห์หน้าจะมีโพสต์ “how this works” อธิบายเหตุผลและโครงสร้างของระบบ
      เดิมทีตั้งใจจะใส่มาตอนเปิดตัว แต่ตัดสินใจว่าควรเก็บข้อมูลการใช้งานจริงเพิ่มอีกหน่อย