Skip to content
~/sph.sh

wasmCloud + NATS: Kilitlenme Aslında Event Bus Topolojisinde Yaşar

Bir keşif tezi: event-driven sistemlerde vendor lock-in runtime katmanında değil, bus topolojisinde yaşar; wasmCloud ve NATS ise bus'ı taşınabilir bir primitif haline getiriyor.

Somut Problem

Serverless kilitlenmesi üzerine konuşmaların çoğu runtime katmanına takılıyor: Lambda'ya karşı Cloud Functions, Workers'a karşı Containers. Event bus ise tesisat gibi ele alınıyor. Event-driven sistemlerde bu çerçeveleme tersine, çünkü runtime haftalar içinde değiştirilebilir, bus topolojisi ise çeyrekler içinde. Bu yazı, Lambda ve EventBridge ile zaten rahat çalışan ama wasmCloud ve NATS'a daha yakından bakmak gerekip gerekmediğini merak eden mühendisler için bir tez denemesi.

Tez

Event-driven sistemlerde vendor lock-in runtime katmanında yaşamaz. Bus topolojisinde yaşar. Lambda artı EventBridge event publish etmeyi çok kolay hale getirir, ama bus'ı sahiplenmezsiniz. Routing rule'lar, cross-account izinler, archive ve replay, schema registry, dead-letter akışı, retention semantiği, bunların hepsi AWS şekilli ve hepsi ister istemez sizinle birlikte taşınır. wasmCloud artı NATS bus'ı taşınabilir bir primitife dönüştürür: aynı subject hiyerarşisi, aynı JetStream retention'ı, aynı lattice bugün AWS'te, yarın bir colocation sunucusunda, bir sonraki çeyrekte bir edge point-of-presence'ta event kontratlarını yeniden yazmadan koşabilir. Bu alanın keşfedilmeye değmesinin sebebi tam olarak bu.

Lambda ve EventBridge bu hikayenin kötü adamları değil. Mükemmel araçlar ve tamamen AWS'e yaslanmış ekipler için çoğu zaman doğru tercih. Tez daha dar bir şey söylüyor: eğer bus'ın kendisi uzun vadeli mimariniz için önemliyse, bus'ı sahiplenmek runtime'ı sahiplenmekten daha önemli.

Zihinsel Model Değişimi

Merkezi yönetilen bus ve federe lattice aynı şeklin küçük varyasyonları değil. Koordinasyon yüzeyinin nerede yaşadığına dair farklı bahisler yapıyorlar.

EventBridge ile bus tükettiğiniz bir servistir. Producer bir bus ARN'ine yazar, routing tablosu IAM ve EventBridge rule'ları içinde yaşar, consumer bir Lambda target olur. Event'leri sahibi olmadığınız bir kutuya gönderir ve kutunun bu event'leri kendi dilinde yazdığınız kurallara göre dağıtmasına güvenirsiniz. Cloud değiştirdiğinizde producer kodu bir hafta içinde taşınabilir, bus topolojisi hiç taşınmaz.

NATS lattice üzerinde wasmCloud ile bus çalıştırdığınız bir primitiftir. Producer'lar payments.webhook.received gibi subject'lere publish eder. Consumer'lar load balancing için queue group'larla ya da broadcast için fan-out subscription'larla bağlanır. JetStream stream'ler seçtiğinizi, seçtiğiniz süre boyunca, seçtiğiniz depolamada tutar. Lattice VPC'ler, region'lar, on-prem datacenter'daki leaf node'lar ve gerekirse browser istemcileri arasında kendi kendini kurar, hepsi endpoint yerine subject ile adreslenir.

EventBridge tarafında ortada proprietary kurallara sahip proprietary bir bus var. NATS tarafında ortada bir subject hiyerarşisi var, ki bu sadece bir isimlendirme konvansiyonu, ve onu taşıyan transport sizin kontrol ettiğiniz bir dizi açık kaynak süreç.

Pratik sonuç: yönetilen tarafta bus topolojisi bir AWS artifact'ı ve taşınmak onu yeniden ifade etmek demek. Lattice tarafında bus topolojisi kodla birlikte taşınan bir dizi subject ismi ve stream konfigürasyonu.

Bir Webhook Fan-Out Keşfi Nasıl Görünürdü

Topoloji iddiasını test etmenin en net yolu scheduler'ı değil bus'ı zorlayan bir yük. Webhook fan-out buna uyuyor: tek bir gelen event'in farklı dayanıklılık ve gecikme ihtiyaçlarıyla birkaç consumer'a ulaşması gerekiyor, ki bu tam olarak bir routing katmanının iyi yapması gereken şey.

Denemek istediğim şekil şöyle. Bir wasmCloud HTTP bileşeni ödeme sağlayıcısından gelen bir webhook alıyor. İmzayı doğruluyor, tenant'ı çıkarıyor ve payments.{tenant}.webhook.{event-type} biçiminde bir subject ağacına publish ediyor. Bu ağaca üç tür consumer takılıyor:

  1. Bir queue group'a katılan gecikme-hassas bir consumer, böylece mesaj başına tam olarak bir worker entitlement cache'ini günceller.
  2. JetStream work-queue stream'i ile desteklenen dayanıklılık-hassas bir consumer, bir gün boyunca düşse bile mesajları kaybetmeden invoicing'i çalıştırır.
  3. Interest-based bir stream üzerinde analitik consumer, geç bağlanan aggregator'ların tutulan log'dan backfill yapmasına izin verir.

Keşfin yanıtlaması gereken, peşinen iddia etmediğim somut sorular:

  • Subject tasarımı. payments.{tenant}.* gibi tenant-scoped bir önek yeterli izolasyon veriyor mu, yoksa tenant sayısı arttıkça tenant başına ayrı stream daha iyi mi ölçekleniyor? Retention politikası seçimi (LimitsPolicy, WorkQueuePolicy, InterestPolicy) cevaba bağlı.
  • JetStream retention. Invoicing yolu için 7 günlük max-age'li bir WorkQueuePolicy stream doğru şekil mi, yoksa iş aslında replay'li LimitsPolicy mi istiyor? Consumer'ın düştüğü senaryoda bunlar farklı arıza modları.
  • Leaf-node şekli. Bir region'ın yerel tüketime ihtiyacı varsa, o region'da filtered JetStream mirror'lı bir leaf node yönetilen tarafla aynı semantiği veriyor mu, yoksa yalnızca yük altında ortaya çıkan zamanlama boşlukları var mı?
  • Cross-region lattice. Producer kodu farkına varmadan tek bir mantıksal lattice iki cloud region'ı ve bir on-prem leaf'i kapsayabilir mi? Lattice dokümanları evet diyor; partition altında tutup tutmadığı POC'nin cevaplaması gereken şey.

Bu yazıda bilinçli olarak gecikme rakamları, throughput değerleri ya da maliyet karşılaştırmaları vermiyorum. Bu iddialar henüz yapılmamış bir koşuya ait. Yukarıdaki şekil denemek istediğim şey, ölçtüğüm değil.

Dürüst Nüans: wasmCloud Roadmap'i "NATS Gerekli" Satışını Zayıflatıyor

Tezin temiz versiyonu "wasmCloud NATS kullandığı için harika" olurdu. Bu çerçeveleme zaten güncelliğini yitirdi. wasmCloud Q3 2025 roadmap'i scheduler'ı ve provider'ları NATS-varsayılanından aktif olarak ayırıyor ve NATS'ın birkaç seçenekten biri (TCP, WebTransport, Unix Domain Sockets ve QUIC yanına geliyor) haline geldiği transport-pluggable bir wRPC katmanına doğru gidiyor.

Bu değişiklik tezi zayıflatmıyor, güçlendiriyor. Topoloji iddiası spesifik olarak NATS hakkında değil. Yönetilen bir router tüketmek yerine routing primitifini sahiplenmek hakkında. wRPC transport'u daha da pluggable yaparsa bir wasmCloud lattice'inin koşabileceği yerler kümesi büyür ve lock-in yüzeyi daha da küçülür. Bugün NATS varsayılan ve yukarıdaki keşif onun üzerinden çalışıyor. Yarın aynı actor manifest'i producer kodu fark etmeden belirli bir provider için farklı bir transport pinleyebilir.

Dürüst ifade "wasmCloud sonsuza dek NATS gerektirir" değil, "wasmCloud bugün NATS üzerinden olgun ve roadmap onu daha az değil, daha pluggable yapıyor."

İsimlendirilmeye değer bir ek bağlam: wasmCloud'un ticari destekçisi, projeyi 2021'de CNCF'e bağışlayan Cosmonic; NATS ise ana bakımını Nisan 2025'te NATS'ı Business Source License (BUSL) altına alma önerisi getiren Synadia üstleniyor — yukarıda atıfta bulunulan wasmCloud açıklaması da tam bu öneriye verilmiş bir yanıt. Taşınabilirlik tezini tartarken her iki olgu da önem taşıyor; "bus'ı sahiplenme" argümanı tam olarak bu primitiflerin etrafındaki ticari katmanlar değişebildiği için güçleniyor.

Takas Ettiğiniz Operasyonel Sınır

Tezin doğrudan isimlendirilmeye değer bir sınırı var, çünkü aksi halde eleştirisiz bir satış gibi okunuyor. Taşınabilir bir bus, vendor sınırını operasyonel sınırla takas eder. EventBridge ile bus'ı AWS çalıştırır: siz onu izlemezsiniz, yamalamazsınız, disk'i dolduğunda uyanmazsınız. Kendiniz çalıştırdığınız bir NATS lattice ile bunların hepsi sizin sorununuz: JetStream depolama boyutlandırması, leaf-node sağlığı, cluster upgrade döngüleri, mesh genelinde TLS rotasyonu.

Bu tarafın savunmaya değer bulduğum çiti: zaten stateful altyapı (Postgres, Redis, Kafka) çalıştıran bir ekip için bir NATS cluster eklemek artımsal bir yük ve taşınabilirlik faydası gerçek. Tüm ops duruşu "her şey yönetilen olsun" olan bir ekip için operasyonel sınır bir basamak fonksiyonu artışı, ve bus'ı daha az sahiplenmek anlamına gelse de EventBridge muhtemelen hala doğru cevap.

Tez birinci tür ekip için en güçlü hali ve bence bu ekip mevcut söylem tarafından yeterince temsil edilmiyor, çünkü en yüksek sesler ikinci tür için optimize ediyor.

Kapanış

Event bus'ınız kısa ömürlü bir üründe küçük bir tesisat parçasıysa EventBridge kullanın ve yola devam edin. Bus topolojisi iki runtime seçimini ve bir cloud vendor'ını geride bırakacaksa, taşınabilir bus yolu incelenmeye değer, ve NATS üzerinde wasmCloud bu yönde bugün en olgun yığın; wRPC roadmap'i bu incelemeyi yalnızca geleceğe daha dayanıklı hale getiriyor. Bu bir production migration blueprint'i değil; bir keşif tezi. Sıradaki adım yukarıdaki subject tasarımı ve leaf-node sorularını test eden küçük bir webhook fan-out POC'si ve gerçekte ne olduğunu raporlayan bir takip yazısı.

Kaynaklar

wasmcloud
nats
event-driven
webassembly
serverless
architecture
aws-eventbridge

İlgili Yazılar