Azure SDK for Rust GA Oldu: Sahadan İlk İzlenimler

Küçük bir detay: Şöyle başlayayım: Geçen ay Logosoft’ta bir fintech müşterimizde tartışıyorduk — yeni bir background worker servisini hangı dilde yazacağız diye. Go mu,.NET mi, yoksa Rust mı? Tam o sıralar Microsoft’un Azure SDK for Rust’ı stable’a aldığı haberi düştü. Açık konuşayım, o ana kadar Rust’ı production’da kullanmaya biraz çekiniyordum. Çünkü SDK tarafı betaydı ve müşteriye “bunu beta SDK ile yapalım” demek pek de iyi durmuyordu.

Şimdi iş değişti.

Vallahi, Azure SDK for Rust resmî olarak GA öldü. Yanı azure_core, azure_identity, azure_security_keyvault_secrets, azure_storage_blob. Diğerleri artık semver garantili, stabil API’ye sahip, üretim ortamında rahatça kullanılabilir crate’ler hâline geldi. Güzel haber, ama dür bir saniye — asıl mesele sadece “GA geldi” kısmı değil; bu, Türkiye’deki kurumsal ekipler için güven, bakım yükü ve uzun vadeli mimarı kararlar tarafında da baya bir şey değiştiriyor. Bu yazıda hem ne geldiğini hem de bunun pratikte ne anlama geldiğini anlatacağım.

Neden Rust? Hem de Azure üstünde?

Şöyle ki, Bu soruyu baya duyuyorum. Geçen hafta bir bankacılık müşterimde IT direktörü, “Aşkın bey, biz.NET evindeyiz, Rust’a niye geçelim?” diye sordu; açık konuşayım, gayet yerinde bir soru bu. Cevabım kısa öldü: Her şeyi Rust’a taşımanız gerekmiyor,. Bazı iş yükleri var ki, orada Rust gerçekten fark yaratıyor.

Bunları tek tek sayayım:

• Küçük binary, düşük bellek, hızlı cold start. Container ve edge senaryolarında her megabayt, her milisaniye kıymetli oluyor. Azure Container Apps üstünde scale-to-zero kullanıyorsanız, cold start farkı doğrudan kullanıcıya dokunuyor; hani o ilk istek vardır ya, işte orada kendini belli ediyor.
• Belli bug sınıfları daha derlenirken eleniyor. Null pointer dereference, data race, use-after-free… bunların hepsi compile time’da yakalanabiliyor. Yanı sabahın üçünde alarm geldiğinde “bu race condition mı acaba?” diye kurcalayıp durmanız gerekmiyor. Rahatlatıyor mu? Biraz evet.
• Tokio üzerinde native async. Yüksek throughput’lu event işleme ve streaming gıbı senaryolarda performans daha öngörülebilir kalıyor. Şey gıbı değil; bazen uçuyor bazen sürünüyor değil yanı. (bence en önemlisi)
• Azure SDK patternleri tanıdık geliyor..NET, Java, Python ve Go SDK’larındaki yaklaşım burada da büyük ölçüde benzer. Diğer SDK’lardan geliyorsanız öğrenme eğrisi sandığınız kadar dik değil; hatta bazı yerlerde “aa bu bana tanıdık geldi” dedirtiyor. — ciddi fark yaratıyor

Şimdi dürüst olayım — Rust’ın bir maliyeti var tabii. Borrow checker ile uğraşmak, lifetime annotation yazmak, ilk başta insanı biraz yoruyor; özellikle junior bir geliştirici için bu iş birkaç gün değil, bazen aylar sürebiliyor. Ama burası önemli: “her şeyi Rust’a çevirelim” demiyorum. Lafı gevelemeden söyleyeyim, doğru iş yükü için artık önünüzde ciddi bir engel yok.

Evet. Bu konuyla ilgili Grok Code Fast 1 Emekli Oldu: Şimdi Hangi Modele Geçmeli? yazımıza da göz atmanızı tavsiye ederim.

Stable olarak neler geldi?

Şu an üretimde kullanabileceğiniz crate’ler şunlar — hepsi resmî olarak stable etiketiyle: (ben de ilk duyduğumda şaşırmıştım)

Servis	Crate	Ne işe yarıyor?
Core	azure_core	Tüm SDK’ların ortak altyapısı
Identity	azure_identity	Entra ID kimlik doğrulama
Key Vault Secrets	azure_security_keyvault_secrets	Secret yönetimi
Key Vault Keys	azure_security_keyvault_keys	Kriptografik anahtar işlemleri
Key Vault Certs	azure_security_keyvault_certificates	Sertifika yönetimi
Blob Storage	azure_storage_blob	Blob işlemleri
Queue Storage	azure_storage_queue	Kuyruk işlemleri

Listeye bakınca şu fark ediliyor: Service Bus yok, Cosmos DB yok, Event Hubs yok. Tamam, başlangıç için Storage + Key Vault + Identity yetiyor. Tam geniş bir Azure tüketicisi olmak için biraz daha bekleyeceğiz. Bu önemli bir nokta — eğer projeniz Service Bus’a sıkı sıkıya bağlıysa, REST API’leri elle çağırmak veya başka dil tercih etmek gerekecek (kendi tecrübem)

Açık konuşayım: Mevcut crate seti minimum viable bir set. Ama doğru bir set. Çünkü identity + storage + key vault, çoğu workload’un %70’ını halleden üçlü. Geri kalanı zamanla gelir.

Beta’dan beri neler değişti?

Sadece “stable etiketi yapıştırıldı” değil, işin aslı biraz daha karışık. Beta sürecinde, yanı geçen bir yılda, arkada ciddi mimarı oynama öldü; dışarıdan bakınca sakın duruyor. Içeride epey taş yerinden oynamış. Birkaçını öne çıkarayım, çünkü hepsini saysam yazı uzar da uzar.

İşte tam da bu noktada devreye giriyor.

API yüzeyi sıkılaştırıldı

Her public type, trait ve fonksiyon Azure SDK kılavuzlarına göre yeniden elden geçirildi. Artık kırıcı değişiklikler semver kurallarına uyacak; yanı Cargo.toml‘da "1.0" yazdıysanız, 1.x boyunca içiniz biraz daha rahat olacak. Bu küçük gıbı görünüyor. Kurumsal tarafta mesele tam burada büyüyor, çünkü patch güncellemesi yaptık diye servis patlamasın istiyorsunuz.

Pager ve Poller birleştirildi

Burada güzel bir sadeleşme var. Yeniden tasarlanan Pager, default olarak item bazlı yield ediyor; yanı sayfa sayfa uğraşmadan doğrudan elemanları akıtıyor, bu da kullanım tarafında baya iş görüyor. Poller işe long-running operasyonlarda sadece .await diyebileceğiniz bir yapı sundu (evet, doğru duydunuz). Eskiden manuel polling loop yazmak gerekiyordu, şimdi daha temiz, daha az gürültülü. Tahmin eder mısınız? Şey, ilk bakışta fark etmeyebilirsiniz bile.

Tek bir ManagedIdentityCredential

Bu benim en sevdiğim değişikliklerden biri öldü. Eskiden farklı hosting ortamları için ayrı ayrı credential class’ları vardı; App Service için başka, AKS için başka, VM için başka… Şimdi tek bir ManagedIdentityCredential her yerde çalışıyor. Bir de yeni DeveloperToolsCredential geldi: Yerel geliştirmede Azure CLI ya da Azure Developer CLI gıbı yüklü araçlardan birini deneyip token alıyor. İlginç, değil mi? Açık konuşayım, geliştirme sırasında insanın sınırını ciddi azaltıyor.

Şunu söyleyeyim, Evet.

Üretim seviyesinde dayanıklılık

Transient hatalarda otomatik retry geliyor, bu iyi haber; ama dür bir saniye — asıl hoş tarafı bunun sadece retry olması değil, challenge-based authentication ile sovereign cloud’lar (Azure Government, China Cloud) (yanlış duymadınız). Private cloud senaryolarının da daha sorunsuz ilerlemesi. Distributed tracing tarafında azure_core_opentelemetry ile OpenTelemetry entegrasyonu var. HTTP logging policy de default olarak secret’ları maskeliyor; compliance derdi olan ekipler için bu detay hiç fena değil.

Pluggable async runtime

Açıkçası, Neyse ki burada tokio’ya kilitlenmiş değilsiniz. Tokio default geliyor ama isterseniz set_async_runtime() ile kendi runtime’ınızı plug-in edebiliyorsunuz; çoğu kişi bunu değiştirmez zaten, fakat embedded ya da özel runtime senaryolarında bu esneklik gerçekten iş görüyor. Hani herkesin ihtiyacı yoktur ama lazım olduğunda da insan arayıp durmaz.

Kısa bir not düşeyim buraya.

Hızlı bir başlangıç

Lafı uzatmadan, küçük bir örnekle gireyim. Bir Storage Account içindeki blob’ları listeleyen birkaç satırlık kod var, hani ilk bakışta “bu kadar mı?” dedirtiyor ama işin aslı tam da burada güzelce toparlanıyor:

# 1. Bağımlılıkları ekle
cargo add azure_identity azure_storage_blob futures tokio --features tokio/full

use azure_identity::DeveloperToolsCredential;
use azure_storage_blob::BlobServiceClient;
use futures::stream::StreamExt;
use std::sync::Arc;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let credential = Arc::new(DeveloperToolsCredential::new(None)?);
let service_client = BlobServiceClient::new(
"https://<hesap-adi>.blob.core.windows.net",
credential,
None,
)?;
let container_client = service_client.blob_container_client("benim-container".into());
let mut pager = container_client.list_blobs(None)?.into_stream();
while let Some(page) = pager.next().await {
for blob in page?.segment.blob_items {
println!("Blob: {:?}", blob.name);
}
}
Ok(())
}

Güzel tarafı şu: connection string yok, account key yok, ortalıkta gereksiz gizli bilgi de dolaşmıyor. Hepsi Entra ID üzerinden yürüyor, yerel geliştirmede Azure CLI’a login olmanız yetiyor, DeveloperToolsCredential token’ı oradan çekiyor; production tarafına geçince de aynı kod managed identity ile devam ediyor. Açık konuşayım, güvenlik açısından ben bu yaklaşımı daha temiz buluyorum.

Türkiye perspektifinden değerlendirme

Açık konuşayım, Şimdi asıl yere gelelim. Türkiye’deki şirketler açısından bakınca bu iş ne anlatıyor, neyi değiştirebilir?

Birinçisi şu: Türkiye’de Rust adoption hâlâ baya düşük. Bir bankada ya da sigorta firmasında “Rust geliştirici” aradığınızda iş biraz uzuyor, hatta bazen bayağı uzuyor; çünkü.NET. Java tarafında havuz geniş, Go da — kendi adıma konuşayım — yavaş yavaş yayılıyor ama Rust hâlâ niş kalıyor. O yüzden bu SDK’nın GA olması, “hadi pek çok projeleri Rust’a taşıyalım” demek değil; daha çok seçili workload’lar için yeni bir kapı açıyor, hepsi bu.

Hangı workload’lar? Bak şimdi, benim gördüğüm yerler şunlar:

• Yüksek throughput event işleme servisleri (özellikle IoT, telemetri toplayan sistemler)
• Edge compute senaryoları — perakende mağazalarda çalışan local agent’lar gıbı
• Maliyete duyarlı container workload’ları, Container Apps’te scale-to-zero senaryoları
• Kriptografi yoğun servisler — Key Vault entegrasyonu burada özellikle iş görüyor

İkincisi de FinOps tarafı. Geçen yıl bir e-ticaret müşterimde bir.NET worker servisini Rust’a çevirme denemesi yaptık (tam üretim değil, deneme gıbı düşünün), RAM kullanımı yaklaşık %65 düştü, container boyutu da neredeyse yarıya indi. Aylık compute maliyetinde gözle görülür bir tasarruf çıktı. Tabi bu tek örnek; genellemek doğru olmaz ama trendi fena göstermiyor.

Enterprise vs startup: kim ne yapmalı?

Bu ayrım önemli, evet. Çünkü tavsiye dediğin şey tek kalıba girince çabuk bozuluyor; ölçek başka, ekip başka, baskı başka, hele teslim tarihî yaklaşıyorsa bambaşka bir dünya çıkıyor ortaya.

Eğer küçük bir startup veya 5-10 kişilik bir ekipseniz: önce durup maliyete bakın, lafı gevelemeden söyleyeyim; Rust’a tüm ürünü taşımanın size ne kadar süre, enerji ve kafa karışıklığı getireceğini hesaplayın. Geliştirme hızı sizin için kritikse.NET ya da Python tarafında kalmak çoğu zaman daha mantıklı ölür. İlginç, değil mi? Sadece performansın gerçekten can yaktığı bir mikroservis varsa, işte önü Rust’ta yazın; polyglot yaklaşım da bana sorarsanız burada baya iş görüyor.

Bir dakika — bununla bitmedi. Bu konuyla ilgili Kubernetes v1.36 CCM: Route Sync Metriği Sahaya İndi yazımıza da göz atmanızı tavsiye ederim.

İlginç olan şu ki, Eğer büyük bir kurumsal yapıdaysanız: burada iş biraz değişiyor. Bir “Rust pilot ekibi” kurmayı düşünün; 2-3 senior developer ile ufak bir POC çıkarın, sonra bakalım gerçekten nerede değer üretiyor. Eğer SRE ya da Platform Engineering ekibiniz varsa, bunlar Rust ile genelde iyi anlaşıyor — özellikle observability ajanları, sidecar’lar ve log shipper’lar gıbı sistem servislerinde. Service Bus + Azure Functions: Backoff ve Circuit Breaker yazımda bahsettiğim resilience pattern’leri Rust’ta da aynı derecede işe yarıyor; hatta tıp sistemi yüzünden bazı yerlerde daha güvenli hissettiriyor. Şey yanı, kağıt üstünde değil de pratikte farkını görüyorsunuz.

Bir de şu kısmı atlamayın: Rust’ı Azure Functions içinde kullanmak hâlâ tam anlamıyla first-class değil. Custom handler ile ilerliyorsunuz, bu — kendi adıma konuşayım — da her senaryoda rahat etmiyor açık konuşayım. E peki, sonuç ne öldü? Container Apps veya AKS işe daha doğal bir zemin sunuyor; eğer mimariyi baştan seçme şansınız varsa orası daha az uğraştırır gıbı duruyor.

Karşılaştığım bir sorun ve çözümü

Beta döneminde bir POC yaparken garip bir şeyle karşılaşmıştım: DefaultAzureCredential yerel makinede çalışıyordu,. AKS pod’unda bir anda patlıyordu. Loglara bakınca token endpoint’e ulaşamadığını gördüm; işin aslı, sorun credential tarafında değil, pod identity binding’in düzgün kurulmamış olmasıydı. Hani ne farkı var diyorsunuz, değil mi? Kısacası, yerelde çalışan kurgu cluster içinde aynı rahatlıkla yürümemişti.

1. AKS cluster’da workload identity’yi etkinleştirin (bu kritik)
2. Service account üstüne azure.workload.identity/client-id annotation’ını ekleyin
3. Pod spec’inde azure.workload.identity/use: "true" label’ını kullanın
4. Federated credential’ı Entra ID tarafında doğru tanımlayın

Bak şimdi, yeni stable sürümle birlikte ManagedIdentityCredential‘ın bu senaryoyu daha düzgün handle ettiğini ben de görüyorum. Ama küçük bir not düşeyim: bu dört adımı atlayınca olay yine dağılıyor, yanı sürüm yeni diye her şey kendiliğinden düzelmiyor. Saatlerimi yedi bu sorun. Sizin zamanınızı yemesin.

Evet. Daha fazla bilgi için Agent Framework + AGT: Üretimde Yönetişim Şart yazımıza bakabilirsiniz.

Pratik bir başlangıç rehberi

Rust’a Azure üstünde girmek isteyenler için kısa bir yol haritası var, ama lafı uzatmadan söyleyeyim: ilk adım biraz garip geliyor, sonra oturuyor.

1. İlk gün: rustup ile Rust kurun, cargo new ile basit bir proje açın. Sonra azure_identity + azure_storage_blob ekleyip Azure CLI ile login olun, yerelde blob listeleyin; işte burada “tamam, bu çalışıyor” hissi geliyor. (bence en önemlisi)
2. Birinci hafta: Key Vault’tan bir secret çekin. Bunu başka bir servise istek atarken kullanın, ama şey, async pattern’lere alışırken küçük sürprizler de çıkıyor; o yüzden akışa hemen güvenmeyin. — ciddi fark yaratıyor
3. İkinci hafta: Storage Queue ile basit bir consumer yazın. Mesajı alıp işlesin ve Blob’a yazsın; kulağa düz geliyor ama end-to-end worker pattern’i kurunca detaylar bir anda çoğalıyor. — ciddi fark yaratıyor
4. Üçüncü hafta: Dockerize edin, Container Apps’e deploy edin. Managed identity ile bağlanın, OpenTelemetry tracing ekleyin; burada artık koddan çok operasyon tarafı konuşmaya başlıyor.
5. Sonrası: Production hardening yapın — retry policy, error handling, structured logging. Evet, sıkıcı gıbı duruyor ama prod’da en çok bunlar kurtarıyor.

Böyle bakınca yol haritası sade duruyor, fakat pratikte her adım ayrı bir küçük kavga çıkarabiliyor (özellikle ilk login ve identity kısmında), yine de bu sırayla ilerlemek baya iş görüyor. Peki neden?

İşin garibi, Açık Kaynağa İlk Katkı: GitHub’da Başlangıç Rehberi yazımda anlattığım gıbı, Azure SDK for Rust deposuna issue açmak veya katkı sağlamak da güzel bir öğrenme yöntemi. Ekip cidden responsive; beta sürecinde açtığım iki issue’ya 48 saat içinde dönüş aldım, açık konuşayım ben de bu kadar hızlı beklemiyordum.

Doğrusu, Neyse uzatmayalım. Sizce en zor kısım hangisi olurdu?

Tam da öyle.

Eksik tarafları

Yazıyı sadece “harika, koşun deneyin” diye kapatmak bana biraz fazla cilalı geliyor. Eksikleri de söylemek lazım, yoksa işin aslı yarım kalıyor; hani servis güzel duruyor. Bazı yerlerde boşluk var, hele bir de bunu production gözlüğüyle bakınca insanın aklına hemen birkaç soru düşüyor.

Servis kapsamı dar. Service Bus, Event Hubs, Cosmos DB, SQL — hepsi henüz yok. Bu baya önemli bir eksik, çünkü günlük işlerde en çok elinizi uzattığınız yerler tam da buralar oluyor; yanı kağıt üstünde Rust destekleniyor gıbı dursa da, pratikte senaryoların önemli kısmı daha ortada görünmüyor.

Durun, bir saniye.

Dokümantasyon olgun değil. Reference docs var ama.NET ya da Python tarafında alıştığımız o “complete sample gallery” hissi daha gelmemiş. GitHub’da örnekler var, evet, fakat dağınık duruyor; bir yerde küçük parça kod görüyorsunuz, başka yerde başka bir repo çıkıyor. Açık konuşayım, insan bazen “şimdi bunu nereden başlatacağım?” diye takılıyor.

Ekosistem yardım almıyor. Üçüncü parti Rust crate’leri (mesela azure-sdk-for-rust community fork’u) ile resmî SDK arasında bir geçiş dönemi yaşanacak gıbı duruyor. Hangisini kullanacağınızı netleştirmek şart, çünkü aksi hâlde ekip içinde aynı işi iki farklı yoldan yapanlar çıkabiliyor; sonra da debug ederken kim neyi neden seçmiş diye uğraşıyorsunuz.

Bunu yaşayan biri olarak söyleyeyim, Kağıt üstünde fena değil. Pratikte işe göreceğiz artık.

Garip gelecek ama, Evet.

Önümüzdeki 6 ayda servis sayısı artarsa, iş değişir; o zaman Rust-first Azure development gerçekten mümkün hâle gelir, yoksa bu hikâye biraz niyet seviyesinde kalır. Siz ne dersiniz?

Sıkça Sorulan Sorular

Azure SDK for Rust production-ready mi?

Size bir şey söyleyeyim, Evet, kesinlikle. Resmî stable etiketiyle yayınlandı, semver garantisi var ve Microsoft destekliyor. Yanı Identity, Key Vault veya Storage senaryoların varsa gönül rahatlığıyla üretimde kullanabilirsin. Ama mesela Service Bus ya da Cosmos DB gıbı henüz stable olmayan servisler için hâlâ REST API çağrısı yapmak zorunda kalıyorsun — bu kısmı bilmekte fayda var.

Hangı crate’ler stable, hangileri değil?

Stable olanlar: azure_core, azure_identity, azure_security_keyvault_secrets, azure_security_keyvault_keys, azure_security_keyvault_certificates, azure_storage_blob, azure_storage_queue. Geri kalanlar — yanı Service Bus, Cosmos DB, Event Hubs falan — hâlâ beta ya da geliştirme aşamasında. Tahmin eder mısınız? Bence bu liste yakında genişler, ama şimdilik böyle (evet, doğru duydunuz)

Hmm, bunu nasıl anlatsamdı…

Azure Functions üzerinde Rust kullanabilir mıyım?

Açık konuşayım, Teknik olarak evet, custom handler üzerinden yapılabiliyor. Ama açıkçası first-class bir destek yok. Daha doğal alternatifler şunlar: Azure Container Apps, AKS ya da basit bir VM. Eğer serverless şart ve Rust kullanmak istiyorsan, tecrübeme göre Container Apps’teki scale-to-zero senaryosu çok daha pratik oluyor.

Yerel geliştirmede authentication nasıl yapılıyor?

Aslında çok kolay. Yeni gelen DeveloperToolsCredential sayesinde Azure CLI veya — kendi adıma konuşayım — Azure Developer CLI’a login olduğun sürece token’ı otomatik alıyor. Connection string ya da account key falan kullanmana gerek yok. Üstelik production’da aynı kod managed identity ile de sorunsuz çalışıyor — hani ekstra bir şey yapman gerekmiyor (bu beni çok şaşırttı)

.NET’ten Rust’a geçmek mantıklı mı?

Ne yalan söyleyeyim, Tüm projeyi taşımak için değil, bence o çok da gerekli değil. Ama belirli workload’lar için — mesela yüksek throughput event işleme, edge agent ya da memory-sensitive container’lar — ciddi avantaj sağlıyor. Önerim şu: ana stack.NET kalsın, performans kritik mikroservisler Rust olsun. Yanı polyglot yaklaşım çoğu zaman en sağlıklısı.

Kaynaklar ve İleri Okuma

Azure SDK Blog: GA Duyurusu (Orijinal Yazı)

Azure SDK for Rust — GitHub Deposu

Microsoft Learn: Rust on Azure Resmî Dokümantasyonu

Burada, size bir şey söyleyeyim, azure_core Crate Reference (docs.rs)