Rasionalisasi Cloud

Pelajari tentang rasionalisasi cloud, proses mengevaluasi aset untuk menentukan cara terbaik bermigrasi atau memodernisasi setiap aset di cloud. Untuk informasi selengkapnya tentang proses rasionalisasi, lihat Apa itu real estat digital.

Konteks rasionalisasi

Lima Rs rasionalisasi yang tercantum dalam artikel ini adalah cara yang bagus untuk memberi label keadaan masa depan yang potensial untuk setiap beban kerja yang dianggap sebagai kandidat cloud. Masukkan proses pelabelan ini ke dalam konteks yang benar sebelum Anda mencoba merasialisasi lingkungan. Untuk memberikan konteks tersebut, tinjau mitos berikut:

Mitos: Sangat mudah untuk membuat keputusan rasionalisasi di awal proses

Rasionalisasi yang baik membutuhkan pengetahuan mendalam tentang beban kerja dan aset terkait, seperti aplikasi, infrastruktur, dan data. Yang paling penting, keputusan rasionalisasi yang baik membutuhkan waktu. Kami menyarankan agar Anda menggunakan proses rasionalisasi inkremental.

Mitos: Adopsi cloud harus menunggu semua beban kerja dirasionalisasi

Ketika seluruh portofolio TI atau bahkan satu pusat data dirasionalisasi, itu dapat menunda realisasi nilai bisnis berdasarkan bulan atau bahkan tahun. Hindari rasionalisasi penuh jika memungkinkan. Sebaliknya, gunakan Kekuatan 10 pendekatan untuk merilis perencanaan untuk membuat keputusan bijak tentang 10 beban kerja berikutnya yang dijadwalkan untuk adopsi cloud.

Mitos: Pertimbangan bisnis harus menunggu semua beban kerja dirasionalisasi

Untuk mengembangkan pertimbangan bisnis untuk upaya adopsi cloud, buat beberapa asumsi dasar di tingkat portofolio. Ketika motivasi selaras dengan inovasi, asumsikan arsitektur ulang. Jika mereka selaras dengan migrasi, asumsikan penghostingan ulang. Asumsi ini dapat mempercepat proses pertimbangan bisnis. Selama fase penilaian siklus adopsi setiap beban kerja, asumsi kemudian ditantang, dan anggaran disempurnakan.

Sekarang tinjau lima Rs rasionalisasi berikut untuk membiasakan diri dengan proses jangka panjang. Saat mengembangkan rencana adopsi cloud Anda, pilih opsi yang paling sesuai dengan motivasi, hasil bisnis, dan lingkungan kondisi Anda saat ini. Tujuan dalam rasionalisasi properti digital adalah untuk menetapkan garis besar, bukan untuk merasionalisasi setiap beban kerja.

Lima R rasionalisasi

Lima R rasionalisasi berikut menjelaskan opsi paling umum untuk rasionalisasi.

Menentukan host kembali

Juga dikenal sebagai migrasi lift and shift , upaya rehost memindahkan aset status saat ini ke penyedia cloud yang dipilih dengan perubahan minimal pada arsitektur keseluruhan.

Driver umum mungkin untuk:

• Kurangi biaya modal.
• Kosongkan ruang pusat data.
• Capai pendapatan investasi yang cepat di cloud.

Faktor analisis kuantitatif adalah:

• Ukuran VM, termasuk CPU, memori, dan penyimpanan.
• Dependensi, seperti lalu lintas jaringan.
• Kompatibilitas aset.

Faktor analisis kualitatif adalah:

• Toleransi untuk perubahan.
• Prioritas bisnis.
• Peristiwa bisnis penting.
• Proses dependensi.

Menentukan faktor kembali

Opsi platform as a service (PaaS) dapat mengurangi biaya operasional yang terkait dengan banyak aplikasi. Ini adalah ide yang baik untuk sedikit refaktor aplikasi agar sesuai dengan model berbasis PaaS.

Refaktor juga mengacu pada proses pengembangan aplikasi refaktor kode untuk memungkinkan aplikasi untuk memberikan peluang bisnis baru.

Driver umum yang mungkin termasuk:

• Pembaruan yang lebih cepat dan lebih pendek.
• Portabilitas kode.
• Efisiensi cloud yang lebih besar untuk membantu sumber daya, kecepatan, biaya, dan operasi terkelola.

Faktor analisis kuantitatif adalah:

• Ukuran aset aplikasi, seperti CPU, memori, dan penyimpanan.
• Dependensi, seperti lalu lintas jaringan.
• Lalu lintas pengguna, seperti tampilan halaman, waktu di halaman, dan waktu pemuatan.
• Platform pengembangan, seperti bahasa, platform data, dan layanan tingkat menengah.
• Database yang mencakup CPU, memori, penyimpanan, dan versi.

Faktor analisis kualitatif adalah:

• Investasi bisnis yang berkelanjutan.
• Opsi atau garis waktu bursting.
• Dependensi proses bisnis.

Merancang ulang

Beberapa aplikasi penuaan tidak kompatibel dengan penyedia cloud. Ketidakcocokan ini adalah karena keputusan arsitektur yang dibuat ketika aplikasi dibangun. Dalam kasus ini, aplikasi mungkin perlu didesain ulang sebelum transformasi.

Dalam kasus lain, aplikasi yang kompatibel dengan cloud, tetapi bukan cloud-native, dapat menciptakan efisiensi biaya dan efisiensi operasional dengan menata ulang solusi ke dalam aplikasi cloud-native.

Driver umum yang mungkin termasuk:

• Skala aplikasi dan kelincahan.
• Adopsi kemampuan cloud baru yang lebih mudah.
• Campuran dari tumpukan teknologi.

Faktor analisis kuantitatif adalah:

• Ukuran aset aplikasi, seperti CPU, memori, dan penyimpanan.
• Dependensi, seperti lalu lintas jaringan.
• Lalu lintas pengguna, seperti tampilan halaman, waktu di halaman, dan waktu pemuatan.
• Platform pengembangan, seperti bahasa, platform data, dan layanan tingkat menengah.
• Database yang mencakup CPU, memori, penyimpanan, dan versi.

Faktor analisis kualitatif adalah:

• Untuk menumbuhkan investasi bisnis.
• Biaya operasional.
• Perulangan umpan balik potensial dan investasi DevOps.

Membangun kembali

Dalam beberapa skenario, delta yang harus diatasi untuk terus membawa aplikasi bisa terlalu besar untuk membenarkan investasi lebih lanjut. Masalah ini terutama berlaku untuk aplikasi yang sebelumnya memenuhi kebutuhan bisnis tetapi sekarang tidak didukung dengan proses bisnis saat ini. Untuk mengatasi masalah ini, buat basis kode baru untuk menyelaraskan dengan pendekatan cloud-native.

Driver umum mungkin untuk:

• Percepat inovasi.
• Bangun aplikasi lebih cepat.
• Kurangi biaya operasional.

Faktor analisis kuantitatif adalah:

• Ukuran aset aplikasi, seperti CPU, memori, dan penyimpanan.
• Dependensi, seperti lalu lintas jaringan.
• Lalu lintas pengguna, seperti tampilan halaman, waktu di halaman, dan waktu pemuatan.
• Platform pengembangan, seperti bahasa, platform data, dan layanan tingkat menengah.
• Database yang mencakup CPU, memori, penyimpanan, dan versi.

Faktor analisis kualitatif adalah:

• Menolak kepuasan pengguna akhir.
• Proses bisnis yang dibatasi oleh fungsionalitas.
• Potensi keuntungan biaya, pengalaman, atau pendapatan.

Replace

Solusi biasanya diimplementasikan dengan menggunakan teknologi dan pendekatan terbaik yang tersedia pada saat itu. Terkadang aplikasi perangkat lunak sebagai layanan (SaaS) dapat menyediakan semua fungsi yang diperlukan untuk aplikasi yang dihosting. Dalam skenario ini, beban kerja dapat dijadwalkan untuk penggantian di masa mendatang, yang menghapusnya dari upaya transformasi.

Driver umum mungkin untuk:

• Standarisasi seputar praktik terbaik industri.
• Mempercepat adopsi pendekatan berbasis proses bisnis.
• Alokasikan kembali investasi pengembangan ke dalam aplikasi yang membuat diferensiasi atau keunggulan kompetitif.

Faktor analisis kuantitatif adalah:

• Pengurangan biaya pengoperasian umum.
• Ukuran VM, termasuk CPU, memori, dan penyimpanan.
• Dependensi, seperti lalu lintas jaringan.
• Aset yang akan dihentikan.
• Database yang mencakup CPU, memori, penyimpanan, dan versi.

Faktor analisis kualitatif adalah:

• Analisis manfaat biaya dari arsitektur saat ini versus solusi SaaS.
• Peta proses bisnis.
• Skema data.
• Proses kustom atau otomatis.

Langkah berikutnya

Anda dapat menerapkan lima R rasionalisasi ini ke real estat digital untuk membantu Anda membuat keputusan rasionalisasi tentang keadaan masa depan setiap aplikasi.

Apa itu real estat digital