Legacy uygulamaları modernleştirmek tüm yazılımı tek seferde yeniden yazmak demek değildir. Birçok işletme için daha iyi ilk soru hangi işlevin değişmesi gerektiği, neyin şimdilik çalışabileceği ve geçiş boyunca bir siparişin nasıl doğru kalacağıdır. DAXS bu nedenle yeni arayüz, API veya platforma karar vermeden önce mevcut Windows ya da Linux uygulamasını veriler, arayüzler ve üretici onayları bakımından incelerdi.
Mevcut VM’yi taşımak işletim sistemini donanımdan ayırabilir, ancak uygulamanın kendisini henüz modernleştirmez. VMware/Proxmox geçişinin kabulü ayrı bir adımdır. Burada işletme çalışırken işlevlerin ve entegrasyonların daha uzun vadeli değiştirilmesi ele alınır.
Önce mevcut durumu tanımlayın, sonra sınır çizin
Envanter sunucu adları listesinden fazlasını gerektirir. Her hizmetin uygulama kartı; sorumlu, kullanıcı grupları, Windows veya Linux sürümü, veritabanı ve sürücüler, toplu işler, dosya paylaşımları, yazıcılar, kimlik kaynağı, gelen ve giden arayüzler ile bakım ve lisans sözleşmesini kapsar. Az görünen yollar özellikle önemlidir: muhasebeye gece CSV aktarımı, parolası dolan hizmet hesabı veya sürümü sunucuya bağlı masaüstü istemcisi.
Kapalı kaynak yazılımda desteklenen konuk işletim sistemlerini, veritabanı sürümlerini, sürücüleri ve sanallaştırma ortamlarını üretici belirler. Veritabanına doğrudan yazmak kolay entegrasyon gibi görünebilir; fakat iş kurallarını, garanti koşullarını ve sonraki güncellemeleri ihlal edebilir. DAXS önce belgelenmiş API’yi, onaylı dışa aktarımı veya üretici SDK’sını değerlendirirdi. Hiç desteklenen entegrasyon noktası yoksa aşamalı değiştirme teknik ya da sözleşmesel açıdan uygun olmayabilir; o zaman sağlayıcıyla başka bir karar gerekir.
Bir örnek: sipariş durumunu yenileyin, çekirdeği koruyun
İç sipariş yönetiminin bir Windows uygulama hizmeti, SQL veritabanı ve gece aktarımı olduğunu varsayalım. Müşteriler sık sık sipariş durumunu soruyor; eski çekirdek ise sipariş ve faturaları güvenilir biçimde işliyor. İlk yeni işlev, verilerini onaylı bir arayüzden alan salt okunur durum görünümü olabilir. Sipariş çekirdeği ve veritabanı başlangıçta yetkili kaynak olarak kalır.
Entegrasyon katmanı eski tanımlayıcıları ve durum değerlerini belgelenmiş yeni modele çevirir. Bu yaklaşım bağdaştırıcı veya Anti-Corruption Layer olarak bilinir. Kontrolsüz veritabanının önüne konmuş sihirli bir API değildir: sipariş bazında yetkiler, kimlik doğrulama, girdi kontrolü, hız sınırları, günlükleme ve yanıt süreleri yeniden değerlendirilmelidir. OWASP, nesne düzeyinde yetkilendirme ve kimlik doğrulamayı başlıca API riskleri arasında sayar. Salt okunur durum sorgusu bile başkalarının siparişlerini açığa çıkarmamalıdır.
Ancak okuma işlevi kararlı olduktan sonra tek bir sipariş türünün kaydı gibi sınırlı bir yazma süreci gelebilir. Veri yetkisi artık kritiktir: eski çekirdek yetkili kaynak olduğu sürece yeni arayüz gizlice ikinci bağımsız gerçek yaratmamalıdır. Her kayıt için hangi sistemin yazabileceği, isteklerin nasıl kesin tanınacağı ve başarısız denemeler, gecikmiş mesajlar ile düzeltmelerin nasıl uzlaştırılacağı belirlenmelidir. İş çatışmaları modeli olmadan iki sistemin aynı anda yazması geçiş planı değildir.
Ölçülebilir durma noktalarıyla dört aşama
| Aşama | Değişiklik | Sonraki aşamadan önce gereken kanıt |
|---|---|---|
| 1. Mevcut sistemi güvenceye alın | Bağımlılıkları, sözleşmeleri, veri akışlarını ve geri yüklenebilir yedekleri kaydedin | Uygulama ve veritabanını test ağında geri yükleyin; örnek siparişi iş birimiyle karşılaştırın |
| 2. Okumayı ayırın | Yeni durum görünümü için onaylı dışa aktarım/API kullanın | Durumu, görüntüleme haklarını, güncelleme gecikmesini ve yükü eski sistemle karşılaştırın |
| 3. Tek yazma durumunu taşıyın | Yalnızca bir sipariş türünü yeni arayüzden geçirin; veri yetkisini belirleyin | Her siparişi tam bir kez kaydedin, belgeleri ve düzeltmeleri uzlaştırın, geri dönüşü prova edin |
| 4. Eski parçayı kaldırın | Yalnızca işlev ve veri devri kanıtlandıktan sonra kapatın | Çözülmemiş gizli çağıran, dışa aktarma/saklama yükümlülüğü veya üretici bağımlılığı kalmasın |
İşlevlerin bu şekilde aşamalı değiştirilmesi Strangler Fig örüntüsüne benzer. Her yere uymaz: istekler yönlendirilemiyorsa, sağlayıcı tüm arayüzleri kapatıyorsa veya küçük sistem kolayca bütünüyle değiştirilebiliyorsa bağdaştırıcı getirisinden fazla emek gerektirebilir. Geçiş katmanının da izleme, kapasite ve işletim sorumlusuna ihtiyacı vardır; yeni bir tek hata noktasına dönüşmemelidir.
İlk üretim yazmasından önce geri dönüşü tanımlayın
Salt okunur durum görünümünde geri dönüş genellikle basittir: yeni görünümü kapatın, çekirdeği kullanmayı sürdürün ve nedeni araştırın. Yeni veritabanına ilk yazmadan sonra proxy’yi eski yola döndürmek yetmez. Yeni siparişler, iptaller ve belgeler eski duruma aktarılmalı veya iş birimi tarafından uzlaştırılmalıdır. Her geçişte bu nedenle son uzlaştırılmış veri durumu, açık yazma durdurma, dışa/içe aktarma prosedürleri, sorumlular ve prova bulunmalıdır. Microsoft, eski veri nesneleri kaldırıldıktan sonra geri dönüşün zorlaştığı konusunda açıkça uyarır.
Paralel dönemde eski ortam da unutulmamalıdır. İşletim sistemi ya da uygulama artık güvenlik güncellemesi almıyorsa ilgili hizmetler, ağ yolları ve erişimler hedefli kısıtlanmalı, izlenmeli ve çıkış tarihine bağlanmalıdır. Önüne yeni API koymak eski çekirdekteki açığı kaldırmaz. Yalıtımın yeterliliği somut riske ve üreticinin sunduğu önlemlere bağlıdır.
Emeği ve sınırları dürüst değerlendirin
Üç veya beş yıllık karşılaştırma en azından mevcut durum analizi, üretici ve lisans açıklığa kavuşturması, bağdaştırıcı geliştirme, veri eşleme, güvenlik incelemesi, test verileri, iş birimi kabulü, paralel işletim, izleme ve sonraki kaldırmayı içerir. Yeni işletim sistemi/veritabanı lisansları ve iki ortamı geçici olarak işleten kişilerin eğitimi de eklenebilir. Paralel işletim bilinçli bir maliyettir, ücretsiz ara aşama değildir. Aşamalı çözüm ancak önlenen riskler ve yeni işlevler gerçek emeği haklı çıkarıyorsa değerlidir; evrensel bir tasarruf oranı çıkarılamaz.
DAXS, iş birimiyle örnekteki durum sorgusu gibi küçük ve görünür ilk sınırı seçer, doğru veriler, yanıt süresi, desteklenebilirlik ve geri yükleme üzerinden kabul ederdi. Sonra hangi işlevin gerçekten ayrı hizmete ihtiyaç duyduğu belirlenirdi. Mevcut bir VM’nin teknik temeli için İşletmelerde Proxmox altyapı çerçevesini açıklar; API erişimlerini öngörülebilir işletmek sonraki arayüz işletimini tamamlar. Somut uygulama kartı hazırlamak isteyenler DAXS’a şu bölümden ulaşabilir: İletişim.
Kaynaklar: Microsoft Azure Architecture Center: Strangler Fig örüntüsü · Microsoft: Anti-Corruption Layer örüntüsü · OWASP: API Security Top 10.
