- Fly.io vừa giới thiệu ‘Sprites’, một khái niệm máy tính đám mây bền vững thay thế cho các sandbox dùng một lần truyền thống
- Có thể tạo trong 1~2 giây, đồng thời cung cấp tự động chuyển sang trạng thái nhàn rỗi, khôi phục checkpoint, và 100GB bộ nhớ bền vững
- Chỉ ra rằng mô hình container không trạng thái hiện tại kém hiệu quả với các AI agent (ví dụ: Claude), và nhấn mạnh sự cần thiết của môi trường bền vững
- Là ví dụ thực tế, bài viết đưa ra trải nghiệm Claude xây dựng và vận hành lâu dài ứng dụng Go dựa trên SQLite (MDM) trên Sprite
- Kết luận của bài viết: “Kỷ nguyên của sandbox đã kết thúc, và kỷ nguyên của máy tính dùng một lần đã bắt đầu”
- Fly.io cho rằng mô hình sandbox chỉ đọc hiện nay đã lỗi thời và công bố ‘Sprite’ để thay thế
- Lệnh
sprite create tạo một root shell Linux trong vòng 1 giây
- Sprite có 100GB bộ nhớ bền vững, tự động ngủ khi nhàn rỗi và có thể khôi phục lại
- Có thể tạo checkpoint cho toàn bộ hệ thống ngay lập tức bằng
sprite-env checkpoints create
- Khôi phục trong 1 giây với
sprite checkpoint restore v1, cho phép quản lý phiên bản ở cấp độ hệ thống như Git
- Các đặc điểm chính
- Dễ dàng tạo hàng trăm instance
- Tự động dừng tính phí khi idle (Idle metering) để giảm chi phí
- Cung cấp URL HTTPS qua kết nối mạng Anycast
- Độ bền hoàn chỉnh, được giữ lại cho đến khi bị xóa một cách tường minh
Claude và giới hạn của container không trạng thái
- Hiện nay phần lớn môi trường đám mây xoay quanh kiến trúc container không trạng thái (stateless)
- Dữ liệu chỉ được lưu trong DB bên ngoài, nhằm đạt được sự đơn giản và khả năng mở rộng
- Tuy nhiên, cấu trúc này không phù hợp với các AI agent như Claude
- Chúng có xu hướng tìm cách vượt qua hoặc thoát khỏi container, và muốn truy cập vào toàn bộ “máy tính”
- Bài viết đưa ra định nghĩa của “máy tính” là phải có tính bền vững (durability) và môi trường không biến mất sau khi công việc kết thúc
- Các sandbox hiện nay đều thiếu cả hai yếu tố này
Sự đơn giản chiến thắng (Simple Wins)
- Trong môi trường bền vững, không cần dựng lại môi trường phát triển (như node_modules)
- Cả ngành đang đầu tư hàng chục triệu USD vào công nghệ snapshot để giải quyết vấn đề này
- Đã có các trường hợp dựng hạ tầng thực tế để agent truy cập vào tài nguyên bên ngoài như S3, Redis, RDS
- Đây là giải pháp tạm thời nhằm lách vấn đề không bền vững của sandbox
- Sprites loại bỏ sự phức tạp đó, cung cấp môi trường mà file được ghi ra sẽ tiếp tục tồn tại nguyên vẹn
- Ví dụ, trong dự án Phoenix.new, agent chạy trên Fly Machine có thể quan sát trực tiếp log ứng dụng để sửa lỗi
Galaxy Brain Win: sự hợp nhất giữa phát triển và vận hành
- Tác giả đã cùng Claude xây dựng ứng dụng Go dựa trên SQLite (MDM) trên Sprite
- Dùng URL Anycast làm URL đăng ký MDM
- Claude còn tự động xử lý cả thiết lập chứng chỉ APNS
- Ứng dụng này đã vận hành ổn định trên Sprite trong hơn một tháng
- Hiện thực hóa khái niệm “môi trường dev chính là prod, và prod cũng là dev (dev is prod, prod is dev)”
- Tác giả cho rằng phần lớn ứng dụng không cần lưu lượng cực lớn; điều quan trọng hơn là các ứng dụng bền vững được cá nhân hóa
- Cấu trúc cho phép người dùng trực tiếp yêu cầu tính năng và được phản ánh ngay lập tức
Sự kết thúc của sandbox và kỷ nguyên của máy tính dùng một lần
- Fly.io đã phát triển nền tảng micro VM mở rộng theo chiều ngang trong thời gian dài, nhưng mô hình sandbox đã chạm đến giới hạn
- Sprites tương tự Fly Machines, nhưng có stack lưu trữ mới và cấu trúc điều phối mới, đồng thời không cần Dockerfile
- Đặt ra câu hỏi cốt lõi:
> “Nếu đã có thể chạy agent, chẳng phải bạn sẽ muốn một EC2 instance có thể gọi lên ngay lập tức thay vì một sandbox chỉ đọc hay sao?”
- Kết luận: “Kỷ nguyên của sandbox đã kết thúc, và kỷ nguyên của máy tính dùng một lần đã bắt đầu.”
1 bình luận
Ý kiến Hacker News
Ban đầu tôi thật sự rất thích, nhưng cũng như những trải nghiệm khác khi dùng Fly API, lần này nó vẫn cho cảm giác còn lỗi
Nếu chạy nguyên xi lệnh ví dụ trong tài liệu https://sprites.dev/api thì sẽ nhận được phản hồi
{"error":"name is required"}Nhưng nếu dùng toàn bộ phần thân request trong tài liệu Create Sprite thì lại hoạt động bình thường
Với workflow cá nhân thì có thể chấp nhận những góc cạnh thô ráp như vậy, nhưng với CI/CD ảnh hưởng đến cả nhóm thì tôi sẽ ngần ngại
Tôi muốn nhắn đội Fly rằng — các ví dụ trong tài liệu nên luôn được xác minh bằng kiểm thử tự động
https://sprites.dev/ thật sự rất thú vị
Nó giải quyết cùng lúc hai vấn đề mà tôi rất quan tâm
Nó còn có tính năng snapshot, nên sau khi chạy xong có thể dễ dàng quay lại trạng thái trước đó
Tôi có viết chi tiết hơn trên blog của mình → bài viết trên simonwillison.net
Và tôi cũng rất vui khi nghe tin Simon đang cố gắng kiếm tiền tốt hơn từ công việc của mình. Anh ấy càng có lợi nhuận thì có lẽ thế giới càng tốt hơn
Về mặt triết lý thì tôi thích Fly và đã là khách hàng từ rất sớm
Nhưng mỗi khi làm việc liên quan đến CLI tôi vẫn thấy e ngại. Dù chỉ dùng vài tuần một lần, việc tự động cập nhật xảy ra quá thường xuyên và làm đứt mạch làm việc
Tôi lo Sprite CLI sẽ lặp lại vấn đề tương tự
Cái này thật sự rất thú vị!
Ở công ty tôi đang dùng máy chủ phát triển duy trì trạng thái với Claude kết nối qua SSH, nhưng sẽ rất bất tiện nếu git repo hay môi trường bị biến mất
Sprite có vẻ có thể dùng SQLite hay thứ tương tự để lưu dữ liệu và tạo ra các ứng dụng đơn giản có thể truy cập bằng URL
Nếu nó có cấu trúc tự động biến mất sau một khoảng thời gian ngắn thì sẽ rất hợp cho phần mềm cá nhân đơn giản
Sẽ còn tốt hơn nữa nếu có tính năng xem URL sau khi xác thực tài khoản Fly, giống như môi trường preview của Vercel
Trông rất hay, nhưng các sản phẩm khác của Fly không phải hình mẫu về độ ổn định hay mức độ hoàn thiện
API downtime và lỗi tạm thời xảy ra khá thường xuyên, còn vấn đề thanh toán thì xử lý chậm
Ví dụ, các instance đã xóa vẫn hiển thị là đang dùng, và phí theo giờ bị tính gấp đôi thực tế
Họ đã tung ra các sản phẩm AI mới là Phoenix.new và Sprites, nhưng có vẻ đang tập trung vào sản phẩm mới hơn là cải thiện chất lượng sản phẩm hiện có
Tôi đã muốn có kiểu sandbox cho phát triển như thế này — một môi trường mà dù quên tắt đi cũng không tốn quá nhiều tiền
Tuy vậy tôi gặp vài vấn đề
manpath: can't set the locale— có lẽ thiết lập locale ở máy local đã được truyền nguyên sang$SHELLđược đặt là/opt/homebrew/bin/fish. Việc các biến môi trường local bị gửi sang từ xa mà không rõ ràng làm tôi hơi bất anCái này thật sự quá tuyệt. Đây đúng là dạng môi trường chạy sandbox với DX và API mà tôi chờ đợi
Tôi muốn có thể tùy biến image hay VM cơ bản để chỉ chứa những binary cần thiết, không kèm các công cụ thừa
Hoặc sẽ hay nếu có khả năng nhân bản sprite dựa trên checkpoint. Hiện tại tôi chưa thấy tùy chọn đó
Tôi đã rất thích thú khi làm việc với Sprites trong vài tháng qua
Chúng tôi sắp mã nguồn mở một phần phía Elixir
Cũng có một video demo dài 5 phút → demo YouTube
Những sprite không dùng đến gần như không tốn chi phí. Mỗi khi bắt đầu việc mới, bạn chỉ cần tạo cái mới
Cảm giác có một môi trường có thể chạy bất cứ lúc nào mà không cần đưa ra quyết định gì thật khá lạ
Vì domain là fly.io nên lúc đầu tôi tưởng đây sẽ là một giải pháp local
Dù không nhất thiết phải self-hosted, tôi đã kỳ vọng một wrapper VM local bọc quanh Docker hay bubblewrap hoặc thứ tương tự
Nếu chạy IncusOS dựa trên ZFS trên phần cứng local thì sẽ có một môi trường sandbox cực kỳ mạnh
Có thể tôi đã bỏ sót trong tài liệu, nhưng tôi muốn biết liệu có thể fork/clone sprite hoặc khôi phục checkpoint thành một sprite mới hay không
Ví dụ, tôi muốn dùng một sprite làm mẫu để khởi tạo nhiều cái, hoặc để Claude Code thử nhiều hướng giải quyết rồi chỉ giữ lại một cái và dọn các cái còn lại
Ban đầu chúng tôi định đưa nó vào ngay lúc phát hành, nhưng cuối cùng quyết định rằng nên thu thập thêm dữ liệu sử dụng thực tế trước đã