Proses migrasi
Migrasi adalah proses yang sangat berulang. Saat ini, Anda memiliki kumpulan aset biner (komputer virtual, aplikasi, dan data) di pusat data lokal. Besok, Anda ingin mereplikasi aset biner tersebut ke cloud dan menggeser lalu lintas produksi untuk menggunakan salinan baru aset yang sama.
Seperti kebanyakan proses berulang, sebagian besar pekerjaan dapat diotomatisasi untuk mengurangi tugas manusia yang berulang. Tetapi, karena sebagian besar tim migrasi dengan cepat menemukan, proses yang dapat diulang adalah bagian yang mudah. Upaya manajemen perubahan yang membutuhkan keputusan dan intervensi manusia tersembunyi dalam proses ini.
Disiplin migrasi berikut menguraikan cara alat Azure Migrate dan Cloud Adoption Framework bekerja sama untuk membentuk intervensi manusia yang diperlukan menjadi proses yang dapat diulang.
Migrasi massal versus migrasi iteratif
Aset biner yang berpindah ke cloud secara teoritis dapat dimigrasikan dalam satu batch besar. Beberapa organisasi telah berhasil dalam migrasi massal semua aset menggunakan Azure Migrate. Melakukannya membutuhkan upaya analisis dan remediasi terencana untuk memastikan bahwa semua aset kompatibel dengan cloud. Ini juga memerlukan rencana mendetail untuk menguji dan menjamin performa untuk setiap beban kerja yang berjalan pada aset tersebut.
Tingkat perencanaan dan dampaknya pada pengguna bisnis membuat pendekatan migrasi massal tidak menarik bagi sebagian besar organisasi. Pendekatan alternatif adalah untuk menerapkan prinsip metode Agile, seperti Scrum, untuk memecah migrasi massal menjadi gelombang: memigrasikan kumpulan beban kerja yang lebih kecil pada irama yang teratur.
Pendekatan iteratif untuk migrasi memungkinkan bisnis menyerap perubahan unit yang lebih kecil dan menghasilkan lebih sedikit gangguan bisnis. Pendekatan iteratif juga memungkinkan tim untuk mengukur dan belajar dari setiap iterasi. Tim dapat memperoleh kecepatan dan keahlian secara progresif dari satu iterasi ke iterasi berikutnya.
Untuk sisa modul ini, Anda dapat mengasumsikan bahwa Tailwind Traders memutuskan untuk mengikuti pendekatan berulang untuk migrasi.
Disiplin ilmu
Dalam setiap proses migrasi berulang, tim menyelesaikan tiga set tugas atau disiplin ilmu untuk berhasil memigrasikan setiap beban kerja ke Azure:
Menilai beban kerja: Saat menilai beban kerja di setiap gelombang, arsitek terutama mencari kompatibilitas cloud dan dependensi antar aset. Mereka juga mencari kompatibilitas dengan peluang modernisasi dan pengoptimalan. Terkadang, mereka mendekati arsitektur beban kerja individual untuk melakukan tugas pengoptimalan tingkat lanjut menggunakan Azure Well-Architected Review.
Menyebarkan beban kerja: Selama migrasi, atau penyebaran, beban kerja, tim menggunakan alat migrasi untuk menyelesaikan replikasi aset (komputer virtual, aplikasi, dan data) ke cloud. Dalam langkah ini, tim terutama mengarahkan dan mengawasi proses yang dapat diulang untuk memastikan replikasi aset yang akurat untuk beban kerja yang dipilih.
Merilis beban kerja: Setelah setiap platform teknologi dan beban kerja dimigrasikan ke cloud, tim perlu menguji, mengoptimalkan, dan merilis lalu lintas produksi ke beban kerja yang baru dimigrasikan. Pengujian mungkin juga memerlukan evaluasi perutean pengguna dan pengoptimalan jalur jaringan ke beban kerja yang baru disebarkan.
Mengulangi ketiga disiplin ini untuk setiap beban kerja dalam rencana migrasi membantu memastikan keberhasilan migrasi ke cloud.
Perencanaan sprint
Saat merencanakan upaya migrasi, salah satu langkah pertama adalah memecah daftar beban kerja yang akan dimigrasikan ke dalam grup yang lebih kecil.
Saat Anda mempelajari tentang kecepatan tim Anda (berapa banyak beban kerja yang dapat mereka pindahkan dalam sprint), kami sarankan untuk memulai dengan pendekatan Power of 10 . Dalam pendekatan itu, Anda secara konsisten mendefinisikan kelompok dengan 10 beban kerja umum di setiap gelombang. Kemudian, Anda memetakan grup 10 beban kerja tersebut ke iterasi atau sprint dua minggu dengan menggunakan rencana adopsi cloud Anda di Azure DevOps. Referensi modul Perencanaan untuk panduan langkah demi langkah.
Sebelum setiap sprint, tim migrasi harus mengevaluasi gelombang beban kerja berikutnya yang akan dimigrasikan. Tujuan dari evaluasi ini adalah untuk memastikan bahwa tim memiliki semua informasi dan akses yang diperlukan agar berhasil dalam sprint saat ini. Ini juga memberi tim kesempatan untuk menyesuaikan 10 beban kerja berikutnya berdasarkan apa yang dipelajari dari sprint sebelumnya. Setelah tim berkomitmen untuk sprint, pekerjaan yang sebenarnya dapat dimulai.
Organisasi tim
Anda dapat menerapkan prinsip-prinsip pengorganisasian dasar ke struktur tim Anda untuk memaksimalkan output setiap sprint berdasarkan kecepatan yang tersedia. Dua bentuk organisasi tim yang paling umum adalah:
Tim yang mengorganisir sendiri: Jenis organisasi ini selaras dengan metodologi tangkas. Tim yang mengorganisir sendiri memastikan bahwa anggota tim migrasi dapat secara kolektif mengirimkan setiap disiplin ilmu. Di setiap sprint, tim mengidentifikasi siapa yang melakukan tugas yang terkait dengan setiap disiplin di setiap beban kerja dalam gelombang.
Dalam organisasi ini, tujuannya adalah untuk menyelesaikan ketiga disiplin ilmu untuk setiap beban kerja dalam sprint saat ini.
Pabrik migrasi: Sifat disiplin migrasi yang berulang menyesuaikan mereka ke pembagian kerja di seluruh tim yang sangat terspesialisasi. Dalam pendekatan ini, satu tim didedikasikan untuk setiap disiplin migrasi. Tim penilai selalu satu sampai dua gelombang di depan tim migrasi. Tim perilis selalu satu sampai dua sprint di belakang tim migrasi.
Pendekatan ini bisa menjadi efektif dalam upaya migrasi besar termasuk ribuan aset dan ratusan beban kerja.
Pemblokir umum
Teknologi jarang memblokir proses migrasi. Sebagian besar pemblokir migrasi berasal dari langkah yang terlewatkan dalam dependensi upstram atau downstream pada proses migrasi. Pemblokir berikut ini dicantumkan dari yang paling umum hingga yang tidak umum:
Pemblokir Strategi dan perencanaan: Pemblokir yang paling umum untuk migrasi yang sukses berasal dari langkah yang terlewat selama upaya strategi atau perencanaan. Kegagalan untuk mengatur ekspektasi yang tepat dengan eksekutif, manajer proyek, atau staf teknis dapat membuat pemblokir, bahkan saat semua disiplin teknis berjalan seperti yang direncanakan.
Sebelum memulai upaya migrasi dalam skala besar, pastikan Anda telah membuat strategi adopsi cloud dan rencana adopsi cloud, dan bahwa pemangku kepentingan telah meninjaunya.
Pemblokir Lingkungan: Lingkungan yang dikonfigurasi secara tidak benar adalah pemblokir paling umum berikutnya untuk keberhasilan migrasi. Secara khusus, upaya migrasi memerlukan minimal konfigurasi jaringan dan identitas untuk konektivitas dan persyaratan akses yang tepat.
Untuk sebagian besar upaya migrasi, pertimbangan tata kelola dan operasi harus ditangani lebih awal, jika tidak sebelum proses migrasi. Untuk memastikan konfigurasi lingkungan yang tepat, referensikan modul Cloud Adoption Framework Learn tentang menyiapkan lingkungan Anda.
Pemblokir tata kelola: Sebagian besar organisasi memiliki persyaratan untuk biaya, keamanan, konsistensi, dan pengelolaan identitas yang melampaui konfigurasi lingkungan dasar. Banyak organisasi tidak memahami persyaratan tersebut sampai mereka mencoba memigrasikan lalu lintas produksi ke cloud.
Kami menyarankan agar semua tim migrasi meninjau modul Learn untuk metodologi Tata Kelola dalam Cloud Adoption Framework sebelum memulai upaya migrasi skala. Meninjau informasi ini dapat membantu menghindari kejutan yang terlambat terikat.
Pemblokir operasi: Sebagian besar organisasi telah mengatur persyaratan operasi untuk beban kerja produksi mereka di pusat data saat ini. Seringkali diasumsikan bahwa persyaratan operasi tersebut berfungsi ketika lalu lintas produksi dipindahkan ke cloud. Sebelum tim migrasi memulai upaya migrasi skala apa pun, tim harus meninjau modul Learn tentang mengembangkan strategi yang jelas untuk memahami harapan dasar tentang manajemen operasi di cloud.
Pemblokir Teknis: Terkadang, beban kerja mungkin diblokir karena peningkatan kebutuhan dalam remediasi, modernisasi, atau perubahan strategi rasionalisasi. Ketika beban kerja individual diblokir, Anda dapat mengatasinya dengan lonjakan teknis, yang menghapus beban kerja bermasalah dari alur standar.
Biasanya, tim terpisah mengatasi lonjakan teknis dalam sprint paralel. Tim migrasi dapat mengatasi banyak masalah teknis sekeliling remediasi dan modernisasi. Skenario migrasi Cloud Adoption Framework yang dibagikan di akhir modul ini mencakup masalah ini.
Saat beban kerja memerlukan perubahan komprehensif yang memengaruhi arsitektur aplikasi, tim beban kerja harus meninjau modul Pembelajaran Kerangka Kerja dengan Arsitektur yang Baik untuk panduan tambahan.