Azure Cloud Services (Extended Support) 31 Mart 2027'de Kullanımdan Kalkıyor: Web ve Worker Rollerini Taşımak

Microsoft, Azure Cloud Services'i (extended support) 31 Mart 2025'te kullanımdan kaldırılacak hizmetler arasına aldı ve 31 Mart 2027'de tamamen kapatıyor. İş uygulamalarınızdan biri web rolleri ve worker rolleri olarak çalışıyorsa, o tarihten önce Azure'da başka bir yerde çalışıyor olması gerekiyor. Kullanımdan kaldırma SSS sayfası, herkesin önce sorduğu iki soruya açıkça cevap veriyor: Microsoft “can't grant extension requests” (süre uzatma talebi kabul edemiyor) ve “there's no one-click migration tooling available” (tek tıkla geçiş aracı yok).

Bugün, yani 3 Ekim 2026 itibarıyla geriye altı ay kalıyor.

Bu Yazı Kimin İçin

Tipik durum şu: .NET Framework üzerinde bir ASP.NET uygulaması, önde bir web rolü, arkada kuyrukları işleyen bir ya da iki worker rolü; sekiz on yıl önce bir ajans tarafından geliştirilmiş. Ajans çoğu zaman başka işlere geçmiştir, uygulama hâlâ sipariş işlemeyi ya da bir müşteri portalını yürütüyordur ve son geçişten beri kimse .csdef dosyasını açmamıştır.

Etkilenip etkilenmediğinizi anlamak için Azure portalını açın ve “Cloud services (extended support)” türündeki kaynakları listeleyin. Microsoft'un kullanımdan kaldırma bildirimi doğrudan bu görünüme bağlantı veriyor. Liste boşsa yapacak bir şeyiniz yok.

Bu makale, 2024'te kullanımdan kaldırılan Cloud Services (classic) ile ilgili değil. Ürünü sizin için bir sağlayıcı barındırıyorsa geçiş onun işidir: tarihini yazılı olarak isteyin. Aşağıdakilerin hepsi, kodun sahibi olan ya da kâğıt üzerinde sahibi olup onu anlayan birini bulmak zorunda olan ekipler için.

Bu Geçiş Neden 2024'tekinden Daha Zor

Pek çok şirket 2024'te, classic kullanımdan kaldırıldığında extended support'a geçti. O geçiş bilinçli olarak ucuz tasarlanmıştı. Microsoft'un extended support genel bakış sayfası, .csdef, .cscfg ve .cspkg dosyalarının “are carried forward and there's no change in the formats” (aynen aktarıldığını ve biçimlerinde değişiklik olmadığını) ve “No changes are required to runtime code” (çalışma zamanı kodunda değişiklik gerekmediğini) söylüyor. Yerinde geçiş seçeneği bile vardı. Aynı sayfa, gelişmeye devam etmeyen uygulamalar için extended support'u öneriyordu, çünkü “it provides a quick migration path” (hızlı bir geçiş yolu sunuyordu).

Bu kez birebir karşılık gelen bir hedef yok. Microsoft'un ifadesiyle Cloud Services “is about deploying applications as VMs. The code you write is tightly coupled to a VM instance”: uygulamaları sanal makine olarak dağıtmaya dayanıyor ve yazdığınız kod bir sanal makine örneğine sıkı sıkıya bağlı. Kodunuz bir rol içinde çalıştığını biliyor. Yapılandırmayı rolden okuyor, disk alanını rol üzerinden buluyor, sertifikalarını rol kuruyor ve rol başlamadan önce kurulum betiklerini yönetici olarak çalıştırıyor. Bunların hepsinin yerine başka bir şey konması gerekiyor.

Resmi kılavuzları okumadan önce bir şey daha. Microsoft'un kullanımdan kaldırma bildirimi ve SSS sayfası tek bir hedef adı veriyor: Service Fabric managed cluster. Genel bakış sayfası beş hedef sayıyor, Microsoft'un kendi geçiş karar matrisi ise yedi hedefi karşılaştırıyor. Service Fabric bir varsayılan, zorunluluk değil; pek çok web rolü için de yanlış seçim.

Hedefler ve Hangisinin Ne Zaman Uygun Olduğu

Web ve worker rollerinin aynı yere taşınması gerekmiyor. Her rol için ayrı bir hedef seçin.

App Service (Windows). Bir ASP.NET uygulaması için web rolüne en yakın seçenek. Windows örneklerinde desteklenen .NET Framework sürümleri kurulu gelir; böylece Web Forms ve MVC 5 yeniden yazılmadan çalışır. Worker rolleri, “in the same instance as a web app” (web uygulamasıyla aynı örnekte) ek ücret olmadan çalışan WebJobs olarak taşınabilir. Sınır makinenin kendisi: Microsoft, COM bileşenleri, kayıt defteri erişimi ya da MSI yükleyicileri gerektiren uygulamaları Managed Instance'a yönlendiriyor; dolayısıyla yükseltilmiş yetkiyle çalışan başlangıç görevlerinin standart bir planda gidecek yeri yok.

App Service Managed Instance. Eski Windows web uygulamaları için tasarlandı. Microsoft'un genel bakış sayfasına göre “generally available for Windows web apps in select regions” (belirli bölgelerde Windows web uygulamaları için genel kullanıma açık); yalnızca Pv4 ve Pmv4 planlarıyla sınırlı, .NET Framework 3.5 ve 4.8 önceden kurulu ve COM bileşenlerini kaydedebilen, kayıt defteri anahtarları yazabilen, MSI yükleyicileri çalıştırabilen ve IIS'i yapılandırabilen PowerShell kurulum betikleri sunuyor. Bu, yükseltilmiş başlangıç görevlerinin yaptıklarının çoğunu karşılıyor. Sınırları: yalnızca web uygulamaları (WebJobs yok), konteyner yok, yalnızca Entra ID ve managed identity (etki alanına katılma, NTLM ya da Kerberos yok); bu yazının yazıldığı tarihte listelenen tek Avrupa bölgesi de North Europe.

Container Apps. Modern .NET'e geçirildikten sonra worker rolleri için iyi bir seçenek: kuyruğa göre ölçeklenme, zamanlanmış ve olayla tetiklenen işler, sıfıra kadar ölçeklenme. Ancak konteyner gereksinimleri “Linux-based (linux/amd64) container images are required” diyor: Linux tabanlı konteyner imajları zorunlu. .NET Framework üzerindeki kod, taşınana kadar orada çalışmaz.

Azure Kubernetes Service. Windows Server konteynerlerini Windows düğüm havuzlarında çalıştırır; böylece bir .NET Framework rolü konteynere alınıp taşınabilir. Karar matrisi hem geçiş karmaşıklığını hem de işletim yükünü yüksek olarak değerlendiriyor. Zaten Kubernetes çalıştırıyorsanız uygun; tek bir eski uygulama için kurulacak ilk küme olarak değil.

Virtual Machine Scale Sets. Matris bunu “Closer to Cloud Services model, offering easier lift-and-shift” olarak tanımlıyor: Cloud Services modeline daha yakın ve olduğu gibi taşımayı kolaylaştıran bir seçenek. Sanal makineyi geri alırsınız; rolün sizin için yaptığı yama, imaj oluşturma ve IIS kurulumu işleriyle birlikte.

Service Fabric managed cluster. Microsoft'un adını verdiği hedef. Worker rolleri buna temiz biçimde oturur. Web rolleri ise çoğu zaman oturmaz: Service Fabric “does not support IIS” (IIS'i desteklemiyor) ve dönüştürme kılavuzu ASP.NET Web Forms'u desteklenmeyenler arasında sayıp yol olarak ASP.NET Core MVC'ye dönüştürmeyi gösteriyor. Service Fabric geçiş kılavuzu ayrıca managed cluster'ların “currently do not support containers” (şu anda konteynerleri desteklemediğini) ekliyor; dolayısıyla IIS'e bağımlı bir uygulama, işletmesi daha zahmetli olan geleneksel bir küme gerektiriyor.

Karar tablosu

Kodda Neler Değişiyor

Çözümde Microsoft.WindowsAzure.ServiceRuntime araması yapın. Bunu içe aktaran her dosya listeye girer.

RoleEntryPoint

Bir worker rolü, RoleEntryPoint'ten türeyen ve OnStart, Run ile OnStop metotlarını geçersiz kılan bir sınıftır. Run geri dönerse örnek yeniden başlatılır. Service Fabric bu üçünü, “when the RunAsync method's CancellationToken is signaled” (RunAsync metodunun CancellationToken'ı sinyal verdiğinde) durması gereken tek bir RunAsync metodunda birleştiriyor. App Service'te ya da bir konteynerde aynı mantık, döngüsü ve iptal belirteci olan bir konsol uygulamasına ya da barındırılan bir arka plan hizmetine dönüşür.

Gözden kaçan kısım kapanış. OnStop, elinizdeki mesajı bitirmeniz için size bir an tanıyordu. Yeni barındırıcının iptal sinyalini ilettiğinden ve işlenirken yarıda bırakılan bir mesajın iki kez işlenmesinin güvenli olduğundan emin olun.

Web rollerinde de çoğu zaman böyle bir sınıf bulunur, genellikle WebRole.cs. OnStart metodu bir şey yapıyorsa (IIS ayarları, önbellek ısıtma), silmeden önce ne yaptığını öğrenin.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key"), ayarları .cscfg dosyasından okur. Cloud Services dışında bunu sağlayan hiçbir şey yok. Herhangi bir şeyi taşımadan önce her çağrıyı küçük bir yapılandırma arayüzüne sarın, sonra bu arayüzü yeni barındırıcıda uygulama ayarlarına, ortam değişkenlerine ya da Key Vault'a yönlendirin. Projedeki en ucuz değişiklik budur ve geri kalanını bir dizüstü bilgisayarda test edilebilir hâle getirir.

Aranması gereken üç kullanım daha:

• RoleEnvironment.Changed: yapılandırma değişikliklerini yeniden başlatma olmadan uyguluyordu. Service Fabric'te eşdeğer bir olay var. Diğer hedeflerde bir ayar değişikliğinin süreci yeniden başlattığını varsayın ve bunun yürütülmekte olan işe etkisini test edin.
• Zamanlanmış iş için tek bir örnek seçmekte kullanılan RoleEnvironment.CurrentRoleInstance. Tetiklenen WebJobs tek bir örnekte çalışır; sürekli olanlar kısıtlanmadıkça tüm örneklerde çalışır. Bunu bilinçli olarak kararlaştırın.
• RoleEnvironment.IsAvailable ve IsEmulated dalları. Bunlar “bulut” yolunu “yerel” yoldan ayırır ve ikisinden biri yakında ölü koda dönüşecek.

.cscfg ve .csdef

.cscfg, ortama özgü ayarları, örnek sayılarını ve sertifika parmak izlerini tutar. .csdef ise uç noktaları, sanal makine boyutunu, yerel depolamayı, başlangıç görevlerini, sertifika depolarını ve bazen tek bir web rolü içindeki birden fazla IIS sitesini tutar. İkisini satır satır inceleyin ve her girdinin taşımadan sonra nerede duracağını yazın: bir uygulama ayarı, bir Key Vault referansı, altyapı kodu ya da hiçbir yer. Rollerin birbirini doğrudan çağırmasını sağlayan dahili uç noktaların yerine bir şey gerekir: bir hizmet adresi ya da bir kuyruk.

Sertifikalar

Extended support sertifikaları zaten Key Vault'a taşımaya zorlamıştı; 2024'teki çalışmanın o kısmı şimdi işe yarıyor. Değişen, kodun onları nasıl bulduğu. Bir .csdef, sertifikaları adı belirtilmiş bir depoya, çoğu zaman LocalMachine'e kurar. Windows App Service'te WEBSITE_LOAD_CERTIFICATES ayarı onları Current User\My deposunda kullanılabilir kılar. LocalMachine deposunu açan kod hiçbir şey bulamaz ve sertifikaya ihtiyaç duyan ilk çağrı başarısız olur. Linux konteynerlerinde ise sertifikayı başlangıçta Key Vault'tan yükleyin.

Başlangıç görevleri

Startup.cmd dosyasını açın. Sürprizler burada yaşar ve genellikle executionContext="elevated" ile çalışır: PDF üretimi için yazı tipleri, bir COM bileşeni, bir IIS rewrite modülü, TLS için bir kayıt defteri değişikliği. Her satırın üç olası akıbeti var: artık gerekmiyor, Managed Instance'ta bir kurulum betiğine taşınıyor ya da bir konteyner veya sanal makine imajının içine gömülüyor.

Yerel depolama

.csdef içindeki bir LocalStorage kaynağı, RoleEnvironment.GetLocalResource üzerinden okunarak her örneğe geçici disk alanı sağlıyordu. Gerçekten geçici dosyalar için platformun geçici dizinini kullanın. Yeniden başlatmadan sonra da kalması gereken her şey, birinin kalıcı olduğunu varsaydığı dosyalar dahil, Blob Storage'a gider.

Web Forms

Geri kalan her şeyi belirleyen karar bu. Web Forms System.Web üzerine kuruludur ve ASP.NET Core sürümü yoktur; dolayısıyla bir Web Forms uygulamasını Service Fabric'e ya da Container Apps'e taşımak, kullanıcı arayüzünü yeniden yazmak demektir. App Service, Managed Instance, bir Windows konteyneri ya da bir ölçek kümesi onu değiştirmeden çalıştırabilir. Uygulamayı olduğu gibi taşıyın, modernizasyonu kendi bütçesi olan ayrı bir proje yapın. Arayüzü yeniden yazmak, bir kapanış tarihinin kritik yolunda yer almamalı.

Geri kalanlar

İki cloud service arasındaki VIP swap, App Service'te dağıtım yuvalarına (deployment slots) ya da Container Apps'te revizyonlara dönüşür. Tanılama (WAD) uzantısı üzerinden gönderilen günlüklerin yeni bir hedefe ihtiyacı var, genellikle Application Insights. Standart App Service ve Container Apps uzak masaüstü sunmaz; Managed Instance buna Azure Bastion üzerinden, yalnızca tanılama amacıyla izin verir.

Altı Aylık Bir Plan

31 Mart 2027'den geriye doğru hesaplandı; araya aralık tatilleri giriyor.

Ekim: envanter ve hedef seçimi. Tüm extended support dağıtımlarını listeleyin. Her rol için .NET Framework sürümünü, Web Forms mu MVC mi olduğunu, her RoleEnvironment çağrısını, başlangıç görevini, yerel depolama kaynağını, sertifikayı ve uç noktayı kaydedin. Ardından rahatsız edici kısmı kontrol edin: dağıtılmış paketi elinizdeki kaynak koddan derleyebiliyor musunuz? Ajansların geliştirdiği sistemlerde cevap bazen hayırdır ve bunu öğrenmenin zamanı ekimdir. Her rol için bir hedef seçin.

Kasım: bir rol, baştan sona. Yapılandırma sarmalayıcısını ekleyin, hedef ortamı altyapı kodu olarak yazın ve bir rolü (genellikle en basit worker'ı) bir test ortamında günlükleri, sertifikaları ve dağıtım hattıyla birlikte çalışır hâle getirin.

Aralık ve ocak: geri kalanını taşıyın. Giriş noktalarını, başlangıç görevlerini ve yerel depolamayı değiştirin. Bir hazırlık (staging) ortamına üretimdekine benzer verilerle yük testi yapın: bir WebJob ya da konteyner, kendine ayrılmış bir rol sanal makinesinin işlem hacmine yetişemeyebilir.

Şubat: paralel çalıştırma. Yeni ortamı gerçek trafikle çalıştırın. Eski rollerle aynı kuyruğu paylaşan worker'lar için ya önce işlemeyi idempotent hâle getirin ya da yenilerini başlatmadan önce eski worker'ları durdurun.

Mart başı: geçiş. DNS'i bolca zaman payı bırakarak değiştirin. Eski dağıtımı bir iki hafta boyunca durdurulmuş ama bozulmamış hâlde tutun, sonra silin. Geçişi martın son haftasına planlamayın: o zaman başarısız bir geçişin ikinci denemesi olmaz.

Bunun yerine ocakta başlıyorsanız modernizasyonu tamamen bir kenara bırakın. En az kod değişikliği gerektiren hedefi seçin (App Service, Managed Instance ya da ölçek kümeleri), taşıyın ve yeniden düzenlemeyi sonraya bırakın.

Belirsiz Olanlar

Microsoft, hizmetin “fully retired” (tamamen kullanımdan kaldırılmış) olacağını ve geçişin “to avoid service disruption” (hizmet kesintisini önlemek için) gerekli olduğunu söylüyor. Okuduğumuz sayfalar, 1 Nisan 2027'de hâlâ çalışan bir dağıtıma ne olacağını söylemiyor. Bunu deneyerek öğrenmeyi planlamayın. Managed Instance bölgeleri ve planları da önümüzdeki aylarda büyük olasılıkla değişecek; bunları bu makaleden değil, karar verdiğiniz anda teyit edin.

Nereden Destek Alabilirsiniz

Başkalarının geliştirdiği uygulamaları devralıyor, nasıl çalıştıklarını çözüyor ve taşıyoruz: envanter, her rol için hedef, RoleEnvironment ve başlangıç görevi değişiklikleri ve geçiş. Eski sistem bakımı çalışmamız .NET Framework ve Web Forms'u kapsıyor; geçişi kendi ekibiniz yapıyor ve ek kaynağa ihtiyacı varsa ekip takviyesi sayfasına bakın.

Bir Cloud Services dağıtımınız ve altı ay sonraya düşen bir tarihiniz varsa office@c9group.dev adresine yazın.