Menjelaskan kerangka kerja migrasi Azure

Selesai

Sebelum Anda dapat mulai memigrasikan beban kerja lokal Tailwind Traders ke Azure, Anda harus mempertimbangkan untuk membuat rencana migrasi. Rencana harus mengidentifikasi beban kerja untuk dimigrasikan, dan layanan atau alat yang sesuai untuk digunakan selama migrasi. Idealnya, rencana Anda juga harus mencakup detail tentang cara mengoptimalkan layanan yang dimigrasikan.

Kerangka kerja migrasi Azure dapat membantu Anda mengembangkan paket dan bekerja melalui migrasi Anda. Kerangka kerja terdiri dari empat tahap: Menilai, Memigrasikan, Mengoptimalkan, dan Memantau.

Tahap 1: Menilai lingkungan lokal Anda

Pada tahap pertama, Anda menilai lingkungan lokal saat ini:

  • Identifikasi aplikasi Anda, dan server, layanan, dan data terkait, yang berada dalam cakupan untuk migrasi
  • Mulai melibatkan pemangku kepentingan, seperti departemen IT dan grup bisnis yang relevan
  • Buat peta inventori dan dependensi lengkap server, layanan, dan aplikasi yang anda rencanakan untuk dimigrasikan
  • Perkirakan penghematan biaya Anda dengan menggunakan Kalkulator Total Biaya Kepemilikan (TCO) Azure
  • Mengidentifikasi alat dan layanan yang sesuai yang dapat Anda gunakan untuk melakukan empat tahap

Pola strategi migrasi

Ada lima pola strategi yang luas untuk memigrasikan beban kerja ke cloud, biasanya disebut lima R rasionalisasi: Rehost, Refactor, Rearchitect, Rebuild, dan Replace. Strategi yang Anda adopsi tergantung pada driver bisnis dan tujuan migrasi Anda. Anda mungkin mempertimbangkan untuk mengadopsi beberapa pola. Anda dapat memilih untuk menghosting ulang aplikasi atau aplikasi sederhana yang tidak penting bagi bisnis Anda, tetapi menyusun ulang aplikasi yang lebih kompleks dan penting bagi bisnis.

  • Rehost: Rehost sering disebut sebagai migrasi lift dan shift. Strategi ini tidak memerlukan perubahan kode, dan memungkinkan Anda untuk memigrasikan beban kerja yang ada ke Azure dengan cepat. Setiap beban kerja dimigrasikan apa adanya, tanpa risiko dan biaya yang terkait dengan perubahan kode.

  • Refaktor: Refaktor sering disebut sebagai pengemasan ulang. Pemfaktoran ulang memerlukan perubahan minimal pada aplikasi sehingga mereka dapat terhubung ke platform Azure sebagai layanan (PaaS) dan menggunakan penawaran cloud. Anda dapat memigrasikan aplikasi yang ada ke Azure App Service atau Azure Kubernetes Service (AKS). Atau, Anda dapat merefaktor database relasional dan non-relasional ke dalam opsi lain. Refaktor ke Azure SQL Managed Instance, Azure Database for MySQL, Azure Database for PostgreSQL, dan Azure Cosmos DB (jika aplikasi Anda dapat dengan mudah dikemas ulang agar berfungsi di Azure).

  • Rearchitect: Merancang ulang untuk migrasi berfokus pada memodifikasi dan memperluas fungsionalitas aplikasi dan basis kode untuk mengoptimalkan arsitektur aplikasi untuk skalabilitas cloud. Anda dapat memecah aplikasi monolitik menjadi sekelompok layanan mikro yang bekerja sama dan menskalakan dengan mudah. Atau, Anda dapat menyusun ulang database relasional dan non-relasional ke solusi database yang dikelola sepenuhnya. Buat ulang ke Azure SQL Managed Instance, Azure Database for MySQL, Azure Database for PostgreSQL, dan Azure Cosmos DB.

  • Membangun kembali: Membangun kembali mengambil langkah lebih jauh dengan membangun kembali aplikasi sepenuhnya dengan menggunakan teknologi cloud Azure. Anda dapat membangun aplikasi bidang hijau dengan teknologi cloud-native seperti Azure Functions, Azure AI, Azure SQL Managed Instance, dan Azure Cosmos DB.

  • Ganti: Terapkan solusi menggunakan teknologi dan pendekatan terbaik yang tersedia saat ini. Terkadang, aplikasi software as a service (SaaS) dapat menyediakan semua fungsionalitas yang diperlukan untuk aplikasi yang dihosting. Kemudian, beban kerja dapat dijadwalkan untuk penggantian, menghapusnya dari cakupan migrasi.

Tabel berikut ini mencantumkan skenario untuk bekerja dengan empat pola.

Rehost Menentukan faktor kembali Merancang ulang Membangun kembali Menggantikan
Memindahkan beban kerja dengan cepat ke cloud

Memindahkan beban kerja tanpa memodifikasinya

Untuk aplikasi yang dirancang untuk memanfaatkan skalabilitas Azure IaaS setelah migrasi

Saat beban kerja penting untuk bisnis Anda, tetapi Anda tidak memerlukan perubahan segera pada kemampuan aplikasi
Menerapkan praktik DevOps inovatif yang disediakan oleh Azure

Menerapkan strategi kontainer DevOps untuk beban kerja

Mendukung portabilitas basis kode yang ada dan keterampilan pengembangan yang tersedia
Aplikasi Anda memerlukan revisi utama untuk menggabungkan kemampuan baru

Aplikasi Anda memerlukan revisi utama untuk bekerja secara efektif di platform cloud

Menggunakan investasi aplikasi yang ada

Memenuhi persyaratan skalabilitas

Menerapkan praktik DevOps yang inovatif

Meminimalkan penggunaan komputer virtual
Perkembangan pesat

Mendukung aplikasi yang ada dengan fungsionalitas dan masa pakai terbatas

Mempercepat inovasi bisnis dengan menggunakan praktik DevOps

Membangun kembali dengan teknologi cloud-native baru seperti Azure Blockchain

Membangun kembali aplikasi warisan sebagai "tanpa aplikasi kode" atau "aplikasi rendah" di cloud
Standarisasi sekeliling praktik terbaik industri

Mempercepat adopsi pendekatan berbasis proses bisnis

Investasi pengembangan yang dialokasikan yang menciptakan diferensiasi atau keuntungan yang kompetitif

Ganti solusi yang ada untuk penawaran SaaS

Tahap 2: Memigrasikan beban kerja Anda

Setelah Anda menyelesaikan penilaian, Anda dapat memulai proses migrasi aplikasi yang ditargetkan dan layanan dan data terkait. Tahap migrasi biasanya terdiri dari upaya berikut:

  • Menyebarkan target infrastruktur cloud. Sebelum Anda dapat memigrasikan beban kerja Tailwind Traders, Anda perlu membuat target infrastruktur cloud yang diperlukan. Tergantung pada alat yang Anda gunakan untuk melakukan migrasi, Anda mungkin perlu membuat sumber daya Azure yang diperlukan sebelum memulai migrasi. Beberapa alat, seperti Azure Migrate dan Azure Database Migration Service dapat membuat sumber daya Azure target untuk Anda.

  • Memigrasikan beban kerja. Ada baiknya untuk menguji coba migrasi beban kerja Anda, dan memilih aplikasi non-kritis untuk pilot. Pendekatan ini memungkinkan Anda untuk terbiasa dengan alat, mendapatkan pengalaman dengan proses dan prosedur, dan mengurangi risiko saat memigrasikan beban kerja yang besar atau kompleks.

  • Menonaktifkan infrastruktur lokal: Setelah Anda puas bahwa aplikasi sumber dan database Anda berhasil dimigrasikan, Anda perlu menonaktifkan beban kerja sumber. Pertimbangkan untuk menyimpan cadangan beban kerja sumber dan data yang diarsipkan. Data ini dapat terbukti berguna karena menyediakan arsip historis. Anda dapat menyimpan cadangan dan arsip ini di Azure Blob Storage.

Tahap 3: Optimalkan beban kerja yang dimigrasikan

Untuk tahap pengoptimalan, ada tiga upaya utama untuk fokus pada perencanaan Anda:

  • Menganalisis biaya migrasi untuk beban kerja Anda
  • Tinjau rekomendasi untuk mengurangi biaya Anda
  • Mengidentifikasi opsi untuk meningkatkan performa beban kerja Anda

Anda dapat menggunakan Microsoft Cost Management (sebelumnya dikenal sebagai Azure Cost Management and Billing) di portal Azure untuk menganalisis biaya beban kerja Anda. Alat ini tersedia untuk grup sumber daya Azure yang berisi beban kerja yang dimigrasikan. Anda akan menemukan alat di bagian Costs analysis>Cost Management. Cuplikan layar berikut menunjukkan analisis biaya untuk periode terakhir yang dapat ditagih ContosoResourceGroup untuk grup sumber daya. Hasilnya menampilkan biaya sesuai dengan nama layanan, wilayah, dan sumber daya. Anda dapat menyesuaikan hasil tampilan untuk memenuhi kebutuhan Anda.

Screenshot that shows a cost analysis example with estimated costs in the Azure portal.

Untuk membantu mengurangi biaya, Anda dapat menggunakan fitur Azure Advisor dengan memilih rekomendasi Advisor. Setelah menganalisis biaya saat ini dan meninjau rekomendasi, Anda dapat menentukan opsi untuk meningkatkan performa beban kerja Anda.

Tahap 4: Memantau beban kerja Anda

Anda dapat menggunakan Azure Monitor untuk mengambil informasi kesehatan dan performa dari komputer virtual Azure Anda. Instal agen Log Azure Monitor (sebelumnya dikenal sebagai Analitik Log) pada komputer virtual target, lalu siapkan pemberitahuan dan pelaporan.

Catatan

Anda dapat menginstal agen Log Azure Monitor pada komputer yang menjalankan Windows atau Linux.

Anda dapat menyiapkan pemberitahuan berdasarkan rentang sumber data:

  • Nilai metrik tertentu, seperti penggunaan CPU
  • Teks tertentu dalam file log
  • Metrik kesehatan
  • Metrik skala otomatis