Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek
Size bir şey söyleyeyim, Geçen hafta bir müşteride tam da şu soruyu masaya yatırdık: “Biz büyüyoruz,. Sınırlarımızı da korumak zorundayız. Bu ikisi aynı anda olur mu?” Açık konuşayım, ilk bakışta bu iş teknik değil de yönetsel gibi dürüyor. Ama işin aslı şu ki, veri egemenliği, operasyon kontrolü. Ölçek aynı cümlede geçince, mimarı kararlar bir anda daha sert hissediliyor.
Microsoft’un Azure Local tarafında yaptığı güncelleme de tam buraya değiyor. Artık tek bir sovereign ortam içinde binlerce sunucuya kadar uzanan yapılardan söz ediyoruz. Kağıt üstünde fena değil. Pratikte işe bunu doğru tasarlamazsanız, elinizde “büyük ama hantal” bir altyapı kalabiliyor; benim takıldığım yer de tam olarak bu zaten.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Asıl mesele ölçek değil, sınırı koruyarak ölçeklenmek
Cloud dünyasında yıllarca “ne kadar hızlı büyüdüğün” konuşuldu (evet, doğru duydunuz). Şimdi tablo biraz değişti. “Nerede büyüdüğün”, “kimin denetiminde büyüdüğün” ve “hangi veriyi hangi sınırın içinde tuttuğun” daha öne çıktı. Mesela kamu kurumlarında, finans tarafında, enerji şirketlerinde ve savunma ekiplerinde bunu net görüyorum.
Azure Local’ın Sovereign Private Cloud için sunduğu yaklaşım bence doğru yöne gidiyor. Çünkü her müşteri public cloud’a koşmak istemiyor; bazıları regülasyon yüzünden koşamıyor, bazıları da operasyon riski nedeniyle frene basıyor. Bir de işin AI tarafı var: model verinin yanına gitmek istiyor. Yanı veri merkezdeyse model orada çalışsın istiyorsunuz; gecikme azalsın, veri dışarı taşmasın, audit izi yerinde kalsın… mantık burada gayet oturuyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Doğrusu, Ben 2024 sonbaharında İstanbul’da bir finans müşterisinde benzer bir tasarım tartışmasına girdim. Ekip “Edge mi yapalım, private cloud mu kuralım?” diye bakıyordu. Sorun sadece teknoloji değildi; BT ekibiyle uyum ekibinin beklentileri birbirine sürtüyordu. Sonunda hibrit ama sıkı kontrollü bir yapı seçtik. Şunu gördüm: Sovereign senaryolarda sonucu belirleyen şey ürün adı değil, işletme modeli.
Ha bu arada, Azure Local’ın connected / intermittently connected / disconnected senaryolarını desteklemesi küçük detay değil. Mesela uzak üretim tesisleri ya da bağlantısı zayıf bölgeler için baya iş görüyor (ki bu çoğu kişinin gözünden kaçıyor). İnternet gidince sistemin duvara toslaması yerine lokalde devam etmesi (ki bu çoğu kişinin gözünden kaçıyor). işte kurumsal dünyada insanlar buna para ödüyor.
Azure Local neden önemli hâle geldi?
Şunu söyleyeyim, Azure Local’ı ben çoğu zaman “bulutun taşınabilir hali” gibi anlatıyorum. Evdeki priz neyse bu da ona benziyor; arkadaki enerji kaynağı değişse bile cihazlar aynı deneyimi bekliyor. Buradaki kilit nokta cloud-consistent yönetim modeli. Aynı mantığı farklı sahalarda tekrar edebiliyorsunuz.
Beni en çok çeken taraflardan biri policy enforcement ve RBAC’in lokal ortamda tutulabilmesi öldü (ciddiyim). Birçok regüle kurumda sorun şu: merkezî politika istiyorlar ama dış bağımlılık istemiyorlar. Yanı kontrol odası içeride olsun, anahtarlar bizde kalsın diyorlar (yanlış duymadınız). Bu model özellikle disconnected ops için ciddi anlam taşıyor; çünkü bazen bağlantıdan çok kontrol önemli oluyor.
Durun, bir saniye.
2019’da Ankara’daki küçük bir üretim hattında buna benzer bir kurgu denemiştim — o zaman teknoloji bugünkü kadar olgun değildi ama ihtiyaç aynıydı: sistem lokalde çalışsın, merkezle senkron gitsin ama merkeze bağımlı kalmasın. O projede yaşadığımız en büyük problem yönetim karmaşasıydı; şimdi Microsoft’un yaklaşımı o düğümü biraz gevşetiyor gibi dürüyor.
Sovereign Private Cloud neyi çözüyor?
Kısaca söyleyeyim: veri rezidansını koruyor, operasyonu içeride tutuyor ve bulut benzeri deneyimi büyük ölçüde bırakmadan ilerletiyor. Bence güzel tarafı bu; çünkü klasik on-prem ile public cloud arasında gidip gelmek zorunda bırakmıyor sizi. Bu konuyla ilgili .NET ve PostgreSQL ile Azure’da Cache’i Ciddiye Almak yazımıza da göz atmanızı tavsiye ederim.
- Veri kontrolü: Veri ve loglar sınır dışına çıkmadan tutulabiliyor. (bence en önemlisi)
- Operasyonel süreklilik: Bağlantı zayıf olsa bile lokal çalışma devam ediyor.
- Daha net uyumluluk: Audit ve compliance süreçleri sadeleşebiliyor. (bence en önemlisi)
- Büyüme alanı: Yüzlerce sunucudan binlercesine çıkmak mümkün oluyor.
Büyük ölçek herkes için iyi mi? Değil
Neyse uzatmayalım: her müşteri binlerce node’a çıkmak zorunda değil (bizzat test ettim). Hatta çoğu kurum çıkmamalı bile. Küçük ekiplerde karmaşık sovereign kurgu bazen gereksiz yük oluşturuyor; çünkü orada öncelik hızdır, yalınlıktır ve maliyet disiplinidir. Startup zihniyetiyle yürüyen ekiplerin fazla katmanla uğraşması insanı yavaşlatıyor.
E tabi enterprise tarafta resim değişiyor. Ulusal altyapılar, bankalar, kamu platformları veya kritik üretim tesislerinde geniş fault domain’ler ve yüksek dayanıklılık şart oluyor. Orada “bir host bozuldu mu?” sorusundan çok “bu bölge giderse hizmet nasıl ayakta kalır?” sorusu var.
| Senaryo | Daha Mantıklı Yaklaşım | Neden? |
|---|---|---|
| Küçük startup | Daha sade Azure mimarisi | Düşük operasyon yükü ve hızlı teslimat |
| Büyüyen orta ölçek | Aşamalı hybrid + policy odaklı yapı | Maliyet kontrolü ile esnek büyüme dengesi |
| Kamu / banka / enerji | Sovereign boundary içinde Azure Local | Kontrol, mevzuat uyumu ve disconnected çalışma ihtiyacı |
Maliyet kısmını da dürüstçe konuşalım… Türkiye’de döviz bazlı altyapılarda fiyat algısı hemen değişiyor. Bir servis TL karşılığıyla düşünüldüğünde ilk bakışta pahalı gelebiliyor. Toplam sahip olma maliyetine baktığınızda resim farklılaşıyor: saha operasyonu azalıyor mu, denetim kolaylaşıyor mu, kesinti riski düşüyor mu? Eğer bunlara evet diyorsanız yatırım kendini savunmaya başlıyor.
AI iş yüklerini lokalde taşımak niye gündemde?
AI konusu açılınca herkes direkt model eğitimi düşünüyor ama benim sahada gördüğüm kullanım daha çok inference tarafında yoğunlaşıyor. Modeli eğitmek ayrı dert; çalıştırmak ayrı dert… özellikle hassas veriyi dışarı çıkarmadan karar vermek istiyorsanız inference’ı lokalde yapmak baya akıllıca oluyor. C++’ta Copilot’u Konuşturmak: VS Code İçin Akıllı İpuçları yazımızda bu konuya da değinmiştik.
Lafı gevelemeden söyleyeyim: sağlıkta hasta verisiyle çalışan uygulamalar, bankacılıkta dolandırıcılık tespiti ya da üretimde kalite analizi gibi işlerde gecikme ve veri sınırı çok önemli oluyor. GPU desteği olan local yapıların önemi burada ortaya çıkıyor. Model içeride kalıyor, log içeride kalıyor, yetkilendirme yine sizin elinizde oluyor (bu beni çok şaşırttı) Bu konuyla ilgili microsoft ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Benim görüşüm şu: AI’yi her yerde public cloud’a taşımak kolay görünüyor ama her zaman en doğru seçenek değil.
Hele bir de regülasyon baskısı yüksek kurumlarda lokalde inference yapmak bazen daha temiz çözüm oluyor.
Kendi deneyimlerimde nerede tökezledik?
Şunu fark ettim: Açık konuşayım, ilk kez dağıtık bir güvenlik politikası kurarken ben de hata aldım; role assignment ile policy scope çakışmıştı. Doğrulama sırasında yetki zinciri beklediğim gibi ilerlememişti. Çözümü aslında basitti: önce kapsamları daralttık, sonra audit akışını yeniden düzenledik. Ama o gün anladığım şey şuydu — kağıt üzerinde düzgün görünen governance modeli pratikte minik çatlaklardan sızabiliyor! Java OpenJDK Nisan 2026 Güncellemesi: Bellek, Güvenlik ve Sürprizler yazımızda bu konuya da değinmiştik.
Bir başka örnek de geçen mart ayında Bursa’daki bir sanayi müşterisinden geliyor. Bağlantısı kararsız olan tesiste merkezî logging’e güvenmişlerdi; bağlantı düşünce raporlama körleşti. Lokalde buffer edilen log yaklaşımıyla sorun çözüldü. İşte Azure Local’ın disconnected mantığı bu yüzden bana güçlü geliyor; çünkü gerçek hayat ideal WAN çizgilerini pek umursamıyor (buna dikkat edin)
Nereden başlamalı? Düzgün giriş yapmak için üç adım
Eğer böyle bir yapıyı değerlendirecekseniz ilk iş ürün broşürüne dalmayın. İhtiyaç haritasını çıkarın: Hangi veri içeride kalacak? Hangi servis offline çalışacak? Kaç node gerçekten gerekiyor? Bu üç sorunun cevabı netleşmeden tasarım çizmek erken olur. Bu konuyla ilgili VSIX İçin SDK-Style Proje Desteği: Build Süresi %75 Azalıyor yazımıza da göz atmanızı tavsiye ederim.
- Kritik iş yüklerini sınıflandırın: regülasyona tabi olanlarla olmayanları ayırın.
- Ağ topolojisini test edin: bağlantının kopması halinde ne olacağını simüle edin.
- Yedeklilik modelini yazın: fault domain ve bakım pencerelerini baştan planlayın.
- Maliyet senaryosu hazırlayın: başlangıç yatırımıyla operasyon maliyetini birlikte görün.
Bütçe kısıtlıysa hemen binlerce node hayali kurmayın. Daha küçük başlayıp ölçmek bazen daha akıllıca olur. Mesela önce pilot site kurarsınız… sonra compliance doğrulanır… en son genişletirsiniz. Bu yaklaşımı birkaç projede uyguladık ve dürüst olayım, en az kavga çıkan yöntem buydu!
Bence Microsoft burada doğru yere oynuyor mu?
Evet… ama eksiksiz değil. Doğru yere oynuyor çünkü sovereign cloud hikâyesi artık pazarlama süsü olmaktan çıktı; gerçek operasyon ihtiyacına dönüştü. Eksik kalan taraf işe hâlâ kullanım karmaşıklığı olabilir. Yanı teknoloji güçlendikçe önü yönetecek ekiplerin de olgunlaşması gerekiyor. Aksi hâlde elinizde kuvvetli motor olur ama direksiyon hafif boşta kalır (kimse istemez) (en azından benim deneyimim böyle)
AZ-305 sınavına hazırlanırken öğrendiğim şeylerden biri şuydu:
Mimarinin gücü yalnızca bileşen sayısıyla ölçülmez,
bağımlılıkların sade olmasıyla da ölçülür.
Azure Local gibi yapılar bunu iyi gösteriyor;
doğru yerde kullanırsanız baya iş görüyor,
yanlış yerde kullanırsanız gereksiz kompleksite üretebilir.
Ben kendi adıma bu güncellemeyi özellikle kamuya yakın sektörlerde,
savunma çevresinde,
enerji tesislerinde,
hatta bazı büyük üretim kampüslerinde oldukça anlamlı buluyorum.
Eğer bugün böyle bir yolculuğa başlayacaksanız,
ilk olarak network ayrıştırmasını yapın,
sonra identity modelini kilitleyin,
en son workload placement konusuna girin.
Bakın şimdi…
Sihir yok.
Doğru sırayla ilerlemek var!
Sıkça Sorulan Sorular
Sovereign Private Cloud ne demek?
Yanı aslında şöyle: verinin, operasyonun. Erişimin belirlenmiş bir egemenlik sınırı içinde kaldığı özel bir bulut yaklaşımı bu. Azure Local da hani bu yapının tam ortasında oturuyor. En çok da regülasyon baskısının yoğun olduğu kurumlar için gerçekten işe yarıyor.
Azure Local internet olmadan da çalışıyor mu?
Evet, çalışıyor.
Mesela disconnected senaryoda lokal politika uygulaması, RBAC ve audit akışları sorunsuz sürdürülebiliyor.
Tabiî bazı merkezî servislerle eşitleme kısıtlanabiliyor, açıkçası bu kaçınılmaz.
Bu yüzden bence tasarımı en baştan buna göre yapmak çok önemli.
Binlerce node herkes için uygun mu?
Hayır, değil.
Büyük ölçek teknik olarak mümkün olsa da her organizasyon için ekonomik ya da operasyonel açıdan mantıklı olmayabiliyor.
Tecrübeme göre küçük ekiplerde daha yalın hibrit modeller çoğu zaman gayet yeterli oluyor.
Kurumsal tarafta işe ölçek büyüdükçe faydası zaten kendiliğinden belirginleşiyor.
(buna dikkat edin)
AI iş yükleri neden lokalde tutuluyor?
Bunun birkaç sebebi var:
düşük gecikme,
veri rezidansı,
ve denetim kolaylığı.
Aslında hassas verilerle çalışan inference senaryolarında lokalde tutmak çok daha güvenli hissettiriyor, bence de öyle.
Ekiplerin bu yolu tercih etmesinin arkasında genelde bu his yatıyor.
(ki bu çoğu kişinin gözünden kaçıyor)
Kaynaklar ve İleri Okuma
Bi saniye — Azure Local resmî dokümantasyonu
Azure hibrit mimarı rehberleri
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments