Geçtiğimiz yıl, BT ekiplerinin genel buluta taşıdığı kurumsal uygulamaların sayısında hızlı bir artış yaşandı. Son dönemde en kritik yaşamsal uygulamalarını, veritabanlarını, ERP yazılımlarını bile taşıdıkları görülüyor ve bunların arasında SQL Server, SAP HANA ve Oracle da yer alıyor.
BT ekipleri, katı hizmet düzeyi anlaşmalarını karşılama baskısı altındayken uygulamaları genel buluta taşımaya çalışıyor ve bunların pek çoğu beklenmedik zorluklarla karşı karşıya kalıyor.
SIOS Technology Müşteri Deneyimi Başkan Yardımcısı Cassius Rhue, bu zorluklardan bazılarının nasıl tanımlanacağı ve bunlardan kaçınmanın yollarını anlatıyor.
Veri Noktası 1: Buluta geçiş planlarının yüksek kullanılabilirliğe sahip olduğundan emin olun.
Herhangi bir önemli BT projesinin başarısı için kapsamlı planlamanın gerekli olduğu bir sır değil. Bununla birlikte, buluta geçiş planları genellikle önemli bir faktörü dikkate almaz: Yüksek kullanılabilirlik koruması. Ayrıntılı bir bulut planı, paydaşların tüm ekiplerini, teknoloji gereksinimlerini ve son kullanıcı beklentilerini, tanımlanan kilometre taşları veya proje aşamaları boyunca ilerleyen koordineli bir çabayla getirir.
İyileştirme süresi ve kurtarma noktası için son kullanıcı beklentilerini ve iş hedeflerini hesaba katarak, iyi tasarlanmış bir plan son tarihlerin karşılanmasını ve gereksiz risklerin önlenmesini sağlar. Buluta geçiş planının, uygulama düzeyinde yüksek kullanılabilirlik ve felaket kurtarma ile ilgili tüm adımları ve bağımlılıkları dikkate aldığından emin olmak gerekir.
Veri Noktası No. 2: Şirket içi yapılandırmalar bulutta aşırı yükleme yapabilir.
Şirket içi yüksek kullanılabilirlik yapılandırmasını buluta kopyalamak kimi zaman ciddi bir hata olabilir. Bunun yerine, şirket içi yapılandırmanızın sunduğu işlevlerin ve hizmet seviyelerinin tam tanımından başlayın ve ardından bu gereksinimleri karşılayan bir bulut ortamı tasarlayın. Gözünüz sürekli ağ ve depolama ortamınızın, aynı zamanda da buluttaki sanal sunucu kaynaklarınızın üzerinde olsun; mühendislik süreçlerine gereğinden fazla maruz kalmış (over-engineered) bileşen ve tasarımların eski (legacy) şirket içi ortamınızdan ileri seviyeye taşınmamasına dikkat edin.
Veri Noktası No: 3: Kaynaklarınızı akılcı kullanın, kaynak israfı yapmayın ama tercihlerinizde dikkatli olun.
Bulut kullanımına dayalı ücretlendirmeler, şirket içi ortamlarda işletme giderlerinin tahmin edilmesinde BT ekipleri için rahatsız edici olabilir. Ancak, bulut maliyetlerini kontrol altına almak için en başta yetersiz kaynak tahsisiyle yola çıkılması, uzun vadede daha fazla maliyete neden olabilir. Yetersiz veya düşük performanslı diskler, yetersiz CPU veya bellek kaynakları kullanıldığında bulut ücretlerinden yapılacak tasarruf, çok az düğüm (node) içeren kümeler (cluster) oluşturur. Yaşanabilecek sorunların giderilmesinin maliyeti yüksek olabilir. Kullanıcı Kabul Testi (UAT) başladığında yük devretme sırasında beklenmedik sonuçlara neden olabilir. Sanal makinelerin yeniden boyutlandırılması kolaydır, ancak boyut sorunları hemen görülemeyebilir ve sorunları gidermeye çalışırken gecikmeler yaşanabilir. Yetersiz kaynaklarla yola çıkmak bütçelerin gerçekçi olmaması ve zaman içinde beklenmedik faturalarla karşılaşılması anlamına gelebilir.
Veri Noktası 4: Süresi geçmiş tedarik süreçleri
Bulutun benimsenmesi, BT’deki değişim hızını artırdı. Uzun süreçler tipik olarak talep, teklif gerektiren satın alma, örnek boyutlandırma, kurumsal onaylar, sunucu hazırlama yapılandırması, test etme ve üretime aktarma için gerekli adımları içerir. Depolama, ağ ve bilgi işlem kaynakları, geleneksel tedarik süreçlerine kolayca uymayan daha hızlı ve daha esnek yollarla bulutta tedarik edilir. Süresi geçmiş tedarik süreçleri, bulut geçişinde gereksiz gecikmeler anlamına gelebilir.
Veri Noktası No.5: Geç HA / DR planlaması
Bir buluta geçiş planı yapmak genellikle taşınan uygulamayla başlar. Çoğu zaman, yüksek kullanılabilirlik ve felaket kurtarma ihtiyacı en sona bırakılır. Verimli, uygun maliyetli HA / DR (High Availability / Disaster Recovery) planlaması, uygulama için bir kurumsal lisans satın almaktan daha fazlasını gerektirir. Dikkatli sistem tasarımı, bir buluta geçiş sürecinin hızını, verimliliğini ve maliyet etkinliğini artırabilir. Kapasite, kritiklik, RTO / RPO, artıklık ve düzeltme gereksinimlerinin dahil edilmesi gerekir. Planlama ayrıca risklere karşı güvenlik açığını, potansiyel tek hata noktalarını ve eksik katmanları ve uygulama kurtarma ve dayanıklılık düzeylerini de dikkate almalıdır.
Veri Noktası No. 6: Derinlemesine ve sık test yapın
Tipik bir geçiş planında, “git / gitme” için son karar noktası, aşamalandırma sunucularında bir grup kullanıcı kabul testidir. İlk test başarısız olursa, programdaki gecikmeyi telafi etmek için sonraki testler genellikle atlanır. Atlanan testler tipik olarak yedekleme ve güvenlik yazılımının en yeni işletim sistemi ve destekleyici yamalar ile entegre edilmesiyle ilgilidir. Testteki simüle edilmiş yük, çekirdek hatası, CPU veya bellek sağlama ve depolama düzeni ve kapasite sorunları dahil olmak üzere herhangi bir yaygın sorunu tetiklerse proje gecikebilir ve karmaşık hale gelebilir. Oyunun sonundaki testlerin artık müşteri güvenini artırmak, daha kapsamlı bir test ve doğrulama planı üzerinde çalışmak, olası yeniden boyutlandırma ve mimari değişikliklerini dahil etmek ve yazılım ve işletim sistemi düzeltmelerini uygulamak için geriye doğru izlemesi gerekir.
Kaynak: eweek.com
Makalenin orijinali için: https://www.eweek.com/storage/how-to-avoid-impediments-to-migrating-critical-apps-to-the-cloud
Comments