Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Solusi cloud-native menciptakan nilai bisnis dengan membangun beban kerja baru atau meningkatkan yang sudah ada. Baik Anda mengembangkan aplikasi baru atau menambahkan fitur baru ke sistem yang ada, pengembangan cloud-native adalah perjalanan melalui perencanaan, pembangunan, penyebaran, dan pengoptimalan beban kerja Anda. Kerangka kerja ini memberikan panduan untuk menyelaraskan aplikasi Anda dengan tujuan bisnis, praktik terbaik arsitektur, dan manajemen risiko.
Prasyarat:Zona pendaratan Azure
Menentukan tujuan bisnis untuk solusi cloud-native
Mulailah dengan tujuan bisnis yang jelas. Tentukan hasil spesifik yang harus dicapai solusi Anda, seperti mengaktifkan produk digital baru, memasuki pasar baru, meningkatkan pengalaman pelanggan, atau mengurangi biaya operasional. Gunakan indikator terukur seperti pertumbuhan pendapatan, pengurangan waktu ke pasar, atau volume tiket dukungan untuk mengukur keberhasilan. Untuk fitur baru, tentukan tujuan seperti meningkatkan pengalaman pelanggan, mengurangi biaya operasional, atau meningkatkan skalabilitas sistem.
Identifikasi batasan dan kriteria keberhasilan. Dokumentasikan batasan bisnis apa pun seperti anggaran, kepatuhan, atau garis waktu pengiriman. Tentukan seperti apa kesuksesan untuk setiap tujuan. Misalnya, "luncurkan portal pelanggan baru pada Q4" atau "kurangi latensi checkout sebesar 40%." Kriteria ini menjadi panduan untuk memprioritaskan dan membantu mengevaluasi kompromi selama perencanaan.
Memvalidasi penyelarasan pemangku kepentingan. Konfirmasikan semua pemangku kepentingan (bisnis dan teknis) menyetujui tujuan, batasan, dan seperti apa kesuksesannya. Penyelarasan ini mungkin melibatkan lokakarya atau persetujuan formal. Keselarasan awal mencegah miskomunikasi nanti dan menghindari pengerjaan ulang yang mahal, memastikan semua orang berbagi harapan yang sama sejak awal.
Menentukan persyaratan untuk solusi cloud-native
Persyaratan fungsi dokumen. Dokumentasikan kemampuan dan fitur yang harus disediakan sistem untuk memenuhi kebutuhan pengguna. Setiap persyaratan harus mengikat kembali ke tujuan bisnis, memastikan upaya pengembangan secara langsung mendukung hasil yang diinginkan. Gunakan wawancara pemangku kepentingan dan dokumen strategi bisnis untuk mengidentifikasi hasil bernilai tinggi. Prioritaskan fitur berdasarkan nilai bisnis dan kelayakan teknis. Lacak setiap persyaratan ke tujuan bisnis yang terukur untuk membenarkan penyertaannya.
Menetapkan persyaratan nonfungsional. Persyaratan nonfungsi menentukan persyaratan teknis untuk memenuhi persyaratan dan tata kelola fungsional. Tetapkan atribut kualitas dan target teknis yang diperlukan untuk mendukung fitur tersebut. Tentukan metrik keandalan target seperti tujuan tingkat layanan (SCO) untuk waktu aktif, tujuan titik pemulihan (RPO), dan tujuan waktu pemulihan (RTO). Menetapkan garis besar keamanan. Buat model biaya. Tetapkan target performa.
Kendali cakupan solusi cloud-native. Tentukan dengan jelas apa yang termasuk dalam cakupan dan yang tidak termasuk untuk rilis awal. Sangat menggoda untuk menyertakan lebih banyak fitur yang bagus untuk dimiliki, tetapi perluasan cakupan yang tak terencana dapat membahayakan jadwal dan anggaran. Dokumentasikan batas solusi Anda dan terapkan proses kontrol perubahan untuk permintaan baru apa pun. Hanya menyetujui perubahan yang secara langsung mendukung tujuan yang ditentukan dan yang dapat dikirimkan tanpa merusak jadwal atau anggaran. Tangguhkan ide berprioritas lebih rendah ke backlog masa depan. Mengelola cakupan secara ketat membuat tim fokus pada memberikan fungsionalitas yang paling berharga terlebih dahulu dalam batasan.
Merencanakan arsitektur cloud-native
Arsitektur yang terencana dengan baik sangat penting untuk memenuhi tujuan dan persyaratan Anda. Setiap keputusan arsitektur utama melibatkan pertukaran dalam skalabilitas, kompleksitas, biaya, dan kelincahan. Langkah-langkah dan poin keputusan berikut membantu Anda membuat desain cloud-native yang selaras dengan praktik terbaik:
Menjelajahi arsitektur cloud-native yang divalidasi
Tinjau dasar-dasar arsitektur. Sebelum menemukan arsitektur dari awal, tinjau arsitektur referensi dan dasar-dasar yang divalidasi dari Azure Architecture Center. Jelajahi arsitektur referensi yang divalidasi untuk beban kerja umum. Arsitektur ini membantu mempercepat keputusan desain dan mengurangi risiko.
Pilih gaya arsitektur yang sesuai. Pilih gaya arsitektur berdasarkan karakteristik beban kerja dan kemampuan tim Anda. Gaya arsitektur termasuk N-tingkat (monolitik), layanan mikro, berbasis peristiwa (berbasis pesan), pekerja antrean web. Misalnya, jika Anda memerlukan pengembangan cepat untuk aplikasi yang relatif sederhana, monolit N-tingkat yang terstruktur dengan baik mungkin sudah cukup. Untuk aplikasi berskala besar atau berkembang pesat dengan domain yang berbeda, layanan mikro, atau pendekatan berbasis peristiwa menawarkan fleksibilitas (dengan biaya kompleksitas). Dalam praktiknya, banyak sistem berakhir dengan gaya hibrid. Misalnya, ada inti layanan mikro dengan beberapa layanan bersama atau subsistem berbasis peristiwa. Kuncinya adalah memahami trade-off dari setiap gaya dan memilih pendekatan yang paling memenuhi persyaratan skalabilitas, ketahanan, dan kelincahan Anda.
Menerapkan praktik terbaik desain. Apa pun gaya yang Anda pilih, patuhi dasar-dasar arsitektur cloud dan praktik terbaik. Azure Architecture Center menyediakan katalog pola desain cloud (Coba lagi, Pemutus Sirkuit, CQRS) yang mengatasi tantangan umum dalam beban kerja terdistribusi. Mengintegrasikan pola-pola ini ke dalam desain Anda dapat meningkatkan keandalan dan performa.
Integrasikan lima pilar ke dalam keputusan desain. Gunakan Well-Architected Framework untuk memandu keputusan di seluruh keandalan, keamanan, efisiensi performa, pengoptimalan biaya, dan keunggulan operasional. Kelima pilar ini harus menginformasikan semua keputusan desain. Misalnya, saat memilih database, pertimbangkan keandalan (redundansi, cadangan), performa, dan biaya bersama-sama untuk mencapai keseimbangan yang tepat. Catat di mana Anda membuat pertimbangan antara pilar, seperti biaya lebih tinggi untuk performa yang lebih tinggi. Catatan ini berharga untuk tata kelola dan ulasan di masa mendatang.
Merencanakan integrasi dengan sistem yang ada
Inventarisasi semua sistem dan layanan dependen. Solusi cloud-native baru jarang beroperasi dalam isolasi, kecuali Anda adalah perusahaan rintisan tahap awal. Pertimbangkan bagaimana beban kerja atau fitur baru Anda sesuai dengan lingkungan. Memetakan aliran data dan memastikan kompatibilitas dengan standar. Buat daftar komprehensif semua sistem yang berinteraksi dengan beban kerja Anda. Daftar ini mencakup API internal, database, penyedia identitas (ID Microsoft Entra), alat pemantauan, alur CI/CD, dan sistem lokal yang diakses melalui VPN atau ExpressRoute. Gunakan diagram arsitektur dan peta dependensi untuk memvisualisasikan hubungan ini.
Mengklasifikasikan jenis dan protokol integrasi. Kategorikan setiap titik integrasi berdasarkan jenis (autentikasi, pertukaran data, olahpesan) dan protokol (REST, gRPC, ODBC, SAML, OAuth2). Klasifikasi ini membantu mengidentifikasi persyaratan kompatibilitas dan potensi hambatan.
Memvalidasi identitas dan integrasi akses. Pastikan solusi Anda terintegrasi dengan IdP organisasi. Misalnya, gunakan ID Microsoft Entra untuk autentikasi dan otorisasi alih-alih memperkenalkan sistem identitas baru. Konfirmasikan dukungan untuk akses menyeluruh (SSO), kontrol akses berbasis peran (RBAC), dan kebijakan akses bersyarat.
Menilai konektivitas dan keamanan jaringan. Tinjau bagaimana beban kerja Anda terhubung ke sistem lain. Memvalidasi aturan firewall, resolusi DNS, dan jalur perutean. Untuk skenario hibrid, konfirmasikan konfigurasi ExpressRoute atau VPN diberlakukan dan diuji. Gunakan Azure Network Watcher untuk memantau dan memecahkan masalah konektivitas.
Pastikan kompatibilitas dan kepatuhan aliran data. Memetakan aliran data antar sistem. Mengonfirmasi format, skema, dan persyaratan transformasi data. Pastikan kepatuhan terhadap kebijakan residensi, enkripsi, dan retensi data.
Menguji titik integrasi lebih awal dan berkelanjutan. Lakukan pengujian integrasi selama tahap pengembangan awal. Gunakan tiruan atau stub untuk sistem yang tidak tersedia. Otomatiskan pengujian ini di alur CI/CD Anda menggunakan alat seperti Azure DevOps atau GitHub Actions. Pantau latensi, throughput, dan tingkat kesalahan. Misalnya, Anda ingin menghindari situasi di mana API yang aplikasi Anda bergantung pada tidak dapat mendukung beban yang diperlukan atau firewall jaringan yang memblokir layanan Anda.
Kontrak integrasi dokumen dan SLA. Tentukan dan dokumentasikan perilaku, ketersediaan, dan performa yang diharapkan dari setiap titik integrasi. Sertakan logika pengulangan, pengaturan batas waktu, dan mekanisme fallback. Selaras dengan perjanjian tingkat layanan (SLA) sistem dependen.
Pilih layanan dan tingkat layanan Azure yang sesuai
Gunakan panduan keputusan untuk memilih layanan yang cocok dengan persyaratan beban kerja. Azure menyediakan beberapa opsi untuk menjalankan kode aplikasi Anda, masing-masing dengan pro dan kontra. Tinjau ringkasan pilihan teknologi untuk mengidentifikasi layanan yang selaras dengan persyaratan fungsional dan nonfungsi Anda. Prioritaskan opsi platform-as-a-service (PaaS) karena layanan ini mengurangi overhead operasional dengan menangani manajemen infrastruktur, patching, dan penskalaan secara otomatis.
Tentukan pola penggunaan dan persyaratan performa untuk memilih tingkat layanan. Pemilihan tingkat layanan memengaruhi biaya dan kemampuan. Mendokumen volume transaksi yang diharapkan, beban pengguna bersamaan, persyaratan penyimpanan, dan target performa seperti waktu respons dan throughput. Gunakan metrik ini untuk memilih tingkat layanan awal (SKU) yang memenuhi persyaratan dasar tanpa provisi berlebihan yang signifikan. Rencanakan untuk menyesuaikan tingkatan berdasarkan pola penggunaan aktual setelah penyebaran.
Validasi kompatibilitas fitur di seluruh tingkat layanan yang dipilih. Fitur penting seperti kemampuan keamanan tingkat lanjut, opsi ketersediaan tinggi, atau API integrasi bervariasi menurut tingkat layanan. Buat matriks fitur yang memetakan kemampuan yang diperlukan untuk SKU yang tersedia. Pastikan tingkat yang dipilih mendukung semua fitur yang diperlukan untuk menghindari migrasi mahal atau perubahan arsitektur nanti. Referensi dokumentasi khusus layanan untuk mengonfirmasi ketersediaan dan batasan fitur.
Pilih berapa banyak wilayah yang akan digunakan
Evaluasi pertimbangan penyebaran multi-wilayah. Arsitektur wilayah tunggal lebih sederhana dan lebih murah, tetapi pemadaman regional akan menurunkan aplikasi Anda. Penyebaran multi-wilayah dapat mencapai ketersediaan yang lebih tinggi (satu wilayah dapat gagal dan pengguna dilayani dari wilayah lain) dan juga dapat meningkatkan performa dengan melayani pengguna dari wilayah terdekat. Kompromi ini meningkatkan kompleksitas dalam penyebaran dan sinkronisasi data. Anda harus menangani replikasi data di seluruh wilayah dengan potensi masalah konsistensi, perutean lalu lintas global, dan biaya yang lebih tinggi. Biarkan persyaratan keandalan Anda mendorong keputusan ini.
Gunakan target keandalan untuk memandu strategi regional. Tentukan tujuan tingkat layanan (SLO), tujuan titik pemulihan (RPO), dan tujuan waktu pemulihan (RTO) untuk menentukan persyaratan regional.
Memastikan kepatuhan terhadap peraturan residensi data. Bekerja sama dengan tim hukum dan kepatuhan untuk memastikan pilihan regional memenuhi kewajiban peraturan.
Arsitektur Dokumen
Buat diagram arsitektur terperinci dan dokumen desain. Dokumentasi mendukung implementasi, peninjauan, dan pemeliharaan di masa mendatang. Sertakan layanan, SKU, aliran data, dan interaksi pengguna Azure yang dipilih. Pastikan diagram memberikan representasi visual arsitektur yang jelas untuk mendukung implementasi dan tinjauan.
Catat keputusan desain utama dan trade-off. Dokumentasikan alasan di balik pilihan arsitektur, termasuk persyaratan nonfungsi seperti keandalan, keamanan, dan performa. Soroti setiap trade-off yang dibuat untuk menyeimbangkan prioritas bersaing.
Merencanakan strategi penerapan cloud-native
Saat Anda menyebarkan solusi cloud-native ke lingkungan produksi, ikuti strategi yang direncanakan daripada pendekatan ad-hoc. Rencana penyebaran yang solid meminimalkan efek pada pengguna dan menyediakan cara untuk memulihkan jika ada yang salah.
Merencanakan praktik pengembangan dan penyebaran
Praktik pengembangan dan penyebaran memastikan pengiriman yang konsisten dan kesiapan operasional di seluruh lingkungan. Praktik ini mengurangi risiko penyebaran dan meningkatkan koordinasi tim.
Menetapkan praktik DevOps untuk otomatisasi penyebaran. Praktik DevOps menyelaraskan tim pengembangan dan operasi melalui otomatisasi, kontrol versi, dan alur CI/CD. Gunakan alat seperti Azure DevOps atau GitHub Actions untuk mengotomatiskan alur kerja build, pengujian, dan penyebaran. Pendekatan ini mengurangi kesalahan manual, mempercepat siklus rilis, dan menyediakan proses penyebaran yang konsisten di seluruh lingkungan.
Merencanakan kesiapan operasional untuk mendukung aktivitas penyebaran. Kesiapan operasional termasuk pemantauan, pemberitahuan, dan prosedur respons insiden untuk skenario penyebaran. Dokumentasikan runbook penerapan dan skrip otomatisasi yang mencakup prosedur pengembalian, pemeriksaan kesehatan, dan langkah-langkah pemecahan masalah. Simpan sumber daya ini di lokasi pusat seperti Azure DevOps Wiki atau GitHub untuk memastikan aksesibilitas selama aktivitas penyebaran.
Tentukan praktik pengembangan yang mendukung penyebaran yang andal. Gunakan standar pengodean, tinjauan serekan, dan pengujian otomatis untuk memastikan kualitas kode dan kesiapan penyebaran. Integrasikan praktik ini ke dalam alur CI/CD Anda untuk memberlakukan gerbang kualitas sebelum penyebaran. Sertakan pengujian khusus penyebaran seperti pengujian integrasi, uji asap, dan validasi performa untuk memverifikasi kesiapan sistem untuk produksi.
Merencanakan penyebaran untuk beban kerja baru
Gunakan paparan progresif untuk membatasi dampak. Untuk aplikasi baru (greenfield) tanpa pengguna yang ada, Anda harus melakukan peluncuran sementara. Mengerahkan ke lingkungan produksi tetapi mengeksposnya hanya kepada pengguna internal atau grup pilot pada tahap awal. Pendekatan ini adalah penyebaran kenari untuk beban kerja baru. Jika benar-benar baru dan terisolasi, penyebaran langsung sekali saja ke produksi penuh dimungkinkan, tetapi penerapan bertahap masih disarankan untuk mengidentifikasi masalah apa pun secara terkontrol. Jangan merilis sistem ke semua pengguna pada hari pertama tanpa beberapa validasi dunia nyata terlebih dahulu. Untuk informasi selengkapnya, lihat WAF - Mengadopsi model paparan progresif.
Mendokumentasikan prosedur operasional dan rute eskalasi. Buat dokumentasi yang jelas untuk memulai ulang layanan, mengakses log, menangani masalah umum, dan meningkatkan insiden. Simpan dokumentasi ini di repositori bersama seperti SharePoint atau GitHub untuk memastikan ketersediaan untuk tim dukungan.
Merencanakan penyebaran untuk fitur baru
Rencanakan integrasi fitur baru menggunakan manajemen perubahan. Ikuti proses manajemen perubahan organisasi Anda untuk mengontrol dan mendokumen perubahan produksi. Tentukan prosedur putar kembali, seperti mengembalikan versi aplikasi atau memulihkan cadangan database. Amankan persetujuan pemangku kepentingan sebelum penyebaran untuk memastikan keselarasan dengan tujuan bisnis. Untuk informasi selengkapnya, lihat Mengelola perubahan di CAF.
Gunakan pembaruan langsung untuk perubahan kecil atau yang kompatibel ke belakang. Sebarkan pembaruan langsung ke lingkungan produksi menggunakan pembaruan bergulir atau bendera fitur. Mulailah dengan persentase kecil pengguna atau instans. Pantau metrik dan log sistem untuk memvalidasi stabilitas sebelum peluncuran penuh.
Gunakan penyebaran paralel (biru-hijau) untuk perubahan besar atau berisiko tinggi. Sebarkan versi baru di lingkungan terpisah. Rutekan sebagian kecil lalu lintas langsung ke versi baru untuk memvalidasi perilaku. Jika berhasil, alihkan semua lalu lintas ke versi baru. Jika masalah muncul, kembalikan lalu lintas ke versi asli untuk memastikan kelangsungan.
Rencanakan penyerahan operasional untuk beban kerja baru. Identifikasi tim yang bertanggung jawab untuk mengoperasikan dan mendukung solusi pasca-penyebaran. Tentukan model dukungan (dukungan on-call atau jam kerja 24/7) dan pastikan semua pemangku kepentingan memahami peran mereka.
Tentukan tanggung jawab kepemilikan dan dukungan. Konfirmasikan bahwa tim operasi siap untuk mendukung fitur baru. Perbarui dokumentasi dan jalur eskalasi untuk mencerminkan tanggung jawab baru dan memastikan respons insiden yang cepat.
Menentukan rencana pembatalan untuk solusi cloud-native
Rencana putar kembali memungkinkan tim untuk dengan cepat membalikkan perubahan ketika penyebaran gagal atau menimbulkan risiko. Rencana yang ditentukan dengan baik meminimalkan waktu henti, membatasi dampak bisnis, dan mempertahankan keandalan sistem. Selalu tetapkan kriteria dan prosedur pembatalan sebelum memulai migrasi atau penyebaran apa pun.
Definisikan penyebaran yang gagal. Berkolaborasi dengan pemangku kepentingan bisnis, pemilik beban kerja, dan tim operasi untuk memutuskan apa yang dihitung sebagai penyebaran yang gagal. Contohnya termasuk pemeriksaan kesehatan yang gagal, performa buruk, masalah keamanan, atau metrik keberhasilan yang tidak terukur. Definisi ini memastikan keputusan pembatalan selaras dengan toleransi risiko organisasi Anda. Sertakan kondisi tertentu yang memicu pembatalan dalam rencana penyebaran Anda, seperti batas penggunaan CPU, ambang waktu respons, atau tingkat kesalahan. Evaluasi ini membuat keputusan pemulihan menjadi jelas dan konsisten pada saat insiden.
Otomatisasi langkah rollback dalam alur CI/CD. Gunakan alat seperti Azure Pipelines atau GitHub Actions untuk mengotomatiskan tugas putar kembali. Misalnya, siapkan alur untuk menyebarkan ulang versi sebelumnya jika pemeriksaan kesehatan gagal.
Buat petunjuk pemulihan khusus untuk beban kerja tertentu. Tulis langkah putar kembali yang cocok dengan jenis beban kerja, lingkungan, dan metode penyebaran Anda. Misalnya, penyebaran IaC memerlukan penerapan kembali templat sebelumnya. Pembatalan aplikasi melibatkan penyebaran ulang gambar kontainer sebelumnya. Lampirkan skrip rollback, snapshot konfigurasi, dan templat IaC ke rencana rollback Anda. Aset ini mempercepat proses dan mengurangi kebutuhan akan langkah manual.
Menguji prosedur pemulihan. Simulasikan kegagalan penyebaran di lingkungan penahapan untuk mengonfirmasi bahwa pemulihan Anda berfungsi. Temukan dan perbaiki celah dalam otomatisasi, izin, atau dependensi. Verifikasi bahwa prosedur rollback memulihkan sistem ke keadaan stabil dan diketahui baik.
Meningkatkan strategi putar kembali. Setelah setiap penyebaran atau rollback, tinjau apa yang berhasil dan apa yang tidak berhasil. Perbarui aturan pembatalan, langkah, dan skrip berdasarkan pelajaran yang dipelajari. Pertimbangkan perubahan desain atau perangkat baru. Perbarui terus panduan Anda agar rencana pemulihan tetap terkini dan berguna.