Replatforming, iş yükünü buluta kopyaladıktan sonra veritabanı motorunu, mesaj kuyruğunu, dosya katmanını veya uygulama çalışma ortamını bulut sağlayıcısının yönetilen bir servisiyle değiştirme yaklaşımıdır. Kodu baştan yazmazsınız ancak bağımlı katmanı taşır veya dönüştürürsiniz. Lift and shift sonrası iyileştirme kararı şu soruya dayanır. Bu iş yükü hâlâ sanal makine üzerinde kendi yönettiğiniz bileşenlerle mi kalmalı, yoksa operasyon yükünü azaltacak bir platform değişimi ölçülebilir fayda verir mi.
Bu metin buluta geçiş danışmanlığı hizmet sayfasını destekler. Paket veya fiyat listesi sunmaz. İlk dalga lift and shift risklerini lift and shift ilk dalga riskleri yazısında, taşıma öncesi katman kontrollerini buluta geçiş kontrol listesi metninde ele aldık.
Hızlı Özet
Replatforming lift and shift ile refactor arasında durur. Sanal makine ve işletim sistemi çoğu senaryoda korunur. Değişen parça genelde veritabanı örneği, önbellek, nesne depolama bağlantısı veya konteyner çalışma zamanıdır.
Lift and shift sonrası iyileştirme için önce stabilizasyon penceresi tanımlanır. Ağ, kimlik, yedekleme ve izleme çalışır hale gelmeden platform değişimi planlanmamalıdır. Sonra iş yükü listesi maliyet, operasyon süresi, güvenlik sınırı ve entegrasyon karmaşıklığına göre sıralanır.
Leon-X bulut altyapısının sahibi değildir. Replatforming değerlendirmesi, geçiş sırası ve doğrulama adımlarında operasyon ekibinizle çalışır.
İçindekiler
- Replatforming Tanımı ve Sınırları
- Lift and Shift Sonrası Neden Ayrı Karar Gerekir
- Hangi Katmanlar Replatforming Kapsamına Girer
- İyileştirme Adayı Seçim Kriterleri
- Ölçüm ve Kanıt Toplama
- Riskler ve Geri Alma Planı
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, veri merkezinde sunucu altyapısı.
Replatforming Tanımı ve Sınırları
Replatforming bazen lift and shift ile karıştırılır çünkü ikisi de mevcut uygulama koduna dokunmadan buluta geçişi ifade edebilir. Fark şudur. Lift and shift disk veya sanal makine kopyası ile aynı yığını taşır. Replatforming taşıma sonrasında veya taşıma adımında belirli bir bileşeni yönetilen servisle değiştirir.
Örnek senaryolar şunlardır. Yerel SQL Server örneği yönetilen veritabanı servisine taşınır. Dosya paylaşımı nesne depolama API’sine bağlanır. Kendi kurduğunuz mesaj kuyruğu bulut sağlayıcısının kuyruk servisiyle değiştirilir. Uygulama sunucusu konteyner çalışma zamanına alınır ancak iş mantığı aynı kalır.
Refactor ise uygulama mimarisini ve kodu bulut yerel desenlere göre yeniden düzenler. Replatforming refactor kadar geniş değildir. Yine de veri şeması, bağlantı dizeleri, kimlik bilgisi yönetimi ve yedekleme akışı değişir.
IaaS sorumluluk paylaşımı replatforming sonrası hangi katmanın sağlayıcı operasyonuna geçtiğini netleştirir. Yönetilen servis kullandığınızda yama, kapasite ve erişim modeli farklı okunur.
Lift and Shift Sonrası Neden Ayrı Karar Gerekir
İlk geçiş dalgası genelde hız ve öğrenme için lift and shift seçer. Ekip taşıma aracının raporunu başarı sayar. Uygulama ayakta görünür ancak maliyet, performans ve operasyon yükü henüz ölçülmemiş olabilir. Replatforming kararını bu aşamada ertelemek teknik borcu sanal makine üzerinde dondurur.
Ayrı karar vermenizin pratik nedeni kaynak sınırlıdır. Aynı çeyrekte hem yeni dalga taşımaları hem platform değişimleri yürütülürse değişiklik penceresi çakışır. Stabilizasyon süresi tanımlandığında ekip gerçek kullanım verisini toplar. CPU profili, depolama gecikmesi, yedekleme süresi ve olay kayıtları replatforming gerekçesini oluşturur.
Envanter ve bağımlılık haritalama hangi uygulamanın hangi veritabanına ve hangi dış servise bağlı olduğunu gösterir. Replatforming planı bu harita üzerine yazılır. Bağımlılık bilinmeden veritabanı motoru değiştirmek kesinti riskini artırır.
Hangi Katmanlar Replatforming Kapsamına Girer
Veritabanı katmanı en sık replatforming adayıdır. Kendi yönettiğiniz örnek yedekleme, erişilebilirlik yapılandırması ve sürüm yükseltme işlerini ekibinize yükler. Yönetilen servis bu işlerin bir kısmını sağlayıcı operasyonuna taşır. Karşılığında bağlantı modeli, ağ kuralı ve karakter seti uyumu kontrol edilmelidir.
Mesaj ve olay kuyruğu ikinci sık adaydır. Yerelde kurulu broker bulutta farklı erişim anahtarı ve TLS politikası kullanır. Tüketici uygulamaların yeniden bağlanma mantığı test edilmelidir.
Dosya ve ek depolama üçüncü adaydır. Uygulama yerel disk yoluna yazıyorsa nesne depolama veya paylaşımlı dosya servisine geçiş kod veya yapılandırma değişikliği ister. Salt okunur arşiv iş yükleri bu geçişe daha uygun olur.
Kimlik ve sırlar dördüncü adaydır. Yerel yapılandırma dosyasındaki parola bulut sırrı deposuna taşınır. Uygulama bu API’yi desteklemiyorsa replatforming kapsamı genişler.
Yerel sanallaştırma alışkanlıkları replatforming öncesi gözden geçirilmelidir. Ağ, depolama ve yedekleme prosedürleri bulutta farklı okunur.
İyileştirme Adayı Seçim Kriterleri
Her iş yükü replatforming için uygun değildir. Seçim matrisi şu başlıklarda toplanır.
Operasyon yükü. Ekip hangi bileşende en çok gece müdahalesi yapıyor. Yedekleme hatası, disk dolması veya sürüm uyumsuzluğu tekrar ediyor mu.
Ölçülebilir maliyet. Sanal makine, disk ve lisans kalemleri bir arada okunmalıdır. Yönetilen servis fiyat modeli farklıdır. Kesin tasarruf iddiası bu yazıda verilmez. Karşılaştırma tablosu senaryo bazlı hazırlanır.
Entegrasyon sayısı. Tek veritabanına bağlı basit uygulama düşük entegrasyon riski taşır. Onlarca rapor ve arka plan job aynı örneği kullanıyorsa geçiş sırası uzar.
Uyumluluk ve veri sınırı. Veri yerleşimi, şifreleme ve erişim günlüğü gereksinimleri proje öncesinde doğrulanır. Replatforming yeni servis sözleşmesi ve ağ yolu gerektirir.
İş etkisi. Üretim penceresi kısıtlı sistemler ikinci veya üçüncü dalgaya bırakılır. Test ortamında replatforming provası zorunludur.
Ölçüm ve Kanıt Toplama
Lift and shift sonrası en az bir tam iş döngüsü boyunca temel metrikler kaydedilir. Sanal makine CPU ve bellek ortalaması, disk gecikme gözlemi, yedekleme job süresi ve başarısızlık sayısı, uygulama hata oranı ve destek kayıt hacmi tipik girdilerdir.
Kesin IOPS veya gecikme taahhüdü yazılmaz. Ekip kendi ölçümünü trend olarak saklar. Replatforming öncesi ve sonrası aynı iş yükü testi ile karşılaştırma yapılır.
Bulut sunucu operasyon modeli kapasite planını nasıl okuyacağınızı gösterir. Platform değişiminde kapasite birimi değişebilir. Örneğin sanal CPU yerine veritabanı işlem birimi okunur.
Riskler ve Geri Alma Planı
Replatforming geri alınabilir olmalıdır. Veritabanı geçişinde çift yazma veya okuma yönlendirme penceresi tanımlanır. Kesinti süresi iş birimi ile onaylanır. Geri dönüş adımları numaralandırılır ve DNS veya bağlantı dizisi değişiklikleri geri alma sırasına yazılır.
Veri tutarlılığı riski en kritik başlıktır. Şema dönüşümü, karakter seti ve saat dilimi farkları sessiz hata üretir. Karşılaştırma sorguları ve satır sayısı kontrolleri geçiş runbook dosyasında yer alır.
Kimlik ve ağ riski ikinci başlıktır. Yönetilen servis farklı alt ağ veya özel endpoint kullanır. Güvenlik grubu ve yerel isim çözümlemesi geçiş gecesi ilk kez denenmemelidir.
Lisans riski üçüncü başlıktır. Yerel lisans modeli yönetilen serviste geçerli olmayabilir. Sağlayıcı ve yazılım satıcısı ile doğrulama adımı plana eklenir.
Yaygın Hatalar
Lift and shift tamamlanmadan replatforming başlatmak stabilizasyon verisini atlar.
Tüm veritabanlarını aynı çeyrekte yönetilen servise almak değişiklik yorgunluğu yaratır.
Yedekleme ve izlemenin yeni serviste test edilmeden üretime geçmek veri koruma boşluğu bırakır.
Replatforming ile refactor’ı aynı pencerede birleştirmek kapsamı kontrol edilemez hale getirir.
Ölçüm olmadan maliyet gerekçesi yazmak karar defterini zayıflatır.
Kontrol Listesi
- Lift and shift sonrası stabilizasyon süresi tanımlandı ve tamamlandı.
- İş yükü envanteri ve bağımlılık haritası güncel.
- Replatforming adayı seçim matrisi maliyet, operasyon ve risk sütunlarıyla dolduruldu.
- Test ortamında platform değişimi provası yapıldı.
- Veri tutarlılığı ve geri dönüş adımları runbook içinde numaralandı.
- Ağ, kimlik ve lisans kontrolleri geçiş öncesi doğrulandı.
- Yedekleme ve izleme yeni serviste job ve alarm üretiyor.
- Üretim geçişi iş birimi onayı ve pencere kaydı ile planlandı.
Leon-X ile Sonraki Adım
Leon-X lift and shift sonrası iş yüklerinizi replatforming sırasına koyar. Ölçüm şablonu, risk matrisi ve geçiş runbook maddelerini ekibinizle birlikte doldurur. Buluta geçiş danışmanlığı kapsamında platform değerlendirmesi ve dalga koordinasyonu sunar. Altyapı sahibi değildir. Keşif için iletişime geçin.
Sık Sorulan Sorular
Replatforming her zaman lift and shift sonrası yapılır mı?
Zorunlu değildir. Bazı iş yükleri doğrudan yönetilen servisle başlatılabilir. Kurumların çoğu önce lift and shift ile öğrenme dalgası tamamlar.
Replatforming ile refactor arasındaki fark nedir?
Replatforming belirli altyapı bileşenini değiştirir. Refactor uygulama kodunu ve mimarisini yeniden düzenler. Kapsam ve süre refactor tarafında genelde daha büyüktür.
Hangi iş yükü replatforming için uygun değildir?
Özel donanım, seri port veya yerel dosya yolu bağımlılığı güçlü uygulamalar uygun değildir. Önce bağımlılık azaltılır veya refactor değerlendirilir.
Yönetilen veritabanına geçişte kesinti kaçınılmaz mı?
Kesinti süresi geçiş yöntemine bağlıdır. Çift yazma veya replikasyon ile pencere kısaltılabilir. Kesin süre taahhüdü verilmez. Plan iş yüküne özel yazılır.
Sonuç
Replatforming, lift and shift ile taşınan iş yükünü bir üst platform katmanına taşıyarak operasyon yükünü azaltma seçeneğidir. Karar kod yazmadan yapılan bir iyileştirme değildir. Bağlantı, veri, kimlik ve yedekleme akışı yeniden doğrulanır. Stabilizasyon verisi toplandıktan sonra aday seçimi yapılır ve geri alınabilir bir geçiş planı uygulanır. Dalga disiplini korunduğunda ekip bulutta hem öğrenir hem borcu bilinçli şekilde eritir. Geçiş yol haritası için buluta geçiş danışmanlığı sayfasına bakabilirsiniz.
Kaynaklar
- Microsoft Azure migrate ve modernize yaklaşımı genel geçiş modeli terminolojisi için referans alınabilir.
- AWS migration strategies (6 R) replatforming tanımını sektör ortak diliyle karşılaştırmak için kullanılabilir.
