Buluta geçiş planı: 6R ile uygulama bazlı karar verme

Buluta geçiş neden bir sunucu taşıma işi değil, bir portföy kararıdır?

Buluta geçiş planı, "sunucuları oraya götürelim" cümlesiyle başlarsa genellikle yarıda kalır. Gerçek soru şudur: kurumun elindeki her uygulama için buluta taşımanın hangi biçimi iş değeri üretir, hangisi yalnızca masraf ve risk yaratır? Bu yüzden geçiş stratejisi önce bir envanter ve karar işidir, taşıma işi ancak bunun ardından gelir.

Strateji belgesi şu sorulara cevap verir: neden taşıyoruz (maliyet, çeviklik, dayanıklılık, veri merkezi sözleşmesinin bitmesi gibi gerekçeler), neyi taşıyoruz ve ne sırayla taşıyoruz. Gerekçe net değilse sonradan başarı ölçülemez; bir ekip hızı, başka bir ekip maliyeti hedefliyorsa aynı geçişi farklı biçimlerde yönetmeye çalışırlar.

6R yaklaşımı nedir, altı seçenek ne anlama gelir?

6R, her uygulama için seçilebilecek altı geçiş biçimini adlandıran yaygın bir çerçevedir. Seçenekler şunlardır:

• Rehost (lift and shift): Uygulama olduğu gibi, değiştirilmeden sanal makine olarak buluta taşınır. En hızlı yoldur, bulutun getirdiği esnekliğin çoğunu kullanmaz.
• Replatform: Çekirdek mimari korunur ama bazı bileşenler yönetilen hizmete geçirilir; örneğin kendi kurduğunuz veritabanı sunucusu yerine sağlayıcının yönetilen veritabanı hizmeti kullanılır.
• Repurchase: Uygulama terk edilir, yerine hazır bir hizmet olarak yazılım (SaaS) ürünü alınır.
• Refactor: Uygulama bulut doğal mimariyle yeniden tasarlanır. En pahalı ve en uzun yoldur, en yüksek kazancı da en çok burada beklenir.
• Retire: Kimsenin kullanmadığı ya da artık gerekmeyen uygulama kapatılır.
• Retain: Uygulama şimdilik olduğu yerde kalır; mevzuat, gecikme ya da hazır olmama gibi sebepler bu kararı doğurur.

Bu listenin değeri sınıflandırmanın kendisinde değil, her uygulamaya hangi harfin verileceğini gerekçelendirmenizi zorunlu kılmasındadır.

Adım adım: envanterden karara nasıl gidilir?

Uygulamalı bir geçiş planı genellikle şu akışla ilerler.

Birinci aşama keşiftir. Sunucular, uygulamalar, veritabanları, aralarındaki ağ bağımlılıkları ve her uygulamanın iş sahibi listelenir. Bağımlılıkların görünmemesi geçişlerin en sık patladığı yerdir: taşınan uygulama, ayakta kalan eski bir dosya paylaşımına ya da ortak bir veritabanına gizlice bağlıysa taşıma sonrası sessizce bozulur.

İkinci aşama değerlendirmedir. Her uygulama; iş kritikliği, teknik borç, lisans koşulları, veri hassasiyeti ve mevzuat yükümlülükleri gibi ölçütlerle puanlanır. Puanlama tablosu ekip içinde tartışılıp sabitlenir ki kararlar kişiye göre değişmesin.

Üçüncü aşama karardır. Her uygulama altı seçenekten birine atanır ve gerekçesi yazılır. Dördüncü aşamada maliyet modeli çıkarılır: taşıma emeği, çift çalışma dönemi, hedef ortamın işletme maliyeti ve eski ortamın kapatılmasıyla gerçekleşecek tasarruf birlikte hesaplanır. Yalnızca bulut faturasına bakan bir iş gerekçesi çoğu zaman eksiktir.

Taşıma dalgaları nasıl planlanır?

Bütün uygulamaları aynı anda taşımak mümkün değildir; plan dalgalara bölünür. İlk dalga, bilinçli olarak düşük riskli ve birbirinden görece bağımsız uygulamalardan seçilir. Amaç yalnızca bu uygulamaları taşımak değil, süreci denemektir: ağ bağlantısı, kimlik, izleme, yedekleme ve yetkilendirme akışı ilk dalgada sınanır.

Sonraki dalgalar, bağımlılık grupları temel alınarak oluşturulur. Birbirine sıkı bağlı uygulamalar aynı dalgada taşınır; aksi halde ortamlar arasında yüksek gecikmeli geçici bağlantılar kurmak gerekir. Her dalga için bir kesinti penceresi, geri dönüş (rollback) planı ve kabul testleri önceden yazılır.

Bir dalga bittiğinde çıkarılan dersler bir sonraki dalganın planına işlenir. Dalga planı sabit bir belge değil, her dalgadan sonra güncellenen bir takvimdir.

Örnek senaryo: bir perakende şirketinin portföyü

Örneğin bir perakende şirketinin envanterinde şunlar var: eski bir stok raporlama aracı, sipariş yönetim sistemi, kurumsal e-posta, yıllık kampanyalarda yük alan bir web sitesi ve artık kullanılmayan bir kampanya uygulaması.

Karar şöyle çıkabilir. Kullanılmayan kampanya uygulaması Retire ile kapatılır. E-posta, Repurchase ile hazır hizmete geçer. Stok raporlama aracı, sağlayıcı desteği bittiği için Rehost ile hızla taşınır; ileride yeniden ele alınmak üzere not düşülür. Web sitesi, yük dalgalanmasından fayda göreceği için Refactor adayıdır ama hemen yapılmaz; önce Replatform ile veritabanı yönetilen hizmete alınır. Sipariş yönetim sistemi ise mağaza sistemlerine yakın çalışması gerektiği için Retain olarak kalır ve değerlendirme bir sonraki döneme bırakılır.

Burada dikkat çekici olan, tek bir stratejinin tüm portföye uygulanmamasıdır. Her karar kendi gerekçesini taşır.

Sık yapılan hatalar ve nasıl önlenir?

• Envanteri eksik çıkarmak: Gölge BT ve unutulmuş test ortamları geçiş sonrasında sürpriz fatura ve güvenlik açığı olarak geri döner. Ağ trafiğini izleyen keşif araçlarıyla envanter doğrulanır.
• Her şeyi Rehost etmek: Hız kazandırır ama maliyeti beklentiden yüksek bırakabilir; bulut kaynakları ihtiyaçtan büyük kurulduğu için sürekli ödeme yapılır. Taşıma sonrası boyut ayarlaması planlanmalıdır.
• Her şeyi Refactor etmeye kalkmak: Program yıllarca uzar, iş değeri geç görünür. Refactor, gerçekten fayda vaat eden az sayıdaki uygulamaya ayrılır.
• Çift çalışma dönemini bütçelememek: Eski ve yeni ortam bir süre birlikte çalışır; bu dönemin maliyeti iş gerekçesinde yer almazsa program tasarruf beklentisiyle yanlış başlar.
• Ekip yetkinliğini unutmak: Bulutta işletme farklı beceri ister. Geçiş başlamadan önce operasyon ekibinin eğitimi plana girer.
• Eski ortamı kapatmamak: Taşınan sistemin eskisi açık bırakılırsa tasarruf hiç gerçekleşmez.

Nasıl öğrenilir, nereden başlanır?

Başlangıç noktası, bulut sağlayıcılarından birinin temel hizmetlerini (hesaplama, depolama, ağ, kimlik) öğrenmektir; geçiş kararları bu bileşenleri tanımadan sağlıklı verilemez. Sonraki adım, kendi çalıştığınız kurumdan küçük bir uygulamayı alıp "bunu altı seçenekten hangisiyle taşırdım ve neden" sorusunu yazıya dökmektir. Gerekçeyi yazmak, çerçeveyi ezberlemekten çok daha öğreticidir.

İleri düzeyde maliyet modellemesi, iş gerekçesi hazırlama, landing zone kurulumu ve geçiş programı yönetişimi öne çıkar. Mindset kataloğunda bu konuya doğrudan odaklanan programlar var: Buluta Geçiş Stratejisi ve 6R Değerlendirme Çerçevesi programının modülleri uygulama envanteri ve keşif, değerlendirme ve puanlama, 6R karar modeli, maliyet modellemesi, dalga planlama ve risk yönetimi başlıklarından oluşuyor. Bulut Geçiş Stratejisi: 6R Yaklaşımı ve Taşıma Dalgalarının Planlanması programı keşif çalışması, iş yükü sınıflandırma, karar atölyesi ve geçiş programının yönetişimini işliyor. Uygulama Bulut Taşıma (Cloud Migration) Desenleri programında ise landing zone, veri taşıma ve entegrasyon konuları ele alınıyor.