Cosmos DB Built-in Connector for Logic Apps Standard GA Oldu
Bir haber düştü, Logic Apps tarafında uzun süredir beklenen bir şey nihayet resmileşti: Azure Cosmos DB’nın built-in connector’ı, Logic Apps Standard için genel kullanıma açıldı. Preview’da bir süredir vardı zaten ama GA damgası vurulunca iş değişiyor — üretime çıkarabilirsin, SLA konuşabilirsin, mimarı kararını buna göre çakabilirsin.
Şimdi bakın, ilk duyduğumda “e connector zaten vardı, ne değişti?” diye düşünenlerden olabilirsiniz. Ben de öyle düşündüm başta. Ama işin aslı şu ki, buradaki mesele “yeni bir connector” değil — connector’ın nerede çalıştığı meselesi. Ve bu, göründüğünden çok daha büyük bir fark yaratıyor.
Managed vs Built-in: Aradaki Fark Neden Bu Kadar Önemli?
Bir şey dikkatimi çekti: Logic Apps dünyasında iki tür connector var. Managed connector‘lar, Microsoft’un multi-tenant altyapısında çalışıyor. Yanı sizin workflow’unuz Cosmos DB’ye bir istek yapacağı zaman, önce dışarıya bir çağrı gidiyor, oradan da Cosmos DB’ye uzanıyor; arada network hop var, throttling var, paylaşılan kaynaklar var. Kısacası yol biraz dolanıyor.
Dürüst olmak gerekirse, Built-in connector işe farklı. Doğrudan Logic Apps runtime’ının içinde, in-process çalışıyor. Yanı sizin workflow motorunuzla connector aynı süreçte oturuyor. Aradaki köprü kalkıyor — Basit gibi dürüyor ama etkisi fena değil.
Bunun pratik yansımalarını sahada çokça görüyoruz. Bir örnek vereyim: sipariş akışında Cosmos DB’ye 3 farklı yazma işlemi yapan bir workflow düşünün; managed connector ile her adımda 80-150ms arası ek gecikme görmek gayet normaldi, built-in tarafta işe bu yük neredeyse uçup gidiyor ve toplamda 300-400ms civarı kazanım çıkabiliyor. Peki bunu neden söylüyorum? Ufak gibi dürüyor ama kullanıcı tarafında hissediliyor.
Peki hangi durumda hangisini seçmeli?
Size bir şey söyleyeyim, Kararı net bir tabloya döktüğümüzde iş biraz berraklaşıyor, ama tabiî her senaryoda aynı cevap çıkmıyor; latency düşük olsun diyorsanız built-in tarafı çekici geliyor, maliyet. Peki bunu neden söylüyorum? Plan uyumu da devreye girince seçenekler iyice ayrışıyor (özellikle production’da), yanı tabloyu ezberlemek yerine kullanım şekline bakmak daha mantıklı oluyor.
Kısa bir not düşeyim buraya.
| Kriter | Managed Connector | Built-in Connector |
|---|---|---|
| Latency | Yüksek (network hop var) | Düşük (in-process) |
| Throughput | Shared quota’ya tabi | Plan’ınıza göre ölçekleniyor |
| Change feed | Yok | Var — native trigger |
| Bulk operations | Yok / kısıtlı | Var |
| Entra ID auth | Kısmen | Tam destek |
| Fiyat | Ayrı faturalanır | Logic Apps compute’a dahil |
| Consumption planla uyum | Uyumlu | Sadece Standard |
Yanı Consumption plan’da kalmak zorundaysanız built-in’i unutun. Ama Standard’daysanız bu artık default tercih olmaya aday. Bence yanı.
Change Feed Trigger: Aslında Asıl Yıldız Bu
Bazı özellikler vardır, ilk bakışta yan detay gibi görünür; sonra bir anda oyunun ortasına oturur. İşte change feed trigger tam öyle bir şey. “When an item is created or modified” tetikleyicisi Cosmos DB’nın dahili change feed mekanizmasını kullanarak workflow’u ayağa kaldırıyor; yanı container’a doküman düştüğü anda ya da güncellendiği anda akışınız kıpırdamaya başlıyor.
Daha önce bunu yapmak için ne gerekiyordu? Ya Azure Function yazacaktınız change feed processor ile, ya da Event Grid’i araya sokacaktınız. İkisi de ayrı altyapı demek, ayrı bakım demek, ayrı fatura demek; şimdi işe doğrudan Logic Apps içinden — kod yazmadan, evet yanlış duymadınız — event-driven mimarı kurabiliyorsunuz.
true yapmayı unutursanız connector kendisi oluşturmuyor ve trigger da sessizce bekliyor; hata fırlatıp bağırmıyor bile. GA sonrası ilk kurcalayanların en çok takıldığı yer burası öldü.Nerelerde işe yarar?
- Sipariş güncellendiğinde CRM’e senkron yapılması gerekiyorsa burada baya iş görüyor.
- Kritik alan güncellemelerinde audit log’a düşmek için fena değil. (bence en önemlisi)
- Cross-region veri replikasyonu yaparken kendi mantığınızla akışı kurabilirsiniz.
düşük-kod ekiplerineciddi bir kapı açıyor diyebilirim; IT tarafındaki business analyst kadrosu integration developer beklemeden Cosmos DB’yi mimariye bağlayabiliyor. Bu bana göre orta ölçekli Türk şirketlerinde yıllardır hissedilen boşluklardan biri idi: developer kaynağı sınırlı ama entegrasyon ihtiyacı bitmiyor. Logic Apps Standard + built-in connector ikilisi tam bu yere oturabilir.
“Built-in connector’ları kullanmıyorsanız, Logic Apps Standard’a geçmenin faydasını yarı yarıya kaçırıyorsunuz. Consumption’da da aynı managed connector’ları kullanmaya devam ediyorsanız, pahalı bir Standard planına para vermenin anlamı yok.”
İşte tam da bu noktada devreye giriyor.
Ve işler burada ilginçleşiyor.
- Cross-partition sorgu maliyetini workflow tarafında görmek zor;RU tüketimi log’a doğrudan düşmüyor. (bence en önemlisi)
- MongoDB API tarafı hâlâ built-in connector kapsamında değil;sadece NoSQL API var.Mongo kullanıyorsanız managed tarafta kalmaya devam.
- Continuation token yönetimi büyük sorgu sonuçlarında biraz elle müdahale istiyor.
- Diagnostic tarafı biraz cılız;Application Insights entegrasyonu var ama connector-spesifik metrikler zayıf kalıyor.
Şöyle ki, Bir de şunu söyleyeyim:Change feed trigger’ın latest version mode‘da çalıştığını unutmayın.Yani bir doküman 5 kez güncellenirse size son hali gelir,ara güncellemeleri kaçırırsınız.Full fidelity change feed hâlâ preview aşamasında ve bu connector’da yok;audit senaryolarında bu gerçekten sınır koyuyor.
Kullanın çünkü uygun:>
- >
- Cosmos DB’ye yoğun okuma/yazma yapan integration akışlarınız varsa burada iyi oturuyor.
>
>
>
>
>
>
>
>
>
Change feed trigger latency’si ne kadar?
Genelde 1-5 saniye arası. Cosmos DB change feed pull-based çalıştığı için connector, belirli aralıklarla lease container’ı kontrol edip yeni değişiklikleri çekiyor. Yanı gerçek anlamda “sub-second” event delivery beklemeyin. Ama şunu da söyleyeyim — Event Grid ile karşılaştırdığınızda event kaybı riski çok daha az, bence bu önemli bir artı.
Managed identity ile bağlanırken hangi role’ü vermeliyim?
Data plane tarafında genellikle “Cosmos DB Built-in Data Contributor” rolü yeterli oluyor. Sadece okuma yapacaksanız “Cosmos DB Built-in Data Reader” da kullanabilirsiniz. Bir de şunu dikkat edin: control plane rolleriyle (mesela Contributor) data plane erişimini karıştırmayın — Cosmos DB’de bu iki tarafın rolleri ayrı ayrı yönetiliyor.
MongoDB API için ne zaman geliyor?
Açıkçası şu an Microsoft’tan resmî bir tarih yok. NoSQL API önceliklendirildi. MongoDB API kullanıyorsanız managed connector’la devam etmeniz ya da custom bir çözüm (mesela Function) üretmeniz gerekiyor. Community feedback’e bakılırsa yol haritasında var gibi görünüyor, ama garanti yok.
Lease container ayrı bir maliyet yaratıyor mu?
Evet, lease container da RU/s tüketiyor. Ama tipik olarak çok düşük — hani 400 RU/s manual throughput genelde yeterli oluyor. Serverless veya autoscale kullanıyorsanız bu daha da az. Tecrübeme göre bu container’ı monitored container’la aynı database’de tutmak mantıklı, operasyonel karmaşayı ciddi ölçüde azaltıyor.
Kaynaklar ve İleri Okuma
Announcing General Availability of the Azure Cosmos DB Built-in Connector for Logic Apps Standard
Azure Logic Apps Built-in Connectors — Resmî Dokümantasyon
Bunu yaşayan biri olarak söyleyeyim, Cosmos DB Change Feed Design Patterns
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.
4 comments