Oracle’ın Bulut Ortamına Migrasyon İçin Önerdiği 7 R…
Merhaba;
Daha önce yazdığım yazılarda bulutun genel tanımından, mimarisinden, “Ravello Cloud Service” den, Oracle’ın “public” bulut ortamında sunduğu hizmetlerden, Cloud@Customer yapısından bahsetmiştim. Evet teknoloji tartışmalarına baktığımızda en çok konuşulan konulardan birisi bulut yapıları. Peki, biz tamam karar verdik, bulut ortamına geçelim dedik. Bulut ortamına ne şekilde geçiş yapabileceğiz? Bugün bu yazımda, bulut ortamına geçişte 7 R yaklaşımından bahsetmek istiyorum.
Nedir bu 7 R?
“Replace, Rebuild, Refactor, Revise, Rehost, Remain, Retire” olarak 7 R’ı ifade edebiliriz. Bulut ortamına geçişte, ortamımıza en uygun gelen birden fazla yaklaşımı kullanabiliriz. 7 R, üç ana kategoride kapsanacak şekilde: “Invest”, “Optimize” ve “Manage” şeklinde bölümleniyor. Şekil 1’de görsel olarak üç kategoriyi ve içerdiği R’ları görebiliriz.
“Replace, Rebuild, Rehost, Revise, Refactor”, Gartner tarafından bulut migrasyonunda 5 R olarak tasarlanmıştır. Oracle bu 5 R’a “Remain” ve “Retire” de eklemiştir. 7 R’ın her birine biraz daha detaylı bakalım. “Invest” kategorisinde tanımlanan “Replace” de, “on-premises” çalışan uygulamamızı, migrasyon sonrası “Software-as-a-Service” aboneliğiyle alıyoruz. Eğer
ihtiyaç duyarsak PaaS sayesinde, SaaS’ı genişletebilir veya kendimize göre özelleştirebiliriz. Bu süreçte, uygulamayla ilişkili süreçleri, prosesleri SaaS ile uyumlu iş akışları şeklinde değiştirmemiz, üzerlerinde yeniden çalışmamız gerekebilir. Şekil 2, migrasyon sonrası durumumuzu ifade ediyor.
Şekil 2. “Invest” – “Replace”
“Invest” kategorisinde tanımlanan ikinci R, “Rebuild”. “Rebuild” işleminde, uygulamayı, en baştan bulut ortamında inşa ediyoruz ve diğer bulut servislerine ihtiyaç duyarsak bağlıyoruz. Şekil 3. “Rebuild” işlemini görsel olarak detaylandırıyor.
Gelelim optimizasyon kategorisine. Bu kategoride, ilk R, “Rehost”. “Rehost”, pek çok dökümanda gördüğünüz “Lift & Shift” olarak geçen yaklaşımı anlatır. Şekil 4’de görsel olarak yapıyı görüyoruz. Bu yönteme çok aşinayız, uygulama olduğu gibi alınıyor ve IaaS olarak bulut ortamına bırakılıyor. Yani şöyle demek belki daha anlaşılır kılacak, uygulamayı “on-premises” den tuttuk, kaldırdık ve bulut ortamına getirdik bıraktık. Şekil 4’de bu işlemi görsel olarak görebiliyoruz. Bulut ortamında VM oluşturuyoruz, VM’in üzerine de uygulamamızı kuruyoruz. PeopleSoft ve Oracle e-Business Suite, IaaS üzerinde “Rehost”
yapılmaya çok uygundur.
Şekil 4. “Optimization” – “Rehost”
“Revise” da ne yapıyoruz? Uygulamızı optimize ediyoruz. Örneğin revizyonunu yükseltebiliriz. Bu şekilde, “on-premises” de olmayan veya “on-premises” de olandan daha modern ek servisleri bulut ortamından uygulamamıza ekleyebiliyoruz. Örneğin, “shopping card” fonsiyonu veya kredi kartı ile işlem yapabilme fonksiyonları ekleyebilirsiniz. Hatta kredi kart validasyonu mesela ekleyebiliyorsunuz. Şekil 5’de görsel olarak bu yaklaşımı görebiliyorsunuz. Dikkat ederseniz, “on-premises” ile bulut arasında bir network’e ihtiyaç vardır. Network’un uygulamanızı etkilemeyecek şekilde yeterli olması gerektiği açıktır.
Şekil 5. “Optimization” – “Revise”
“Optimization” kısmındaki son R, “Refactor”. “Rehost” ve “Revise” ın kombinasyonu olarak düşünülebilir. Uygulamanızı hem bulut üzerinde “Rehost” ediyorsunuz hem de “Revise” ile bulutun bazı ekfonksiyonlarından yararlanıyorsunuz. Bu sayede uygulamanızı modernize ediyor ve uygulamanızın yeteneklerini genişletmiş oluyorsunuz. Şekil 6’da “Refactor” yaklaşımını görüyoruz.
Şekil 6. “Optimization” – “Refactor”
6. R, “Remain”. Uygulamanızı olduğu şekliyle “on-premises” de bırakabilirsiniz. Buluta migrasyonu yapılan uygulamalarla “on-premises” de bırakılan bu uygulama için entegrasyon gerekiyorsa, entegrasyonun performans sorunu vermeden çalıştığından emin olunması gerekiyor. 7.R ise “Retire”. Uygulamanın artık emekliye ayrılma vakti gelmiş olabilir. Bu durumda, veriyi arşivlersiniz. Uygulamayı daha sonraki herhangi bir duruma karşı arşivleyebilirsiniz. Örneğin, “SaaS” aboneliğiyle aldığınız bir uygulama, “on-premises” deki bir uygulamanın emekliye ayrılması olarakta düşünülebilir. 7R’ı bu şekilde özetleyebiliriz. Buluta migrasyonda bu kadar yöntem var çünkü her firmanın farklı stratejileri, farklı metrikleri ve hatta her uygulamaya göre farklı beklentileri mevcut. Bu nedenle firmaya göre, uygulamaya göre “case-by-case” buluta geçiş senaryoları irdelenmeli ve en doğru yönteme karar verilmelidir.
Uygulamanın bulut ortamına migrasyonu için doğru yaklaşıma karar vermemize yardımcı olacak kriterler mevcut.
Uygulamanın iş yükü, uygulamanın mevcut ekosistemdeki konumu, uygulamanın gelecekteki ekosistemdeki yerinin ne olacağı, buluta geçişi gerekli kılan iş ihtiyaçları, varış yeri için 4 kriter (“four destination criteria”) , uygulamanın anatomik yapısı, uygulamanın doğru yöntemle ve doğru bir yol ile buluta geçişini belirlemede önemlidir.
“Four destination criteria” nın içeriğini detaylandıralım. Fonksiyonel sınıflama (“Gartner Pace Layering model”), istenen kapsamı içerecek SaaS çözümü var mı, uygulamanın yaşı, özelleştirme ve entegrasyon ihtiyacının karmaşıklık seviyesi olarak içini doldurabiliriz.
Fonksiyonel sınıflama (“Gartner Pace Layering model”) de, sistemlerin iş ihtiyaçlarına göre üç kategoride inceleniyor: “systems of records”, “systems of differentiation”, “systems of innovation”. Fonksiyonelsınıflamaya göre, yukarda ifade ettiğimiz veriler kullanılarak uygulamanın hangi yöntemle SaaS, SaaS+PaaS, PaaS/IaaS, IaaS, PaaS olarak mı buluta migrasyonu yapılacağına karar verilebilir. Yazdıklarımızı özetleyecek olursak, buluta geçişte kullanılan 7 R’dan bahsettik. Her firmanın, uygulamanın farklı metrikleri, farklı iş ihtiyaçları olduğu için firmaya ve uygulamaya göre doğru kararın verilmesi
gerektiğini belirttik. “Four destination criteria” yönteminin buluta geçiş için doğru yaklaşımı belirleme konusunda yardımcı olacağını söyledik.
Umarım yazım biraz da olsa buluta geçiş ile ilgili kafadaki soru işaretlerini giderebilmiştir. Yeni bir yazıda
tekrar görüşmek üzere.
Asiye Yiğit – 1 Nisan 2018
Leave A Comment