MulticloudDB SDK Nedir? Tek Java API, Üç Sağlayıcı
Aynı çözümde farklı bulut sağlayıcılarının veritabanlarını kullanmak pratikte şu demek: her biri için ayrı bir SDK öğrenmek, sorguları yeniden yazmak, hata tiplerini ayrı ayrı ele almak, her sağlayıcıda testi baştan kurmak. MulticloudDB SDK for Java bu tekrar eden işi paylaşılan bir katmana taşıyor. CRUD ve sorgu mantığını tek bir Java API’si üzerinden yazıyorsunuz, sağlayıcı seçimiyle bağlantı ayarları konfigürasyonda kalıyor. Desteklenen hedefler Azure Cosmos DB, Amazon DynamoDB ve Google Cloud Spanner.
SDK şu anda public preview aşamasında, genel kullanıma sunum (GA) için bir yol haritası da var. Aynı uygulamanın hiç değiştirilmeden iki farklı sağlayıcı üzerinde çalıştığı gösterim, Azure Cosmos DB Conf 2026’da “MultiCloudDB: Write Önce. Run Anywhere.” oturumunda yapıldı.
Taşınabilirlik vergisi: neden ortak bir SDK?
Her ekip, sorguların, hataların ve desteklenen işlemlerin veritabanları arasında nasıl farklılaştığını kendi başına çözüyor; sağlayıcılar değiştikçe bu bilgiyi güncel tutmak da yine aynı ekibin sırtında kalıyor. Her yeni sağlayıcı sorgu çevirisi, hata yönetimi, testler ve süregelen bakım maliyeti ekliyor.
Ortak bir SDK bu kararları ve testleri tek yerde topluyor, böylece yeniden kullanılabiliyorlar. Paylaşılan bir adaptörde yapılan düzeltme, o adaptörü kullanan bütün uygulamalara yarıyor.
“Kodlama ajanı zaten yazar” itirazına iki cevap
Kodlama ajanlarının dakikalar içinde yeni bir implementasyon ve testlerini taslaklayabildiği bir dönemde ortak bir soyutlamanın hala gerekli olup olmadığı meşru bir soru. Kaynak yazı bunu iki ayrı soruya bölüyor.
Uygulamayı başka bir veritabanı için yeniden yazdırmak yeterli mi?
Yazdırabilirsiniz. Zor olan kısım, yeniden yazılan uygulamanın gerçekten aynı şekilde davrandığını doğrulamak. Eksik değerler aynı biçimde mi ele alınıyor? Sayfalama sonuçları atlıyor ya da tekrarlıyor mu? Bir yazma işlemi throttle edildiğinde veya işlemin yalnızca bir kısmı başarılı olduğunda ne oluyor? Bu soruların yanıtları ilgili veritabanlarına göre değişiyor ve testlerin bu farkları yakalayabiliyor olması gerekiyor. SDK, işi paylaşılan adaptörlere ve uyumluluk (conformance) testlerine taşıyor, böylece her uygulama sıfırdan başlamak zorunda kalmıyor.
Ajan soyutlamayı da üretebilecekken bu SDK niye?
Kod üretimi ucuzladıkça test edilmiş ortak bir soyutlamanın değeri düşmüyor, artıyor. Kodlama ajanları implementasyonu hızlandırdıkça darboğaz kod yazmaktan kodun doğru davrandığını doğrulamaya kayıyor. MulticloudDB SDK bu doğrulamada bir başlangıç avantajı sağlıyor, çünkü paylaşılan sözleşmesi ve sağlayıcı implementasyonları desteklenen işlemler için birlikte test edilmiş durumda.
Bir kodlama ajanı ortak arayüzü ve arkasındaki adaptörleri kurabilir. Bunların doğru davrandığını ortaya koymak ise çok daha uzun sürüyor, her veritabanına dair ayrıntılı bilgi istiyor. Birinin paylaşılan API’nin neyi vaat ettiğini tanımlaması, her sağlayıcının bu vaatleri karşılayıp karşılamadığını kontrol etmesi, sorgu çevirisini, sayfalamayı, hata yönetimini ve hata senaryolarını test etmesi gerekiyor. Ajanlar bunların hepsinde yardımcı olabilir ama üretilen kodla üretilen testler aynı hatalı varsayımı paylaşabilir. Testlerin geçmesi, sözleşmenin doğru olduğunu ya da her adaptörün onu doğru uyguladığını kanıtlamaya yetmiyor.
Kaynak yazı bu yaklaşımı arayüz tasarımı üzerine yapılan çalışmalara da bağlıyor. SWE-agent, kod düzenleme ve test çalıştırma arayüzlerinin ajan performansını nasıl etkilediğini inceliyor; Anthropic’in basit ve birleştirilebilir desenler ile araç tasarımı üzerine rehberlerinde de net operasyonlar, işe yarar hata mesajları ve değerlendirme öne çıkıyor. Bu kaynakların hiçbiri doğrudan bu SDK’yı değerlendirmiyor, yalnızca yaklaşımı besliyor: kodlama ajanlarına belgelenmiş operasyonlar ve kendi işlerini kontrol edebilecekleri geri bildirim verin.
Sözleşme neyi kapsıyor?
- Taşınabilir CRUD ve sorgu: Create, read, update, delete için tek bir Java API’si ve her sağlayıcının yerel sorgu diline çevrilen bir sorgu DSL’i.
- Konfigürasyonla sağlayıcı değiştirme: Sağlayıcıyı ve bağlantı ayarlarını, desteklenen CRUD ve sorgu işlemlerini yeniden yazmadan belirleyebilme.
- Yetenek denetimi (capability introspection): Bir kod yolunu seçmeden önce sağlayıcının neyi desteklediğini kontrol edebilme.
- Normalleştirilmiş hatalar ve tanılama: Ortak hata kategorileri ve tanılama alanları; sağlayıcıya özgü ayrıntılar korunuyor.
- Yerel erişim:
nativeExpression()venativeClient()ile sağlayıcıya özgü özellikleri kullanabilme. Bu çağrıların kendi sağlayıcıya özel testleri gerekiyor. - Sağlayıcılar arası uyumluluk testleri: Conformance test paketleri aynı işlemleri her sağlayıcının emülatörüne karşı çalıştırıyor, ortak davranış böyle doğrulanıyor.
Paylaşılan API, sağlayıcı adaptörlerinin üzerinde konumlanıyor; yetenek kontrolleri ve yerel özelliklere erişim de bu katmanın parçası.
Başlangıç: istemciyi oluşturmak
MulticloudDbClientConfig config = MulticloudDbClientConfig.builder()
.provider(ProviderId.fromId(props.getProperty("multiclouddb.provider")))
.connection("endpoint", props.getProperty("multiclouddb.connection.endpoint"))
.connection("key", props.getProperty("multiclouddb.connection.key"))
.build();
MulticloudDbClient client = MulticloudDbClientFactory.create(config);
ResourceAddress products = new ResourceAddress("appdb", "products");
Key key = Key.of("books", "product-42");
client.upsert(products, key, productDocument);
DocumentResult loaded = client.read(products, key);Sağlayıcı seçimi kodun dışında kalıyor:
multiclouddb.provider=cosmos
multiclouddb.connection.endpoint=${DATABASE_ENDPOINT}
multiclouddb.connection.key=${DATABASE_KEY}DynamoDB veya Spanner için dynamo ya da spanner değerleri, ilgili sağlayıcı modülü ve bağlantı ayarlarıyla birlikte kullanılıyor. Veri modelleme ve desteklenen yetenekler yine sağlayıcıdan sağlayıcıya farklılık gösteriyor, güncel bağımlılıklar ve kurulum adımları için dokümantasyona ve README’ye bakmak gerekiyor.
Preview’da neyi denemeli?
Önerilen yaklaşım sade. Üzerinde çalıştığınız bir uygulamadan birkaç CRUD ve sorgu işlemi alıp her sağlayıcının emülatörüne karşı çalıştırın. Ekip neyin çalıştığını, neyin eksik olduğunu ve hangi noktalarda hala sağlayıcıya özgü koda ihtiyaç duyulduğunu duymak istiyor. Bir işlem ya da veritabanı önermek, beklenmedik davranış bildirmek veya gereksinimleri tartışmak için GitHub deposunda issue ya da feature request açılabiliyor.
SDK bugün sınırlı destekle public preview durumunda, Microsoft desteği genel kullanıma sunum için planlanıyor. Kendi soyutlamanızı yazmayı seçerseniz doğrulama, sürekli bakım ve destek sorumluluğu tamamen ekibinizde kalıyor.
Kaynaklar ve İleri Okuma
- MulticloudDB SDK: Cross-cloud portability in the coding agent era (Theo van Kraay, Azure Cosmos DB Blog)
- MulticloudDB SDK for Java — GitHub deposu
- MulticloudDB SDK dokümantasyonu
- Örnek uygulamalar deposu
- Azure Cosmos DB Conf 2026 ve “MultiCloudDB: Write Önce. Run Anywhere.” oturumu
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
- Building effective agents ve Writing tools for agents
- Azure Cosmos DB dokümantasyonu
- İlgili yazı: Azure Cosmos DB Conf 2026: Benim Gözümden Asıl Mesaj
- İlgili yazı: Azure Cosmos DB vNext Emulator: Yerelde Gerçek Gibi Test Etmek
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder