Prinsip desain zona pendaratan Azure
Arsitektur konseptual zona pendaratan Azure secara universal berlaku untuk setiap proses atau implementasi zona pendaratan Azure. Pada dasar arsitektur, serangkaian prinsip desain inti berfungsi sebagai kompas untuk keputusan desain berikutnya di seluruh domain teknis penting.
Prinsip-prinsipnya sengaja aspirasional, untuk membantu Anda mengupayakan desain arsitektur target yang optimal. Jika Anda memilih untuk menyebarkan implementasi yang merupakan akselerator zona pendaratan Azure, atau versi apa pun dari basis kode zona pendaratan skala perusahaan, bangun arsitektur dengan menerapkan prinsip desain yang dijelaskan artikel ini.
Gunakan prinsip-prinsip ini dalam implementasi Anda sebagai panduan yang berguna untuk mewujudkan manfaat teknologi cloud. Pendekatan cloud-oriented atau cloud native ini mewakili cara kerja dan opsi teknis untuk organisasi Anda yang biasanya tidak ditawarkan oleh pendekatan teknologi warisan.
Biasakan diri Anda dengan prinsip-prinsip ini untuk lebih memahami dampaknya dan tradeoff yang terkait dengan penyimpangan.
Dampak penyimpangan desain
Mungkin ada alasan yang valid untuk menyimpang dari prinsip desain. Misalnya, persyaratan organisasi mungkin menentukan hasil atau pendekatan tertentu untuk merancang lingkungan Azure. Dalam kasus seperti itu, penting untuk memahami dampak penyimpangan terhadap desain dan operasi di masa depan. Pertimbangkan dengan cermat tradeoff yang diuraikan setiap prinsip.
Sebagai aturan umum, bersiaplah untuk menyeimbangkan persyaratan dan fungsionalitas. Perjalanan Anda ke arsitektur konseptual berkembang dari waktu ke waktu seiring perubahan persyaratan dan Anda belajar dari implementasi Anda. Misalnya, menggunakan layanan pratinjau dan bergantung pada peta jalan layanan dapat menghapus pemblokir teknis selama adopsi.
Demokratisasi langganan
Gunakan langganan sebagai unit manajemen, dan skalakan untuk mempercepat migrasi aplikasi dan pengembangan aplikasi baru. Selaraskan langganan dengan kebutuhan dan prioritas bisnis untuk mendukung area bisnis dan pemilik portofolio. Menyediakan langganan ke unit bisnis untuk mendukung desain, pengembangan, dan pengujian beban kerja baru serta migrasi beban kerja yang ada.
Untuk membantu organisasi beroperasi secara efektif dalam skala besar, dukung langganan dengan hierarki Grup Manajemen yang sesuai. Hierarki ini memungkinkan manajemen dan organisasi langganan yang efisien.
Tip
Untuk informasi selengkapnya tentang demokratisasi langganan, lihat video YouTube terbaru Zona Pendaratan Azure - Berapa banyak langganan yang harus saya gunakan di Azure?
Dampak penyimpangan
Operasi terdesentralisasi vs. terpusat. Salah satu cara untuk menerapkan operasi transisi prinsip ini ke unit bisnis dan tim beban kerja. Penetapan ulang ini memungkinkan pemilik beban kerja memiliki lebih banyak kontrol dan otonomi atas beban kerja mereka, dalam pagar pembatas fondasi platform. Organisasi yang memerlukan operasi pusat mungkin tidak ingin mendelegasikan kontrol lingkungan produksi ke tim beban kerja atau unit bisnis. Organisasi-organisasi ini mungkin perlu memodifikasi desain organisasi sumber daya mereka untuk menyimpang dari prinsip ini.
Ketidakselarasan model operasi. Desain arsitektur konseptual zona pendaratan Azure mengasumsikan hierarki grup manajemen dan langganan tertentu untuk semua langganan manajemen operasi. Hierarki ini mungkin tidak selaras dengan model operasi Anda. Seiring pertumbuhan dan perkembangan organisasi Anda, model operasi Anda mungkin berubah. Memindahkan sumber daya ke langganan terpisah dapat menyebabkan migrasi teknis yang rumit. Tinjau panduan Selaraskan sebelum Anda berkomitmen pada pendekatan.
Tata kelola yang didorong kebijakan
Gunakan Azure Policy untuk menyediakan pagar pembatas dan pastikan bahwa aplikasi yang Anda sebarkan mematuhi platform organisasi Anda. Azure Policy memberi pemilik aplikasi kemandirian dan jalur yang aman dan tidak terhapus ke cloud.
Untuk informasi selengkapnya, tinjau Mengadopsi pagar pembatas berbasis kebijakan.
Dampak penyimpangan
Peningkatan overhead operasional dan manajemen. Jika Anda tidak menggunakan kebijakan untuk membuat pagar pembatas dalam lingkungan Anda, Anda meningkatkan overhead operasional dan manajemen untuk menjaga kepatuhan. Azure Policy membantu Anda membatasi dan mengotomatiskan status kepatuhan yang diinginkan dalam lingkungan.
Kontrol tunggal dan bidang manajemen
Hindari dependensi pada lapisan abstraksi seperti portal atau alat yang dikembangkan pelanggan. Yang terbaik adalah memiliki pengalaman yang konsisten untuk operasi pusat dan operasi beban kerja. Azure menyediakan sarana kontrol terpadu dan konsisten yang berlaku di semua sumber daya Azure dan saluran provisi. Sarana kontrol tunduk pada akses berbasis peran dan kontrol berbasis kebijakan. Anda dapat menggunakan sarana kontrol Azure ini untuk membuat serangkaian kebijakan dan kontrol standar yang mengatur seluruh kawasan perusahaan Anda.
Dampak penyimpangan
Peningkatan kompleksitas integrasi. Pendekatan multivendor untuk mengontrol dan bidang manajemen mungkin memperkenalkan kompleksitas dukungan integrasi dan fitur. Mengganti komponen individu untuk mencapai desain "terbaik dari jenis" atau peralatan operasi multivendor memiliki keterbatasan, dan dapat menyebabkan kesalahan yang tidak diinginkan karena dependensi yang melekat.
Jika Anda membawa investasi peralatan yang ada untuk operasi, keamanan, atau tata kelola, tinjau layanan Azure dan dependensi apa pun.
Model layanan yang berpusat pada aplikasi
Fokus pada migrasi dan pengembangan yang berfokus pada aplikasi, daripada migrasi lift-and-shift infrastruktur murni seperti memindahkan komputer virtual. Pilihan desain tidak boleh membedakan antara aplikasi lama dan baru, aplikasi infrastruktur sebagai layanan (IaaS), atau aplikasi platform as a service (PaaS).
Terlepas dari model layanan, berusahalah untuk menyediakan lingkungan yang aman untuk semua aplikasi yang Anda sebarkan di platform Azure.
Dampak penyimpangan
Peningkatan kompleksitas kebijakan tata kelola. Jika Anda mengelompokkan beban kerja secara berbeda dari opsi implementasi hierarki grup manajemen, Anda meningkatkan kompleksitas dalam kebijakan tata kelola dan struktur kontrol akses yang mengatur lingkungan Anda. Contohnya termasuk penyimpangan dari struktur hierarki organisasi atau pengelompokan berdasarkan layanan Azure.
Peningkatan overhead operasional. Tradeoff ini memperkenalkan risiko duplikasi dan pengecualian kebijakan yang tidak disengaja, yang menambah overhead operasional dan manajemen.
Dev/Test/Production adalah pendekatan umum lain yang dipertimbangkan organisasi. Untuk informasi selengkapnya, lihat Bagaimana cara menangani zona pendaratan beban kerja "dev/test/production" di arsitektur zona pendaratan Azure.
Penyelarasan dengan desain dan peta strategi asli Azure
Manfaatkan layanan dan kemampuan platform asli Azure jika memungkinkan. Pendekatan ini harus selaras dengan peta strategi platform Azure untuk memastikan bahwa kemampuan baru tersedia dalam lingkungan Anda. Peta jalan platform Azure akan membantu menginformasikan strategi migrasi dan lintasan konseptual zona pendaratan Azure.
Dampak penyimpangan
Peningkatan kompleksitas integrasi. Memperkenalkan solusi pihak ketiga ke lingkungan Azure Anda dapat menciptakan dependensi pada solusi tersebut untuk memberikan dukungan fitur dan integrasi dengan layanan pihak pertama Azure.
Terkadang membawa investasi solusi pihak ketiga yang ada ke dalam lingkungan tidak dapat dihindari. Pertimbangkan prinsip ini dan tradeoff-nya dengan hati-hati untuk menyelaraskan dengan kebutuhan Anda.
Langkah berikutnya
Organisasi mungkin berada pada tahap yang berbeda dari perjalanan cloud mereka ketika mereka meninjau panduan ini. Oleh karena itu, tindakan dan rekomendasi yang diperlukan untuk maju menuju hasil sebelumnya mungkin bervariasi. Untuk memahami tindakan terbaik berikutnya untuk tahap adopsi cloud Anda, tinjau perjalanan ke arsitektur target.
Untuk memilih opsi implementasi zona pendaratan Azure yang tepat, pahami area desain zona pendaratan Azure.