Deno về với Cloudflare: Thứ đáng chú ý không phải là cái tên, mà là Durable Objects

Ngày 9/10/2026, Cloudflare ra một thông báo mà lướt qua tiêu đề thì dễ nhầm là tin tuyển dụng bình thường: đội ngũ Deno gia nhập công ty. Nhìn kỹ ai đứng tên thì khác hẳn. Ryan Dahl — người tạo ra Node.js, rồi sau đó tạo luôn cả Deno — và Bert Belder, đồng sáng lập Deno. Người đồng viết thông báo phía Cloudflare là Kenton Varda, một trong những kiến trúc sư gốc của Workers Runtime. Người dựng Node và người dựng Workers cùng ký tên một bài blog. Vậy thì không chỉ là tin lướt qua feed.

Chi tiết đáng giá nhất không nằm ở chuyện nhân sự. Dự án mã nguồn mở celld của Deno đang sáp nhập vào workerd — Workers Runtime mã nguồn mở mà Cloudflare dùng thật trong production, không phải bản demo tách riêng. Đây không phải kiểu thông cáo “hợp tác chiến lược” mơ hồ thường thấy. Một codebase đang nhập vào codebase khác, với mục tiêu nói rõ hiếm khi thấy Cloudflare tuyên bố thẳng vậy: làm Workers và Durable Objects có thể tự host được, ngoài nền tảng Cloudflare, lần đầu tiên.

celld giải quyết đúng cái gì

Durable Objects là mô hình của Cloudflare cho compute serverless có trạng thái — một object chạy trên một máy, giữ state, được định tuyến ổn định tới đúng máy đó, khác kiểu function không trạng thái cộng database ngoài mà ta hay gặp. Hữu dụng thật. Nhưng tới giờ, nó gắn chặt vào hạ tầng riêng của Cloudflare. workerd đã chạy được Durable Objects, chỉ ở dạng single-instance: một Durable Object tương ứng một máy. Chưa có cách nào sẵn sàng cho production để chạy một cụm Durable Objects phân tán trên phần cứng tự kiểm soát.

celld là câu trả lời của Dahl cho đúng bài toán đó, xây độc lập bên Deno. Ông mô tả nó là một binary duy nhất, viết bằng Rust, với object storage là phụ thuộc dịch vụ bên ngoài duy nhất. celld triển khai Durable Objects phân tán trên nhiều máy, tự động định vị và định tuyến. Phát hành lần đầu từ tháng 8/2024 — không phải bản vẽ nháp, mà đã có hai năm trưởng thành như một dự án độc lập trước khi ai đó nghĩ tới chuyện sáp nhập nó vào đâu.

Đặt hai sự kiện cạnh nhau thì hướng đi khá rõ. workerd biết chạy tốt một Durable Object đơn lẻ. celld biết chạy hàng loạt Durable Objects, phân tán, chỉ cần một storage bucket phía sau. Nhập năng lực thứ hai vào cái thứ nhất, ta có một Workers Runtime có khả năng chạy ngoài trung tâm dữ liệu Cloudflare — do người vận hành tự quản lý, trên hạ tầng họ chọn.

Cách Dahl mô tả trạng thái cuối cùng, trích trực tiếp trong thông báo: bạn sẽ “quản lý nhiều instance của celld và một object storage bucket duy nhất.” Đó là toàn bộ mô hình vận hành, ít nhất theo những gì được nói tới giờ. Không cần dựng thêm platform orchestration, không cần control plane riêng — chỉ là các process celld và một bucket. Mục tiêu ông nêu là làm việc này “dễ dàng đến mức triệt để để xây dựng và vận hành ứng dụng phân tán trên hạ tầng riêng của bạn.” Câu trích thật, và là một câu hay. Nhưng ngay bây giờ, nó vẫn là câu diễn tả ý định, chứ chưa phải thứ tải về chạy thử được.

Tại sao chuyện này đáng để đội ngũ kỹ thuật quan tâm

Thử hình dung một tình huống giả định — mình tự đặt ra để minh họa, không phải case thật của ai: một đội chạy trạng thái cộng tác thời gian thực trên Durable Objects — document chia sẻ, con trỏ chuột nhiều người cùng thấy. Sản phẩm chạy ổn. Rồi một khách hàng ở châu Âu hỏi dữ liệu của họ nằm vật lý ở đâu, và câu trả lời thành thật là “ở đâu đó trong hạ tầng Durable Objects của Cloudflare” — câu trả lời không sống sót qua một cuộc audit GDPR. Lúc đó, lựa chọn của đội khá hẹp: tái thiết kế quanh một mô hình compute khác, hoặc nói không với khách. Durable Objects bị khóa cứng vào nền tảng Cloudflare chính là rào cản kiểu này cho những đội có yêu cầu compliance, data residency, hay multi-cloud không thể đàm phán.

Nếu workerd thật sự thừa hưởng được logic định vị phân tán của celld, tình huống trên đổi hẳn. Vẫn cùng đoạn code Workers, cùng mô hình lập trình Durable Objects, nhưng chạy trên hạ tầng đội tự kiểm soát — châu Âu, on-prem, chỗ nào yêu cầu chỉ tới. Lời hứa này đáng tin ở mức nào đó, vì celld không phải thứ chỉ tồn tại trên slide. Nó sống hai năm như một dự án độc lập, giải một phiên bản của đúng bài toán này — không phải chuyện ai đó hứa xây distributed state management từ đầu vào quý sau.

Nhưng đáng tin và đã ra mắt là hai chuyện khác nhau. Khoảng cách giữa hai thứ đó mới là nơi mình muốn dừng lại cẩn thận.

Những câu hỏi mình muốn được trả lời trước

Ngôn từ chính thức của Cloudflare là “sẽ có thêm chi tiết trong những tháng tới.” Không ngày GA. Không giá. Không công cụ migration. Nếu bạn là technical lead và có người trong đội đang vẽ sẵn kế hoạch migration cho Q4/2026 dựa trên tin này, nên kéo họ lại. “Những tháng tới” không phải mốc để lên lịch cho cả quý.

Trước khi dám tin Durable Objects tự host cho bất cứ thứ gì quan trọng, đây là những gì mình muốn thấy — chưa cái nào có câu trả lời lúc này, đây là câu hỏi mở, không phải lời chê trách kế hoạch.

Tính nhất quán sẽ ra sao khi state của một Durable Object trải ra trên nhiều máy do chính bạn vận hành, thay vì một instance duy nhất do Cloudflare quản lý? Durable Objects dạng single-instance có câu chuyện nhất quán đơn giản gần như theo bản chất — chỉ có một bản duy nhất. Định vị phân tán buộc phải nghĩ kỹ chuyện gì xảy ra khi mạng bị chia cắt, một node chạy chậm, hay một process celld crash giữa lúc ghi dữ liệu. celld có lẽ đã có câu trả lời; mình chỉ chưa thấy nó công bố chi tiết.

Gánh nặng vận hành thực tế của tự chạy celld, ngày qua ngày, so với để Cloudflare chạy phần tương đương, là gì? “Quản lý nhiều instance của celld và một object storage bucket duy nhất” là câu gọn gàng. Chạy bất cứ thứ gì có trạng thái trong production, với các ca on-call và lỗi xảy ra lúc 3 giờ sáng, hiếm khi vẫn gọn gàng vậy. Mình muốn biết cái gì sẽ hỏng, debug ra sao, và việc debug đó cần loại chuyên môn gì — không phải đội nào cũng sẵn có.

Và nếu đội bạn đang có Durable Objects chạy trên Cloudflare ngay lúc này, dữ liệu đó sẽ ra sao nếu một ngày muốn chuyển sang celld tự host? Có đường di chuyển không, hay phải bắt đầu lại từ số 0? Thông báo không nói gì tới chuyện đó, cũng hợp lý — chưa có sản phẩm ra mắt thì chưa có gì để kể về migration. Nhưng đây sẽ là câu hỏi đầu tiên mình hỏi thẳng Cloudflare khi có thêm chi tiết.

Không câu hỏi nào trong số này là lý do để xem nhẹ thông báo. Tuyển được người tạo ra Node và Deno, rồi sáp nhập một dự án Rust hai năm tuổi, có năng lực state phân tán thật, trực tiếp vào codebase mã nguồn mở của runtime production — đó là cam kết cụ thể, kỹ thuật, kiểm chứng được, khác hẳn thông cáo hợp tác mơ hồ. Dấu hiệu tốt cho thấy những người liên quan hiểu rõ họ đang giải bài toán gì, và đã xây sẵn một phần câu trả lời chạy thật.

Chỉ là mình sẽ không lên kế hoạch dựa trên một timeline chưa tồn tại. Mình sẽ đọc lại thông báo của Cloudflare khi bản cập nhật tiếp theo xuất hiện, và nếu bạn đang định đưa cái này vào roadmap của đội mình, nên làm điều tương tự trước khi chốt bất cứ dòng nào.