Perşembe günü öğleden sonra, Türkiye saatiyle 19:17’ dünyanın dört yanındaki kullanıcılar Outlook’un açılmadığını fark. Birkaç saat içinde sorun Teams’e, SharePoint’e, Copilot’a en kritik olarak security device management araçlarına yayıldı. Outage ertesi sabah Asya’nın iş gününe Avrupa’nın sabahına sarktı.
yazı “cloud’dan kaçış” manifestosu değil. Amacımız, olayı somut vaka olarak kullanıp Microsoft’un sovereign cloud stratejisinin en uç noktası olan Azure Local disconnected operations modelini ayrıntılı biçimde incelemek, “ akşam ne farklı olurdu?” sorusunu dürüstçe cevaplamak en sonunda çoğu kurum için doğru cevabın neden hybrid tasarım olduğunu göstermek.
Ne oldu?Microsoft, outage’ı Exchange Online için EX1550543 numaralı incident 12 Kasım 2026 saat 16:17 UTC’ Incident kaydı, kullanıcıların birden fazla connection method mailbox’larına bağlanamayabileceğini söylüyordu. Yaklaşık iki saat sonra, 18:26 UTC’ Microsoft 365’in geri kalanı için ikinci advisory (MO1550821) açıldı. 13 Kasım sabahına gelindiğinde advisory Exchange Online dışında 18 servisi listeliyordu; consumer tarafında Outlook., OneDrive, OneNote, To Do Teams etkilenmişti.
Microsoft’un açıklamasına göre sorunun kaynağı, çok sayıda server’ın beklenmedik biçimde unavailable olması bunun ayakta kalan altyapıya aşırı load bindirmesiydi. Şirket malicious activity tespit etmediğini, outage çözüldükten sonra root cause raporu (PIR) yayımlayacağını belirtti. Kurtarma süreci kolay olmadı: restart edilen server’ların traffic almaya başladıktan sonra tekrar unresponsive hale gelebildiği bildirildi; Microsoft traffic’i throttle ederek capacity’yi kademeli geri getirmeye çalıştı süreçte deployment’ları durdurdu.
Ölçek dikkat çekiciydi. Downdetector, ABD’ Outlook için perşembe öğleden sonra kısa sürede yaklaşık 130 bin outage report kaydetti bildirimler saat içinde 74 ülke bölgeye yayıldı. Microsoft 365 connector’ları üzerinden çalışan third-party AI servisleri bile etkilendi.
Blast radius neden kadar büyüktü?outage’ı diğerlerinden ayıran şey, etkilenen servislerin çeşitliliği. Yalnızca e-posta chat değil, security management plane aynı anda sorun yaşadı. Defender for Office 365’in Safe Links özelliğinin URL’leri verify edemeyebileceği bildirildi; kullanıcıların Outlook Teams içindeki link’lere security check olmadan tıklayabileceği pencere demek. Customer Key kullanan bazı Windows 365 tenant’larında Cloud PC bağlantısı etkilendi.
Mimari açıdan bakınca tablo Modern Microsoft 365 tenant’ında identity, iletişim, içerik, security telemetry device policy aynı provider’ın aynı global altyapısında yaşıyor. normal günlerde büyük avantaj; ama ortak altyapı layer’ı sorun yaşadığında blast radius ortak oluyor.
Gözden kaçan risk
outage sırasında çalışanlar alternatif kanallara yönelir: kişisel e-posta, grupları, USB bellekle dosya taşıma. Aynı anda security telemetry link protection zayıflamışsa, outage saatleri saldırganlar için en verimli saatler haline gelebilir. Business continuity planı, security planının parçasıdır.
Azure Local’a kısa bakışAzure Local (eski adıyla Azure Stack HCI), Microsoft’un Azure yeteneklerini müşterinin kendi datacenter’ına, şubesine edge lokasyonlarına taşıyan distributed infrastructure çözümü. Müşterinin sahip olduğu, Microsoft tarafından doğrulanmış donanım üzerinde çalışır; VM’ler, Kubernetes cluster’ları seçili Azure servisleri donanımda koşar. Platform iki operating model sunar.
Connected modeDefault model budur. Management plane Azure’dadır; kaynaklar Azure Arc üzerinden Azure portalında görünür Azure Policy, Azure Monitor, Defender for Cloud gibi cloud servisleri kullanılabilir. Connected deployment’larda sistemin en az 30 ardışık günde Azure başarılı biçimde sync olması gerekir. Yani workload’lar on-premises çalışsa bile management, billing update Azure’a bağlıdır.
Disconnected modemodelde Azure control plane’inin seçili fonksiyonları, müşterinin ortamında çalışan local control plane değiştirilir. Portal, Azure Resource Manager, RBAC policy engine local virtual appliance üzerinde koşar. Microsoft’un ifadesiyle veri, operasyon kontrol kurumun sınırları içinde kalır.
Not: “disconnected” neyi kesiyor?
“Disconnected” ifadesi öncelikle management control plane’in Azure’a bağımlı olmamasını anlatır. Microsoft modeli bağlantının sınırlı, kesintili ya hiç olmadığı ortamlar için konumlandırıyor. Dolayısıyla tamamen air-gapped savunma ortamı internet erişimi olan ama management’ını cloud’a bağlamak istemeyen kurum aynı platformu kullanabilir. Workload’larınızın internete çıkıp çıkmayacağı ise sizin network tasarımınızın kararıdır.
Disconnected operations mimarisiDisconnected operations, Azure Local’a eklenen virtual appliance olarak teslim edilen add-on’dur. appliance, normalde Azure’ çalışan portal, Resource Manager servis backend’lerinin subset’ini barındırır. Sonuç: admin’ler Azure portal’a çok benzeyen arayüz aynı Azure CLI komutlarıyla çalışır, ARM template’leri subscription/resource group yapısı aynen korunur.
Desteklenen servislerMicrosoft’un güncel dokümantasyonuna göre disconnected mode’ kullanılabilen servisler aşağıdaki gibidir. Listenin Azure public cloud’un tamamı olmadığına, bilinçli olarak sınırlı subset olduğuna dikkat.
ServisDisconnected mode’ ne sağlar?Azure portalAzure public cloud’a benzeyen local portal deneyimiAzure Resource ManagerSubscription’lar, resource group’lar, ARM template’leri CLIRBACSubscription resource group seviyesinde role-based accessManaged identityDestekleyen resource type’lar için system-assigned managed identityArc-enabled serversAzure Local VM’lerinin guest OS yönetimiAzure Local VMsWindows Linux VM oluşturma yönetimiArc-enabled KubernetesVM’ler üzerindeki CNCF uyumlu Kubernetes cluster’larının yönetimiAKS on Azure LocalManaged Kubernetes cluster’larıAzure Local device managementCluster oluşturma, node ekleme çıkarmaAzure Container RegistryContainer image artifact’ler için local registryAzure Key VaultSecret key’ler için local vaultAzure PolicyYeni resource’lar oluşturulurken standartların enforce edilmesiBurada en önemli kazanım governance tutarlılığı. Cloud’ yazdığınız ARM template’leri, RBAC role definition’ları Azure Policy kuralları on-premises ortamda aynı mantıkla çalışır. “cloud’ yöntem, on-prem’ başka yöntem” ikiliğini ortadan kaldırır hybrid mimarinin operasyonel maliyetini düşürür.
Management cluster donanımLocal control plane’in kendisi workload olduğu için kendi donanımına ihtiyaç duyar. Microsoft, production ortamlarında control plane’i barındırmak üzere dedicated, 3 node’lu Azure Local management cluster şart koşuyor. cluster yalnızca control plane management bileşenlerine ayrılır, uygulama veya tenant workload’larından izole edilir. Gerekçe üç başlıkta toplanıyor: control plane’in availability’si, workload’lardan operational isolation upgrade/maintenance süreçlerinde öngörülebilirlik.
ÖzellikDatacenter configurationStandard configurationMinimum node sayısı33Node başına memory512 GB128 GBNode başına core24 physical core24 physical coreNode başına storage8 sürücü, her biri en az 2 TB (SSD/NVMe)6 sürücü, her biri en az 2 TB (SSD/NVMe)Boot disk960 GB SSD/NVMe960 GB SSD/NVMeHedef scaleBüyük datacenter, 1000+ nodeOrta ölçek, 100+ nodeTopoloji olarak Microsoft, management cluster için switchless storage network tasarımını öneriyor; control plane için quorum resiliency sağlarken network karmaşıklığını azaltıyor. Capacity planning’ net kurallar var: management cluster’ı general-purpose compute pool gibi kullanmamak, update’ler için capacity headroom bırakmak node failure/replacement senaryolarını önceden planlamak. Donanım tarafında yalnızca Premier Solutions for Azure Local kategorisindeki, kataloğunda “disconnected operations” yeteneği işaretli çözümler destekleniyor.
POC için 4 nodeHızlı deneme için Microsoft 4 node’luk donanım seti öneriyor node’ların test hedefinize göre üç farklı biçimde konumlandırılabileceğini belirtiyor:
Pratik tavsiye
Microsoft, POC için bile production’ kullanılabilecek donanımla başlamayı öneriyor. Farklı donanım tercih edilirse control plane node’ları için minimum olarak 256 GB memory, 24 core, 4 TB dedicated SSD/NVMe storage 960 GB boot disk belirtiliyor. POC’yi atılacak deneme olarak değil, production’ın ilk adımı olarak planlamak bütçe açısından daha akıllıca.
Identity: Entra ID olmadan12 Kasım outage’ının dersi açısından belki en kritik bölüm. Cloud tabanlı Microsoft 365’te identity’nin merkezi Microsoft Entra ID’dir. Disconnected mode’ ise Entra ID yoktur; control plane kurumun mevcut identity altyapısıyla entegre. Desteklenen doğrulanmış çözümler şunlar:
- Active Directory: group group membership’ler. Yalnızca Universal scope’lu group’lar destekleniyor.
- Active Directory Federation Services (AD FS): authentication.
Mekanizma şöyle işliyor: OpenID Connect (OIDC) endpoint’i kullanıcıların sign-in yapmasını sağlarken, LDAP endpoint’i kurumdaki group membership’leri control plane’e sync. Entegrasyon tamamlandıktan sonra bildiğimiz Azure RBAC role’leri istenen scope’lara atanır.
Operator modeliDeployment sırasında root operator belirlenir. kullanıcı, özel operator subscription’ın owner’ıdır deployment sonrasında operator’leri ekler. Operator’ler subscription scope’unda yeni subscription oluşturma, service principal (SPN) yönetimi, sync edilen group’ları görüntüleme, log collection syslog forwarding gibi işlemleri yapabilir. Önemli ayrıntı: role assignment’lar policy’ler operator subscription’dan subscription’lara inherit edilmez; her subscription kendi scope’una sahiptir.
Bilinmesi gereken sınırlamalar- Sync’ten sonra AD’den silinen user group’lar control plane’ otomatik temizlenmez; durum group membership sorgularında hatalara yol açabilir.
- Force sync seçeneği yok; ilk sync altı saate kadar sürebilir.
- Management group’lar subscription’ların üstünde root level bulunmuyor.
- Support kapsamında validate edilen identity provider’lar yalnızca Active Directory AD.
Cloud outage’larında kullanıcılar çoğu zaman uygulamaya değil, authentication’a takılır. Disconnected mode’ identity zinciri tamamen kurum içindedir: AD AD FS ayaktaysa sign-in yapılır. Elbette identity altyapınızın kendisinin high availability tasarlanmasını zorunlu kılar; birden fazla domain controller AD FS farm burada opsiyonel değildir.
Network, DNS PKICloud’ görünmez olan pek çok infrastructure servisi, disconnected mode’ sizin sorumluluğunuza geçer. Microsoft’un planlama adımları bunu açıkça yansıtıyor: network requirement’ların yapılandırılması, identity entegrasyonu, security control’leri, PKI endpoint’lerin güvenceye alınması management cluster donanımının planlanması deployment’tan önce tamamlanması gereken başlıklar.
Pratikte anlama geliyor. Local portal, ARM identity endpoint’leri kurumunuzun kendi Certificate Authority’sinden imzalanmış sertifikalarla publish edilir; LDAP OIDC endpoint’lerinin certificate chain bilgileri deployment parametreleri arasında yer. LDAP endpoint’i için FQDN kullanılacaksa, disconnected operations appliance’ının adı resolve edebilecek DNS’e yönlendirilmesi gerekir. Identity entegrasyonu için AD üzerinde read-only LDAP hesabı sync’in başlayacağı root group önceden hazırlanmalıdır.
Deployment öncesi toplanması gereken parametrelerin tipik örneği şöyle görünüyor:
$idpConfig = @{ authority = 'https://adfs.kurum.local/adfs' clientId = '<AD FS client app ID>' rootOperatorUserPrincipalName = '[email protected]' ldapServer = 'ldap.kurum.local' LdapCredential = $ldapReadOnlyCredential syncGroupIdentifier = '<root AD group ObjectGUID>' }Fully automated deployment’lar için automation certificate tanımlanabiliyor; sayede operator olarak login olup subscription oluşturma, resource provider register etme gibi işlemler script’lerle yürütülebiliyor. Infrastructure as Code çalışan ekipler için önemli kolaylık.
Update lifecycle yönetimiCloud’ update’ler sizin yerinize yapılır; disconnected mode’ ise lifecycle management tamamen operasyon ekibinize aittir. Microsoft burada aylık update package sunuyor. paket appliance’ın kendisini, Azure Local yazılımını, AKS’i Arc-enabled servis agent’larını kapsıyor tüm Azure Local instance’ının internet bağlantısı olmadan local control plane üzerinden update edilmesine imkan veriyor.
modelin doğal sonucu var: update döngüleri public cloud’un gerisinde kalır. Cloud’ security fix Microsoft tarafından saatler içinde rollout edilebilirken, disconnected ortamda fix sizin maintenance window’unuza kadar bekler. nedenle disiplinli patch takvimi, test ortamı RACI matrisi.
Observability tarafında ise ürün, troubleshooting için on-demand fallback log collection mekanizmaları sunuyor; operator’ler syslog forwarding’i yapılandırarak log’ları kurumun kendi SIEM’ine aktarabiliyor. Appliance Azure’a geçici olarak bağlanabildiğinde log’ların doğrudan Microsoft Support’a gönderilmesi mümkün.
Microsoft 365 Local, SQL Server Foundry Local Microsoft 365 LocalOutage tartışmasının merkezindeki workload. Microsoft 365 Local, Exchange Server, SharePoint Server Skype for Business Server’ı Azure Local üzerinde çalıştırmak için deployment framework; Azure Local Premier Solutions üzerine kurulu validated reference architecture’a dayanıyor. Microsoft 365 Local Kasım 2025’te connected mode’ GA olmuş, fully disconnected desteği ise 2026’ geldi. Licensing açısından Exchange Server SharePoint Server’ın Subscription Edition (SE) sürümleri kullanılıyor. Uzun vadeli planlama için önemli taahhüt var: server workload’larının en az 2035’e kadar desteklenmesi.
Security tarafında platform, network’leri izole etmek için SDN yönetilen Network Security Group’lardan yararlanıyor hem host’lara hem workload VM’lerine 300’ü aşkın ayardan oluşan security baseline default olarak uygulanıyor.
Dürüst olmak gerekirse, Microsoft 365 Local, Microsoft 365 cloud’un on-premises kopyası değildir. Teams yerine Skype for Business Server, Exchange Online’ın cloud özellikleri yerine Exchange Server SE, SharePoint Online yerine SharePoint Server SE çalışır. Copilot, Loop, cloud tabanlı Defender Intune pakette yoktur. User experience bilinçli olarak daha klasik daha sınırlıdır.
SQL Server on Azure LocalMicrosoft, 28 Eylül 2026’ SQL Server on Azure Local’ın connected disconnected operations için GA olduğunu duyurdu. SQL Server, Azure Local üzerindeki Windows Server veya Linux VM’lerinde çalışıyor Azure Local’dan ayrı lisanslanıyor. Microsoft’un resiliency guidance’ı, host protection’ın database-native high availability disaster recovery mekanizmalarıyla birleştirilmesini, düzenli backup restore testlerini öneriyor.
Foundry LocalCopilot’un olmadığı ortamda AI ihtiyacı nasıl karşılanacak? Microsoft’un cevabı Foundry Local. Uygun müşteriler multimodal LLM’leri kendi on-premises, private cloud ortamlarında çalıştırabiliyor; inference API’ler tamamen müşterinin kontrolündeki boundary içinde kalıyor. Ancak Foundry Local on Azure Local için bazı kaynaklar hala preview durumda.
Eligibility onboarding süreciDisconnected operations herkesin tıkla açabileceği özellik değil. Microsoft net eligibility criteria uyguluyor:
CriteriaAçıklamaEligible agreementMicrosoft uygun agreement gerekir; Microsoft Online Subscription Program (MOSA) uygun değildir.Support planMicrosoft Standard veya üzeri aktif support plan ya aktif support plan’ı olan partner.Business needConnectivity sorunları veya regülasyon kısıtları nedeniyle Azure’a bağlanamama; geçerli disconnected çalışma ihtiyacı.Operational & technical prerequisitesDeployment operasyonu yapabilecek personel ya bunu sizin adınıza yapacak partner; workload uygulama requirement’larının belirlenmiş olması.HardwarePremier Solutions for Azure Local; kendi donanımınız dedicated management cluster. Senaryo: iki dünyada 12 Kasım akşamıŞimdi düşünce deneyimine geçelim. Elimizde 3.000 çalışanlı, Türkiye’ faaliyet gösteren kurum var; hastane grubu, enerji şirketi ya kamu kurumu olabilir.
Birinci dünyada kurum tamamen Microsoft 365 cloud’u kullanıyor. İkinci dünyada ise kritik iletişim içerik workload’ları Azure Local disconnected üzerinde Microsoft 365 Local çalışıyor.
Dünya A: Cloud-only saat 19:17’den itibaren ekip vardiya devrini e-postayla yapamıyor outlook bağlanamıyor, mobile app yanıt vermiyor. Kriz toplantısı Teams’te açılamıyor yöneticiler kişisel grubuna geçiyor prosedür dokümanları SharePoint’te kilitli Local cache’i olmayanlar erişemiyor SOC ekibi Defender XDR’ blind spot’ta safe links verification zayıflamış durumda IT ekibi yalnızca bekleyebiliyor müdahale imkanı yok, Microsoft’un status update’ini izliyor.
Dünya B: Azure Local disconnected aynı saat, aynı global incidentKurum içi e-posta akmaya devam ediyor Exchange Server SE on-prem, identity AD/AD FS üzerindeIM voice çalışıyor. Skype for Business Server; Teams kadar zengin değil dokümanlar SharePoint Server SE’ erişilebilir data kurum boundary’si içinde management plane bağımsız local portal, policy key vault etkilenmez ama: copilot yok, cloud security araçları yok local security monitoring SIEM sizin sorumluluğunuzda
Aynı global incident, iki farklı mimari. Dünya B’nin kazancı business continuity; bedeli ise daha sınırlı feature set tamamen kurum içine geçen operasyon.
Tablonun en sağdaki sütunu sadece yeşil değil; bilinçli. Dünya B’ 12 Kasım akşamı sakin geçerdi. Ama aynı kurumun başka akşamı, örneğin kendi datacenter’ında storage controller’ın arızalandığı gece, Dünya A’ hiç fark edilmezken Dünya B’ kriz olabilirdi. Disconnected, riski ortadan kaldırmaz; riskin sahibini türünü değiştirir.
Disconnected’ın bedeli Sorumluluk yer değiştirirCloud’ Microsoft’un server’ları çöktü; on-prem’ kendi server’larınız, storage’ınız, enerji soğutma altyapınız çökebilir. Patch management, backup, disaster recovery capacity planning ekibinizin işidir. analizde vurgulandığı gibi, bağlantısız site için asıl test, yöneticilerin sistemi yalnızca ortamın içindeki kaynaklarla işletip kurtarabilmesidir.
Disaster recovery’yi yeniden düşünmek gerekirConnected mode’ Azure Site Recovery gibi cloud tabanlı recovery seçenekleri vardır. Fully disconnected ortamda ise recovery, uygulamaların kendi native mekanizmalarıyla secondary site tasarlanmalıdır: Exchange için Database Availability Group (DAG), SQL Server için Always On Availability Groups, SharePoint için farm seviyesinde redundancy düzenli restore testleri. Tek datacenter’daki disconnected kurulum, cloud outage’ına karşı korur ama kendi tesisinizdeki felakete karşı korumaz.
Maliyet donanımYalnızca control plane için üç ayrı physical node, üstüne workload cluster’ları, secondary site Premier Solutions donanım kategorisi. Ek olarak SQL Server gibi workload’lar ayrıca lisanslanır. subscription tabanlı cloud modelinden belirgin biçimde farklı profil çizer.
İnsan kaynağıAzure Local, AD/AD FS, PKI, Exchange, SharePoint, Kubernetes security monitoring konularında derinlik gerektiren ekip ya güvenilir partner. Microsoft’un eligibility criteria’sında yetkinliği açıkça araması tesadüf değil.
Feature hız farkıDisconnected ortam bilinçli olarak public cloud’un gerisinden gelir. Yeni feature’lar, AI entegrasyonları security iyileştirmeleri cloud’a önce gelir; on-prem ortama ya geç gelir ya hiç gelmez.
Asıl ders: hybrid tasarımoutage’dan çıkarılacak en sağlıklı sonuç, herkesin bağlantısız ortama geçmesi gerektiği değil. Asıl ders: workload’ları criticality seviyesine göre sınıflandırmak single point of failure’a bağımlılığı bilinçli olarak yönetmek. Azure Local’ın değeri tam burada: aynı platform, aynı ARM/RBAC/Policy dili workload bazında connected ya disconnected kararı verebilmek.
Tier 2 için bile yapılabileceklerTamamen cloud’ kalan kurumlar için 12 Kasım’ın öğrettiği somut adımlar. Microsoft 365’e bağımlı olmayan emergency communication kanalı (örneğin farklı provider’ host edilen notification sistemi veya yöneticiler için ayrı messaging çözümü), kritik prosedür dokümanlarının offline erişilebilir kopyaları, outage senaryosunu içeren BCP tatbikatı outage sırasında security ekibinin hangi alternatif telemetry kaynaklarına bakacağının önceden belirlenmesi bunların başında geliyor.
Türkiye perspektifiTürkiye’ faaliyet gösteren kurumlar için tartışmanın düzenleyici boyutu. Kişisel verilerin korunması mevzuatı yurt dışına veri aktarımına özel şartlar getiriyor; kamu kurumları Bilgi İletişim Güvenliği Rehberi kapsamında kritik verilerin yurt içinde tutulmasına yönelik beklentilerle çalışıyor; bankacılık gibi sektörlerde birincil ikincil bilgi sistemlerinin konumuna ilişkin özel düzenlemeler bulunuyor. kurumlar için Azure Local disconnected, “sovereignty modern management ?” ikileminde ikisini birlikte sunan nadir seçeneklerden. Kendi yükümlülüklerinizi değerlendirirken hukuk uyum ekiplerinizden görüş almayı unutmayın.
sonraki outage’a hazırlık checklist’i- Dependency envanteri çıkarın. Hangi iş süreci hangi cloud servisine, hangi identity provider’a hangi security aracına bağlı? 12 Kasım’ etkilenen her servisi kendi süreçlerinizle eşleştirin.
- Workload’ları tier’lara ayırın. Tier 0 var ? Varsa, workload’lar için RTO RPO değerleri tanımlı ?
- Emergency communication kanalı kurun. Ana platformunuzdan bağımsız, düzenli test edilen kanal.
- Break-glass hesaplarını gözden geçirin. Cloud identity servisi erişilemezken kritik sistemlere nasıl girileceği belgelenmiş ?
- Security visibility için yedek planlayın. Defender XDR erişilemezken hangi telemetry kaynaklarına bakılacak?
- Tier 0 için Azure Local seçeneklerini değerlendirin. Eligibility criteria’yı, hardware requirement’ları ekip yetkinliğini account team’iniz partner’ınızla birlikte inceleyin; POC’yi production’a dönüşebilecek donanımla planlayın.
- Identity altyapınızı güçlendirin. Disconnected gelecek düşünüyorsanız AD AD FS’in high availability’si, Universal group yapısı PKI olgunluğu bugünden ele alınmalı.
- Tatbikat yapın. öğleden sonra boyunca Microsoft 365 outage’ını simüle etmeyi deneyin. Kağıt üzerindeki planla gerçek davranış arasındaki fark genellikle şaşırtıcıdır.
12–13 Kasım outage’ı cloud’un kötü olduğunu göstermedi. Gösterdiği şey, dependency’nin görünmez hale geldiğiydi. Pek çok kurum e-postasının, dosyalarının, security console’unun device management’ının aynı anda aynı altyapıya bağlı olduğunu ancak hepsi birden durduğunda fark.
Azure Local disconnected operations, dependency’yi kırmak isteyen kurumlar için artık gerçek, dokümante edilmiş desteklenen seçenek: local control plane, tanıdık Azure management deneyimi, on-prem identity, aylık offline update’ler üzerinde Microsoft 365 Local, SQL Server local. Ama bedeli gerçek: dedicated donanım, derin yetkinlik gerektiren operasyon, daha sınırlı feature set tamamen size geçen sorumluluk.
Doğru cevap çoğu kurum için “her şeyi on-prem’e çekmek” değil; hangi workload’un nerede çalışacağına bilinçli karar vermek, kritik süreçler için bağımsız çalışma alanı tasarlamak bunu düzenli olarak test etmek. sonraki outage geldiğinde sorulması gereken soru “Microsoft ne zaman düzeltecek?” değil, “Biz süre zarfında nasıl çalışmaya devam ediyoruz?” olmalı.
Hybrid mimari uzlaşma değil, tasarım kararıdır: Cloud’un hızını, on-prem’in bağımsızlığıyla aynı governance dili altında birleştirmek.
konuyla ilgili forum tartışmaları- Kullanıcı değişikliği sonrası Azure Devops lisansı ne olur?
- Multi App Kiosk Autologin Sorunu
- Virus Scan Failed
- Intune Win32 uygulaması AzCopy yükleniyor ama 'Committing' aşamasında takılıyor
- Microsoft Azure Ortamında Radius Nasıl Kurulur?
- Lokal DC/AD'yi Microsoft Entrada platformuna taşıma
