Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Tugas 4: Mendefinisikan proses penyelaman mendalam aplikasi
Sekarang setelah Anda selesai menetapkan aturan dan proses untuk prioritas aplikasi, Anda melakukan penyelaman mendalam aplikasi yang akan membantu Anda menyempurnakan prioritas setiap aplikasi. Anda melakukan penyelaman mendalam aplikasi pada satu aplikasi pada satu waktu, dalam urutan dari prioritas tertinggi hingga terendah. Untuk proyek dengan beberapa tim portofolio, setiap tim dapat melakukan penyelaman mendalam aplikasi pada aplikasi yang berbeda secara bersamaan.
Selama deep dive, Anda mungkin mengalami beberapa masalah tak terduga, seperti dependensi, yang memengaruhi kompleksitas migrasi aplikasi. Ketika ini terjadi, Anda harus memodifikasi kriteria penilaian kompleksitas yang Anda tentukan pada langkah sebelumnya dan memperbarui lembar skor yang sesuai untuk mendapatkan skor kompleksitas yang lebih akurat untuk aplikasi masa depan. Anda kemudian dapat memperbarui prioritas aplikasi dengan menggunakan skor kompleksitas baru.
Tugas ini terdiri dari langkah-langkah berikut:
Langkah 1: Tentukan proses lokakarya aplikasi
Proses lokakarya adalah salah satu pendekatan paling efisien untuk aplikasi deep dive. Dengan menggunakan proses ini, Anda berkolaborasi dengan pemangku kepentingan, pemilik aplikasi, dan tim portofolio untuk menilai dan menganalisis aplikasi. Tujuannya adalah untuk memahami dengan jelas keadaan aplikasi saat ini, termasuk arsitektur, tujuan bisnis, dependensi, dan lingkungannya. Anda kemudian menggunakan informasi terperinci ini tentang ukuran dan kompleksitas aplikasi untuk merancang status target aplikasi.
Setiap lokakarya biasanya berlangsung 1—8 jam, meskipun Anda mungkin menemukan bahwa waktu tambahan diperlukan untuk aplikasi dengan kompleksitas tinggi. Anda juga dapat memecah lokakarya menjadi beberapa pertemuan, tergantung pada ketersediaan sumber daya, preferensi Anda, dan ukuran dan kompleksitas aplikasi.
Identifikasi hasil yang diharapkan
Sebelum melakukan lokakarya aplikasi, Anda harus menetapkan agenda dan menentukan hasil yang diharapkan dari lokakarya, atau informasi yang perlu Anda kumpulkan di lokakarya. Hal ini memungkinkan peserta lokakarya untuk mempersiapkan lokakarya, membantu menjaga pertemuan tetap tepat sasaran, dan memastikan bahwa pada akhir lokakarya, Anda memiliki semua informasi yang diperlukan untuk memprioritaskan, merencanakan gelombang, dan memigrasikan aplikasi.
Kami menyarankan Anda menentukan serangkaian standar hasil yang diharapkan dan mendokumentasikannya dalam runbook prioritas aplikasi Anda. Saat menyiapkan lokakarya, Anda menggunakan hasil standar yang diharapkan dan menambahkan yang baru untuk aplikasi tertentu.
Tentukan set standar hasil yang diharapkan untuk lokakarya aplikasi sebagai berikut:
-
Buka runbook prioritas aplikasi Anda.
-
Di bagian hasil lokakarya Aplikasi yang diharapkan, tetapkan serangkaian standar hasil yang diharapkan untuk lokakarya aplikasi. Saat menyiapkan lokakarya, Anda dapat menyesuaikannya untuk kebutuhan spesifik aplikasi.
-
Simpan runbook prioritas aplikasi.
-
Pertahankan hasil yang diharapkan dalam runbook prioritas aplikasi. Saat Anda melakukan lokakarya aplikasi dan melanjutkan penilaian portofolio dan perencanaan gelombang, Anda dapat mengidentifikasi hasil baru yang diharapkan atau menyempurnakan hasil yang ada.
Berikut ini adalah contoh hasil yang diharapkan untuk lokakarya aplikasi.
| Prioritas | Hasil yang diharapkan dari lokakarya aplikasi |
|---|---|
1 |
Pemahaman yang jelas tentang arsitektur aplikasi saat ini, termasuk server terkait, dependensi, lingkungan, dan tingkat aplikasi. |
2 |
Tim telah mengumpulkan metadata untuk mendukung desain arsitektur target. Metadata berikut diperlukan:
|
3 |
Kuesioner pemilik aplikasi lengkap, dan semua pertanyaan kunci dijawab. |
4 |
Tim telah mengumpulkan semua dokumentasi aplikasi, seperti panduan pengguna, dokumentasi arsitektur aplikasi, dokumentasi pengujian, dokumentasi desain, dan dokumentasi antarmuka pemrograman aplikasi (API). |
Tentukan aturan lokakarya aplikasi
Sebelum melakukan lokakarya aplikasi, Anda harus menentukan aturan yang akan mengatur lokakarya Anda. Aturan umum termasuk panjang lokakarya, alat yang mungkin diperlukan di bengkel, dan pertimbangan penjadwalan atau tenggat waktu yang perlu dipertimbangkan. Ini membantu menjaga rapat tetap tepat sasaran dan memastikan bahwa keputusan yang dibuat di lokakarya selaras dengan jadwal migrasi.
Kami menyarankan Anda mendokumentasikan aturan lokakarya aplikasi di runbook prioritas aplikasi Anda.
Tentukan aturan lokakarya aplikasi Anda sebagai berikut:
-
Buka runbook prioritas aplikasi Anda.
-
Di bagian Aturan lokakarya aplikasi, tentukan aturan yang mengatur lokakarya Anda.
-
Simpan runbook prioritas aplikasi.
-
Pertahankan aturan dalam runbook prioritas aplikasi. Saat Anda melakukan lokakarya aplikasi dan melanjutkan penilaian portofolio dan perencanaan gelombang, Anda dapat mengidentifikasi aturan baru atau menyempurnakan aturan yang sudah ada.
Berikut ini adalah contoh aturan untuk lokakarya aplikasi.
| Prioritas | Aturan lokakarya |
|---|---|
1 |
Lokakarya harus dijadwalkan maksimal 2 jam per sesi pada hari Selasa dan Kamis. |
2 |
Ada pembekuan infrastruktur yang dijadwalkan 1 Desember—15 Januari. |
3 |
Ada lokakarya langsung untuk alat migrasi. |
4 |
Kontrak pusat data akan berakhir pada 31 Maret. Beban kerja harus dievakuasi pada 31 Maret untuk menghindari hukuman dan perpanjangan kontrak yang mahal. |
5 |
Aplikasi biometrik dan aplikasi waktu dan kehadiran akan dipertahankan. |
Tentukan proses lokakarya aplikasi
Penting bagi Anda untuk menentukan proses standar untuk melakukan lokakarya aplikasi. Ini memastikan pengalaman yang konsisten dan menetapkan harapan bagi peserta lokakarya, yang dapat meningkatkan efisiensi lokakarya.
Ada tiga tahap proses lokakarya aplikasi:
-
Mempersiapkan lokakarya — Mempersiapkan lokakarya membantu memastikan bahwa sesi berjalan lancar dan peserta tahu apa yang diharapkan. Untuk mempersiapkan lokakarya, Anda membuat agenda dan menentukan hasil yang diharapkan, Anda mengidentifikasi peserta, alat, dan informasi yang dibutuhkan dalam lokakarya, dan Anda menjadwalkan lokakarya. Menjadwalkan lokakarya setidaknya satu minggu sebelumnya memberi tim waktu untuk memblokir kalender mereka, mempersiapkan lokakarya, dan mengumpulkan informasi yang berguna.
-
Melakukan lokakarya — Saat melakukan lokakarya, Anda membatasi diskusi pada item dalam agenda dan memastikan bahwa Anda memenuhi hasil yang diharapkan. Perhatikan topik yang menurut Anda bermanfaat tetapi tidak termasuk dalam agenda Anda. Akan sangat membantu untuk merekam lokakarya.
-
Selesaikan hasil lokakarya — Setelah lokakarya, tim Anda harus memiliki pemahaman yang jelas tentang keadaan aplikasi saat ini dan potensi titik nyeri, risiko, tantangan, dan penghambat yang dapat memengaruhi prioritas dan migrasi. Tugas umum setelah lokakarya meliputi: memprioritaskan ulang aplikasi, menyusun status aplikasi di masa depan, dan memperbarui runbook dengan hasil, aturan, atau perubahan proses yang diharapkan yang mungkin membantu dalam lokakarya berikutnya.
Template Runbook untuk prioritas aplikasi mencakup step-by-step proses standar untuk mempersiapkan, melakukan, dan menyelesaikan lokakarya aplikasi. Tentukan proses lokakarya aplikasi Anda sebagai berikut:
-
Buka runbook prioritas aplikasi Anda.
-
Di bagian Proses lokakarya Aplikasi, modifikasi proses standar untuk memenuhi kebutuhan kasus penggunaan Anda.
-
Simpan runbook prioritas aplikasi.
-
Pertahankan proses dalam runbook prioritas aplikasi. Saat Anda melakukan lokakarya aplikasi, Anda dapat mengidentifikasi perubahan yang ingin Anda lakukan pada proses ini.
Kriteria keluar langkah
-
Anda telah menentukan agenda lokakarya dan sumber daya serta artefak yang diperlukan untuk mendukung lokakarya.
-
Anda telah menentukan hasil yang diharapkan dari lokakarya dan mengidentifikasi informasi yang perlu Anda kumpulkan di bengkel.
-
Anda telah melakukan uji coba proses lokakarya dan memiliki informasi yang diperlukan untuk mendukung pemetaan aplikasi dan merancang status target.
-
Anda telah mendokumentasikan hal-hal berikut dalam runbook prioritas aplikasi Anda:
-
Lokakarya aplikasi hasil yang diharapkan
-
Aturan lokakarya aplikasi
-
Proses lokakarya aplikasi
-
Langkah 2: Tentukan proses pemetaan aplikasi
Pemetaan aplikasi adalah proses menetapkan setiap aplikasi ke pola migrasi, yang Anda identifikasi dan validasi. Langkah 4: Validasi pola migrasi Pada langkah ini, Anda menentukan aturan yang akan Anda gunakan untuk mengevaluasi aplikasi. Anda kemudian menentukan proses yang akan Anda gunakan untuk mengevaluasi setiap aplikasi. Memetakan setiap aplikasi ke kasus penggunaan pola migrasi membantu Anda mengidentifikasi alat migrasi, keterampilan apa pun yang diperlukan untuk menyelesaikan migrasi, dan kompleksitas pola migrasi.
Anda tidak selalu memigrasikan aplikasi ke satu pola. Untuk informasi selengkapnya tentang kapan Anda mungkin memerlukan beberapa pola untuk aplikasi yang sama, lihat Tentukan proses pemetaan aplikasi nanti di bagian ini.
Aturan pemetaan aplikasi
Aturan pemetaan aplikasi membantu Anda mengevaluasi aplikasi dan mengidentifikasi pola migrasi yang sesuai. Setiap aturan terdiri dari informasi apa pun yang harus Anda gunakan untuk mengevaluasi aplikasi dan mencocokkan kriteria untuk pola tersebut.
Dalam template playbook portofolio, template Runbook untuk prioritas aplikasi menyertakan bagian untuk mendokumentasikan aturan pemetaan aplikasi Anda. Tentukan proses Anda sebagai berikut:
-
Buka runbook prioritas aplikasi Anda.
-
Di bagian Aturan pemetaan aplikasi, tentukan aturan pemetaan aplikasi Anda.
-
Simpan runbook prioritas aplikasi.
-
Pertahankan aturan dalam runbook prioritas aplikasi.
Tabel berikut memberikan contoh aturan pemetaan aplikasi.
catatan
Pola IDs dan nama dalam tabel ini sesuai dengan pola sampel diLangkah 4: Validasi pola migrasi. Gunakan pola IDs dan nama yang Anda tentukan dalam runbook prioritas aplikasi Anda.
| Prioritas | Aturan pemetaan |
|---|---|
1 |
Dengan menggunakan data pemanfaatan atau alat pemantauan, identifikasi apakah aplikasi tersebut adalah aplikasi zombie atau idle. Jika aplikasi adalah aplikasi zombie atau idle, pilih Pola 8: Pensiun aplikasi, lalu matikan server di tumpukan aplikasi. |
2 |
Identifikasi apakah memigrasikan aplikasi ini ke cloud memberikan nilai bisnis. Aplikasi yang hanya digunakan di tempat dan tidak dibagikan di seluruh cabang atau lokasi geografis, seperti aplikasi waktu dan kehadiran, biasanya tidak perlu dimigrasikan ke cloud. Jika memigrasi aplikasi ini tidak memberikan nilai bisnis, pilih Pola 9: Simpan di tempat. |
3 |
Identifikasi apakah sistem operasi (OS) aplikasi didukung oleh AWS, layanan AWS migrasi, vendor, atau alat migrasi rehost Anda, lalu lakukan hal berikut:
|
4 |
Identifikasi apakah aplikasi memiliki versi perangkat lunak sebagai layanan (SaaS) atau setara, dan kemudian evaluasi manfaat dan biaya pindah ke platform baru ini. Jika kriteria ini terpenuhi, pilih Pola 10: Pembelian kembali dan tingkatkan ke SaaS. |
5 |
Identifikasi apakah database lokal aplikasi dapat dimigrasi ke layanan homogen di cloud, seperti memigrasikan database Oracle lokal ke Amazon RDS for Oracle atau memigrasikan database MySQL lokal ke Amazon Aurora MySQL database Edition yang kompatibel dengan Amazon Aurora. Jika kriteria ini terpenuhi, gunakan Pola 2: Replatform ke Amazon RDS menggunakan AWS DMS dan. AWS SCT |
6 |
Identifikasi apakah aplikasi menggunakan Microsoft .NET Core (.NET 5 atau .NET 6), Java, PHP, atau bahasa pemrograman open-source lainnya dan apakah aplikasi tersebut di-host di Microsoft Windows Server. Evaluasi apakah biaya replatforming dapat dibenarkan. Jika kriteria ini terpenuhi, pilih Pola 7: Replatform dari Windows ke Linux di Amazon EC2. |
7 |
Identifikasi penyimpanan file lokal dan bersama lokal yang bergantung pada aplikasi Anda, lalu tentukan apakah harus disertakan dalam migrasi. Jika penyimpanan file lokal dan bersama harus dimigrasikan, pilih Pola 4: Platform Ulang ke Amazon EFS menggunakan AWS DataSync atau. AWS Transfer Family |
8 |
Identifikasi apakah server aplikasi adalah server mainframe atau midrange, seperti IBM AS/400 atau Apache Spark, dan konfirmasikan bahwa aplikasi tersebut kompatibel dengan emulator. Jika kriteria ini terpenuhi, gunakan Pattern 6: Replatform mainframe atau server midrange ke Amazon EC2 menggunakan emulator. |
9 |
Identifikasi apakah ini adalah aplikasi berbasis warisan, monolitik, atau mainframe yang tidak dapat lagi memenuhi permintaan bisnis karena keterbatasannya. Misalnya, identifikasi apakah aplikasi dapat menskalakan, berintegrasi dengan aplikasi terkait, atau mahal dan sulit dirawat. Jika aplikasi memenuhi salah satu kriteria ini, pilih Pola 11: Arsitek ulang aplikasi. |
Tentukan proses pemetaan aplikasi
Saat Anda memetakan aplikasi ke pola migrasi, akan sangat membantu jika Anda meminta data penemuan untuk aplikasi dari tim penemuan. Data ini biasanya mencakup informasi seperti pola migrasi yang direkomendasikan (kadang-kadang disebut pola R atau skor R), informasi pemanfaatan, dependensi aplikasi, dan informasi lain yang dapat Anda gunakan dalam penilaian. Saat Anda menjelajahi aplikasi ini secara rinci, Anda mungkin memutuskan untuk mengubah pola migrasi yang sebelumnya diidentifikasi.
Ketika Anda memiliki data, Anda dapat membandingkan aplikasi dengan kriteria bisnis dan teknis yang Anda identifikasiLangkah 2: Identifikasi driver bisnis dan teknis. Anda merekam driver Anda di runbook prioritas aplikasi Anda. Mengevaluasi aplikasi berdasarkan kriteria dapat mengarahkan Anda untuk memilih beberapa pola migrasi untuk aplikasi, atau mungkin mengarahkan Anda untuk menghilangkan pola berdasarkan biaya, jadwal, atau batasan lainnya.
Berikut ini adalah contoh driver bisnis yang mengharuskan Anda untuk menggunakan beberapa pola migrasi pada satu aplikasi. Anda ingin memigrasikan database SQL Server lokal ke Amazon DynamoDB, tetapi karena kontrak untuk pusat data kedaluwarsa, bisnis ingin memigrasikannya lebih cepat daripada jadwal yang diusulkan untuk memplatform ulang. Untuk mengatasi driver bisnis ini, Anda merevisi rencana migrasi untuk aplikasi menjadi pendekatan dua pola. Pertama, Anda meng-host ulang aplikasi ke cloud untuk menghapusnya dari pusat data. Kemudian, setelah aplikasi berada di cloud, Anda dapat memplatform ulang sesuai dengan jadwal yang diusulkan.
Anda juga harus mempertimbangkan apakah aplikasi tersebut adalah aplikasi n-tier, yang merupakan aplikasi yang terdiri dari beberapa tingkatan. Tingkat aplikasi adalah sekelompok server fisik yang meng-host lapisan horizontal aplikasi Anda. Aplikasi N-tier lebih kompleks karena setiap tingkatan mungkin memerlukan strategi yang berbeda, dan Anda mungkin memilih untuk memigrasikan tingkatan aplikasi dalam gelombang yang berbeda. Misalnya, jika Anda memiliki aplikasi yang terdiri dari presentasi, layanan bisnis, dan tingkatan basis data, ada kemungkinan Anda dapat memetakan pola yang berbeda untuk setiap tingkatan.
Anda kemudian mengevaluasi aplikasi terhadap aturan pemetaan aplikasi Anda, yang Anda tentukan dalam runbook prioritas aplikasi Anda. Untuk informasi lebih lanjut, lihat Aturan pemetaan aplikasi sebelumnya di bagian ini.
Setelah Anda memetakan aplikasi Anda ke satu atau beberapa pola, tinjau dan verifikasi keputusan ini dengan pemilik aplikasi. Pemilik aplikasi harus mengonfirmasi pola yang dipilih, dan mereka akan membantu Anda merencanakan dan melakukan migrasi. Pada saat ini, pemilik aplikasi mungkin juga memberikan wawasan berdasarkan pengalaman mereka atau berbagi masalah apa pun yang mereka antisipasi dengan migrasi.
Ketika Anda telah memetakan aplikasi ke satu atau beberapa pola migrasi dan mengonfirmasi pola dengan pemilik aplikasi, Anda merekam aplikasi, ID pola, nama pola, dan driver yang relevan dalam tabel pemetaan aplikasi di runbook prioritas aplikasi Anda.
Dalam template playbook portofolio, template Runbook untuk prioritas aplikasi mencakup step-by-step proses standar untuk pemetaan aplikasi. Tentukan proses Anda sebagai berikut:
-
Buka runbook prioritas aplikasi Anda.
-
Di bagian Proses lokakarya Aplikasi, modifikasi proses standar untuk memenuhi kebutuhan kasus penggunaan Anda.
-
Simpan runbook prioritas aplikasi.
-
Pertahankan proses dalam runbook prioritas aplikasi.
Tabel berikut adalah contoh tabel pemetaan aplikasi. Template Runbook yang disediakan untuk prioritas aplikasi menyertakan tabel kosong tempat Anda dapat merekam hasil dari proses pemetaan aplikasi.
catatan
Pola IDs dan nama dalam tabel ini sesuai dengan pola sampel diLangkah 4: Validasi pola migrasi. Gunakan pola IDs dan nama yang Anda tentukan dalam runbook prioritas aplikasi Anda.
| Nama aplikasi | ID Pola | Nama pola | Driver bisnis dan teknis ditangani |
|---|---|---|---|
Situs web perusahaan |
1 |
Rehost ke Amazon EC2 menggunakan Layanan Migrasi Aplikasi atau Pabrik Migrasi Cloud |
|
Sistem SDM |
8 |
Pensiun aplikasi |
|
Aplikasi waktu dan kehadiran |
9 |
Pertahankan di tempat |
|
Sistem PO |
3 |
Replatform ke Amazon EC2 menggunakan CloudFormation |
|
Sistem CRM |
10 |
Beli kembali dan tingkatkan ke SaaS |
|
Sistem aset tetap |
7 |
Replatform dari Windows ke Linux di Amazon EC2 |
|
Penyimpanan file ERP |
4 |
Platform ulang ke Amazon EFS menggunakan AWS DataSync atau AWS Transfer Family |
|
Sistem buku besar |
6 |
Rehost server mainframe atau midrange ke Amazon EC2 menggunakan emulator |
|
Buku besar |
11 |
Arsitek ulang aplikasi |
|
Kriteria keluar langkah
-
Anda telah mendokumentasikan hal-hal berikut dalam runbook prioritas aplikasi Anda:
-
Aturan pemetaan aplikasi
-
Proses pemetaan aplikasi
-
-
Anda telah memvalidasi aturan dan proses pemetaan dengan menggunakan satu atau beberapa aplikasi proof-of-concept (POC).
Langkah 3: (Opsional) Tentukan status target aplikasi
Pada langkah ini, Anda menentukan atribut dan proses yang Anda gunakan untuk mendokumentasikan status target, atau status calon, untuk aplikasi. Status target adalah bagaimana aplikasi beroperasi di lingkungan cloud target setelah migrasi. Lingkungan target bervariasi berdasarkan platform target atau layanan dan persyaratan bisnis Anda. Lingkungan target bisa menjadi AWS Cloud or AWS Managed Services (AMS).
Mendefinisikan status target membantu manajer proyek, konsultan migrasi, arsitek, pemilik aplikasi, dan pemangku kepentingan berkolaborasi secara efektif. Dengan menggunakan proses ini, tim dapat mengidentifikasi dan menyelesaikan masalah terlebih dahulu dan lebih efisien menerapkan lingkungan status target.
Untuk beberapa aplikasi, langkah ini opsional. Anda dapat melewati langkah ini jika aplikasi yang Anda migrasi mandiri atau kompleksitas rendah. Strategi migrasi yang tidak mengubah aplikasi, seperti rehost, mungkin tidak memerlukan langkah ini. Namun, untuk strategi migrasi yang lebih kompleks, seperti replatform dan arsitek ulang, Anda harus menentukan status target sebelum memulai migrasi.
Lokakarya ini memberi Anda pemahaman mendalam tentang keadaan aplikasi saat ini, jadi ada baiknya untuk menyusun status target setelah menyelesaikan lokakarya. Selain itu, pemetaan aplikasi ke pola migrasi memberikan wawasan tambahan dan membantu Anda mengidentifikasi apakah menentukan status target diperlukan. Misalnya, jika Anda memetakan aplikasi ke pola Rehost ke Amazon EC2 menggunakan Layanan Migrasi Aplikasi atau Pabrik Migrasi Cloud, Anda telah mengidentifikasi bahwa strateginya adalah rehost, dan Anda mungkin tidak perlu menentukan status target untuk aplikasi ini.
Atribut status target
Saat menentukan status target dan membuat keputusan tentang aplikasi, kami sarankan Anda mempertimbangkan atribut status target berikut:
-
AWS Well-Architected Tool— Tinjau status target aplikasi terhadap AWS Well-Architected Framework untuk membantu meningkatkan keamanan, kinerja, dan ketahanan aplikasi di cloud.
-
Target landing zone — Biasanya, pada akhir fase mobilisasi, Anda seharusnya telah membangun landing zone lengkap yang siap menjalankan aplikasi pilot. Landing zone harus sudah dikonfigurasi dengan arsitektur multi-akun, identitas dan manajemen akses, tata kelola, keamanan data, desain jaringan, dan logging. Anda menggunakan aplikasi pilot untuk memverifikasi bahwa landing zone sudah lengkap. Verifikasi bahwa Anda dapat meluncurkan dan menjalankan aplikasi pilot Anda di target landing zone yang ada. Jika Anda perlu memodifikasi landing zone untuk aplikasi, beri tahu tim landing zone tentang kebutuhan Anda. Misalnya, aplikasi Anda mungkin memerlukan akses ke layanan yang di-host di akun terpisah, atau aplikasi Anda mungkin memerlukan perutean khusus ke virtual private cloud (VPC).
-
Dependensi — Identifikasi aplikasi apa pun yang diandalkan aplikasi Anda agar berfungsi dengan baik. Misalnya, aplikasi Anda mungkin bergantung pada database, penyimpanan, atau layanan pihak ketiga, seperti gateway pembayaran atau layanan web eksternal, atau aplikasi Anda mungkin bergantung pada aplikasi lain di lingkungan Anda. Untuk mengakses dependensi ini, Anda mungkin memerlukan perutean atau konfigurasi khusus, seperti menghubungkan ke layanan direktori untuk otentikasi.
-
Aplikasi dependen — Identifikasi aplikasi apa pun yang bergantung pada aplikasi Anda agar berfungsi dengan baik. Anda mungkin perlu mengkonfigurasi ulang dan memperbarui aplikasi ini untuk mencegah waktu henti selama migrasi.
-
Keamanan dan kepatuhan - Tinjau lingkungan target dengan tim keamanan dan kepatuhan, dan identifikasi celah apa pun. Aplikasi ini mungkin terdiri dari beberapa komponen, lapisan logis, atau beberapa tingkatan. Bergantung pada persyaratan kepatuhan, Anda mungkin tidak dapat memigrasikan beberapa komponen ini ke lingkungan target, atau Anda mungkin memerlukan langkah-langkah keamanan tambahan saat memigrasikan beban kerja. Persyaratan keamanan dan kepatuhan yang umum adalah residensi data, enkripsi dalam perjalanan, dan enkripsi saat istirahat. Ini memerlukan konfigurasi tambahan di lingkungan target Anda. Misalnya, Anda mungkin perlu mengonfigurasi sertifikat untuk mengamankan komunikasi, atau Anda mungkin memerlukan kunci enkripsi untuk mengamankan data saat istirahat. Anda mungkin juga perlu memilih beberapa pola migrasi untuk aplikasi sehingga beberapa tingkatan aplikasi tetap berada di lokasi dan tingkatan lainnya dimigrasikan ke cloud.
-
Dependensi penyimpanan — Tinjau dependensi penyimpanan aplikasi Anda dan tentukan bagaimana migrasi aplikasi ke lingkungan target akan memengaruhi dependensi ini. Misalnya, jika aplikasi bergantung pada penyimpanan jaringan, seperti penyimpanan terpasang jaringan (NAS) atau jaringan area penyimpanan (SAN), Anda perlu merencanakan layanan penyimpanan di cloud, seperti Amazon Simple Storage Service (Amazon S3) atau Amazon. FSx Anda juga perlu merencanakan bagaimana Anda akan memigrasikan data Anda ke lingkungan cloud target agar aplikasi Anda tetap berjalan.
-
Database — Tinjau strategi migrasi untuk database apa pun yang digunakan aplikasi. Apakah Anda akan memplatform ulang ke layanan database baru, seperti Amazon Relational Database Service (Amazon RDS), Amazon Aurora, atau Amazon DynamoDB? Apakah Anda akan meng-host ulang database Anda di lingkungan target? Dalam beberapa kasus, terutama untuk database monolitik, Anda perlu memfaktorkan ulang database untuk memenuhi persyaratan teknis, seperti latensi sub-detik, atau untuk memanfaatkan fitur dari jenis database tertentu. AWS Seperti persyaratan kepatuhan residensi data, Anda perlu mengidentifikasi data mana yang harus disimpan di tempat dan mana yang harus dimigrasikan ke cloud. Misalnya, Anda mungkin perlu menyimpan tabel database lokal untuk informasi pelanggan, dan Anda dapat memigrasikan sisa database ke cloud.
-
Komponen aplikasi — Tinjau komponen yang bergantung pada aplikasi Anda. Tentukan apakah aplikasi Anda bergantung pada komponen yang tidak didukung oleh lingkungan target. Jika lingkungan target tidak mendukung semua komponen aplikasi, Anda perlu memfaktorkan ulang aplikasi untuk mengurangi masalah. Misalnya, jika Anda memiliki aplikasi.NET Framework yang bergantung pada komponen khusus Windows seperti Component Object Model (COM) Interop, COM+, atau registri Windows, untuk memplatform ulang aplikasi pada sistem operasi Linux, Anda harus memfaktorkan ulang aplikasi ke .NET Core.
-
Tingkatan aplikasi — Identifikasi jumlah tingkatan dalam aplikasi Anda. Apakah aplikasi n-tier, two-tier, atau standalone? Konfirmasikan bahwa Anda memahami pola migrasi untuk setiap tingkatan. Misalnya, aplikasi Anda mungkin memiliki tingkat presentasi (atau web) yang menghosting antarmuka pengguna, tingkat aplikasi yang menghosting layanan bisnis, dan tingkat basis data yang menghosting database, dan setiap tingkat mungkin memerlukan pola migrasi yang berbeda.
-
Pemulihan bencana - Identifikasi rencana pemulihan bencana (DR) aplikasi saat ini dan masa depan, termasuk tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). Putuskan apakah akan menggunakan rencana DR lokal yang ada atau untuk menjelajahi strategi DR baru di cloud. Untuk informasi selengkapnya, lihat bagian Opsi pemulihan bencana di cloud dan tujuan Pemulihan (RTO dan RPO) di Disaster Recovery of Workloads on AWS: Recovery in the Cloud whitepaper.
Tentukan proses status target
Untuk menentukan status target aplikasi, kami sarankan Anda menggunakan templat yang disediakan, Lembar kerja status target aplikasi (format Excel), yang tersedia di templat buku pedoman portofolio. Template mencakup atribut standar yang dapat Anda gunakan atau modifikasi. Tentukan proses untuk mendokumentasikan status target aplikasi sebagai berikut:
-
Buka lembar kerja status target aplikasi.
-
Tinjau atribut default dan buat perubahan apa pun untuk kasus penggunaan Anda.
-
Simpan lembar kerja.
-
Buka runbook prioritas aplikasi Anda.
-
Di bagian Status aplikasi Target, lakukan hal berikut:
-
Di bagian Kapan menyelesaikan proses ini, tetapkan kriteria yang memungkinkan tim portofolio untuk menentukan apakah mereka perlu menentukan status target aplikasi.
-
Perbarui bagian atribut sesuai kebutuhan.
-
Perbarui bagian proses sesuai kebutuhan untuk kasus penggunaan Anda.
-
-
Simpan runbook prioritas aplikasi.
Sampel dari status target aplikasi
Tabel berikut menunjukkan contoh bagaimana Anda menggunakan lembar kerja status target Aplikasi untuk mendokumentasikan status target aplikasi.
| Aplikasi | Contoh |
|---|---|
Platform target |
AWS Cloud |
Zona pendaratan |
Memerlukan akses ke layanan direktori lokal Membutuhkan AWS Control Tower untuk memusatkan pengelolaan beberapa akun dan layanan di seluruh organisasi |
Dependensi |
Active Directory, gateway pembayaran, sistem inventaris |
Aplikasi tergantung |
Tidak ada |
Keamanan |
Enkripsi saat istirahat dan dalam transit |
Kepatuhan |
PCI, SOC |
Dependensi penyimpanan |
Boot drive terpasang, NAS, berbagi jaringan |
Basis Data |
Saat ini: Oracle DB Cloud: Amazon RDS for Oracle |
Komponen aplikasi |
.NET Framework 4.5 |
Tingkatan aplikasi |
N-tingkat Front-end, layanan bisnis, layanan data dan agen, database |
Pemulihan bencana |
RPO: 1 menit, RTO: 5 menit Strategi DR saat ini adalah siaga hangat DR di wilayah AS mana pun |
Kriteria keluar langkah
-
Di lembar kerja status target aplikasi, Anda telah menentukan atribut yang ingin Anda sertakan dalam proses status target.
-
Dalam runbook prioritas aplikasi Anda, Anda telah melakukan hal berikut:
-
Anda telah menetapkan kriteria kapan tim portofolio diharapkan untuk menentukan status target aplikasi.
-
Anda telah memperbarui proses untuk menentukan status target berdasarkan kasus penggunaan Anda.
-
Langkah 4: Selesaikan proses penyelaman mendalam aplikasi
Sekarang, Anda menentukan bagaimana alur kerja portofolio menggunakan lokakarya, aturan, dan proses yang Anda buat dalam tugas ini untuk melakukan penyelaman mendalam ke dalam aplikasi. Ini adalah proses yang direferensikan oleh alur kerja portofolio dalam tahap implementasi migrasi.
Sesuaikan proses ini di runbook prioritas aplikasi sebagai berikut:
-
Buka runbook prioritas aplikasi Anda.
-
Di Tahap 2: Lakukan aplikasi deep dive, modifikasi proses yang sesuai untuk kasus penggunaan dan lingkungan Anda.
-
Simpan runbook prioritas aplikasi.
-
Bagikan runbook prioritas aplikasi Anda dengan tim untuk ditinjau.
