Monolit ve mikroservislerin
ötesinde.

01 / Mimari seçimi

Monolitler ve mikroservisler farklı sorunları çözer.

Bir monolit, uygulamayı tek bir kurulabilir birim olarak paketler. Modüler olabilir, özenle test edilebilir ve bir yük dengeleyicinin arkasında çoğaltılabilir. Çekiciliği pratiktir: yerel çağrılar, kolay hata ayıklama ve daha az hareketli parça. Sınırları ise çoğu zaman ortak sürümler, sahiplik sınırları ya da dengesiz kaynak ihtiyaçları etrafında ortaya çıkar.

Mikroservisler bir uygulamayı bağımsız olarak kurulabilen servislere böler. Alanların ve ekiplerin kendi sürüm döngülerine, ölçekleme politikalarına ya da operasyonel sınırlarına ihtiyaç duyduğu durumlarda faydalıdır. Bu bağımsızlık beraberinde iş getirir: ağ çağrıları, sürümlenmiş sözleşmeler, gözlemlenebilirlik, hata yönetimi ve çoğu zaman ayrı veri depoları arasında tutarlılık.

Hiçbiri kendiliğinden daha hızlı ya da daha ölçeklenebilir değildir. İyi tasarlanmış bir monolit büyük bir iş yüküne hizmet verebilir. Kötü bölünmüş bir mikroservis sistemi ise darboğazlarını dağıtıp onları görmeyi zorlaştırabilir.

Bu ayrım önemlidir, çünkü kurulumun dağıtılması ile iş modülerliği ayrı kararlardır. Ayrı servisler olmadan modüllere sahip olabilirsiniz; uygulamanın mantıksal modelini parçalamadan çok sayıda sunucuya da sahip olabilirsiniz.

02 / Tek bir mantıksal model

Veritabanını ve arka ucu birbirine yaklaştırın.

Cygnus, NatusAI'ın planlanan dil, veritabanı ve arka uç temelidir. Tasarım; tipli uygulama mantığını, kalıcı veriyi ve dışa açılan fonksiyonları tutarlı tek bir ortamda bir araya getirir. Geliştiriciler her sınırda ayrı bir eşleme sürdürmek yerine bağlantılı nesnelerle ve onlar üzerinde çalışan fonksiyonlarla çalışır.

Bu, özellikle bir dijital ikiz ya da operasyonel bir uygulama için önemlidir. Bir geminin, binanın ya da endüstriyel varlığın kimliği, ilişkileri, konumu, ölçümleri, dokümanları ve bir geçmişi vardır. Her görünümü birbiriyle ilgisiz bir sisteme bölmek, işletmede zaten var olan bağlantıları yeniden kurmak anlamına gelir.

Birleşik bir model bu bağlantıları korumayı hedefler. Ayrıca çalışma ortamına veri, sorgular ve yürütme hakkında daha fazla bilgi verir; bu bilgi gelecekteki yerleştirme ve koordinasyon kararlarını destekleyebilir.

Uygulama için tek bir model.
Nerede çalışacağı için daha fazla seçenek.

Bu bir tasarım ilkesidir; her iş yükünün şeffaf biçimde ölçekleneceğine dair bir vaat değildir. Bölümleme anahtarları, sorgu kalıpları, işlem sınırları ve gecikme, bir uygulamanın nasıl kurulması gerektiğini etkilemeye devam eder.

03 / Büyümenin dört yolu

İstekleri ve veriyi ayrı ihtiyaçlar olarak ölçekleyin.

“Ölçeklenmemiz gerekiyor” ifadesi daha fazla eşzamanlı istek, daha büyük bir veri kümesi, daha iyi erişilebilirlik ya da üçü birden anlamına gelebilir. Replikasyon ve parçalama (sharding) bu sorunun farklı kısımlarını ele alır. Aşağıdaki gösterim, Cygnus'un dağıtık tasarım yönünü anlatır; canlı bir küme ya da yayınlanmış bir kurulum özelliği değildir.

Tek düğümle başlayın

Planlanan v1 profili tek bir sunucuyla başlar. Uygulama kodu ve veri bir arada bulunur; böylece ilk kurulum kolay erişilebilir kalır. Yedekleme, kurtarma, yetkiler ve kaynak sınırları, sistemi sorumlu biçimde işletmenin parçası olmaya devam eder.

Yedeklilik ve istek kapasitesi için çoğaltın

Gelecekteki dağıtık modelde birkaç düğüm aynı kodu ve veri kümesinin tam bir kopyasını taşıyabilir. Bu, uygun isteklere hizmet verecek daha fazla nokta yaratabilir ve sistemin bazı düğüm arızalarını tolere etmesini sağlayabilir. Sonuç; yönlendirmeye, replikasyon gecikmesine, tutarlılık garantilerine ve hangi işlemlerin hangi replikalarda yürütülebileceğine bağlıdır.

Veri kapasitesi için parçalayın

Veri kümesi bir sunucuya sığmaz hale geldiğinde tam kopyalar eklemek depolama kısıtını çözmez. Parçalama, veriyi düğümlere böler. Bir iş yükü coğrafyaya, zaman aralığına ya da anahtar aralığına göre bölümlenebilir. Bu bölümleri aşan sorgular yönlendirme ve bazen dağıtık yürütme gerektirir.

Basit bir kapasite örneği: 30 TB mantıksal veri; replikalar, indeksler, operasyonel pay ya da diğer ek yükler hesaba katılmadan, her biri 4 TB olan en az sekiz sunucu gerektirir. Bu bir aritmetik hesaptır, bir Cygnus kapasite ölçümü değildir.

İkisini birleştirin

Her parçanın kendi replikaları olabilir. Parçalar toplam veri kapasitesini sağlar; replikalar yedeklilik ve isteklere hizmet verme olanakları ekler. İnsanlar bir sunucu filosuna dağıtılmış bir veritabanını hayal ettiğinde çoğu zaman bu birleşik topolojiyi kastederler.

Talebe göre büyüyün ve küçülün

Uzun vadeli yön, bu seçimleri iş yükü politikalarına göre otomatikleştirmektir: talep arttığında kapasite eklemek, yürütmeyi ihtiyaç duyduğu veriyle birlikte taşımak ve talep düştüğünde kapasiteyi serbest bırakmak. Amaç, yerleştirme değişirken uygulamanın mantıksal modelini korumaktır.

Küçülme, önce işleri boşaltmalı ve gerekli veri kopyalarını güvenle taşımalı ya da korumalıdır. Zamanlama, yeniden dengeleme, tutarlılık ve kurtarma açık kurallar ve nitelendirme gerektirir. Otomatik yatay büyüme ve küçülme, planlanan tek sunuculu v1'in dışında kalan gelecekteki küme tasarımı hedefleridir.

04 / Çalışma ortamının sorumluluğu

Koordinasyonu platforma taşıyın.

Hedeflenen Cygnus deneyimi, kurulum geliştikçe tek bir uygulama kod tabanını ve tek bir mantıksal veritabanını korur. Çalışma ortamının yönettiği dağıtım; yerleştirmeyi, yönlendirmeyi, replikasyonu ve katılımcı düğümlerin koordinasyon mekaniğini üstlenir.

Bu mekanikler ortadan kalkmaz. Ağlar gecikme ve bölünmeler getirir. Güncellemeler tutarlılık kuralları gerektirir. Parçalar arasına yayılan işlemler tanımlı bir protokole ihtiyaç duyar. Kurtarma neyin commit edildiğini bilmeli, yeniden dengeleme de veri taşınırken sahipliğini kaybetmekten kaçınmalıdır.

Fırsat, her uygulamanın kendi versiyonunu kurmasını gerektirmek yerine bu sorumlulukları açık sözleşmeler ve işletim araçlarıyla platformda bir kez uygulamaktır. Uygulama yine de iş yüküne uygun sınırlara ihtiyaç duyar.

05 / Zaman içinde veri

Bağlantılı bir modelin hafızaya ihtiyacı vardır.

Pek çok iş sorusu, kimse yüksek sesle söylemese de bir zaman boyutu içerir. Bu varlık bir olaydan önce neredeydi? O sırada onu hangi kurum kontrol ediyordu? Sistem o öneriyi yaptığında neyi biliyordu?

Cygnus tasarımı graf ilişkilerini, coğrafi veriyi, vektörleri, triple'ları, zaman serilerini ve tam metin aramayı aynı mantıksal temel içinde birbirine bağlar. Bunlar, bir konunun ne olduğuna dair ayrı tanımlar değil, o konuyu keşfetmenin yollarıdır.

Veri için geçmiş, yapay zeka için köken

Zamansal veri; bir varlığın, okumalarının ya da ilişkilerinin nasıl değiştiğini tanımlayabilir. Tarihsel bir yapay zeka yanıtı ise daha fazlasını gerektirir: Yanıtı üretmek için kullanılan kaynak dokümanlara, gömmelere, erişim yapılandırmasına, model sürümüne ve isteme de bağlıdır.

Bir veri geçmişini saklamak, her vektör indeksini kendiliğinden saklamaz ya da geçmişteki bir model yanıtını yeniden üretmez. İyi bir tasarım bu sürümleri birbirine bağlar ve kökenlerini bilinçli olarak kaydeder; böylece bir yanıt, onu destekleyen kanıta ve bağlama işaret edebilir.

Uygulamalar ve araçlar için tek bir temel

Planlanan yerel MCP ve sohbet yetenekleri, izin verilen fonksiyonları dışa açmanın ve bağlantılı bilgiyi sorgulamanın yollarını sunar. Bir araç ya da sohbet arayüzü, uygulamayla aynı model ve erişim politikası üzerinde çalışmalıdır. Böylece tarihsel bir sorgu seçilen bir zamanı sorabilir ve o yanıt için hangi kanıtın ve yapay zeka yapılandırmasının mevcut olduğunu açıklayabilir.

Birleşik bir arka uç tam da burada daha basit bir kurulum hikâyesinden fazlası haline gelir: operasyonel veri, iş geçmişi ve yapay zeka destekli çalışma için ortak bir temel sağlayabilir.

06 / Sınırları belirlemek

Mimariyi işle uyumlu tutun.

Bağımsız ekipler, ayrı güvenlik sınırları ya da farklı işletim gereksinimleri bunu haklı çıkardığında mikroservisler faydalı olmaya devam eder. Ortak bir kurulum ekibi verimli tuttuğunda modüler bir monolit faydalı olmaya devam eder. Cygnus'un yönü bir seçenek daha ekliyor: dağıtımı çalışma ortamının derinliklerinde yönetilen birleşik bir uygulama ve veri modeli.

Doğru seçim iş yüküyle başlar. Hangi istekler baskın? Güncellemeler ne kadar hızlı görünür olmalı? Hangi veriler birbirine ait? Bir ağ arızası sırasında ne olur? Hangi sorumluluklar bağımsız sahiplik gerektirir?

Hedefimiz, geliştiricilerin bu anlamlı kararlara daha fazla, araçları arasındaki bağlantıları yeniden kurmaya ise daha az zaman ayırmasını sağlamak. Tutarlı bir modelle başlayın. İş ilişkilerini bozmadan koruyun. İş yükü ve platform hazır olduğunda fiziksel kurulumu büyütün.