Azure SDK Mayıs 2026: Rust GA, AI Search ve Agent Server

⏱️ 12 dk okuma📅 24 Haziran 2026👁️ görüntülenme

Şunu söyleyeyim, Açık konuşayım: Azure SDK release notlarını her ay takip etmek pek heyecan verici bir iş değil. Çoğu zaman “şu paket.0.1 öldü, şuraya bir property eklendi” gibi şeylerle karşılaşıyoruz. Ama Mayıs 2026 sürümü… bu biraz başka. Hatta baya başka. Çünkü bu ay birkaç yapısal değişiklik var, bir tanesi de uzun zamandır beklediğim o konu: Rust SDK sonunda GA öldü.

Bu yazıda Microsoft’un Mayıs 2026 Azure SDK duyurusuna kendi gözümden bakacağım. Sertifikasyonlarım gereği bu paketleri — kendi adıma konuşayım — günlük olarak kullanıyorum, özellikle.NET ve Python tarafında, o yüzden release notunun arkasındaki “bu bizi nasıl etkiler?” sorusuna odaklanacağım. Çünkü release notu okumak ayrı, “bunu prod’a alırsam ne kırılır?” diye düşünmek ayrı bir mesele.

Önce büyük resim: Bu ayın damgasını vuran 4 başlık

Microsoft’un bu ayki release’inde dört ana konu var, hani öyle ufak tefek değil. Sırasıyla bakınca tablo netleşiyor:

Azure SDK for Rust artık stabil. 1.0.0 yayında.
Azure AI Search‘e “knowledge base” ve agentic retrieval geldi.
Azure AI Agent Server preview olarak çıktı — agent host’lamak için yeni bir model. — bunu es geçmeyin
.NET Azure Batch kütüphanesi GA. Yanında JS ve Python tarafında da düzenlemeler var.

Bak şimdi, ilk bakışta bunlar ayrı ayrı küçük haber gibi dürüyor,. Aslında aynı yere çıkıyorlar (daha düzgün entegrasyon, daha az el emeği, daha az “şunu da ben bağlayayım” hali) (yanlış duymadınız). Şimdi tek tek gidelim; klasik release note ezberi yapmayacağım, daha çok “bu iş pratikte ne değiştiriyor?” kısmına odaklanacağım (şaşırtıcı ama gerçek)

Rust SDK’in stabil sürümü: Geç kalmış ama doğru bir karar

Rust tarafında bulut SDK’leri hep biraz tuhaf ilerledi, yanı bir yerden bakınca tamam, başka bir yerden bakınca eksik kalıyordu. AWS SDK for Rust bir süredir GA, Google Cloud tarafı da toparlanmaya çalışıyor, Microsoft işe bunu uzun süre preview’da tuttu; şimdi nihayet 1.0.0 ile çıktı ve Core, Identity, Key Vault (Secrets, Keys, Certificates) ile Storage (Blobs, Queues) paketleri stabil hâle geldi.

Şimdi gelelim işin can alıcı noktasına.

İnanın, Peki neden önemli? Bak şimdi. Eğer elinizde bir edge servis varsa ya da çok yüksek throughput isteyen bir veri pipeline yazıyorsanız,.NET ya da Python’un GC’si bazen can sıkabiliyor; Go burada fena değil ama Rust’ın güvenlik tarafı ve performansı ayrı bir yerde dürüyor. Şimdiye kadar Azure’a Rust ile yazmak isteyenler ya community crate’lerine güveniyordu (ki bazıları zamanla sessizce geride kalıyor), ya da REST API’yi kendi eliyle çağırıyordu; açık konuşayım, ikisi de prod ortamı için pek iç açıcı değildi.

Rust SDK’in GA olması, Microsoft’un “polyglot enterprise” stratejisinin son halkası. Artık.NET, Java, JS, Python, Go, C++ ve Rust — yedi dilde aynı tasarım kalıplarıyla yazılmış stabil SDK’leriniz var. Bu, kurumsal mimarı açısından çok güçlü bir mesaj.

Türkiye’deki şirketler için bu ne anlama geliyor?

Sahada gördüğüm kadarıyla Türkiye’de Rust adoption hâlâ baya zayıf. Fintech ve oyun şirketlerinde küçük adacıklar var; bir de bazı kripto/blockchain ekipleri kullanıyor. Geri kalan dünya daha çok.NET veya Python’a yaslanıyor. Tahmin eder mısınız? Ama işin aslı şu: önümüzdeki 2-3 yıl içinde özellikle cost optimization baskısı artarsa Rust daha çok konuşulur hâle gelecek; çünkü aynı işi yapan bir Node.js servisini Rust’a çevirdiğinizde Azure App Service ya da Container Apps faturasında ciddi düşüş görebiliyorsunuz (bellek tüketimi çoğu senaryoda yaklaşık 1/4 seviyesine iniyor).

Bir dakika — bununla bitmedi.

Bütçesi dar olan bir ekipseniz hemen “haydi geçelim” demem ben. Öğrenme eğrisi sert, orası net. Ama eğer sürekli çalışan bir background worker’ınız varsa ve milyonlarca mesajı aynı kodla işliyorsa — işte orada denemeye değer; ROI kendini daha çabuk gösteriyor.

Evet.

Azure AI Search: Knowledge Base kavramı her şeyi değiştiriyor

İşin ilginç tarafı tam burada başlıyor..NET için Azure.Search.Documents 12.0.0 ve Python için azure-search-documents 12.0.0 ile birlikte yeni bir şey geldi: knowledge base. Yanında da KnowledgeBaseRetrievalClient diye bir sınıf var, hani ilk gördüğümde “bu neyin nesi şimdi” dedirten cinsten.

Şimdi bakın, AI Search zaten vardı (ben de ilk duyduğumda şaşırmıştım). RAG yapıyorduk, vektörler vardı, semantic ranking vardı, biraz da klasik arama refleksiyle iş dönüyordu. Peki ne değişti? Eskiden bir index’ınız olurdu, embedding basardınız, query atar top-K döndürürdünüz; fena değil ama epey el emeği istiyordu. Knowledge base işe daha üst seviye bir yaklaşım sunuyor: birden fazla knowledge source tanımlayabiliyorsunuz — Azure Blob Storage, mevcut bir search index, OneLake, hatta web. Sonra bunların hepsine tek yerden agentic retrieval yapıyorsunuz.

Yanı RAG’ın “veri kaynağı” katmanı biraz soyutlandı diyeyim. Artık her source için ayrı pipeline kurmuyorsunuz; bu güzel gibi dürüyor. Dur bir saniye — asıl kazanç standartlaşma tarafında geliyor. Tahmin eder mısınız? Bir knowledge base tanımlıyorsunuz, içine source’ları koyuyorsunuz, retrieval client tek API üzerinden hepsiyle konuşuyor (bizzat test ettim)

Kısa bir not düşeyim buraya.

Pratik tarafına gelelim

İtiraf edeyim, Bunu kurumsal müşterilerde gördüğüm hâliyle anlatayım: Türkiye’deki şirketlerin RAG mimarisinde en büyük dert genelde tek veri kaynağı olmaması (ilk duyduğumda inanamadım). SharePoint var, Confluence — itiraz edebilirsiniz tabi — var, eski bir Oracle sisteminde PDF metadata’sı dürüyor, bir de S3’te (pardon, Blob’da) raw dokümanlar var; yanı tabloyu görüyorsunuz, işler hiç steril değil. Eski yaklaşımda bunların hepsini ayrı ayrı index’liyordunuz, sonra retrieval sırasında hangisinden ne çekeceğinizi sız orkestre ediyordunuz; işte knowledge base bu dağınıklığı baya toparlıyor.

JavaScript tarafında (@azure/search-documents 13.0.0) iki hoş ekleme var: debug property’si ile artık semantic olmayan query’leri inceleyebiliyorsunuz ve vector search için oversampling opsiyonu gelmiş durumda (buna dikkat edin). Oversampling özellikle recall sorunu yaşayanlar için işe yarıyor — yanı “doğru cevap aslında corpus’ta vardı ama top-K içine düşmedi” sıkıntısını yaşayanlar için; küçük gibi duran ama bazen bütün sonucu değiştiren detay bu.

Açık konuşayım, This new knowledge base modeli aslında Deep Agents + Cosmos DB: Operasyonel Veride Plan-Eylem-Doğrulama yazımda anlattığım plan-eylem-doğrulama döngüsüyle baya iyi örtüşüyor. Retrieval katmanını soyutlayınca agent’ın planlama tarafına daha fazla odaklanabiliyorsunuz; açık konuşayım, bazen asıl fark da burada çıkıyor zaten.

Hmm, bunu nasıl anlatsamdı…

Evet.

Agent Server: Microsoft’un agent host’lama hikâyesi

Bakın, Bu ayın preview tarafında öne çıkan şey bu, açık konuşayım. Azure.AI.AgentServer.Core (1.0.0-beta.23).NET tarafı için geliyor, azure-ai-agentserver-core (2.0.0b3) işe Python tarafında dürüyor; yanında da.NET’te Invocations. Responses paketleri, Python’da bir Responses paketi var. Kısacası, işin iskeleti kurulmuş gibi ama her parça hâlâ biraz oynak. JetBrains Copilot Artık CLI Üzerinde Çalışacak: Ne Değişiyor? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili SharePoint Copilot Apps: Sohbete Gerçek Arayüz Geliyor yazımıza da göz atmanızı tavsiye ederim.

Buradaki ana fikir şu: Agent’ı kendi servisinizde host etmek istiyorsanız, ortak bir framework lazım oluyor (ilk duyduğumda inanamadım). AgentServerHost diye bir hosting modeli geliyor; built-in health probe’lar, graceful shutdown, request-ID middleware ve PlatformHeaders dediği ortak HTTP header sabit setleri var. Küçük gibi duran detaylar bunlar, ama operasyon tarafında insanın başını ağrıtan şeyler de genelde tam burada çıkıyor.

Yanı Microsoft burada şunu söylüyor: “Agent host etmek istiyorsanız her ekip kendi web server boilerplate’ını yazmasın.” Fena değil aslında. Sız business logic’e odaklanın diyorlar, geri kalan uğraşıyı biraz paketleyelim mantığı var; tabi bu yaklaşım güzel görünüyor ama entegrasyon tarafında bazı ekipler yine ufak sürprizlerle karşılaşır, ona da hazırlıklı olmak lazım.

Evet.

İşte burada bir parantez açayım. Microsoft Agent Framework: Katmanlı SDK Tasarımının İç Yüzü yazımda detaylıca konuşmuştum; Microsoft’un agent çevrei bir süredir parçalı haldeydi (ciddiyim). Agent Framework var, Semantic Kernel var, Foundry agents var, şimdi de Agent Server geldi. Bunların hepsi birbirini tamamlıyor gibi dürüyor ama dışarıdan bakınca insanın kafası hafif karışıyor, hatta “şey, bunu hangi senaryoda kullanacağım?” diye durup düşünüyorsunuz.

Preview = dikkatli ol

Bunu özellikle söylemek lazım: bu paketler hâlâ hızlı değişiyor. Son.NET beta’sında daha önce 6 ayrı setup çağrısıyla yaptığınız konfigürasyon tek bir AddAgentServerCore() / UseAgentServerCore() çiftine inmiş durumda. Az önce yazdığınız kodun yarın çalışmama ihtimali var, abartmıyorum. Preview kütüphanelerin huyu bu işte — bugün rahat ettirir, yarın küçük bir sürümle sizi tekrar dokümantasyona döndürür.

Peki neden?

💡 Bilgi:
Preview paketleri POC ve internal tooling için iyi gidiyor, ama prod yükü altında bazen tökezliyorlar. En azından bir-iki versiyon stable olmasını beklemek daha akıllıca olur. Acilse de API surface’i kendi anti-corruption layer’ınızla sarın ki SDK breaking change’leri doğrudan business kodunuza sızmasın; yoksa bir gün sabah kahvenizi içerken kırılan build’e bakıp sessizce ekranı kapatırsınız.

İşin garibi, Neyse uzatmayalım.

Batch SDK GA: Sessiz ama kritik

.NET tarafında Azure.Compute.Batch 1.0.0 GA olmuş, sessiz sedasız geldi ama etkisi az değil. Beta’dan taşınan breaking change’ler var; AuthenticationTokenSettings ve BatchAccessScope kalkmış, üstüne bir sürü property adı da değişmiş (şaşırtıcı ama gerçek). Mesela BatchJobScheduleConfiguration.DoNotRunUntil, şimdi DoNotRunBefore olmuş.

Böyle işim değişiklikleri ilk bakışta insanı hafif sinirlendiriyor, hani “bunu niye kurcaladılar şimdi?” dedirtiyor (buna dikkat edin). Ama açık konuşayım, DoNotRunBefore daha net dürüyor; Until kısmı biraz kaygan, çünkü tarih mantığında bazen “o güne kadar mı, o günden sonra mı?” diye ufak bir kafa karışıklığı yaratabiliyor. Before işe direkt tokat gibi ortada.

JS tarafında @azure/batch 13.0.0, Python’da azure-batch 15.1.0 ile benzer bir modernleşme akıyor. Tabi burada mesele sadece sürüm numarası değil; eğer Batch kullanıyorsanız (HPC işleri, render farm senaryoları, ML training queue gibi şeyler), bu upgrade’i sıradan bir version bump sanmayın. Changelog’u açın, property mapping’i tek tek kontrol edin, yoksa sonra “ama biz sadece güncellemiştik” cümlesi havada kalır. GitHub Copilot Modernization C++ İçin GA: MSVC Yükseltmesi Artık Kolay yazımızda bu konuya da değinmiştik.

Küçük ekip vs Enterprise farkı

Küçük bir ekipseniz iş kolay görünüyor; breaking change gelince oturup bir saat içinde toparlarsınız, belki biraz can sıkılır. Biter gider. Evet.

Aslında, Enterprise tarafta işe durum başka; bu iş ayrı proje oluyor, ayrı sprint oluyor, üstüne bir de QA döngüsü uzuyor (özellikle production’a dokunan batch akışlarında),. Basit görünen şey bir anda zincirleme etkiye dönüşebiliyor. Benim kafamdaki en temiz çözüm şu: Batch SDK’yi doğrudan domain koduna saçmayın, araya ince bir abstraction katmanı koyun. IBatchJobScheduler gibi bir interface ile çağrıları izole edin. Daha fazla bilgi için ChatGPT’de Sağlık Zekası: GPT-5.5 Ne Kadar Güvenli? yazımıza bakabilirsiniz.

// Anti-corruption layer örneği
public interface IBatchJobScheduler
{
Task ScheduleJobAsync(JobDefinition job, DateTimeOffset runAfter);
}
// Implementation içinde SDK detayları izole
public class AzureBatchScheduler : IBatchJobScheduler
{
public async Task ScheduleJobAsync(JobDefinition job, DateTimeOffset runAfter)
{
var config = new BatchJobScheduleConfiguration
{
DoNotRunBefore = runAfter // Eskiden DoNotRunUntil idi
};
//... SDK çağrıları
}
}

Neyse uzatmayalım, bu kalıbı kurduğunuzda sonraki sürümde yine işim değişirse sadece AzureBatchScheduler sınıfına dokunursunuz; geri kalan yerler sakın kalır. Sahada bunu atlayan ekipleri gördüm, her SDK upgrade’inde günlerce hatta haftalarca uğraşıyorlar, sonra da suçlu arıyorlar.

Çok konuştum, örnekle göstereyim.

Diğer stable çıkışlar: Sessiz ama bir o kadar değerli

Bu ayın “Initial stable releases” listesini görünce şöyle bir durup baktım, çünkü management library tarafında epey paket var. Hepsini tek tek sayıp uzatmayayım; en temizi kategorilere bölmek, iş daha net oturuyor.

Kategori	Stable olan paketler	Hedef kullanıcı
Compute	Compute Batch, Compute Limit	HPC, kapasite planlaması
Data & Analytics	Customer Insights, Informatica	CDP ve veri entegrasyon ekipleri
DevOps	Dev Spaces, DevOps Infrastructure	Platform mühendisliği
Storage	File Shares	Klasik enterprise file workload

İtiraf edeyim, Bence burada asıl dikkat çeken parça DevOps Infrastructure management library’sının GA seviyesine gelmesi. Çünkü managed runner senaryolarını kodla kurmak — kendi adıma konuşayım — isteyenler için bu kütüphane şimdiye kadar preview’da kalmıştı (ve açık konuşayım, API tarafı biraz havada duruyordu); artık stable olmasıyla birlikte iş daha rahat ilerliyor. Azure DevOps Issuer Emekliye Ayrılıyor: WIF Geçişi Şart yazımdaki migration konularını da yan yana koyarsanız, DevOps Infrastructure SDK’i WIF (Workload Identity Federation) ile otomatik runner provisioning yazarken bayağı iş görüyor.

Peki bütün bunlardan pratik çıkarımlar ne?

Lafı dolandırmadan birkaç maddeyle toparlayayım. Eğer bu release’ten bir aksiyon listesi çıkaracaksanız, işin özü bence burada; çünkü kağıt üstünde küçük görünen değişiklikler, sahada bazen baya uğraştırıyor, hele ki dependency zinciri uzunsa daha da can sıkıyor.

Rust ilgilendiriyorsa: Küçük bir POC ile başlayın. Identity + Storage yeterli. Bir Logic App veya cron job’unuzu Rust ile yeniden yazıp ölçün. Bellek tüketimini karşılaştırın. (bu kritik)
AI Search kullanıyorsanız: 12.0.0’a hemen geçmeniz şart değil ama knowledge base modelini öğrenmeye başlayın. Önümüzdeki 6 ay içinde bu standart hâle gelecek.
Agent host’luyorsanız: Agent Server’ı izleyin ama prod’a almayın henüz. Hâlâ çok değişiyor. POC için iyi.
Batch kullanıyorsanız: Upgrade planınızı yapın. Property rename’leri vakit alacak.
Management SDK’leri tarafındaysanız: Hangi servislerin GA olduğunu listenizden geçirin, hâlâ preview SDK kullandığınız bir servis için stable’a geçiş zamanı.

Aslında, Bak şimdi, ben olsam ilk sıraya Rust’u koyarım. Küçük bir iş yükünde denemek kolay, sonuç da çabuk geliyor. Ama AI Search tarafını da hafife almazdım, şey gibi düşünün: bugün acelesi yokmuş gibi dürüyor, yarın ekip standardı oluyor ve sız ortada kalıyorsunuz.

Evet, biraz öyle. Sız ne dersiniz?

Kişisel değerlendirme: Doğru yönde ama yorucu bir release

Bence Microsoft bu ay önemli adımlar attı. Rust GA kısmı, polyglot stratejisinin artık laf olmaktan çıkıp biraz ete kemiğe büründüğünü gösteriyor; AI Search tarafındaki knowledge base fikri de, hani uzun vadede RAG mimarilerini baya sadeleştirebilir, ama tabiî bunun sahada ne kadar rahat işleyeceğini zaman gösterecek.

Aslında, Ama açık konuşayım: bir kullanıcı olarak, her ay bu kadar breaking change ve işim değişikliği görmek insanı yoruyor. SDK’lerin tasarımı oturuyor, evet; fakat her oturma — en azından ben öyle düşünüyorum — sürecinde bizim kod da ufak ufak kırılıyor. DoNotRunUntil → DoNotRunBefore gibi bir değişiklik tek başına küçük dürüyor, neyse ki mesele orada bitmiyor; bir kurumda 30-40 Azure SDK paketi kullanıyorsanız. Bunların 5-6’sı her ay breaking change getiriyorsa, sırf upgrade işi için bir kişiyi tam zamanlı ayırmanız bile gerekebiliyor. Bu konu konuşulmalı, yanı geçiştirilecek şey değil.

Peki neden?

Neyse uzatmayalım. Genel kanım şu: yazı içinde anlattığım anti-corruption layer kalıbı bu tip durumlarda gerçekten hayat kurtarıyor. SDK’leri direkt çağırmak yerine araya bir katman koyuyorsunuz; basit gibi dürüyor, hatta ilk bakışta fazla klişe geliyor, ama işin aslı çoğu ekipte en az can yakan yol bu oluyor (ciddiyim)

Sıkça Sorulan Sorular

Azure SDK for Rust artık prod’da kullanılabilir mi?

Evet, 1.0.0 ile Core, Identity, Key Vault ve Storage paketleri stabil hâle geldi. Yanı Microsoft artık semantic versioning garantisi veriyor. Ama açıkçası Rust ekosisteminde her Azure servisi için SDK yok henüz — mesela Service Bus, Event Hubs, Cosmos DB gibi şeyler için ya REST’e sarılmanız ya da.NET/Go tarafına geçmeniz gerekebilir.

AI Search knowledge base ile klasik index arasındaki fark ne?

Şunu fark ettim: Klasik index hani tek bir veri kaynağına bağlı vektör + metin index’i. Kısacası, knowledge base işe birden fazla source’u (Blob, OneLake, web, mevcut index) tek bir mantıksal çatı altında toplayan üst seviye bir kavram. Retrieval işlemini bu birim üzerinden yapıyorsunuz, hangi source’tan ne çekileceğine SDK karar veriyor. Bence multi-source RAG senaryoları için gerçekten işe yarıyor bu yaklaşım.

Agent Server’ı Microsoft Agent Framework’ten ayıran ne?

Aslında ikisi farklı şeylere cevap veriyor. Agent Framework agent’ın iç davranışını modelliyor — yanı planning, tool calling, memory gibi şeyler. Agent Server işe o agent’ı bir HTTP servisi olarak host’lamak için gereken altyapıyı sağlıyor: health probe, graceful shutdown, request ID, middleware, bunlar gibi şeyler. Kısaca biri “agent ne yapıyor?”, diğeri “agent nasıl yayınlanıyor?” sorusuna cevap veriyor. İkisi birlikte kullanılıyor zaten.

Batch SDK 1.0.0’a geçiş için ne kadar süre ayırmalıyım?

Tek bir uygulamanız varsa ve abstraction katmanınız düzgünse yarım gün yeter tecrübeme göre. Ama direkt SDK çağrıları her yere dağılmışsa ve birden fazla proje söz konusuysa bir sprint planlayın. Property rename’leri compile-time’da yakalanıyor, asıl risk runtime davranışında — özellikle scheduling tarihleriyle ilgili kısımlarda. Test coverage’ınıza iyi bakın.

Yeni bir Azure projesi için hangi dildeki SDK’i seçmeliyim?

Pratik cevap şu: ekibinizin en rahat olduğu dil. Performans kritikse Go veya Rust, AI/ML ağırlıklıysa Python, enterprise hattaysa.NET, web/edge işleri için JS/TS. Microsoft yedi dilde de aynı tasarım kalıplarını kullanıyor, o yüzden öğrenme transferi oldukça kolay oluyor. Yanı aslında dil seçimi artık SDK eksikliğinden gelmiyor — bayağı ekip ve workload tipine göre şekilleniyor bu karar.

Kaynaklar ve İleri Okuma

Azure SDK Release (May 2026) — Resmî Microsoft DevBlog (evet, doğru duydunuz)

Azure SDK Blog (RSS ile takip için)

Azure SDK Releases Page (paket linkleri. Dokümantasyon)

Azure AI Search Resmî Dokümantasyonu

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102