Desain arsitektur beban kerja sebelum migrasi

Artikel ini menjelaskan proses dan pertimbangan untuk merancang status beban kerja yang dimigrasikan yang dimaksudkan di cloud. Artikel ini meninjau aktivitas yang merupakan bagian dari menentukan arsitektur beban kerja dalam iterasi.

Artikel tentang rasionalisasi inkremental menunjukkan bahwa beberapa asumsi arsitektur adalah bagian dari transformasi bisnis apa pun yang mencakup migrasi. Artikel ini mengklarifikasi asumsi umum. Ini juga menunjuk ke beberapa hambatan yang dapat Anda hindari, dan mengidentifikasi peluang untuk mempercepat nilai bisnis dengan menantang asumsi arsitektur. Model inkremental ini untuk merancang arsitektur membantu tim bergerak lebih cepat dan mendapatkan hasil bisnis lebih cepat.

Desain arsitektur dasar pada asumsi umum

Asumsi berikut umum untuk setiap upaya migrasi:

• Asumsikan beban kerja infrastruktur sebagai layanan (IaaS). Migrasi beban kerja terutama melibatkan pemindahan server dari pusat data fisik ke pusat data cloud melalui migrasi IaaS. Proses ini biasanya memerlukan pembangunan ulang atau konfigurasi ulang minimal. Pendekatan ini dikenal sebagai migrasi lift dan shift .
• Menjaga arsitektur tetap konsisten. Membuat perubahan pada arsitektur inti selama migrasi jauh meningkatkan kompleksitas. Men-debug sistem yang berubah pada platform baru akan menghadirkan banyak variabel yang mungkin sulit untuk diisolasi. Beban kerja hanya boleh mengalami perubahan kecil selama migrasi, dan setiap perubahan harus diuji secara menyeluruh.
• Rencanakan untuk mengubah ukuran aset. Asumsikan bahwa beberapa aset lokal sepenuhnya menggunakan sumber daya apa pun. Sebelum atau selama migrasi, aset diubah ukurannya agar paling sesuai dengan persyaratan penggunaan aktual. Alat seperti Azure Migrate dan Modernisasi menyediakan ukuran berdasarkan penggunaan aktual.
• Menangkap persyaratan kelangsungan bisnis dan pemulihan bencana (BCDR). Jika Anda memiliki perjanjian tingkat layanan (SLA) yang disepakati untuk beban kerja yang sudah dinegosiasikan dengan bisnis, terus gunakan SLA setelah migrasi ke Azure. Jika SLA belum diatur, tentukan sebelum Anda merancang beban kerja di cloud untuk memastikan bahwa Anda merancang dengan tepat.
• Merencanakan waktu henti migrasi. Seperti gagal memenuhi persyaratan SLA, waktu henti yang terjadi ketika Anda mempromosikan beban kerja ke produksi dapat memiliki efek buruk pada bisnis. Terkadang solusi yang harus bertransisi dengan waktu henti minimal membutuhkan perubahan arsitektur. Sebelum Anda memulai perencanaan rilis, asumsikan bahwa pemahaman umum tentang persyaratan waktu henti ditetapkan.
• Tentukan pola lalu lintas pengguna dan aplikasi. Solusi yang ada mungkin bergantung pada pola dan solusi perutean jaringan yang ada. Identifikasi sumber daya yang Anda butuhkan untuk mendukung penggunaan jaringan saat ini.
• Rencanakan untuk menghindari konflik jaringan. Saat Anda mengonsolidasikan pusat data ke dalam satu penyedia cloud, Anda cenderung membuat konflik di Sistem Nama Domain (DNS) atau struktur jaringan lainnya. Selama migrasi, penting untuk merancang untuk menghindari konflik ini untuk menghindari gangguan pada sistem produksi yang dihosting di cloud.
• Rencanakan untuk tabel perutean. Pastikan proyek Anda menyertakan rencana untuk memodifikasi tabel perutean jika Anda mengonsolidasikan jaringan atau pusat data. Pertimbangkan persyaratan perutean pusat data silang.

Desain arsitektur untuk zona pendaratan

Dalam fase Siap dari Cloud Adoption Framework, organisasi Anda menyebarkan layanan platform bersama sebagai bagian dari mengadopsi zona pendaratan Azure. Di Siapkan zona pendaratan Anda untuk migrasi, Anda menyiapkan zona pendaratan untuk menerima beban kerja yang dimigrasikan.

Berdasarkan perencanaan ini, Anda dapat mengasumsikan bahwa komponen migrasi berikut ini sudah ada:

• Konektivitas hibrid menghubungkan jaringan Azure Anda ke jaringan lokal Anda.
• Appliance keamanan jaringan seperti Azure Firewall menangani pemeriksaan lalu lintas di luar beban kerja Anda.
• Kebijakan Azure untuk menerapkan praktik tata kelola seperti persyaratan pengelogan, wilayah yang diizinkan, layanan yang tidak diizinkan, dan kontrol lainnya aktif.
• Ruang kerja Log Azure Monitor untuk pengelogan bersama disiapkan di Azure Monitor.
• Sumber daya identitas bersama untuk mendukung server yang bergabung dengan domain atau kebutuhan identitas lainnya dibuat.

Jika migrasi penting ini tidak dibuat, organisasi Anda harus segera mengunjungi kembali fase Siap untuk mengatasi kebutuhan ini. Tanpa komponen ini, migrasi Anda kemungkinan akan mengalami penundaan dan kemunduran dan kurang berhasil.

Beban kerja yang Anda rancang memiliki langganan yang ditetapkan untuknya, idealnya melalui proses penjual langganan. Langganan mungkin berisi beberapa beban kerja atau hanya satu beban kerja tergantung pada bagaimana organisasi Anda menyelesaikan organisasi sumber dayanya untuk beban kerja. Jika Anda memigrasikan beban kerja yang memiliki banyak lingkungan aplikasi, Anda bahkan mungkin memiliki beberapa langganan berdasarkan panduan untuk lingkungan aplikasi.

Desain arsitektur jaringan beban kerja

Rencanakan untuk menyebarkan sumber daya khusus aplikasi ke langganan tertentu, dan rencanakan untuk merancang jaringan virtual khusus untuk beban kerja. Untuk informasi selengkapnya, lihat panduan untuk merancang arsitektur jaringan Anda. Anda harus fokus pada segmentasi jaringan virtual.

Jaringan Anda kemungkinan membutuhkan sumber daya seperti load balancer dan sumber daya pengiriman aplikasi lainnya. Anda dapat menggunakan panduan arsitektur N-tingkat untuk merencanakan sumber daya ini di Azure.

Mendesain dependensi beban kerja

Alat penilaian migrasi Anda harus memberi Anda cara untuk melakukan analisis dependensi, seperti analisis dependensi di Azure Migrate dan Modernisasi. Alat ini membantu Anda mengidentifikasi interdependensi antar server.

Selain merencanakan arsitektur untuk beban kerja itu sendiri, Anda mungkin perlu mempertimbangkan dependensi beban kerja ke beban kerja. Misalnya, beberapa beban kerja mungkin memerlukan komunikasi yang sering. Jika demikian, merencanakan gelombang dan dependensi migrasi Anda untuk memperhitungkan persyaratan ini membantu membuat migrasi Anda berhasil.

Anda dapat menggunakan panduan di Azure Architecture Center, seperti untuk jaringan spoke-to-spoke , untuk merancang cara kerja beban kerja yang saling terhubung setelah migrasi.

Bersiap untuk mengadopsi komputasi rahasia

Subset beban kerja Anda dengan persyaratan kedaulatan dapat menyebabkan penggunaan komputasi rahasia. Sebagai bagian dari penyebaran zona pendaratan berdaulat, grup manajemen untuk komputasi rahasia dibuat.

Dalam konteks kedaulatan, menggunakan komputasi rahasia memerlukan Azure Key Vault dan kunci yang dikelola pelanggan sebagai layanan pendukung. Untuk informasi selengkapnya, lihat enkripsi dengan kunci yang dikelola pelanggan di Microsoft Cloud for Sovereignty.

Memperbarui perkiraan cloud awal Anda

Saat Anda menyelesaikan desain arsitektur, kunjungi kembali perkiraan cloud Anda untuk memastikan bahwa Anda masih dalam anggaran yang direncanakan. Saat Anda menambahkan layanan pendukung seperti load balancer atau cadangan, biaya dapat berubah. Meskipun Anda dapat menggunakan alat seperti kasus bisnis di Azure Migrate dan Modernisasi untuk melakukan latihan manajemen biaya terperinci, Anda harus secara berkala mengunjungi kembali perkiraan saat Menyesuaikan desain arsitektur Anda.

Jika Anda terbiasa dengan proses pengadaan IT tradisional, memperkirakan sumber daya di cloud mungkin tampak asing. Ketika Anda mengadopsi teknologi cloud, akuisisi bergeser dari model pengeluaran modal yang kaku dan terstruktur ke model pengeluaran operasi yang lancar. Merencanakan migrasi ke cloud sering kali adalah pertama kalinya organisasi atau tim TI mengalami perubahan ini.

Dalam model pengeluaran modal tradisional, tim TI mencoba menggabungkan daya beli untuk beberapa beban kerja di berbagai program. Pendekatan ini mempusatkan kumpulan aset IT bersama yang dapat mendukung masing-masing solusi tersebut. Dalam model cloud biaya operasi, biaya dapat langsung dikaitkan dengan kebutuhan dukungan beban kerja individu, tim, atau unit bisnis. Ini memberi organisasi atribusi biaya yang lebih langsung kepada pelanggan internal dan tujuan bisnis yang mereka dukung. Pendekatan yang lebih dinamis untuk manajemen keuangan ini sering disebut operasi keuangan (FinOps). Meskipun FinOps bukan pertimbangan khusus Azure, akan sangat membantu untuk memiliki pemahaman yang diperluas tentang FinOps. Untuk informasi selengkapnya, lihat Apa itu FinOps?.

Saat merancang arsitektur beban kerja untuk migrasi, Anda dapat menggunakan kalkulator harga dengan informasi penilaian Anda untuk memahami harga seluruh beban kerja.

Selain itu, setelah beban kerja Anda dimigrasikan, Anda harus terus bekerja untuk mengoptimalkan biaya beban kerja. Untuk informasi selengkapnya tentang bagaimana organisasi dapat mematangkan keterampilan manajemen biaya mereka, lihat Meningkatkan disiplin manajemen biaya.

Ketahui kapan harus mengubah arsitektur Anda

Migrasi cenderung berfokus pada mempertahankan arsitektur yang ada dan mentransisikannya ke platform cloud Anda. Namun, ada kalanya Anda mungkin perlu merancang ulang beban kerja Anda, bahkan untuk migrasi. Daftar ini memberikan contoh kapan Anda mungkin perlu membuat perubahan arsitektur sebelum bermigrasi:

• Membayar utang teknis. Beberapa beban kerja yang menua membawa sejumlah besar utang teknis. Utang teknis dapat menyebabkan tantangan jangka panjang dengan meningkatkan biaya hosting dengan penyedia cloud mana pun. Ketika utang teknis secara tidak wajar meningkatkan biaya hosting, Anda harus mengevaluasi arsitektur alternatif.
• Meningkatkan keandalan. Garis besar operasi standar memberikan tingkat keandalan dan pemulihan di cloud. Beberapa tim beban kerja mungkin memerlukan SLA yang lebih tinggi, yang dapat menyebabkan perubahan arsitektur.
• Beban kerja berbiko tinggi. Selama migrasi, Anda harus mengoptimalkan semua aset untuk menyelaraskan ukuran dengan penggunaan aktual. Beberapa beban kerja mungkin memerlukan modifikasi arsitektur untuk mengatasi masalah biaya tertentu.
• Persyaratan performa. Ketika performa beban kerja secara langsung memengaruhi bisnis, pertimbangan arsitektur tambahan mungkin diperlukan.
• Mengamankan aplikasi. Persyaratan keamanan cenderung diterapkan secara terpusat dan biasanya diterapkan ke semua beban kerja dalam portofolio. Beberapa beban kerja mungkin memiliki persyaratan keamanan khusus yang dapat menyebabkan perubahan arsitektur.

Masing-masing kriteria ini berfungsi sebagai indikator potensi hambatan migrasi. Dalam kebanyakan kasus, Anda dapat mengatasi kriteria setelah memigrasikan beban kerja dengan server ukuran yang tepat, menambahkan server baru, atau membuat perubahan lain. Namun, jika salah satu kriteria tersebut diperlukan sebelum Anda memigrasikan beban kerja, hapus beban kerja dari gelombang migrasi dan evaluasi satu per satu.

Azure Well-Architected Framework dan Azure Well-Architected Review dapat membantu memandu percakapan dengan pemilik teknis beban kerja tertentu untuk membantu mereka mempertimbangkan opsi alternatif untuk menyebarkan beban kerja.

Beban kerja kemudian diklasifikasikan sebagai upaya rearchitecture atau modernisasi dalam rencana adopsi cloud Anda. Karena waktu tambahan yang diperlukan untuk merancang ulang beban kerja, pertimbangkan jalur adopsi beban kerja alternatif ini sebagai terpisah dari proses migrasi.

Daftar periksa arsitektur

Anda dapat menggunakan daftar periksa berikut untuk memastikan bahwa Anda membahas pertimbangan arsitektur penting:

• Konfirmasikan bahwa arsitektur Anda memenuhi SLA untuk ketersediaan, pemulihan bencana, dan pemulihan data.
• Konfirmasikan bahwa Anda menerapkan praktik segmentasi jaringan ke desain jaringan Anda.
• Konfirmasikan bahwa Anda berencana untuk memantau dan menangkap log.
• Konfirmasikan bahwa komputer virtual Anda berukuran tepat untuk waktu komputasi aktual yang Anda butuhkan.
• Konfirmasikan bahwa disk Anda berukuran tepat untuk ukuran dan performa aktual yang Anda butuhkan.
• Konfirmasikan bahwa Anda merencanakan layanan penyeimbangan beban jika diperlukan. Layanan ini mungkin mencakup instans Azure Load Balancer, Azure Application Gateway, Azure Front Door, atau Azure Traffic Manager.
• Konfirmasikan bahwa Anda merencanakan persyaratan kedaulatan dan komputasi rahasia jika diperlukan.

Langkah selanjutnya

Menyebarkan beban kerja migrasi