Azure Local projelerinde ilk birkaç sanal makineyi Azure portal üzerinden oluşturmak son derece doğal. VM adını veriyoruz, image seçiyoruz, CPU ve memory değerlerini belirliyoruz, logical network’ü bağlıyoruz ve oluşturuyoruz.
Ancak ortam büyümeye başladığında aynı yöntem çok hızlı şekilde operasyonel probleme dönüşebiliyor.
On Azure Local cluster’ınız olduğunu düşünün. Her lokasyonda aynı standartlara sahip 20 VM oluşturulacak. VM isimleri, network bağlantıları, image’lar, CPU-memory değerleri ve tag’ler aynı standarda göre hazırlanacak.
Bunu portal üzerinden 200 kez yapmak teknik olarak mümkün.
Ama bence burada artık sorun VM oluşturmak değil, aynı altyapıyı 200 kez aynı şekilde oluşturabilmek.
Azure Local’ın klasik Hyper-V yaklaşımından ayrıldığı önemli noktalardan biri de burada ortaya çıkıyor. Azure Local üzerindeki modern VM kaynakları Azure Resource Manager resource modelinin bir parçası. Microsoft’un güncel resource provider dokümantasyonunda Azure Local VM’leri Microsoft.AzureStackHCI/virtualMachineInstances, logical network’ler ise Microsoft.AzureStackHCI/logicalNetworks kaynakları olarak tanımlanıyor. Aynı kaynaklar ARM template, Bicep ve Terraform AzAPI üzerinden yönetilebiliyor.
Yani portal, CLI, Bicep veya Terraform birbirinden tamamen farklı dört yönetim modeli değil.
Çoğu durumda aynı resource modeline ulaşmanın farklı yolları.
Bence Azure Local otomasyonunu anlamaya da buradan başlamak gerekiyor.
Portal aslında son nokta değil, başlangıç noktası
Azure portal’ın en büyük avantajı görünürlük.
İlk kez bir Azure Local VM oluşturuyorsanız hangi parametrelerin gerektiğini, hangi image’ların bulunduğunu, hangi logical network’ün seçilebildiğini ve resource’ın Azure tarafında nasıl göründüğünü anlamanın en kolay yolu portal.
Ancak portal ile yapılan işlem manuel.
Bir administrator bugün:
VM Name: SQL01
CPU: 8
Memory: 32 GB
Network: PROD-LNET
oluşturabilir.
Başka bir administrator yarın:
VM Name: SQL02
CPU: 8
Memory: 64 GB
Network: PROD-LNET
oluşturabilir.
Belki ikinci VM gerçekten 64 GB olmalıydı.
Belki de yanlışlıkla 64 GB verildi.
Portal size bu iki ihtimal arasındaki farkı söylemez.
Infrastructure as Code yaklaşımında ise istediğimiz durum kod içerisinde tanımlıdır.
Örneğin bütün SQL VM’lerinin başlangıç konfigürasyonu:
8 vCPU
32 GB RAM
PROD-LNET
SQL-IMAGE-2026
olarak tanımlanmışsa değişiklik artık kişinin hafızasına değil kodun kendisine bağlı hale geliyor.
Asıl kazanım da bence burada.
Otomasyon sadece işi hızlandırmak değildir.
Konfigürasyonu tekrar üretilebilir hale getirmektir.
Azure Local VM artık Azure resource modelinin içinde
Klasik Hyper-V ortamında VM oluşturduğumuzda VM’nin yaşam döngüsü büyük ölçüde lokal Hyper-V ve Failover Cluster yönetim katmanında kalıyordu.
Azure Local’da Arc-enabled VM management ile model değişiyor.
Azure Local VM, Azure Resource Manager tarafından yönetilebilen bir Azure resource haline geliyor. Microsoft’un resource reference dokümantasyonunda VM instance için CPU, memory, storage, network interface, image, GPU assignment ve extended location gibi özelliklerin resource tanımının parçası olduğunu görebiliyoruz.
Basitleştirirsek akış şöyle:
Portal / CLI / Bicep / Terraform
|
v
Azure Resource Manager
|
v
Microsoft.AzureStackHCI
|
v
Azure Local
|
v
VM / LNET
Buradaki kritik nokta şu:
VM fiziksel olarak sizin veri merkezinizde çalışıyor.
Ama onu tanımlayan resource Azure management modelinin bir parçası.
Bu sayede aynı Azure RBAC, resource group, subscription ve Infrastructure as Code yaklaşımını lokal VM’lere de uygulayabiliyoruz.
Önceki yazılarda Azure Local’ın sadece yeni isim verilmiş bir Hyper-V cluster olmadığını birkaç kez söylemiştim. Automation tarafı bunun en net örneklerinden biri.
Azure CLI nerede devreye giriyor?
Portalda yaptığımız işlemleri script haline getirmek istediğimizde en kolay geçiş noktalarından biri Azure CLI.
Azure Local VM yönetimi için Microsoft stack-hci-vm Azure CLI extension’ını kullanıyor. Güncel CLI referansında VM ve ilişkili vNIC işlemleri dahil Azure Local VM kaynaklarının komut satırından yönetilebildiğini görüyoruz. Örneğin mevcut vNIC’leri bir VM’ye eklemek veya çıkarmak için az stack-hci-vm nic komutları kullanılabiliyor.
Burada CLI’nin bana göre en önemli avantajı öğrenme eğrisinin düşük olması.
Portalda yaptığınız işlemi script’e dönüştürmek istiyorsanız doğrudan CLI ile başlayabilirsiniz.
Örneğin genel mantık:
az login az account set \ --subscription "<subscription-id>" # Azure Local VM, image, network ve diğer # kaynaklar burada CLI komutlarıyla yönetilebilir.
CLI’nin güzel tarafı CI/CD pipeline içerisine de kolayca girebilmesi.
Ama burada önemli bir ayrım var.
Script yazmak ile Infrastructure as Code aynı şey değil.
100 satırlık Bash script’i de otomasyondur.
Fakat script çoğunlukla:
Şimdi şu işlemleri sırayla yap.
der.
Declarative Infrastructure as Code ise:
Altyapının olması gereken hali budur.
der.
Bu ikisi arasında operasyon açısından ciddi fark var.
ARM aslında bütün yapının temelinde
Azure Resource Manager yani ARM, Azure’ın deployment ve management katmanı.
Portalda bir resource oluşturduğunuzda da arka tarafta ARM ile konuşuyorsunuz. Bicep yazdığınızda da sonuçta ARM resource modelini kullanıyorsunuz.
Azure Local instance deployment’ının kendisi bile ARM template üzerinden gerçekleştirilebiliyor. Microsoft’un Azure Local deployment dokümantasyonunda template içerisinde deployment mode, Key Vault, diagnostic storage account ve diğer deployment parametreleri tanımlanabiliyor. Hatta deployment mode Validate veya Deploy olarak belirlenebiliyor.
Bu bence önemli.
Infrastructure as Code sadece workload VM oluşturmak için kullanılmıyor.
Azure Local platform deployment’ının kendisi de otomasyon modelinin içine alınabiliyor.
ARM template JSON tabanlı.
Örneğin bir Azure Local VM resource’u kavramsal olarak şu yapıda tanımlanıyor:
{
"type": "Microsoft.AzureStackHCI/virtualMachineInstances",
"apiVersion": "<supported-api-version>",
"name": "<vm-name>",
"extendedLocation": {
"name": "<custom-location>",
"type": "CustomLocation"
},
"properties": {
"hardwareProfile": {
"processors": 4,
"memoryMB": 16384
}
}
}
Burada özellikle API version’ı örnekte sabitlemedim.
Çünkü Azure Local resource provider hızlı gelişiyor. Microsoft’un güncel resource reference’ında virtualMachineInstances için 2024 sürümlerinin yanında 2025 ve 2026 preview API sürümleri de bulunuyor. Deployment yaparken kullandığınız özelliğin desteklediği API version’ı kontrol etmek gerekiyor.
Bu küçük görünen ama production automation için önemli bir konu.
Bir template’i iki yıl önce yazıp sonsuza kadar değiştirmeden kullanacağınızı düşünmemek gerekiyor.
Kod da lifecycle’ın bir parçası.
Peki Bicep neden var?
ARM template son derece güçlü fakat JSON büyüdükçe okunabilirlik ciddi şekilde azalıyor.
Bicep bu problemi çözüyor.
Bicep, Azure resource’larını declarative olarak tanımlamamızı sağlayan daha sade bir syntax sunuyor ve deployment sırasında ARM template modelini kullanıyor.
Microsoft Azure Local VM oluşturma dokümantasyonunda da örnek Bicep template’leri sunuyor. Akış oldukça basit: template içerisindeki parametreleri kendi Azure Local ortamınızdaki custom location, logical network ve diğer kaynaklara göre tanımlıyorsunuz; ardından Bicep dosyasını Azure CLI veya Azure PowerShell ile deploy ediyorsunuz.
Standart bir Bicep deployment’ının CLI tarafındaki mantığı şöyle:
az deployment group create \ --resource-group AzureLocal-Prod-RG \ --template-file main.bicep \ --parameters @prod.bicepparam
Azure Resource Manager aynı deployment komutuyla .json, .jsonc veya Bicep template kabul edebiliyor. Microsoft’un güncel ARM deployment dokümantasyonu da resource group seviyesindeki deployment için az deployment group create kullanılmasını tanımlıyor.
Bence Bicep’in Azure Local için en güçlü kullanım alanlarından biri standardizasyon.
Örneğin tek bir VM modülü hazırlayabiliriz:
vm.bicep
Sonra parametreleri ortam bazında ayırabiliriz:
prod.bicepparam
test.bicepparam
branch01.bicepparam
branch02.bicepparam
Böylece altyapı mantığı tek yerde kalırken lokasyona özgü değerler değişebilir.
Bu özellikle çok lokasyonlu Azure Local projelerinde ciddi avantaj sağlar.
Logical network de kod olabilir
Infrastructure as Code yaklaşımında sadece VM’yi otomatik oluşturup network’ü manuel bırakmak bana göre yarım otomasyon.
Azure Local logical network de ARM resource.
Microsoft bunu:
Microsoft.AzureStackHCI/logicalNetworks
olarak tanımlıyor ve resource Bicep, ARM template ve Terraform AzAPI ile oluşturulabiliyor. Resource tanımında subnet, DNS server, DHCP seçenekleri, fabric network configuration ve IP pool gibi network özellikleri bulunuyor.
Bu durumda deployment zincirini daha anlamlı hale getirebiliriz:
- Logical Network
- VM Image
- Network Interface
- Virtual Machine
- Guest configuration
Bu yaklaşımda yeni bir lokasyon açıldığında önce administrator’ın portalda 30 farklı ayar yapmasını beklemiyoruz.
Lokasyonun parametre dosyasını hazırlıyoruz.
Pipeline çalışıyor.
Altyapı tanımladığımız standarda göre oluşturuluyor.
Özellikle onlarca edge lokasyonu bulunan yapılarda Azure Local otomasyonunun gerçek değeri burada ortaya çıkıyor.
Tek cluster için 15 dakika kazanmaktan bahsetmiyoruz.
50 cluster’ın aynı standarda göre kalmasını sağlamaktan bahsediyoruz.
Terraform tarafında durum biraz farklı
Terraform uzun süredir multi-cloud ve Infrastructure as Code projelerinde kullanılan en yaygın araçlardan biri.
Azure Local tarafında da Terraform kullanılabiliyor.
Ancak burada hangi provider ve resource modelinin kullanıldığını bilmek önemli.
Microsoft’un güncel Azure resource reference’ında Microsoft.AzureStackHCI/virtualMachineInstances ve logicalNetworks kaynakları için Terraform tarafında AzAPI provider tanımları bulunuyor. Aynı zamanda VM resource’u için Microsoft tarafından Azure Verified Module da yayınlanıyor.
Microsoft Architecture Center’ın Azure Virtual Desktop on Azure Local rehberinde de Terraform ile Azure Local instance, logical network ve Azure Local VM deploy edilebildiği açıkça belirtiliyor ve ilgili Azure Verified Modules listeleniyor.
Burada Azure Verified Modules önemli.
AVM, Microsoft tarafından geliştirilen ve sürdürülen reusable Infrastructure as Code modülleri. Microsoft bunları Bicep ve Terraform için tutarlı ve tekrar kullanılabilir resource deployment’ları sağlamak amacıyla geliştiriyor.
Azure Local için bugün örneğin VM tarafında:
Azure/avm-res-azurestackhci-virtualmachineinstance/azurerm
gibi AVM modüllerini kullanabiliyoruz. Microsoft’un Architecture Center dokümanı Azure Local instance ve logical network için de ilgili AVM modüllerini listeliyor.
Bu bana göre önemli bir değişim.
Eskiden Terraform projesine başladığımızda çoğu zaman kendi modüllerimizi sıfırdan yazıyorduk.
Bugün mümkün olduğunda Microsoft’un doğruladığı AVM modüllerini başlangıç noktası olarak değerlendirmek daha mantıklı.
Terraform’un farkı state
Bicep ile Terraform arasındaki önemli operasyonel farklardan biri state yönetimi.
ARM/Bicep Azure’ın kendi resource state’i üzerinden çalışıyor.
Terraform ise kendi state dosyasını tutuyor.
Basitleştirirsek:
main.tf | terraform plan | terraform.tfstate | Azure Resource Manager | Azure Local
Terraform’un hangi resource’u yönettiğini, resource’un mevcut durumunu ve configuration ile gerçek durum arasındaki ilişkiyi state üzerinden takip ediyoruz.
Bu nedenle production Terraform kullanımında terraform.tfstate dosyasını bir administrator’ın laptop’unda bırakmak doğru değil.
Remote backend kullanmak gerekiyor.
Microsoft’un Terraform rehberlerinde Azure Storage’ın merkezi state backend olarak kullanılabileceği ve state’in merkezi, güvenli ve ortak erişilebilir bir yerde tutulması gerektiği anlatılıyor.
Bu operasyon açısından kritik.
Terraform state içerisinde altyapınızın önemli metadata’sı bulunuyor.
State kaybolursa operasyon zorlaşır.
İki ekip aynı state üzerinde kontrolsüz değişiklik yaparsa problem yaşarsınız.
Sensitive değerlerin state içerisine girme ihtimalini de ayrıca düşünmek gerekiyor.
Yani Terraform kullanmak sadece .tf dosyası yazmak değildir.
State management, locking, access control ve pipeline tasarımı da çözümün parçası.
Bicep mi Terraform mu?
Bu sorunun tek doğru cevabı yok.
Sadece Azure ve Azure Local yöneten bir kurumda Bicep son derece doğal bir seçim.
Azure native.
ARM ile doğrudan entegre.
Ayrı state altyapısı gerektirmiyor.
Azure resource API’lerine yeni özellik geldiğinde Bicep tarafında erişim genellikle oldukça doğrudan.
Terraform ise kurum zaten Terraform standardı kullanıyorsa çok mantıklı.
AWS, Azure, Azure Local ve diğer platformlar aynı IaC süreçlerinden yönetiliyorsa ekiplerin tek tooling üzerinde kalmasını sağlayabilir.
terraform plan ile uygulanacak değişiklikleri önceden görmek de operasyonel olarak çok değerli.
Ben burada teknoloji tartışması yapmak yerine kurum standardına bakmayı tercih ederim.
Ekip zaten Azure DevOps, Bicep ve Azure Policy kullanıyorsa sırf popüler diye Terraform eklemek gereksiz karmaşıklık olabilir.
Ekip bütün altyapısını Terraform ile yönetiyorsa Azure Local için ayrı bir Bicep operasyon modeli kurmak da gereksiz olabilir.
Önemli olan hangi dili seçtiğimiz değil.
Altyapının kod ile tanımlanmış olması.
Portalı tamamen bırakmalı mıyız?
Hayır.
Bence bu da IaC dünyasında zaman zaman gereksiz şekilde uçlara giden bir tartışma.
Portal troubleshooting, visibility ve ad-hoc operasyonlar için son derece değerli.
Problem portal kullanmak değil.
Production altyapının tek kaydının portal olması.
Örneğin VM’yi Bicep ile oluşturduk.
Bir administrator portal üzerinden memory’yi 32 GB’dan 64 GB’a çıkardı.
VM çalışıyor.
Ama Git repository’deki Bicep hala 32 GB diyor.
Artık iki farklı gerçek var.
Git: 32 GB
Gerçek VM: 64 GB
Bir sonraki deployment’ta ne olacağı kullandığınız resource ve deployment davranışına bağlı.
Bu yüzden IaC kullanan yapılarda temel prensip şu olmalı:
Kalıcı konfigürasyon değişikliği kod üzerinden yapılmalı.
Portal üzerinden acil değişiklik yapıldıysa daha sonra mutlaka source code’a yansıtılmalı.
Aksi halde configuration drift oluşturuyoruz.
Network ATC makalesinde fiziksel node’lar arasındaki configuration drift’i konuşmuştuk.
IaC tarafında da aynı problemin management versiyonu var.
Pipeline eklenince iş gerçek anlamda değişiyor
Bicep veya Terraform dosyasını administrator’ın laptop’undan çalıştırmak otomasyonun ilk seviyesi.
Asıl ölçeklenebilir model CI/CD pipeline ile başlıyor.
Örneğin şöyle bir süreç düşünelim:
Engineer → Git Pull Request → Code Review → Validation / Plan → Approval → Deployment → Azure Local
Bu modelde production VM değişikliği yapmak isteyen kişi doğrudan portalda işlem yapmıyor.
Kod değişikliği yapıyor.
Pull request açıyor.
Başka bir mühendis kontrol ediyor.
Pipeline syntax ve deployment validation çalıştırıyor.
Gerekliyse approval alınıyor.
Sonra deployment yapılıyor.
Bunun bize sağladığı en büyük avantaj hız bile değil.
Audit trail.
Altı ay sonra SQL01 VM’nin memory’si neden 32 GB’dan 64 GB’a çıktı?
Portal modelinde bunu araştırmak zor olabilir.
Git modelinde commit var.
Kim değiştirdi?
Ne zaman değiştirdi?
Neden değiştirdi?
Kim onayladı?
Hepsi kayıtlı.
Enterprise ortamda Infrastructure as Code’un gerçek değeri bence tam olarak burada.
Secret’ları template içine koymayın
Automation konuşurken en kritik güvenlik konularından biri de secret management.
VM local administrator password’ü, service account credential’ı, certificate veya API key gibi bilgileri Bicep parameter dosyasına veya Terraform repository’sine düz metin olarak koymak ciddi hata.
Infrastructure as Code repository’sinin source control’da olması gerekiyor.
Source control’a secret koymak istemiyoruz.
ARM/Bicep tarafında Key Vault ve secure parameter modelleri kullanılabilir.
Terraform tarafında sensitive variable kullanmak çıktının görünmesini azaltabilir ama önemli bir ayrım var: sensitive işaretlemek değerin state içerisinde hiç bulunmayacağı anlamına gelmez. Bu nedenle secret management ile state security beraber düşünülmeli.
Ben production automation tasarımında credential’ı mümkün olduğunca pipeline’ın workload identity veya managed identity modeli üzerinden çözmeyi tercih ederim.
İnsan kullanıcı adı ve parolasını pipeline’a koymak yerine servis kimliği.
Statik secret yerine mümkün olduğunca federated identity.
Bu konu Azure Local’dan bağımsız olarak modern IaC tasarımının temel güvenlik prensiplerinden biri.
RBAC otomasyonun bir parçası olmalı
Azure Local resource’ları Azure Resource Manager içerisinde bulunduğu için Azure RBAC modelinden faydalanabiliyoruz.
Bu da self-service senaryolarının önünü açıyor.
Örneğin merkezi altyapı ekibi:
- Logical Network
- VM Image
- Custom Location
- Azure Local Infrastructure
kaynaklarını yönetiyor.
Uygulama ekibine ise sadece kendi resource group’u içerisinde belirli VM resource’larını oluşturma yetkisi veriliyor.
Uygulama ekibi fiziksel cluster’a administrator olmuyor.
Hyper-V host’a login olmuyor.
Failover Cluster Manager açmıyor.
Kendisine tanımlanan Azure resource sınırları içerisinde VM oluşturuyor.
İşte burada Azure Local’ın klasik virtualization platformundan private cloud modeline geçişini daha net görüyoruz.
Self-service’in temelinde portal değil, resource model + RBAC + automation var.
Bu konuyu bir sonraki makalede Azure Arc ile Azure Local VM Yönetimi ve Self-Service IaaS başlığında daha detaylı ele alacağım.
Çok lokasyonlu Azure Local’da asıl değer ortaya çıkıyor
Tek bir dört node Azure Local cluster’ınız varsa bütün VM’leri portal üzerinden yönetebilirsiniz.
Ben yine IaC kullanmanızı öneririm ama operasyonel baskı düşük olabilir.
Fakat 30 mağaza, 50 fabrika veya 100 edge lokasyonunuz varsa durum tamamen değişiyor.
Örneğin her lokasyonda şu altyapıyı istediğimizi düşünelim:
- 1 x Domain Services VM
- 2 x Application VM
- 1 x Monitoring VM
- 1 x Management VM
- 2 x Logical Network
- Standart Tag Set
- Standart RBAC
100 lokasyon için:
500 VM
200 Logical Network
oluşturuyoruz.
Bunları portal üzerinden tek tek yönetmek bana göre artık gerçekçi değil.
Ama aynı Bicep veya Terraform modülünü 100 farklı parameter set ile deploy edebiliriz.
Örneğin:
locations/ istanbul/ parameters ankara/ parameters izmir/ parameters bursa/ parameters
Infrastructure code aynı.
Sadece lokasyon parametreleri farklı.
Yeni bir security standardı geldiğinde 100 lokasyonda manuel değişiklik yapmak yerine module version’ı değiştiriyoruz ve kontrollü deployment gerçekleştiriyoruz.
Azure Local’ın distributed infrastructure tarafındaki gücü de bence burada ortaya çıkıyor.
Donanım dağıtık olabilir.
Ama yönetim standardı dağıtık olmak zorunda değil.
Her şeyi otomatikleştirmek de doğru değil
Burada bir sınır çizmek gerekiyor.
Otomasyon yapılabiliyor diye her operasyonu otomatik çalıştırmak doğru değil.
Özellikle destructive işlemlerde approval mekanizması şart.
VM silme.
Disk silme.
Network değiştirme.
Production resource group üzerinde toplu değişiklik.
Bunları sadece pipeline tetiklendi diye otomatik gerçekleştirmek istemeyebilirsiniz.
Terraform tarafında terraform plan bu nedenle çok değerli.
Uygulanacak değişiklikleri görüp ardından apply kararı verebiliyoruz. Microsoft’un güncel Terraform rehberlerinde de standart workflow terraform init, terraform validate, terraform plan ve ardından terraform apply şeklinde ilerliyor.
Bicep tarafında da deployment öncesi validation ve what-if yaklaşımı kullanılabilir.
Yani iyi otomasyon:
Kod → Kontrol → Onay → Uygulama
olmalı.
Kötü otomasyon:
Kod → Production
değil.
Ben olsam nereden başlardım?
Mevcut Azure Local ortamında bütün operasyonu bir gecede Terraform’a taşımaya çalışmazdım.
Önce tekrar eden bir workload seçerdim.
Örneğin standart Windows Server VM deployment.
VM image’ını standardize ederdim.
Logical network’ü resource olarak tanımlardım.
VM konfigürasyonunu Bicep veya Terraform modülü haline getirirdim.
Parametreleri koddan ayırırdım.
Git repository oluştururdum.
İlk aşamada deployment’ı manuel pipeline approval ile çalıştırırdım.
Süreç oturduktan sonra RBAC, policy, tagging ve diğer governance bileşenlerini eklerdim.
Sonra ikinci workload.
Sonra diğer lokasyonlar.
Böylece otomasyon projesinin kendisi de kontrollü büyür.
Çünkü 500 VM’yi otomatik oluşturabilmek güzel.
500 VM’yi yanlış template ile otomatik oluşturabilmek ise manuel hatadan çok daha büyük problem.
Automation’ın blast radius’u manuel işlemlerden daha geniş.
Bu nedenle kod review, test environment, version control ve approval mekanizması otomasyonun opsiyonel parçaları değil.
Bence production IaC modelinin kendisi.
Azure Local tarafında bugün elimizde oldukça güçlü bir zincir var.
Portal ile başlayabiliyoruz.
Azure CLI ile script seviyesine geçebiliyoruz.
ARM resource modelini doğrudan kullanabiliyoruz.
Bicep ile Azure-native declarative altyapı oluşturabiliyoruz.
Terraform ve Azure Verified Modules ile mevcut enterprise IaC süreçlerine Azure Local’ı dahil edebiliyoruz.
Ama bütün bunların teknik araçlardan daha önemli ortak bir sonucu var:
Azure Local altyapısını artık sadece kurduğumuz bir sistem değil, tanımladığımız bir sistem haline getirebiliyoruz.
Bir cluster’ı elle doğru kurmak zor değil.
Asıl zor olan 50 cluster’ı üç yıl boyunca aynı standartta tutmak.
Infrastructure as Code’un Azure Local için gerçek değeri bence burada.
Bir sonraki makalede bunun kullanıcı tarafındaki karşılığına geçeceğim: Azure Arc ile Azure Local VM Yönetimi ve Self-Service IaaS. Azure Local VM’lerin Azure resource olarak nasıl yönetildiğini, image, logical network ve storage path gibi kaynakların nasıl hazırlandığını, RBAC ile altyapı ve uygulama ekiplerinin nasıl ayrılabileceğini ve klasik Hyper-V yönetiminden self-service private cloud modeline geçişi detaylı olarak inceleyeceğiz.
