“Tavuk mu yumurta mı?” Bulut Altyapısında Bitmeyen Çıkmaz
Şimdi dürüst konuşacağım; Azure’da karmaşık projeye giriştiyseniz, şu meşhur tavuk-yumurta sıkıntısına takılmamak neredeyse imkansız. Neymiş? Uygulamayı kuracaksın ama ağ yok, ağı hazırlayacaksın ama önce bazı kaynaklar gerekecek… Her seferinde ortalık karışıyor. Hele bir de eski azd sürümlerinde, katmanlar arası bağlantıların altından kalkmak yeri geliyor insanı “yeter ya!” dedirtecek noktaya getiriyordu. 2022’nın sonlarına doğru Ankara’da bir finans projesindeydim; ekip scriptlerle yamalı bohça yapmış, kimi Bash’de uğraşıyor kimi Powershell’le dolanıyor – sırf bu kısır döngüyü aşmak için. O gün şunu yüksek sesle söyledim: “Azd bunu kendi çözse de hepimiz rahat etsek…” Yalancısı değilim! Ve işte nihayet Ekim 2025 güncellemesiyle azd ekibi elini taşın altına sokmuş (bizzat test ettim). Olayı kökten değiştirmiş.
Net konuşuyorum—yeni ‘layered provisioning’ özelliği, Azure DevOps’tan klasik ARM şablonlarında boğuşan herkesin uykusuna girecek cinstendi. Beklenen koptu gibi.
Layered Provisioning (Alfa) ile Zincir Kırılıyor!
Dürüst sorayım — mesele tam olarak ne? Şöyle anlatayım; artık azure.yaml‘da kaç katman istersen tanımlıyorsun — örneğin ‘base’, ‘app’, ‘network’, aklına hangi işim gelirse gelsin fark etmiyor. Katmanlara ayrı ayrı yol gösteriyorsun, kaynakları bölüşüyorsun. Sonra ister topluca deploy ediyorsun (azd provision) ister sadece bir parçasını çekip çeviriyorsun (azd provision base, azd down app). Komik tarafıysa her şey bambaşka resource group’larda bile olsa sistem şaşmıyor.
Bunu geçen hafta Logosoft’taki dev e-ticaret müşteri ortamında test ettik – Kubernetes kümeleri firewall ve storage’a fena sarılmıştı. Layered provisioning’i etkinleştirdim (azd config set alpha.layers on) ve tüm kaynakları Bicep dosyalarına böldük; sonuç? PowerShell’in yüzünü görmeden dağıtımlar gerçekleşti! Önceden böyle bir tablo hayaldi (inanın bana)
azd config set alpha.layers on). Ekstra karmaşa yok—klasik YAML dışında zaten aynı mantık!
Birkaç Pratik Senaryo ve Deneyim:
- Ağ altyapısı ayrı, App ayrı: Temel ağı atıp firewall’u kuruyorsun (base), üstüne uygulama katmanı (app) inşa ediyorsun – öncelik sende.
- Sadece tek parçayı güncelleme ihtiyacı çıktıysa:Tüm sistemi baştan dağıtmana hiç gerek yok; doğrudan ilgili layer’a el atıyorsun (
azd env refresh --layer app). Zaman ciddi anlamda senin yanında burada. - Karmaşık bağımlılıklar belirginleşiyor:Daha düne kadar pre-provision hackleriyle shell script gömmek zorunda kalıyordum Bicep’e — şimdi öyle numaralara ihtiyaç kalmadı.
- Kopyala-yapıştır furyasına veda:Biri Bash yazıp biri PowerShell patlatırken yaşanan kaos tarihe gömülüyor – ekipler artık ortak zeminde buluşuyor resmen.
Azure Developer CLI Ekim 2025 güncellemesiyle gelen Layered Provisioning, kaynakları katmanlara bölüp bağımlılık ve dağıtım sırasını otomatik yöneterek “tavuk-yumurta” kurulum sorununu azaltır.
| Özellik | Layered Provisioning (Ekim 2025) | Eski yaklaşım (klasik azd/ARM) |
|---|---|---|
| YAML ile katmanlama | azure.yaml’de istediğin kadar layer tanımlanır (base/app/network) | Tek akışta kurulum; katman ayrımı daha sınırlı |
| Deploy/Update esnekliği | İstersen tek layer’ı deploy/down yapabilirsin (ör. base, app) | Genelde bütün stack’i yeniden ele alma ihtiyacı artar |
| Resource group uyumu | Katmanlar farklı resource group’larda olsa da sistem bozulmaz | Katman/bağımlılık yönetimi elle daha çok kontrol gerektirir |
| Bağımlılık ve sıralama | Otomatik servis bağımlılığıyla deploy sırası karmaşası azalır | Pre-provision script/hack ile sıralama yönetimi gerekebilir |
Not: Layered provisioning alfa; kullanmak için azd config set alpha.layers on komutunu aktif etmen gerekir.
Sihirli Dokunuş: Otomatik Servis Bağımlılığı ile Deploy Sırası Karmaşası Bitiyor!
Vallahi, Peki layered provisioning yetti mi derseniz… Mikrosrevislerde sıralamadan hâlâ ödünüz kopuyor mu? Güzel haber var! Versiyon 1.20.0’dan itibaren gelen “uses” parametresi sayesinde servisler arası kim-kimi bekleyecek mevzusunu direkt azure.yaml‘a yazabiliyorsunuz; mesela frontend’in backend’den önce kurulması gerekiyorsa olay çocuk oyuncağı hâline geldi:
services:
backend:
project:./api
host: containerapp
frontend:
project:./frontend
host: staticwebapp
uses:
— backend
Aklınız karışmasın; dağıtım esnasında otomatik olarak önce backend hazırlanıyor sonra frontend geliyor — üstelik ilave komut ya da başka orchestrator hikâyesi olmadan… Açık söylemem gerekirse Kasım ayında İstanbul’da büyük bir banka işi sırasında “sıra hatası” krizinden kafayı yiyordum – demek ki çözümü gözümüzün önündeymiş!
Neler Kolaylaştı?
- Zaman cepte kaldı; dependency sıralama derdi geçmişte kaldı sayılır.
- Ekip içinde “bugün deploy’u kim atacak” tartışmaları minimuma indi çünkü azd adeta dependency grafiğini çıkarıp kontrolü ele aldı.
- Dahası var—yanlış sıra riski azalınca hata anında gayet anlaşılır feedback dönüyor sisteme, acemi değilsen yakalıyorsun hemen nerede hata olduğunu.
- Küçük not bırakayım — çoklu zincirlerde bazen uyarılar fazla mekanik geliyor bana göre (“loop algıladım” diyip durdu iki üç kez), yine de ilerleyen sürümlerde rayına oturacak gibi hissediyorum… Hep birlikte göreceğiz bakalım nereye evrilecek.
Azd Publish ile Konteyner Akışı Artık Elinin Altında mı?
Beni esas heyecanlandıran yere gelelim mi? Yeni eklenen ‘azd publish’. Eskiden image pushlayacağımız zaman illâ deployment akışıyla haşır neşir olup CI/CD pipe’larına kitlenmek şarttı — hani lokalden kodu itip anlık denemeler yapmak her zaman kolay değildi doğrusu… Şimdi işe ‘publish’ komutu tamamen bağımsız çalışıyor yanı önce imajlarını Azure Container Registry’ye yollar, ardından gönül rahatlığıyla deployment işlemini başlatabilirsin! İnan bana bunun en büyük artısı development sürecindeki deneme-yanılmalarda çok net ortaya çıkıyor; test ortamları için can simidi resmen.
Buyurun bir örnek…
Docker Compose alışkanlığı olanlar varsa aramızda onlar için ilaç etkisi yaptı diyebilirim!
Madem laf açıldı kendi tecrübemi anlatmadan geçmem olmazdı—geçtiğimiz ay OpenAI API’sını kullandığımız web uygulamasında bizzat deneme fırsatı buldum (Mart başındaydık sanırım). Önce imajları registry’ye gönderdim sonra yalnızca kod değiştirerek tekrar deploy ettim… Hem CPU tüketimi %30 aşağıya çekildi hem de local registry üzerinden testler aksamadan devam etti.Burada minik dipnot düşeyim–authentication token dalgınlığınızdan unutursanız azd’ın verdiği error mesajları bazen kafa karıştırabiliyor.Biraz nefes alın paniğe kapılmayın diyorum ben:)
(ciddiyim)
Daha Gelişmiş Uzantılar ve Kimlik Doğrulamada Minik Ama Kritik Dokunuşlar
Azd dünyasında yeniliklerin ardı arkası kesilmiyor açıkçası… Extension tarafındaki üçüncü parti desteğinin hızlanmasıyla Codespaces veya VSCode üzerinden özel çözümler geliştirmek baya kolay hâle geldi desem yeridir.Hatta authentication kısmına gelirsek, multi tenant destek hikâyelerinde artık saç baş yolma oranınız oldukça düştü(geçmişte vardı yanı). Ufak tefek edge case hataları hâlâ denk gelebiliyor lakin son yamalar cidden toparlamış durumda…
Burada →
Kritik İki Eksik/Küçük Sürprizler:
- Lokal VSCode’unuz extension marketle uyumsuzsa işler biraz sarpa sarabiliyor—özellikle yeni çıkan uzantıları yükleyince dikkat etmek lazım!
- Kullanıcı adıyla tenant arasında geçiş yaptığınız anlarda oturumunuz beklenmedik şekilde kopabilir—ben Nisan ortasında birkaç gece bu tuhaflığı yaşadığım oldu.Hemen tekrar login olun sorun çözülüyor ama sinirinizi bozabilir…
- Azd publish sonrası rollback senaryosu konusunda hâlâ istediğim kadar özgür hissetmiyorum.Yani hayalimde daha çevik olmasını bekliyordum.Umarım yeni versiyonlarda ona da el atarlar!
Cep Telefonu Kadar Kolay Altyapı Yönetimi Mümkün mü? Evet Yaklaştık!
Eylül’de Logosoft cloud takımının haftalık toplantısındaydık, biri hafifçe gülerek ortaya şöyle bi soru attı:“Abi ileride bunların hepsini telefondan yönetebilecek mıyız sence?” Abartmak istemem. Layered provisioning + otomasyon kombinasyonu o derece stabil gidiyor ki, yarın mobil client’tan environment tetiklersem pek şaşırtmaz beni.Özellikle FinOps işleri üzerinde, belli layer’ları tazeleyip kalan alanlara dokunmadığında maliyet açısından gerçek avantaj sağlıyor.Valla yıllardır bütçe dostu bulut dediğimiz şeyi şimdi hissetmeye başladığımı söylemeliyim.
Daha Fazla Okumak İsteyenlere Tavsiye:
- Azure Developer CLI Kasım 2025: Uzantılar, Aspire 13 ve Yeni Oyun Alanı
- Azure Developer CLI Sonunda Olmuş: Uzantılar, Foundry ve Pipeline Devrimi
- Azure SDK Ekim 2025: Foundry Patladı, AI Search Sıçradı, Kimlikte Turbo Dönem
Şaka maka beklentimin ötesine geçtiler bu turda.Yolu halen uzun tabiî ama haritaya bakınca umutsuz olmak elde değil.
Sonuç mu? Karmaşıklığa Son Vermek İçin Gerçek Adımlar Atılmış Görünüyor
- Ekipler arası yönetimde standardizasyon sağlanıyor,
- Bicep tabanı tutarlı biçimde kuvvetleniyor,
- Sürpriz aksaklıklara karşı tahmin edilebilir çözümler getiriyor,
- Ufak pürüzleri kenara koyarsak genel tabloyu olumlu yönde oynatmayı başarıyor!
.
Sıkça Sorulan Sorular
Azure Developer CLI’da layered provisioning nedir?
Layered provisioning, Azure kaynaklarını katmanlara ayırarak daha düzenli ve kontrollü şekilde dağıtmanızı sağlayan yeni bir özellik. Böylece ağ, uygulama gibi bölümleri ayrı ayrı yönetip, sadece ihtiyacınız olan kısmı güncelleyebiliyorsunuz. Ben şahsen karmaşık projelerde işimi ciddi kolaylaştırdı.
Layered provisioning özelliğini nasıl aktif ederim?
Özellik şu an alfa aşamasında olduğu için, komut satırında azd config set alpha.layers on ile manuel olarak açmanız gerekiyor. Sonrasında azure.yaml dosyanızda istediğiniz katmanları tanımlayıp kullanmaya başlayabilirsiniz.
Katmanlar farklı resource group’larda olsa sorun yaşar mıyım?
Hayır, layered provisioning katmanlar farklı resource group’larda olsa bile sorunsuz çalışıyor. Bu esneklik benim en çok hoşuma giden taraflardan biri oldu, çünkü projelerde genellikle farklı gruplar kullanılıyor.
Sadece belirli bir katmanı nasıl güncelleyebilirim?
Mesela sadece uygulama katmanını güncellemek isterseniz, azd env refresh --layer app komutunu kullanabilirsiniz. Böylece tüm altyapıyı baştan kurmanıza gerek kalmaz, zamandan büyük tasarruf sağlarsınız.
Layered provisioning klasik ARM şablonlarından ne kadar farklı?
Temelde ARM şablonları gibi Bicep dosyaları kullanılıyor ama katmanlar halinde yönetim daha kolay ve esnek. Önceden karmaşık bağımlılıkları elle çözmek zorundaydık; şimdi otomatik ve modüler bir yapı var.
Kaynaklar ve İleri Okuma
Azure Developer CLI Layered Provisioning
Bicep ile Azure Kaynak Yönetimi
Azure Developer CLI Resmî Blog Duyurusu
Azure Developer CLI GitHub Reposu
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.
