Lift and shift, mevcut sanal makine veya sunucuyu uygulama koduna dokunmadan bulut ortamına kopyalama yaklaşımıdır. İlk geçiş dalgasında ekip genelde düşük riskli iş yüklerini seçer ve taşıma süresini kısaltır. Kısa cevap şudur. İlk dalgada en sık görülen riskler taşınan yapılandırmanın bulut ağına uyumsuzluğu, yerel lisans ve kimlik bağımlılıkları, izleme ve yedekleme ajanlarının eksik kalması ve geri dönüş adımlarının yazılmamasıdır. Taşıma tamamlanmış görünse bile üretim davranışı değişebilir.
Bu metin buluta geçiş danışmanlığı hizmet sayfasını destekler. Paket veya fiyat listesi sunmaz. Geçiş öncesi envanter ve bağımlılık çıkarma adımlarını envanter ve bağımlılık haritalama yazısında, yerel sanal makine ile bulut arasındaki operasyon farklarını sanal sunucu ile bulut sunucu farkları metninde ele aldık.
Hızlı Özet
Lift and shift kodu yeniden yazmaz. Disk, işletim sistemi ve uygulama katmanı mümkün olduğunca aynı kalır. Bu yüzden ilk dalga planı hız odaklıdır ve teknik borç buluta taşınır.
İlk dalgada risk matrisi şu başlıklarda toplanır. Ağ ve güvenlik grubu uyumu, kimlik ve dizin bağımlılığı, lisans ve destek koşulları, yedekleme ve izleme ajanları, performans ve depolama profili, geri dönüş ve doğrulama planı. Her madde için taşıma öncesi ve sonrası kontrol listesi yazılmalıdır.
Leon-X bulut altyapısının sahibi değildir. Geçiş dalgası seçimi, bağımlılık analizi ve runbook hazırlığında operasyon ekibinizle çalışır.
İçindekiler
- Lift and Shift ile Replatforming Ayrımı
- İlk Dalga Seçim Kriterleri
- Ağ ve Güvenlik Uyumsuzluğu
- Kimlik, Lisans ve Yerel Bağımlılıklar
- Yedekleme, İzleme ve Ajan Boşlukları
- Performans ve Depolama Sürprizleri
- Geri Dönüş ve Doğrulama Eksikliği
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, veri merkezinde sunucu altyapısı.
Lift and Shift ile Replatforming Ayrımı
Lift and shift taşıma aracı veya disk kopyası ile çalışır. Uygulama mimarisi yerelde nasıl duruyorsa bulutta da benzer şekilde ayağa kalkması beklenir. Replatforming ise veritabanı motorunu, mesaj kuyruğunu veya depolama katmanını buluta özgü bir servisle değiştirmeyi içerir. Refactor kod ve yapılandırmayı bulut yerel desenlere göre yeniden düzenler.
İlk dalga çoğu kurumda lift and shift ile başlar çünkü takvim ve eğitim maliyeti daha öngörülebilirdir. Bu seçim yanlış değildir. Ancak stratejinin adı gizlenirse ekip taşımanın borcu sıfırladığını sanır. Borç buluta taşınır ve sonraki dalgalarda replatforming kararı gecikir.
IaaS sorumluluk paylaşımı lift and shift sonrası hangi katmanın hâlâ sizin sorumluluğunuzda olduğunu hatırlatır. İşletim sistemi yamaları, ağ kuralları ve uygulama yapılandırması çoğu senaryoda kurum tarafında kalır.
İlk Dalga Seçim Kriterleri
İlk dalgaya alınacak iş yükü düşük iş etkisi ve net geri dönüş yolu olan sistemlerden seçilir. Test ortamları, raporlama sunucuları veya dış entegrasyonu az uygulamalar tipik örneklerdir.
Seçimde şu sorular yanıtlanmalıdır. Taşıma penceresi içinde kimlik servisi kesilir mi. Yerel dosya paylaşımı veya sabit IP bağımlılığı var mı. Lisans taşıma veya yeniden aktivasyon ister mi. Üretim trafiği bu sisteme bağlı mı.
Bulut sunucu operasyon modeli ilk dalgada kapasite ve ağ tasarımının nasıl okunacağını gösterir. Envanter çıkmadan dalga listesi yazmak eksik bağımlılık bırakır.
Ağ ve Güvenlik Uyumsuzluğu
Yerel veri merkezinde katman üç ağ segmentasyonu ve güvenlik duvarı kuralları yıllar içinde birikir. Lift and shift ile gelen sanal makine aynı IP planını ve port beklentisini taşır. Bulut tarafında güvenlik grubu ve alt ağ tasarımı farklıdır.
İlk dalgada sık görülen senaryo şudur. Uygulama sunucusu buluta geçer, veritabanı yerelde kalır. Güvenlik grubu veritabanı portunu açmaz veya yalnızca eski alt ağ aralığını tanır. Bağlantı zaman aşımı ile başarısız olur ve ekip performans sorunu arar.
Yerel isim çözümlemesine bağlı servisler bulut DNS yapısına taşınmadan kopyalanır. Sabit host adı veya elle yazılmış IP adresi yeni ortamda çözülmez. Taşıma öncesi trafik dinleme ve port listesi bu riski azaltır.
Kimlik, Lisans ve Yerel Bağımlılıklar
Active Directory veya LDAP sorgusu uygulama içine gömülü değilse bile işletim sistemi oturumu dizin sunucusuna bağlıdır. İlk dalgada kimlik replikasyon gecikmesi veya güven ilişkisi eksikliği oturum hataları üretir.
Lisanslama modeli donanım kimliği, MAC adresi veya yerel lisans sunucusuna bağlı olabilir. Bulut sanal makinesi yeni kimlik alır ve lisans geçersiz kalır. Taşıma planına lisans sağlayıcısı ile doğrulama adımı eklenmelidir.
Yerel yazıcı, seri port veya USB anahtarı bağımlılığı olan uygulamalar lift and shift ile uyumsuzdur. Bu iş yükleri ilk dalgadan çıkarılmalı veya geçiş modeli değiştirilmelidir.
Yedekleme, İzleme ve Ajan Boşlukları
Yerelde çalışan yedekleme ve izleme ajanları bulut ağında farklı çıkış noktası ve kimlik bilgisi kullanır. Taşıma sonrası ajan kurulu görünür ancak yedekleme sunucusuna ulaşamaz. İlk dalgada yedek job durumu ve son başarılı çalışma zamanı kontrol edilmelidir.
Merkezi log toplama ve güvenlik izleme bağlantıları yerel ağa özel adreslerle tanımlı olabilir. Buluta taşınan sunucu log göndermez ve izleme boşluğu oluşur. Taşıma kontrol listesine ajan yeniden kayıt ve test alarmı eklenmelidir.
Performans ve Depolama Sürprizleri
Yerel SAN veya NVMe dizisi ile bulut block storage farklı gecikme ve IOPS profili sunar. Lift and shift disk boyutunu korur ancak performans karakteristiği değişir. Veritabanı veya dosya indeksleme yoğun uygulamalar ilk dalgada yavaşlık yaşayabilir.
Block ve file storage seçimi taşıma sonrası disk tipi gözden geçirmeyi hatırlatır. İlk dalga raporuna taşıma öncesi ve sonrası temel gecikme ölçümü notu eklenmelidir. Kesin performans taahhüdü bu yazıda verilmez.
Geri Dönüş ve Doğrulama Eksikliği
İlk dalga düşük riskli sayıldığı için geri dönüş planı atlanır. Taşıma başarısız olduğunda ekip hangi snapshot veya kopyadan geri döneceğini bilmez. DNS veya yük dengeleyici kaydı değiştiyse geri alma sırası yazılmalıdır.
Doğrulama yalnızca ping veya oturum açma ile bitmemelidir. İş biriminin tanıdığı örnek işlem, arka plan job ve entegrasyon noktası test edilmelidir. Sonuçlar taşıma runbook dosyasına tarih damgası ile kaydedilir.
Yaygın Hatalar
Tüm sunucuları aynı hafta sonu lift and shift ile taşımaya çalışmak ilk dalga disiplinini bozar.
Bağımlılık haritası olmadan üretim veritabanına bağlı uygulamayı tek başına taşımak ağ gecikmesi ve kesinti riskini artırır.
Güvenlik grubu ve kimlik adımlarını taşıma gecesi ilk kez denemek geri alma ihtiyacını büyütür.
Yedekleme ve izlemenin çalıştığını varsaymak veri koruma boşluğu bırakır.
Lift and shift sonrası optimizasyonu hiç planlamamak teknik borcu kalıcı hale getirir.
Kontrol Listesi
- İlk dalga iş yükü listesi iş birimi onayı ile sabitlendi.
- Bağımlılık haritası ve taşıma sırası yazıldı.
- Ağ, güvenlik grubu ve DNS değişiklikleri önceden test edildi.
- Kimlik ve lisans taşıma adımları doğrulandı.
- Yedekleme ve izleme ajanları yeni ortamda job ve alarm üretiyor.
- Taşıma öncesi ve sonrası temel performans notu alındı.
- Geri dönüş ve işlev doğrulama adımları runbook içinde numaralandı.
- Sonraki dalga için replatforming veya optimizasyon kararı takvime işlendi.
Leon-X ile Sonraki Adım
Leon-X mevcut iş yüklerinizi dalga planına ayırır. Lift and shift için ağ, kimlik ve operasyon kontrol listelerini geçiş runbook dosyanıza işler. Buluta geçiş danışmanlığı kapsamında taşıma öncesi analiz ve taşıma sonrası operasyon koordinasyonu sunar. Altyapı sahibi değildir. Keşif için iletişime geçin.
Sık Sorulan Sorular
Lift and shift her zaman ilk adım mı olmalıdır?
Zorunlu değildir. Bazı iş yükleri doğrudan replatforming ile daha uygun olabilir. İlk dalga genelde öğrenme ve prosedür doğrulama için lift and shift seçer.
İlk dalgada kaç sunucu taşınmalıdır?
Tek bir sayı vermek yerine bağımlılık grubu ve geri dönüş kapasitesi belirler. Ekip aynı pencerede doğrulayabileceği kadar sistem seçmelidir.
Taşıma aracı başarılı görünüyorsa risk bitti mi sayılır?
Hayır. Uygulama, kimlik, yedekleme ve entegrasyon testleri tamamlanmadan dalga kapanmamalıdır.
Lift and shift maliyeti düşürür mü?
Kısa vadede geliştirme eforu azalır. Optimize edilmeyen kaynak ve operasyon borcu orta vadede maliyet görünürlüğünü etkileyebilir. Finansal model sözleşme ve kullanım verisi ile değerlendirilir.
Sonuç
Lift and shift ilk geçiş dalgasında hız sağlar ancak riskleri sıfırlamaz. Ağ uyumu, kimlik, lisans, yedekleme ve geri dönüş planı taşıma ile birlikte yazılmalıdır. Dalga disiplini korunduğunda ekip bulutta güvenli öğrenme alanı kazanır ve sonraki replatforming kararlarını veriye dayandırır. Geçiş yol haritası için buluta geçiş danışmanlığı sayfasına bakabilirsiniz.
Kaynaklar
- Leon-X içerik ve claim politikası,
docs/research/leonx-seo-claim-evidence.md - Buluta geçiş kuyruk kaydı,
blog_konulari.mdStage 5
