Modernisasi Cloud Apps Anda dengan Formula 7R Ini!
Ketika seseorang mengatakan mereka ingin memodernisasi aplikasi untuk cloud, apa sebenarnya yang mereka maksud? Pengguna memiliki satu perspektif: Mereka berharap modernisasi menghadirkan pengalaman yang lebih baik, keandalan yang lebih tinggi, kinerja yang lebih cepat, dan idealnya, penyebaran fitur yang lebih sering. Arsitek, pengembang perangkat lunak, dan mesin devops memiliki jawaban berbeda tentang apa arti modernisasi aplikasi. Itu karena ada beberapa pendekatan teknis untuk modernisasi aplikasi, dan pilihan optimal tidak selalu jelas.
Misalnya, aplikasi alur kerja yang digunakan oleh lusinan pengguna yang ditulis dalam versi terbaru Java dan MySQL dapat dengan mudah diangkat dan dialihkan ke cloud publik. Pendekatan ini memerlukan sedikit penulisan ulang kode tetapi kemungkinan membutuhkan perubahan konfigurasi, memperbarui CI/CD, dan menjalankan kembali otomatisasi pengujian. Di sisi lain, jika aplikasi yang sama ditulis dalam Cobol dan berjalan di mainframe, ada kemungkinan aplikasi tersebut perlu diperbaiki sebelum berjalan di cloud.
Masih ada beberapa opsi teknis di antara lift and shift dan perombakan total; ini dikenal sebagai 7 Rs modernisasi aplikasi cloud. Ada perbedaan kecil dari satu sumber ke sumber lainnya, tetapi keduanya mewakili opsi modernisasi tingkat atas dengan baik.
Faktor yang Perlu Dipertimbangkan
Organisasi memiliki ratusan hingga ribuan aplikasi lama, aplikasi dengan hutang teknis yang signifikan, dan lainnya dengan manfaat pengguna atau bisnis dalam migrasi. Arsitek dan pimpinan teknis sering menggunakan pendekatan modernisasi yang berbeda tergantung pada kebutuhan bisnis dan tantangan teknis.
Masalah pertama yang harus dipertimbangkan adalah dampak pada operasi bisnis dan pengguna. Aplikasi mission-critical, penggunaan lebih tinggi akan membutuhkan pendekatan teknis yang berbeda dari aplikasi yang digunakan secara episodik. Setiap modernisasi akan membutuhkan komunikasi dengan pengguna, pengujian, dan pelatihan orang tentang perubahan alur kerja.
Salah satu tantangan terbesar yang dihadapi organisasi adalah mengidentifikasi dan mengetahui aplikasi mana yang harus diangkat dan digeser, difaktorkan ulang, atau ditulis ulang dan dalam urutan apa. Modernisasi aplikasi memerlukan kecepatan penyeimbangan yang cermat ke pasar dengan skalabilitas, pengoptimalan biaya, pengurangan utang teknis di masa mendatang, dan waktu henti operasional.
Ada banyak manfaat dari migrasi cloud, termasuk mengurangi biaya, meningkatkan keamanan dan ketahanan, dan mempermudah penskalaan pengiriman layanan untuk pelanggan. Untuk tim pengembang, ini dapat meningkatkan ketangkasan dan produktivitas staf, memungkinkan tim untuk fokus pada pengalaman pelanggan.
Tim pengembang dan arsitek harus meninjau faktor bisnis, teknis, operasional, dan keamanan setiap aplikasi, lalu mempertimbangkan pendekatan ini untuk modernisasi cloud aplikasi.
R1 - Retire Apps That are No Longer Valuable
Masih memiliki aplikasi untuk mendukung koneksi dial-up, faks, atau cara lama lainnya dalam berbisnis? Saat aplikasi menjalankan fungsi yang tidak lagi diperlukan, strategi modernisasi yang tepat adalah menghentikannya.
Terkadang keputusan untuk menghentikan aplikasi sudah jelas: Pengguna bisnis telah menandatangani untuk mematikannya, atau menghentikan aplikasi tidak berdampak pada operasi bisnis. Namun, meskipun aplikasi memiliki penggunaan yang rendah atau menjalankan fungsi bisnis, nilai bisnisnya harus dipertimbangkan terhadap modernisasi dan biaya dukungan berkelanjutan.
Untuk meningkatkan pengalaman pengguna, perusahaan harus mempertimbangkan strategi pensiun. Menghentikan aplikasi lawas yang sudah usang menciptakan efisiensi yang lebih baik, yang menghasilkan pengalaman pengguna yang lebih baik bagi pelanggan Anda. Permukaan serangan yang berkurang juga mengarah pada keamanan yang lebih kuat.
R2 - Replace Apps with SaaS, Commercial, or Open Source Options
Mengganti aplikasi adalah saat organisasi berhenti mengandalkan aplikasi yang dibuat khusus sendiri dan bermigrasi ke aplikasi pihak ketiga bawaan yang disediakan oleh vendor dan dihosting di cloud.
Contohnya termasuk alat manajemen hubungan pelanggan, sistem manajemen konten, atau alat alur kerja yang disesuaikan yang dikembangkan ketika solusi SaaS, komersial, atau sumber terbuka yang setara pada saat itu tidak memenuhi kebutuhan bisnis. Saat ini, pengguna bisnis dapat menemukan opsi pihak ketiga yang lebih baik dan lebih murah dibandingkan dengan milik mereka yang perlu diperbarui.
R3 - Relocate the App to the Cloud
Aplikasi yang memenuhi kebutuhan bisnis dan berjalan di tumpukan perangkat lunak yang didukung dapat menjadi kandidat untuk relokasi. Alih-alih menjalankannya pada perangkat keras atau mesin virtual khusus, tim arsitektur dan devops menemukan manfaat teknis dan bisnis dengan memindahkannya ke lingkungan cloud. Misalnya, mungkin lebih mudah untuk mengonfigurasi lingkungan dev dan pengujian, produksi skala otomatis, dan mengonfigurasi lingkungan pemulihan bencana dengan aplikasi yang berjalan di cloud publik atau pribadi.
Migrasi tidak sama dengan modernisasi. Ada banyak keuntungan yang bisa diperoleh dengan metode migrasi lift-and-shift. Hampir semua perusahaan mencapai beberapa keuntungan jangka pendek, tetapi kesalahan yang dilakukan oleh banyak pemimpin teknologi adalah percaya bahwa pekerjaan berhenti di situ.
Relokasi dapat memberikan fleksibilitas infrastruktur, peningkatan keamanan, dan pengurangan biaya, tetapi tidak mengatasi masalah dengan mendukung aplikasi dan kode yang mendasarinya.
Monolit di cloud memiliki semua masalah pelik yang sama seperti yang terjadi di lokasi—kecepatan rekayasa yang lambat, kurangnya skalabilitas, dan pemeliharaan yang sulit. Fase ini dikenal sebagai 'penyesalan lift-and-shift' karena kenaikan biaya dan manfaat cloud masih di luar jangkauan. Untuk mematahkan mitos ini, migrasi harus dilihat dan direncanakan dalam konteks strategi modernisasi yang lebih besar dan lebih strategis.
R4 - Replatform Components That Have Operational Benefits
Banyak yang mengartikan "lift and shift" sebagai opsi migrasi yang memerlukan keterlibatan minimal dari tim pengembangan dan tidak memerlukan peningkatan kode atau perubahan konfigurasi besar. Harapannya adalah mendapatkan beberapa keuntungan dari migrasi tanpa pekerjaan tambahan dan biaya untuk merekayasa ulang kode.
Namun di antara kode dan infrastruktur terdapat platform database, kerangka kerja, dan komponen—serta peluang untuk memasang ulang platform tersebut selama migrasi. Meskipun platform ulang umumnya membutuhkan pengembang, itu mungkin tidak memerlukan perubahan kode yang substansial, terutama ketika platform komoditas, standar, atau hampir setara ditukar ke dalam tumpukan.
Arsitek cloud dapat memodernisasi gudang data dan danau data untuk menerapkannya sebagai layanan cloud publik yang menawarkan keuntungan operasional dan biaya. Opsi replatform lainnya mencakup migrasi bus layanan, pindah ke alat CI/CD standar organisasi, atau mengubah jaringan pengiriman konten.
R5 - Reuse Applications That Offer Longer-term Business Impacts
Gunakan kembali model data, layanan, dan API aplikasi yang sudah ada, tetapi desain ulang pengalaman pengguna.
R6 - Refactor applications that offer longer-term business impacts
Refaktor kode untuk meningkatkan kinerja, keamanan, pemeliharaan, dan pemutakhiran nonfungsional lainnya.
R7 - Rebuild applications that offer longer-term business impacts
Membangun kembali modul dan kemampuan untuk meningkatkan fungsionalitas, mengatasi cacat, atau mengurangi utang teknis. Beberapa akan merancang ulang aplikasi monolitik menjadi layanan mikro.
Tim pengembang juga dapat mempertimbangkan pendekatan bertahap. Misalnya, mereka mungkin terlebih dahulu menghosting ulang aplikasi yang berjalan pada platform yang didukung untuk mendapatkan manfaat operasional dari menjalankannya di cloud pribadi atau publik. Mereka kemudian dapat mempertimbangkan untuk menggunakan kembali aplikasi yang jarang digunakan yang tidak sering ditingkatkan versinya dan merancang ulang aplikasi lain jika ada kebutuhan bisnis untuk penyempurnaan yang sering dilakukan.
Modernisasi aplikasi tidak bebas biaya atau risiko. Untuk organisasi dengan ribuan aplikasi, perlu waktu bertahun-tahun untuk sepenuhnya memodernisasi portofolio. Tim pengembang dan arsitek harus menggunakan lensa kepraktisan dan meninjau semua faktor sebelum memilih strategi modernisasi aplikasi.