Cloudflare تیم Deno را می‌گیرد؛ workerd و celld یکی می‌شوند

Cloudflare در بیانیهٔ ۹ اکتبر ۲۰۲۶ پیوستن تیم Deno و برنامهٔ ادغام کد و ایده‌های celld در workerd را اعلام کرد؛ رایان دال در همان متن نوشت: «we're merging workerd and celld!» هدف این همکاری، آسان‌تر کردن اجرای Workers و Durable Objects روی زیرساختی خارج از شبکهٔ Cloudflare است. ادغام هنوز برنامه‌ای برای توسعه است و محصول مشترک تکمیل‌شده‌ای معرفی نشده است.

TechCrunch در گزارش ۱۰ اکتبر این رویداد را خرید Deno توصیف کرد و نوشت شرایط مالی معامله افشا نشده است؛ Deno پیش‌تر در مجموع ۲۶ میلیون دلار سرمایه جذب کرده بود. برای کسب‌وکارهای متکی به Deno، پرسش فوری به ادامهٔ سرویس میزبانی و پشتیبانی runtime مربوط می‌شود. برای کاربران Workers، اهمیت معامله در امکان آیندهٔ اجرای برنامه‌های دارای وضعیت پایدار روی زیرساخت خودشان است.

ادغام workerd و celld چه گرهی را باز می‌کند؟

workerd موتور متن‌باز اجرای Cloudflare Workers است؛ Cloudflare می‌گوید این همان کدی است که در محیط عملیاتی خود به کار می‌برد. با این حال، پشتیبانی آن از Durable Objects در میزبانی مستقل به یک نمونه محدود است. این محدودیت برای برنامه‌ای که باید وضعیت و درخواست‌ها را میان چند ماشین توزیع کند، تفاوتی اساسی با اجرای همان مدل در شبکهٔ Cloudflare ایجاد می‌کند.

Durable Object منطق برنامه را به یک شیء آدرس‌پذیر و وضعیت آن پیوند می‌دهد. در توصیف رایان دال، هر شیء می‌تواند پایگاه دادهٔ SQLite خود را داشته باشد، ارتباط WebSocket را اداره کند و به درخواست‌های مربوط به همان شیء پاسخ دهد. وقتی چنین برنامه‌ای روی چند ماشین اجرا شود، سامانه باید بداند هر شیء کجا قرار دارد، درخواست را به کدام نمونه بفرستد و دادهٔ ماندگار را چگونه نگه دارد. داشتن موتور اجرای جاوااسکریپت به‌تنهایی این وظایف را انجام نمی‌دهد.

celld برای همین بخش توزیع‌شده ساخته شده است. طرح آن بر یک فایل اجرایی نوشته‌شده با Rust و ذخیره‌سازی شیء به‌عنوان وابستگی خدماتی بیرونی تکیه دارد؛ برنامه می‌تواند روی چند نمونهٔ celld اجرا شود و از یک فضای ذخیره‌سازی شیء استفاده کند. انتقال کد و ایده‌های آن به workerd قرار است فاصلهٔ میان اجرای مستقل یک Worker و ادارهٔ برنامه‌ای مبتنی بر Durable Objects در چند ماشین را کمتر کند. این توصیف، جهت معماری را روشن می‌کند، اما هنوز مشخصات نسخهٔ ادغام‌شده یا شیوهٔ ارتقای استقرارهای موجود را تعیین نمی‌کند.

رایان دال و برت بلدر قرار است توسعهٔ میزبانی مستقل workerd را برای پشتیبانی رسمی هدایت کنند. اهمیت این تصمیم برای Cloudflare فراتر از افزودن اعضای تیم Deno است: اگر ادغام طبق برنامه پیش برود، مدل برنامه‌نویسی Workers می‌تواند در محیطی به کار رود که خود مشتری اداره می‌کند. در نتیجه، وابستگی به شبکهٔ Cloudflare و وابستگی به مدل برنامه‌نویسی آن در تصمیم معماری یکسان نخواهند بود.

پایان Deno Deploy و مسیر متفاوت runtime و JSR

Deno در برنامهٔ منتشرشدهٔ خود اعلام کرد کل تیمش به Cloudflare می‌پیوندد، runtime را یک سال دیگر پشتیبانی می‌کند و Deno Deploy را پس از شش ماه متوقف خواهد کرد. این دو مهلت به دو محصول متفاوت مربوط‌اند: runtime محیط اجرای برنامه است، در حالی که Deploy سرویس میزبانی برنامه‌هاست. بنابراین ادامهٔ کار یکی را نباید به معنای ادامهٔ سرویس دیگری گرفت.

در دورهٔ پشتیبانی runtime، انتشارهای ماهانه شامل اصلاح خطا و به‌روزرسانی امنیتی خواهد بود. پس از پایان این دوره، توسعهٔ آن از سوی تیم Deno متوقف می‌شود، اما کد متن‌باز می‌ماند و دیگران می‌توانند توسعه‌اش را ادامه دهند. برای تیمی که runtime را روی زیرساخت خود اجرا می‌کند، تغییر اصلی پایان پشتیبانی رسمی در موعد اعلام‌شده است؛ متن‌باز ماندن کد به‌تنهایی جای همان تعهد پشتیبانی را نمی‌گیرد.

وضعیت مشتریان Deno Deploy مستقیم‌تر است، زیرا خود سرویس قرار است تعطیل شود. برای مشتریان پولی که به Cloudflare Workers منتقل می‌شوند، کمک مهاجرت وعده داده شده است؛ دامنهٔ این کمک و شرایط قراردادی آن هنوز مشخص نیست. همچنین انتقال به Workers را نمی‌توان معادل اجرای بی‌تغییر همهٔ برنامه‌های Deploy دانست. سازگاری کد، وابستگی‌های برنامه و جایگزینی خدمات میزبانی، جزئیاتی هستند که اعلامیه برای هر پروژه به‌طور جداگانه تعیین نکرده است.

JSR، رجیستری بسته‌های این اکوسیستم، فعال می‌ماند و زیرساخت آن به Cloudflare منتقل می‌شود. پشتیبانی از rusty_v8 نیز ادامه پیدا می‌کند و ادغام آن در workerd در دست پیگیری است. برای کسب‌وکاری که هم بسته‌های JSR مصرف می‌کند و هم برنامه‌اش را روی Deploy اجرا می‌کند، این‌ها یک تغییر واحد نیستند: رجیستری ادامه می‌یابد، اما محل اجرای برنامه باید با پایان سرویس میزبانی سازگار شود.

اثر معامله بر معماری کاربران Workers و Deno

برای کاربران Workers، وعدهٔ اصلی امکان ادارهٔ مدل Workers و Durable Objects بر زیرساخت خودشان است. workerd را می‌توان اکنون مستقل اجرا کرد، ولی محدودیت فعلی Durable Objects همان بخشی است که celld برای رفع آن وارد طرح ادغام می‌شود. از این رو، برنامه‌ای که تنها به اجرای Worker نیاز دارد و برنامه‌ای که وضعیت خود را به Durable Objects می‌سپارد، از این معامله یکسان تأثیر نمی‌گیرند.

برای کاربران Deno، محل اجرای فعلی برنامه تعیین‌کننده‌تر است. استفاده از runtime در محیط اختصاصی به دورهٔ پشتیبانی و آیندهٔ توسعهٔ متن‌باز آن مربوط می‌شود؛ استفاده از Deploy به توقف سرویس میزبانی و مسیر انتقال وابسته است. JSR هم مسئلهٔ توزیع بسته‌ها را پوشش می‌دهد و ادامهٔ فعالیتش تضمینی برای ادامهٔ Deploy نیست. این تفکیک نشان می‌دهد چرا سرنوشت تیم، پروژه‌های متن‌باز و محصولات تجاری Deno را نمی‌توان با یک پاسخ توضیح داد.

جزئیات نسخهٔ مشترک workerd و celld، سطح پشتیبانی میزبانی مستقل و مسیر ارتقای استقرارهای کنونی هنوز منتشر نشده است. انتظار می‌رود توضیحات بیشتری دربارهٔ این کار در ماه‌های آینده ارائه شود. تا آن زمان، کسب‌وکارهای متکی به Deno Deploy با موعد توقف یک سرویس روبه‌رو هستند، در حالی که امکان اجرای توزیع‌شدهٔ Workers روی زیرساخت مستقل هنوز به نتیجهٔ ادغام بستگی دارد.

بیشتر بخوانید:

• Clef تصمیم می‌گیرد، متن نمی‌نویسد؛ ادعای سرعت Cloudflare زیر سؤال رفت
• Cloudflare Workers یا Vercel؛ پهنای باند می‌تواند هزینه را ۳۲ برابر کند
• تلسکوپ PRIMA انتخاب شد؛ خلأ میان Webb و رادیوتلسکوپ‌ها را هدف می‌گیرد