Ne oldu?
Deno ekibi, Cloudflare'e katıldığını duyurdu. Duyuru, Cloudflare blogunda Ryan Dahl ve Kenton Varda'nın kaleminden yayımlandı. İkilinin anlattığına göre bu birleşmenin amacı, Workers ve Durable Objects'in kendi kendine barındırılmasını radikal biçimde basitleştirmek ve geliştiricilerin aynı yapı taşlarını daha fazla yerde kullanabilmesini sağlamak.
Bu duyuruyu bir satın alma ya da bir ürün lansmanı haberi gibi okumak yanıltıcı olur. Burada anlatılan şey, iki ekibin ve iki açık kaynak kod tabanının aynı çatı altında birleşmesi. Deno ekibi, Workers ve Durable Objects'in kendi kendine barındırılmasını radikal biçimde basitleştirmek için Cloudflare'e katılıyor. Yani hedef, mevcut bir ürünü pazarlamak değil; var olan bir programlama modelini bulut dışına taşıyacak altyapıyı olgunlaştırmak.
Cloudflare tarafında somut adım, iki açık kaynak projenin birleştirilmesi: workerd ve celld. Cloudflare, workerd ve celld'i birleştiriyor. Bu birleşmenin sonucunda, kendi altyapınızda dağıtılmış uygulamalar oluşturmayı ve işletmeyi radikal biçimde kolaylaştırmayı amaçlıyorlar. Buradaki "kendi altyapınız" ifadesi kritik: Amaç, geliştiricinin uygulamasını yalnızca Cloudflare'in sunucularında değil, kendi seçtiği donanımda da aynı modelle çalıştırabilmesi.
Duyuruda iki ismin yeni rolleri de netleşiyor. Ryan Dahl, Cloudflare'de Kıdemli Baş Mühendis olarak görev yapıyor. Kenton Varda ise Cloudflare'de Seçkin Mühendis olarak görev yapıyor. Ryan Dahl ve Bert Belder, workerd'in kendi kendine barındırılmasını, Workers programlama modelini kullanarak uygulama oluşturmanın ve çalıştırmanın birinci sınıf desteklenen bir yolu haline getirmek için yeni bir çabaya öncülük edecek. Bu çaba, celld'den kod ve fikirlerin workerd'e geri birleştirilmesini içerecek.
Buradaki "birinci sınıf desteklenen" ifadesi, sıradan bir açık kaynak katkısından farklı bir taahhüdü anlatıyor. Birinci sınıf destek, o yolun artık yan bir deney değil, resmi olarak bakımı yapılan, dokümante edilen ve üzerine uygulama yazılabilen bir seçenek haline gelmesi anlamına geliyor. Kısacası hedef, kendi kendine barındırmayı "meraklısı için" bir uğraş olmaktan çıkarıp normal bir dağıtım biçimi yapmak.
Duyurunun kapsamı konusunda bir sınır da var: Duyuruda ürün takvimi veya fiyatlandırma gibi ek ayrıntı yer almıyor. Önümüzdeki aylarda bu iş hakkında daha fazla duyuru yapılacak. Bekleyemeyenler ise bugün celld veya workerd'i kendi kendine barındırmaya başlayabilir. Yani bugün elinizde çalışan bir şey var, ama iki parçanın gerçekten kaynaşmış hali henüz ortada değil.
Arka plan
Bu duyuruyu anlamak için iki ismin geçmişine bakmak gerekiyor. Ryan Dahl, Node.js'in yaratıcısıdır ve sunucuda JavaScript kullanma fikrini icat etmiştir. Node.js'i Berlin'de bir depoda 500 satırlık bir JavaScript IRC sunucusu ve canlı izleyici katılımıyla tanıttı. Bu tanıtım, sunucu tarafında JavaScript'in ciddiye alınabileceğini gösteren anlardan biriydi; o güne kadar JavaScript çoğunlukla tarayıcı içinde kalan bir dil olarak görülüyordu.
Ardından Ryan Dahl, Bert Belder ve Deno Land ekibinin geri kalanı Deno'yu yarattı. Deno, JavaScript (ve TypeScript) çalışma zamanıdır. Yani Node.js'in ardından gelen, aynı temel fikri farklı tasarım kararlarıyla sürdüren bir çalışma zamanı. Deno'nun çıkış noktası, Node.js deneyiminden öğrenilenlerin daha temiz bir modelle yeniden kurulmasıydı.
Ryan Dahl, Deno'yu daha güçlü soyutlamalar bulmak için başlattı. Ancak kendi değerlendirmesine göre Deno ile JavaScript yazma deneyimini iyileştirdiler, fakat geliştiricilerin çalışma zamanı etrafında bir araya getirmek zorunda olduğu şeyleri temelden değiştirmediler. Bu cümle, bir özeleştiri olarak okunmalı: Dil seviyesindeki iyileştirmeler, uygulamanın çalıştığı ortamın karmaşıklığını ortadan kaldırmıyor.
Ryan Dahl'a göre daha büyük sorunlar ağ üzerinden çalışan uygulamalarla ilgili: hesaplamayı dağıtmak, durumu koordine etmek, genel olarak veri depolama ve talebi karşılamak için otomatik ölçeklendirme. Bu dört başlık, aslında modern bir web uygulamasının kurulmasında en çok zaman yiyen kısımlar. Bir geliştirici kod yazmayı bitirdiğinde iş bitmiyor; kodu nereye koyacağını, durumu nerede tutacağını, trafik arttığında ne olacağını ayrı ayrı çözmesi gerekiyor.
Bu noktada devreye Cloudflare'in Durable Objects'i giriyor. Ryan Dahl, Cloudflare'in Durable Objects'ini okuduğunda çözümün netleştiğini belirtiyor. Deno Deploy'u oluşturmak ve işletmek de ona bulut altyapısının ne kadar karmaşık hale gelebileceğini öğretti: birden fazla genel bulut, birden fazla veritabanı ve derinden iç içe geçmiş hizmetler. Bu deneyim, "tek bir çalışma zamanı yeterli değil" sonucuna götürüyor; asıl mesele, çalışma zamanının etrafındaki hizmet yığını.
Cloudflare tarafında ise Kenton Varda, Deno ekibinin Ağustos ayında celld'i yayınladığında çok memnun olduklarını belirtiyor. Varda, celld'in kendi uygulamalarıyla tamamen uyumlu olacak şekilde tasarlanmış, kendi kendine barındırılabilir ve ölçeklenebilir olmaya odaklanmış bir Workers ve Durable Objects uygulaması olduğunu söylüyor. Yani iki ekip, aynı problemi iki farklı yönden çözmeye çalışırken birbirlerinin çalışmasını fark etmiş görünüyor.
Varda ayrıca Cloudflare Workers'ı diğer bulut platformlarından farklı çalıştırdıklarına dair bir iddiayı da ele alıyor: 'kilitlenme' yaratmak için yapıldığının iddia edildiğini, ancak bu teorinin yanlış olduğunu belirtiyor. Varda'ya göre Workers'ı farklı yaptılar çünkü bunun web uygulamaları oluşturmanın daha iyi bir yolu olduğuna inanıyorlar. Ona göre Workers tasarımı, dünya çapında yüzlerce konumda çalışan bir uygulamayı yönetmeyi son derece basit ve çok ucuz hale getiriyor. Fiyatlandırmanın bir hile olmadığını, rakiplerden daha verimli yeni bir mimari yarattıklarını ve tasarrufları müşterilere aktardıklarını söylüyor.
Buradaki "kilitlenme" tartışması, aslında bir mimari tercihin nasıl yorumlandığıyla ilgili. Bir platform, alışılmış kalıpların dışına çıktığında iki farklı okuma mümkün: Ya bilinçli bir tasarım tercihi, ya da kullanıcıyı platforma bağlamak için yapılmış bir sınırlama. Varda ikinci okumayı reddediyor ve tercihin teknik gerekçesini öne çıkarıyor.
Açık kaynak konusu da bu hikayenin merkezinde. Varda, 'kilitlenme'nin aslında onlara zarar verdiğini, bu yüzden açık kaynak yaptıklarını söylüyor. 2022'de Shopify gibi müşterilere Workers for Platforms'u tanıttıklarında geri bildirim netti: Workers Runtime açık kaynak olmadıkça üzerine inşa edemeyeceklerini söylüyorlardı. Cloudflare Workers Runtime, yani workerd, açık kaynaklıdır ve üretimde çalıştırdıkları kodun aynısıdır, paralel bir uygulama değildir. Varda, workerd kullanarak onlardan ayrılan eski müşterileri olduğunu da belirtiyor ve açık kaynak olmanın, insanlara bir kaçış yolu sunmanın iyi bir iş olduğunu söylüyor.
"Üretimde çalıştırdıkları kodun aynısı" vurgusu önemli. Açık kaynak projelerde sık görülen bir durum, yayınlanan sürümün şirketin içeride kullandığından farklılaşmasıdır. Burada iddia edilen bunun tersi: Dışarıya verilen kod, Cloudflare'in kendi üretiminde koşan kodun ta kendisi. Bu, açık kaynağın bir vitrin değil, gerçek altyapının paylaşılması anlamına geldiği iddiası.
Ancak burada bir boşluk vardı. Varda, workerd'i üretimde kullanma niyetiyle yayınladıklarını ancak şu ana kadar çok fazla kişinin kullanmadığını belirtiyor. Ona göre workerd'in üretime hazır olmasında her zaman büyük bir boşluk vardı: Durable Objects. Workerd, Durable Objects'i uygular ancak yalnızca yerel test için yeterli olan tek örnekli bir şekilde, ölçeklenemez. Varda, Durable Object yönlendirmesinin üretim uygulamalarının, kendi kendine barındıran herhangi birinin isteyeceği uygulama olmadığını söylüyor. Geçen bahar bir girişimde bulunduğunu ancak utanç verici bir şekilde işe yaramadığını da ekliyor.
Bu itiraf, duyurunun tonunu belirliyor. Bir şirketin kendi açık kaynak projesinin neden tutmadığını bu kadar açık anlatması yaygın değil. Ama aynı zamanda sorunun nerede olduğunu da netleştiriyor: Eksik olan şey dil ya da çalışma zamanı değil, dağıtık durumun yönetimi.
Nasıl çalışıyor?
Bu duyurunun teknik özünü anlamak için Durable Objects'in ne olduğuna bakmak gerekiyor. Her Durable Object, kendi ilişkisel veritabanına sahip, ayrı ayrı adreslenebilir küçük bir sunucu gibidir. Bir Durable Object'in JavaScript yürütmesi tek iş parçacıklıdır. Bir Durable Object, WebSockets'i işler ve yerel SQLite veritabanına eşzamanlı olarak erişilebilir.
Bu üç özellik bir arada düşünüldüğünde ortaya çıkan tablo şu: Her nesne, kendi verisini yanında taşıyan, kendi başına adreslenebilen ve aynı anda hem canlı bağlantıları hem de kalıcı veriyi yönetebilen bir birim. Tek iş parçacıklı olması, aynı anda iki işlemin aynı veriyi bozması gibi klasik eşzamanlılık sorunlarını büyük ölçüde ortadan kaldırıyor. Yerel SQLite ise veriyi ağ üzerinden ayrı bir veritabanına gitmeden, nesnenin yanında tutmayı mümkün kılıyor.
Bu yapı, ölçeklenebilir uygulamalar kurmayı kolaylaştırıyor. Kanal başına bir DO kullanarak bir sohbet uygulaması oluşturduğunuzda, verilerinizi ve WebSocket bağlantılarınızı parçalara ayırmış ve böylece uygulamanızı ölçeklenebilir hale getirmiş olursunuz. Buradaki mantık, tek bir merkezi sunucuya yüklenmek yerine işi doğal sınırlarına göre bölmek. Bir sohbet uygulamasında bu sınır kanalın kendisi; her kanal kendi nesnesinde yaşıyor ve kanallar birbirini yavaşlatmıyor.
DO'lar üzerine Queues, KV, Durable Execution (Cloudflare'in Workflow API'si) ve hatta Git depolama gibi diğer hizmetler inşa edilebilir. Bu, Durable Objects'in yalnızca bir uygulama bileşeni değil, başka hizmetlerin üzerine kurulduğu bir temel olduğunu gösteriyor. Durable Objects, klasik üç katmanlı web mimarisinde zor veya imkansız olan gerçek zamanlı işbirliği ve dağıtılmış sistemler oluşturmayı kolaylaştırır.
Klasik üç katmanlı mimaride sunum, uygulama mantığı ve veri katmanı birbirinden ayrılır ve her katman ayrı ölçeklenir. Bu model birçok iş yükü için gayet iyi çalışır; ama aynı belge üzerinde aynı anda düzenleme yapan birden fazla kullanıcı gibi senaryolarda, katmanlar arasındaki gidiş gelişler ve durum paylaşımı ciddi bir mühendislik yükü haline gelir. Durable Objects bu yükü, durumu nesnenin kendisine taşıyarak azaltmayı öneriyor.
Workers tarafında ise canlı ortam tasarımı, diğer adıyla 'bağlamalar', harici kaynaklara erişimi yapılandırmayı aynı anda hem daha kolay hem de daha güvenli hale getirir. Geleneksel yaklaşımda bir uygulama, dış kaynağa erişmek için ortam değişkenlerinde ya da yapılandırma dosyalarında anahtar taşır. Bağlamalar modelinde ise erişim, kodun içinde tanımlı bir bağ üzerinden verilir. Bu, hem yapılandırmayı sadeleştirir hem de sızdırılabilecek ham kimlik bilgilerinin ortada dolaşmasını azaltır.
Varda'ya göre daha iyi olmak farklı olmayı gerektiriyor; mevcut platformlarla tamamen uyumlu kalarak bu faydaları elde edemeyeceklerini belirtiyor. Bu, tercihlerin neden alışılmadık göründüğünü açıklayan bir cümle: Eğer her şey mevcut kalıplara birebir uysaydı, elde edilecek şey de mevcut kalıpların verdiği sonuç olurdu.
Peki celld bu denkleme nasıl giriyor? Celld, Rust ile yazılmış tek bir ikili dosyadır ve tek dış hizmet bağımlılığı nesne depolamadır. Celld'i çalıştırmak için birçok celld örneği ve tek bir nesne depolama paketi yönetirsiniz. Ryan Dahl, celld'i tam da workerd'in ölçeklenemeyen Durable Objects desteği nedeniyle başlattı. Celld, kendi kendine barındırılabilir ve ölçeklenebilir olmaya odaklanmış bir Workers ve Durable Objects uygulaması olarak tasarlandı.
"Tek bir ikili dosya" ve "tek dış bağımlılık" ifadeleri, kendi kendine barındırmanın en çok can yakan kısmına işaret ediyor. Kendi sunucunuzda bir şey çalıştırmak istediğinizde asıl zorluk, uygulamanın kendisi değil; onun etrafındaki veritabanı, kuyruk, önbellek ve yapılandırma yığınıdır. Celld bu yığını tek bir nesne depolama paketine indirmeyi öneriyor. Yani kurulum, "bir sürü servisi ayağa kaldır ve birbirine bağla" yerine "örnekleri çalıştır ve bir depolama paketi ver" noktasına yaklaşıyor.
Şimdi plan, bu iki parçayı birleştirmek. Cloudflare, Workers programlama modelini sunucu oluşturmanın ana akım bir yolu haline getirmek için Deno ekibine katılıyor. Celld ve workerd'i bir araya getirerek, kendi altyapınızda dağıtılmış uygulamalar oluşturmayı ve işletmeyi radikal biçimde kolaylaştırmayı amaçlıyorlar. Bu, celld'den kod ve fikirlerin workerd'e geri birleştirilmesini içerecek.
Burada iki projenin güçlü yanları tamamlayıcı görünüyor: workerd, Cloudflare'in üretimde kullandığı çalışma zamanı; celld ise aynı modelin kendi kendine barındırılabilir ve ölçeklenebilir halini hedefliyor. Birleşmenin mantığı, üretimde kanıtlanmış çalışma zamanını, dağıtık durumu ölçekleyebilen bir yapıyla buluşturmak.
Kenton Varda, bu iş için şahsen evinde bir Cloudflare OS örneği barındırmak için kullanacağını belirtiyor. Bu ayrıntı, hedefin yalnızca kurumsal müşteriler değil, bireysel geliştiriciler ve küçük ekipler olduğunu da gösteriyor: Kendi donanımınızda, kendi nesne depolama paketinizle bir Workers benzeri ortam çalıştırmak. Bir şirketin üst düzey mühendisinin kendi evindeki donanımı bu iş için referans alması, ölçeğin nerede başladığına dair de bir ipucu.
Kimler için ne anlama geliyor?
Geliştiriciler için
En doğrudan etki, kendi kendine barındırma tarafında. Bugüne kadar workerd açık kaynak olsa da Durable Objects desteği tek bir örnekle sınırlıydı; bu da onu yerel test için kullanışlı ama üretim için yetersiz kılıyordu. Celld ve workerd'in birleşmesiyle, geliştiricilerin kendi altyapılarında ölçeklenebilir Durable Objects çalıştırabilmesi hedefleniyor. Bu, bulut sağlayıcısına bağımlı olmadan Workers programlama modelini kullanmak isteyenler için önemli bir kapı aralıyor.
Bunu somutlaştırmak gerekirse: Bugün bir geliştirici, gerçek zamanlı işbirliği özelliği olan bir uygulama yazdığında, durumu yönetmek için ayrı bir veritabanı, ayrı bir önbellek ve ayrı bir mesajlaşma katmanı kurmak zorunda kalıyor. Bu katmanların her biri kendi yapılandırması, kendi izleme aracı ve kendi hata moduyla geliyor. Durable Objects modeli, bu işlerin önemli bir kısmını nesnenin kendi içine taşıyor. Kendi kendine barındırma olgunlaşırsa, aynı model bulut dışında da kurulabilir hale geliyor.
Bekleyemeyenler bugün celld veya workerd'i kendi kendine barındırmaya başlayabilir. Yani birleşme tamamlanmadan da deneme yapmak mümkün. Ancak Varda'nın kendi ifadesiyle workerd'i üretimde kullanma niyetiyle yayınlamalarına rağmen şu ana kadar çok fazla kişi kullanmadı; bu da mevcut durumda deneyimin henüz olgunlaşmadığını gösteriyor. Erken denemek isteyenler için yol açık, ama bunun hâlâ bir kurulum ve deneme süreci olduğunu bilmek gerekiyor.
Şirketler için
Kurumsal tarafta iki farklı senaryo var. Bir yanda Cloudflare Workers ve Durable Objects'i bulut üzerinden kullananlar, diğer yanda kendi altyapısında çalıştırmak isteyenler. İkinci grup için bu duyuru, açık kaynaklı bir alternatifin üretim seviyesine taşınması anlamına geliyor. Varda'nın aktardığına göre 2022'de Shopify gibi müşteriler, Workers Runtime açık kaynak olmadıkça üzerine inşa edemeyeceklerini söylemişti. Bu birleşme, o geri bildirime verilen yanıtın bir sonraki adımı olarak okunabilir.
Buradaki mantık, kurumsal müşterilerin genelde iki şeyi aynı anda istemesiyle ilgili: Bir yandan yönetilen bir hizmetin kolaylığını, diğer yandan da kendi altyapılarında çalıştırabilme esnekliğini. Bir platform yalnızca bulutta çalışıyorsa, o platformun üzerine kurulan ürünler de ister istemez o buluta bağlı kalıyor. Açık kaynak bir çalışma zamanı, bu bağı gevşetmenin yollarından biri.
Ayrıca Varda, workerd kullanarak Cloudflare'den ayrılan eski müşterileri olduğunu belirtiyor. Yani açık kaynak, müşteri kaybına yol açsa bile stratejik olarak sürdürülen bir tercih. Varda bunu 'insanlara bir kaçış yolu sunmanın iyi bir iş olduğu' şeklinde açıklıyor. Bu, kısa vadeli müşteri tutma hesabından farklı bir gerekçe: Kullanıcının çıkış kapısını açık tutmak, uzun vadede ekosistemi büyüten bir hamle olarak görülüyor.
Sıradan kullanıcılar için
Doğrudan bir etki yok; bu bir altyapı ve geliştirici aracı haberi. Ancak dolaylı sonuçlar olabilir: Daha basit ve daha ucuz kendi kendine barındırma, geliştiricilerin gerçek zamanlı işbirliği uygulamaları, sohbet uygulamaları ve dağıtılmış sistemleri daha düşük maliyetle kurmasını sağlayabilir. Varda'ya göre Workers tasarımı, dünya çapında yüzlerce konumda çalışan bir uygulamayı yönetmeyi son derece basit ve çok ucuz hale getiriyor; fiyatlandırmanın bir hile olmadığını, rakiplerden daha verimli yeni bir mimari yarattıklarını ve tasarrufları müşterilere aktardıklarını söylüyor. Bu iddialar şirketin kendi değerlendirmesi; bağımsız olarak doğrulanmış veriler değil.
Kullanıcı açısından bunun görünür hali genelde şu olur: Bir uygulamanın gerçek zamanlı özellikleri daha az gecikmeyle çalışır, geliştirici maliyetleri düşerse bu fiyatlara ya da ücretsiz sürümlere yansıyabilir. Ama bu zincirin her halkası kesin değil; altyapı kararlarının son kullanıcıya yansıması aylar alabilir ve her zaman doğrudan görünmez.
Sınırlar ve açık sorular
Duyurunun en belirgin sınırı, somut bir takvimin olmaması. Duyuruda ürün takvimi veya fiyatlandırma gibi ek ayrıntı yer almıyor. Önümüzdeki aylarda bu iş hakkında daha fazla duyuru yapılacak deniyor, ancak workerd ve celld'in birleştirilmesinin ne zaman tamamlanacağı belirsiz. Bu belirsizlik, bugün başlamak isteyenler için önemli: Elinizdeki iki parça var, ama birleşmiş halleri henüz yok.
Deno tarafında da önemli bir soru işareti var: Deno runtime ve Deno Deploy'un geleceği ne olacak? Duyuruda bu konuda bir açıklama yer almıyor. Deno ekibinin Cloudflare'e katılımının mali koşulları da paylaşılmadı. Bir çalışma zamanının kullanıcıları için bu tür belirsizlikler önemlidir; çünkü bir projenin bakımının kim tarafından ve hangi önceliklerle sürdürüleceği, o projeye yatırım yapma kararını doğrudan etkiler.
Bir diğer açık soru, bu birleşme sonrası Workers ve Durable Objects için fiyatlandırmanın değişip değişmeyeceği. Varda fiyatlandırmanın bir hile olmadığını ve tasarrufların müşterilere aktarıldığını söylüyor, ancak kendi kendine barındırma yaygınlaşırsa bulut fiyatlandırmasının nasıl etkileneceği belirsiz. Burada iki yönlü bir baskı var: Kendi kendine barındırma bir alternatif olarak güçlenirse, bulut tarafının değer önerisini yeniden tanımlaması gerekebilir.
Teknik tarafta ise celld'in tek dış hizmet bağımlılığı nesne depolama. Bu, kendi kendine barındırmanın ne kadar basit olacağını gösteriyor ama aynı zamanda bir nesne depolama altyapısına ihtiyaç duyulduğu anlamına geliyor. Celld'i çalıştırmak için birçok celld örneği ve tek bir nesne depolama paketi yönetmek gerekiyor. Bu modelin ne kadar ölçekleneceği ve üretimde ne kadar dayanıklı olacağı, önümüzdeki aylarda yapılacak duyurularla netleşecek.
Buradaki pratik soru şu: Nesne depolama, dağıtık bir sistemde gecikmeye açık bir bileşen. Örnekler ile depolama arasındaki ilişkinin nasıl kurulduğu, sistemin gerçek dünyadaki davranışını belirleyecek. Duyuruda bu ayrıntı yer almıyor; dolayısıyla bugün için söylenebilecek şey, modelin basitliğinin aynı zamanda dikkat edilmesi gereken bir bağımlılık noktası oluşturduğu.
Son olarak, Varda'nın geçen bahar denediği ve 'utanç verici bir şekilde işe yaramadığını' söylediği girişim, kendi kendine barındırılabilir Durable Objects'in ne kadar zorlu bir problem olduğunu gösteriyor. Deno ekibinin celld deneyimi ve Cloudflare'in workerd altyapısı bir araya gelse bile, bu problemin tamamen çözülüp çözülmediğini zaman gösterecek. İki ekibin aynı problem üzerinde birleşmesi, sorunun ciddiyetinin bir göstergesi; ama çözümün üretimde ne kadar dayanacağı, önümüzdeki aylarda yapılacak duyurularla ve sahadaki denemelerle netleşecek.
