Pertimbangan vendor perangkat lunak independen (ISV) untuk zona pendaratan Azure
Bagi banyak organisasi, arsitektur konseptual zona pendaratan Azure mewakili tujuan perjalanan adopsi cloud mereka. Zona pendaratan menjelaskan cara membangun lingkungan Azure dengan beberapa langganan. Setiap zona pendaratan memperuntukkan skala, keamanan, tata kelola, jaringan, dan identitas, dan didasarkan pada umpan balik dan pelajaran yang dipelajari dari banyak pelanggan.
Tip
Sangat membantu untuk menganggap zona pendaratan Azure seperti rencana kota. Arsitektur beban kerja yang disebarkan ke zona pendaratan seperti rencana untuk bangunan di sebuah kota.
Sistem air, gas, listrik, dan transportasi kota semuanya harus diberlakukan sebelum bangunan dapat dibangun. Demikian pula, komponen zona pendaratan Azure, termasuk grup manajemen, kebijakan, langganan, dan kontrol akses berbasis peran (RBAC), semuanya harus diberlakukan sebelum beban kerja produksi apa pun dapat disebarkan.
Sebagai vendor perangkat lunak independen (ISV) yang membangun dan mengoperasikan solusi Anda di Azure, Anda harus merujuk ke sumber daya berikut saat membangun lingkungan Azure Anda:
- Zona pendaratan Azure: Menyediakan panduan untuk lingkungan Azure Anda secara keseluruhan.
- Azure Well-Architected Framework: Menyediakan panduan arsitektur yang berlaku untuk semua beban kerja.
- Merancang solusi multipenyewa di Azure: Menyediakan panduan arsitektur tertentu untuk solusi multipenyewa di Azure.
Zona pendaratan Azure membantu Anda memilih arah untuk lingkungan Azure Anda secara keseluruhan. Tetapi sebagai ISV, penyedia SaaS, atau startup, kebutuhan implementasi spesifik Anda mungkin berbeda dari skenario pelanggan yang lebih standar. Berikut ini hanyalah beberapa contoh skenario implementasi yang berbeda:
- Anda membangun perangkat lunak yang disebarkan pelanggan ke langganan mereka sendiri.
- Anda memiliki sarana kontrol Anda sendiri dan menggunakan skrip atau perangkat lunak otomatisasi untuk menyebarkan dan mengonfigurasi sumber daya Azure untuk solusi SaaS Anda.
- Anda adalah ISV atau startup kecil dan ingin memulai dengan biaya serendah mungkin, dan mungkin awalnya tidak ingin menggunakan layanan seperti Azure Firewall dan Azure DDoS Protection.
- Anda adalah SAAS ISV besar dan berencana untuk membagi aplikasi SaaS Anda di beberapa langganan untuk skala. Anda juga ingin mengelompokkan langganan sehingga sesuai dengan lingkungan pengembangan, pengujian, penahapan, dan produksi Anda.
- Model operasi organisasi Anda memisahkan peran tim IT perusahaan Anda dan tim produk SaaS Anda. Tim TI perusahaan organisasi Anda mungkin mengelola sumber daya seperti Microsoft Office 365 dan Microsoft Teams, dan tim produk SaaS Anda mungkin bertanggung jawab untuk membangun dan mengoperasikan produk SaaS Anda (termasuk platform pusat dan komponen identitasnya).
Catatan
Terkadang, ISV ingin memulai hanya dengan satu langganan Azure yang mencakup aspek "layanan bersama" platform dan sumber daya beban kerja aktual. Meskipun ini dimungkinkan secara teknis, Anda akan menghadapi tantangan di kemudian hari ketika Anda perlu memindahkan sumber daya antar langganan dan menemukan bahwa tidak semua jenis sumber daya dapat dipindahkan. Tinjau dampak penyimpangan desain untuk memahami penyimpangan apa yang mungkin dan berbagai tingkat risikonya.
Model penyebaran ISV
Solusi ISV sering masuk ke dalam salah satu dari tiga model penyebaran: SaaS murni, SaaS yang disebarkan pelanggan, atau penyebaran ganda. Bagian ini menjelaskan pertimbangan berbeda setiap model untuk zona pendaratan Azure.
SaaS Murni
Dalam model SaaS murni, perangkat lunak Anda disebarkan sepenuhnya hanya di langganan Azure Anda. Pelanggan akhir menggunakan perangkat lunak Anda tanpa menyebarkannya di langganan Azure mereka sendiri. Dalam diagram berikut, pengguna menggunakan aplikasi SaaS murni yang disediakan oleh ISV:
Contoh perangkat lunak SaaS murni termasuk email sebagai layanan, Kafka-as-a-service, cloud-data-warehouse-as-a-service, dan banyak daftar SaaS di Marketplace Azure.
Jika Anda adalah SAAS ISV kecil, Anda mungkin tidak perlu menggunakan beberapa langganan Azure untuk segera menyebarkan sumber daya Anda. Tetapi saat Anda menskalakan, batas langganan Azure dapat memengaruhi kemampuan Anda untuk menskalakan dalam satu langganan. Tinjau prinsip desain zona pendaratan skala perusahaan, terutama demokratisasi langganan, dan biasakan diri Anda dengan pendekatan arsitektur untuk multitenansi guna merencanakan pertumbuhan Anda di masa depan.
ISV yang membangun solusi SaaS murni harus mempertimbangkan pertanyaan-pertanyaan berikut:
- Haruskah semua sumber daya Azure yang membentuk solusi SaaS kami berada dalam satu langganan Azure, atau dipartisi di beberapa langganan Azure?
- Haruskah kita menghosting setiap pelanggan dalam langganan Azure khusus mereka sendiri, atau bisakah kita membuat sumber daya dalam satu atau beberapa langganan bersama?
- Bagaimana kita dapat menerapkan pola Deployment Stamp (unit skala) ke semua tingkatan solusi kita?
- Bagaimana cara menggunakan organisasi sumber daya Azure dalam solusi multipenyewa untuk mencegah kami menghadapi tantangan skala dan batas langganan Azure?
Disebarkan pelanggan
Dalam model yang disebarkan pelanggan, pelanggan akhir Anda membeli perangkat lunak dari Anda lalu menyebarkannya ke langganan Azure mereka sendiri. Mereka mungkin memulai penyebaran dari Marketplace Azure, atau melakukannya secara manual dengan mengikuti instruksi dan menggunakan skrip yang Anda berikan.
Dalam diagram berikut, ISV menyediakan paket perangkat lunak atau produk katalog Marketplace Azure, dan pengguna menyebarkan sumber daya tersebut ke langganan Azure mereka sendiri bersama beban kerja mereka yang lain:
Elemen beban kerja pelanggan lainnya dalam diagram dapat mewakili beban kerja pelanggan sendiri atau produk ISV lain yang telah disebarkan pelanggan dalam langganan Azure mereka. Pelanggan sering menyebarkan beberapa produk dari ISV yang berbeda ke dalam langganan Azure mereka. Mereka menggabungkan produk individu ini untuk menciptakan solusi. Misalnya, pelanggan mungkin menyebarkan produk database dari satu ISV, appliance virtual jaringan dari ISV lain, dan aplikasi web dari ISV ketiga.
Contoh produk ISV yang disebarkan pelanggan termasuk banyak gambar komputer virtual (seperti appliance virtual jaringan dan penyimpanan) dan aplikasi Azure di Marketplace Azure.
Untuk beberapa solusi yang disebarkan pelanggan, organisasi mungkin menyediakan manajemen dan pembaruan untuk solusi yang disebarkan dalam langganan Azure pelanggan akhir mereka dengan menggunakan Azure Lighthouse atau Azure Managed Applications. ISV, Solution Integrators (SIs), dan Managed Service Providers (MSP) semuanya dapat menggunakan strategi ini ketika memenuhi kebutuhan khusus mereka.
Solusi ISV yang disebarkan pelanggan dianggap sebagai beban kerja aplikasi standar dari perspektif zona pendaratan Azure. Pertimbangkan panduan zona pendaratan Azure saat Anda merancang produk Anda untuk bekerja dengan prinsip desain zona pendaratan Azure yang diadopsi pelanggan Azure Anda.
Sangat penting bagi Anda untuk memiliki pemahaman yang baik tentang konsep zona pendaratan Azure saat Anda memigrasikan beban kerja pelanggan yang ada ke Azure.
ISV yang membangun solusi yang disebarkan pelanggan harus mempertimbangkan pertanyaan berikut:
- Haruskah pelanggan menyebarkan solusi kami ke langganan khususnya sendiri atau ke langganan yang sudah ada yang berisi beban kerja terkait?
- Bagaimana pelanggan harus membangun konektivitas jaringan antara beban kerja yang ada (di dalam dan di luar Azure) dan solusi kami?
- Apakah solusi kami mendukung mekanisme autentikasi dari MICROSOFT Entra ID atau memerlukan protokol lain seperti LDAP atau Kerberos?
- Bagaimana cara mengurangi atau menghilangkan pelanggaran Azure Policy, seperti yang disebabkan oleh konflik antara templat solusi kami dan kebijakan Azure pelanggan?
Kebijakan Azure pelanggan yang dapat menyebabkan pelanggaran Azure Policy mencakup contoh seperti "Semua subnet harus memiliki grup keamanan jaringan" dan "Tidak ada alamat IP publik yang dapat dilampirkan ke antarmuka jaringan di zona pendaratan Corp". Ingat potensi kebijakan yang menyebabkan konflik ini saat Anda merencanakan penyebaran.
SaaS penyebaran ganda
Beberapa solusi SaaS berinteraksi dengan atau menggunakan sumber daya yang disebarkan dalam langganan Azure pelanggan. Model penyebaran ini terkadang disebut penyebaran ganda SaaS atau hibrid SaaS. Dalam diagram berikut, ISV menyediakan solusi SaaS yang dihosting yang berinteraksi dengan sumber daya yang disebarkan ke langganan Azure pelanggan akhir:
Contoh dunia nyata dari penyebaran ganda SaaS adalah Microsoft Power BI, layanan SaaS yang dapat secara opsional menggunakan gateway data lokal Power BI yang disebarkan pada komputer virtual dalam langganan Azure pelanggan.
Contoh lain dari skenario SaaS penyebaran ganda meliputi:
- Organisasi Anda membangun Virtual Desktop Manager, produk yang menyediakan antarmuka konsol SaaS untuk mengontrol sumber daya Azure Virtual Desktop di langganan Azure setiap pelanggan.
- Organisasi Anda menyediakan konsol SaaS untuk analitik data, dan secara dinamis membuat dan menghapus komputer virtual simpul komputasi di langganan Azure setiap pelanggan.
Sebagai ISV penyebaran ganda, Anda harus merujuk ke zona pendaratan Azure untuk panduan di dua area: menyusun lingkungan Azure Anda sendiri untuk menghosting layanan SaaS Anda, dan memastikan interaksi yang tepat antara penyebaran Anda di langganan Azure pelanggan dan zona pendaratan pelanggan Anda.
ISV yang membangun solusi SaaS penyebaran ganda harus mempertimbangkan pertanyaan-pertanyaan berikut:
- Apakah kami telah meninjau semua pertimbangan untuk membangun saaS murni dan solusi yang disebarkan pelanggan?
- Komponen mana dari solusi kami yang harus dihosting di langganan Azure kami, dan komponen mana yang harus disebarkan pelanggan?
- Bagaimana kami dapat memastikan provisi dan interaksi yang aman dengan sumber daya yang disebarkan dalam langganan Azure pelanggan kami?
Prinsip dan implementasi desain zona pendaratan Azure
Prinsip desain zona pendaratan Azure merekomendasikan penyelarasan dengan kemampuan platform asli Azure seperti Analitik Log, Azure Monitor, dan Azure Firewall. Panduan zona pendaratan juga menyediakan opsi implementasi zona pendaratan Azure tertentu.
Sebagai ISV, Anda mungkin memutuskan untuk menerapkan lingkungan zona pendaratan Anda sendiri. Anda mungkin perlu menggunakan otomatisasi Anda sendiri untuk menyebarkan sumber daya Azure di seluruh langganan. Atau Anda mungkin ingin terus menggunakan alat yang sudah Anda gunakan untuk pengelogan, pemantauan, dan layanan lapisan platform lainnya.
Jika Anda menerapkan lingkungan zona pendaratan Anda sendiri, kami sarankan Anda menggunakan panduan zona pendaratan Azure dan implementasi sampel untuk referensi, dan selaraskan pendekatan Anda dengan desain zona pendaratan Azure yang terbukti.
Penyewa Microsoft Entra
Setiap zona pendaratan Azure dan hierarki grup manajemennya berakar dalam satu penyewa Microsoft Entra. Ini berarti bahwa keputusan pertama yang perlu Anda buat adalah penyewa Microsoft Entra mana yang akan digunakan sebagai sumber identitas untuk mengelola sumber daya Azure Anda. Identitas dalam ID Microsoft Entra mencakup pengguna, grup, dan perwakilan layanan.
Tip
Penyewa Microsoft Entra yang Anda pilih untuk zona pendaratan Anda tidak memengaruhi autentikasi tingkat aplikasi Anda. Anda masih dapat menggunakan idP lain seperti Azure AD B2C terlepas dari penyewa mana yang Anda pilih.
Panduan untuk zona pendaratan Azure dan penyewa Microsoft Entra sangat merekomendasikan penggunaan satu penyewa Microsoft Entra, dan ini adalah pendekatan yang benar untuk sebagian besar situasi. Namun, sebagai SAAS ISV, Anda mungkin memiliki alasan untuk menggunakan dua penyewa.
Untuk beberapa ISV SaaS, satu tim mengelola sumber daya perusahaan dan tim terpisah mengoperasikan solusi SaaS. Pemisahan ini dapat karena alasan operasional atau untuk mematuhi persyaratan peraturan. Mungkin tim TI perusahaan Anda tidak diizinkan untuk mengelola langganan dan sumber daya terkait SaaS apa pun, sehingga mereka tidak dapat menjadi administrator penyewa Microsoft Entra. Jika skenario ini berlaku untuk Anda, pertimbangkan untuk menggunakan dua penyewa Microsoft Entra terpisah: satu penyewa untuk sumber daya IT perusahaan seperti Office 365, dan satu penyewa untuk sumber daya Azure yang terdiri dari solusi SaaS Anda.
Setiap penyewa Microsoft Entra harus memiliki nama domainnya sendiri. Jika organisasi Anda menggunakan dua penyewa, Anda dapat memilih nama seperti contoso.com untuk penyewa Microsoft Entra perusahaan Anda dan contoso-saas-ops.com untuk penyewa SaaS Microsoft Entra Anda, seperti yang ditunjukkan dalam diagram berikut.
Peringatan
Saat Anda menggunakan beberapa penyewa Microsoft Entra, overhead manajemen Anda meningkat. Jika Anda menggunakan fitur Microsoft Entra ID P1 atau P2 seperti Privileged Identity Management, Anda harus membeli lisensi individual untuk setiap penyewa Microsoft Entra. Yang terbaik adalah hanya menggunakan beberapa penyewa Microsoft Entra jika situasi Anda benar-benar memerlukannya.
Hindari menggunakan penyewa Microsoft Entra terpisah untuk lingkungan pra-produksi dan produksi. Daripada membuat dua penyewa seperti contoso-saas-ops-preprod.com dan contoso-saas-ops-prod.com dengan langganan Azure terpisah di bawah masing-masing, Anda harus membuat satu penyewa Microsoft Entra. Anda dapat menggunakan grup manajemen dan Azure RBAC untuk mengatur akses ke langganan dan sumber daya di bawah penyewa tunggal ini.
Untuk informasi selengkapnya tentang menggunakan beberapa penyewa Microsoft Entra, lihat Zona pendaratan Azure dan beberapa penyewa Microsoft Entra dan mengamankan lingkungan Azure dengan whitepaper Microsoft Entra.
Grup pengelolaan
Arsitektur konseptual zona pendaratan Azure merekomendasikan penggunaan hierarki grup manajemen tertentu. Namun, ISV dapat memiliki persyaratan yang berbeda dari organisasi lain. Bagian ini menjelaskan beberapa cara yang mungkin dipilih organisasi ISV Anda untuk mengadopsi praktik yang berbeda dari yang direkomendasikan oleh arsitektur konseptual zona pendaratan.
Grup manajemen tingkat atas
Hierarki grup manajemen Anda disarangkan di bawah grup manajemen grup akar Penyewa yang dibuat Azure. Anda tidak menggunakan grup akar Penyewa secara langsung.
Organisasi standar yang memiliki tim TI perusahaan terpusat yang mengelola platform dan layanan bersama mereka (seperti pengelogan, jaringan, identitas, dan keamanan) biasanya membuat satu grup manajemen tingkat atas di bawah grup akar Penyewa yang dibuat Azure dan menyebarkan grup manajemen lainnya di bawahnya. Grup manajemen tingkat atas ini biasanya dinamai sesuai dengan organisasi itu sendiri (seperti Contoso).
Sebagai SAAS ISV, Anda mungkin memiliki satu produk SaaS atau Anda mungkin memiliki beberapa produk SaaS atau lini bisnis terpisah. Meskipun Anda umumnya harus menggunakan penyewa Microsoft Entra yang sama untuk mengelola sumber daya Azure di semua produk Anda (seperti yang dibahas di bagian penyewa Microsoft Entra), dalam beberapa skenario Anda mungkin memilih untuk menyebarkan beberapa hierarki grup manajemen.
Pertimbangkan seberapa independen produk Anda satu sama lain, dan tanyakan pada diri sendiri:
- Apakah semua produk kami menggunakan platform yang sama untuk DevOps, identitas, keamanan, konektivitas, dan pengelogan?
- Apakah layanan bersama tersebut dioperasikan oleh satu tim pusat?
Jika Anda menjawab ya untuk kedua pertanyaan, buat satu grup manajemen Produk SaaS tingkat atas di bawah grup akar Penyewa.
Jika Anda menjawab tidak, dan masing-masing produk SaaS Anda dikelola dan dioperasikan oleh tim platform terpisah, pertimbangkan untuk membuat grup manajemen tingkat atas terpisah untuk setiap produk, seperti dua grup manajemen tingkat atas SaaS Product-01 dan SaaS Product-02.
Tip
Tidak jarang satu ISV memiliki lebih dari sekadar beberapa grup manajemen tingkat atas. Seringkali, beberapa produk dapat digabungkan bersama-sama karena kesamaan dalam cara mereka dikelola dan dioperasikan.
Pendekatan manajemen ini mirip dengan pendekatan pengujian untuk zona pendaratan skala perusahaan. Namun, daripada membuat Contoso dan Contoso-Canary di bawah grup akar Penyewa, dalam pendekatan ini perusahaan contoh akan membuat grup manajemen tingkat atas Contoso-SaaS-Product-01, Contoso-SaaS-Product-02, dan Contoso-SaaS-Product-03 di bawahnya. Skenario ini diilustrasikan dalam diagram berikut:
Grup manajemen platform
Dalam hierarki organisasi sumber daya zona pendaratan Azure, grup manajemen Platform berisi semua langganan Azure yang menghosting komponen dan layanan bersama yang digunakan oleh beban kerja di langganan zona pendaratan. Contoh komponen yang disebarkan ke dalam platform dan langganan layanan bersama termasuk infrastruktur pengelogan terpusat (seperti ruang kerja Analitik Log), DevOps, keamanan, alat otomatisasi, sumber daya jaringan pusat (seperti paket hub-VNet dan DDos Protection), dan layanan sarana kontrol ISV.
Grup manajemen Platform sering dipartisi ke dalam grup anak Identitas, Manajemen, dan Koneksi ivitas untuk memberikan pemisahan peran dan kebijakan yang nyaman bagi pelanggan perusahaan.
Di organisasi Anda, Anda mungkin memiliki satu tim yang mengelola semua komponen platform bersama seperti identitas, jaringan, dan manajemen. Jika demikian, dan jika Anda tidak memiliki rencana untuk memisahkan manajemen tersebut di beberapa tim, maka pertimbangkan untuk menggunakan satu grup manajemen Platform .
Jika Anda akan memiliki tim terpisah yang mengelola berbagai bagian platform terpusat, Anda harus menyebarkan tingkat lebih lanjut dalam hierarki grup manajemen di bawah grup manajemen Platform . Ini memungkinkan Anda menetapkan kebijakan terpisah untuk setiap bagian platform terpusat Anda.
Diagram berikut mengilustrasikan dua implementasi potensial grup manajemen Platform . Opsi A menunjukkan skenario yang lebih komprehensif, di mana grup manajemen Platform berisi tiga grup manajemen anak: Manajemen dan DevOps, Identitas dan Keamanan, dan Koneksi ivitas. Setiap grup manajemen anak berisi langganan dengan sumber daya yang relevan. Opsi B menunjukkan skenario yang lebih sederhana, di mana grup manajemen Platform berisi satu langganan platform.
Grup manajemen Zona Pendaratan
Grup manajemen Zona Pendaratan berisi langganan Azure yang menghosting subsistem dan beban kerja aktual solusi SaaS Anda.
Grup manajemen ini berisi satu atau beberapa grup manajemen anak. Masing-masing grup manajemen anak di bawah Zona Pendaratan mewakili beban kerja atau arketipe subsistem, dengan persyaratan kebijakan dan akses yang konsisten yang harus berlaku untuk semua langganan. Alasan untuk menggunakan beberapa arketipe meliputi:
- Kepatuhan: Jika subsistem produk SaaS Anda harus mematuhi PCI-DSS, pertimbangkan untuk membuat grup manajemen anak arketipe PCI DSS di bawah Zona Pendaratan. Semua langganan Azure yang berisi sumber daya dalam cakupan kepatuhan PCI-DSS harus ditempatkan dalam grup manajemen tersebut.
- Tingkatan: Pertimbangkan untuk membuat arketipe zona pendaratan terpisah untuk pelanggan tingkat khusus solusi SaaS Anda dan pelanggan tingkat gratis. Setiap grup manajemen anak berisi pengaturan Azure Policy yang berbeda. Misalnya, kebijakan di tingkat gratis mungkin membatasi penyebaran untuk hanya mengaktifkan SKU komputer virtual tertentu, dan kebijakan di tingkat khusus mungkin memerlukan sumber daya untuk disebarkan ke wilayah tertentu.
Grup manajemen khusus lingkungan
SAAS ISV sering mengatur lingkungan cloud mereka dengan memodelkan lingkungan siklus hidup pengembangan perangkat lunak mereka secara berurutan. Ini biasanya memerlukan penyebaran terlebih dahulu ke lingkungan Pengembangan , lalu ke lingkungan Uji , lalu ke lingkungan Penahapan , dan akhirnya ke lingkungan Produksi .
Salah satu perbedaan umum antara lingkungan adalah aturan Azure RBAC mereka, seperti siapa yang dapat mengakses setiap grup langganan. Misalnya, tim DevOps, SaaSOps, pengembangan, dan pengujian mungkin semuanya memiliki tingkat akses yang berbeda ke lingkungan yang berbeda.
Penting
Sebagian besar pelanggan Azure memiliki ratusan aplikasi dan menggunakan langganan Azure terpisah untuk setiap tim aplikasi. Jika setiap aplikasi memiliki grup manajemen pengembangan, pengujian, pementasan, dan produksi sendiri, akan ada sejumlah besar grup manajemen dengan kebijakan yang hampir identik. Untuk sebagian besar pelanggan, FAQ Zona Pendaratan Skala Perusahaan menyarankan untuk tidak menggunakan grup manajemen terpisah untuk setiap lingkungan. Sebaiknya gunakan langganan terpisah dalam satu grup manajemen sebagai gantinya.
Namun, SAAS ISV dapat memiliki persyaratan yang berbeda dari sebagian besar pelanggan Azure lainnya, dan mungkin memiliki alasan yang baik untuk menggunakan grup manajemen khusus lingkungan dalam beberapa situasi.
SAAS ISV terkadang perlu mengelompokkan beberapa langganan yang mewakili pecahan atau partisi dari subsistem, aplikasi, atau beban kerja yang sama. Anda mungkin perlu menerapkan kebijakan atau penetapan peran ke grup langganan dengan cara yang jauh berbeda dari dalam grup manajemen arketipe. Dalam hal ini, pertimbangkan untuk membuat grup manajemen anak yang sesuai dengan setiap lingkungan di bawah grup manajemen arketipe.
Diagram berikut mengilustrasikan dua opsi potensial. Opsi A memperlihatkan skenario dengan langganan terpisah untuk setiap lingkungan tetapi tidak ada grup manajemen khusus lingkungan. Opsi B memperlihatkan skenario SAAS ISV dengan grup manajemen khusus lingkungan di bawah grup manajemen stempel reguler. Setiap grup manajemen khusus lingkungan berisi beberapa langganan. Seiring waktu, ISV menskalakan sumber daya Azure mereka di setiap lingkungan di sejumlah langganan yang meningkat dengan serangkaian kebijakan dan penetapan peran umum.
Pilih setiap tab untuk melihat dua diagram.
Grup manajemen Dinonaktifkan dan Kotak Pasir
Panduan organisasi sumber daya zona pendaratan Azure merekomendasikan termasuk grup manajemen Dinonaktifkan dan Kotak pasir tepat di bawah grup manajemen tingkat atas Anda.
Grup manajemen yang dinonaktifkan adalah tempat penahanan untuk langganan Azure yang sedang dinonaktifkan dan akhirnya akan dihapus. Anda dapat memindahkan langganan yang tidak lagi digunakan ke dalam grup manajemen ini untuk melacaknya hingga semua sumber daya dalam langganan dihapus secara permanen.
Grup manajemen Kotak Pasir biasanya berisi langganan Azure yang digunakan untuk tujuan eksplorasi dan memiliki kebijakan yang longgar atau tidak diterapkan padanya. Misalnya, Anda dapat memberi pengembang individu langganan mereka sendiri untuk pengembangan dan pengujian. Anda dapat menghindari penerapan kebijakan dan tata kelola normal ke langganan ini dengan menempatkannya di grup manajemen Sandboxes . Ini meningkatkan kelincahan pengembang dan memungkinkan mereka untuk dengan mudah bereksperimen dengan Azure.
Penting
Langganan di grup manajemen Kotak Pasir seharusnya tidak memiliki konektivitas langsung ke langganan zona pendaratan. Hindari menyambungkan langganan kotak pasir ke beban kerja produksi atau ke lingkungan non-produksi apa pun yang mencerminkan lingkungan produksi.
Diagram berikut mengilustrasikan dua opsi potensial. Opsi A tidak menyertakan grup manajemen Dinonaktifkan dan Kotak Pasir , sementara opsi B tidak.
Contoh zona pendaratan ISV
Bagian ini mencakup dua contoh struktur zona pendaratan Azure untuk SAAS ISV. Pilih setiap tab untuk membandingkan dua contoh zona pendaratan.
Diagram berikut menunjukkan contoh hierarki zona pendaratan SaaS ISV Azure dengan karakteristik berikut:
- ISV menyimpan semua komponen platform mereka dalam satu langganan Azure, alih-alih membaginya menjadi beberapa grup manajemen platform.
- Hanya ada satu grup manajemen zona pendaratan.
- Zona pendaratan mencakup grup manajemen khusus lingkungan untuk mengatur langganan dan menetapkan kebijakan dan peran yang berbeda.
- ISV tidak menyertakan grup manajemen untuk langganan yang dinonaktifkan dan kotak pasir.
Langkah berikutnya
- Jika Anda membangun solusi multipenyewa, pelajari selengkapnya tentang merancang solusi multipenyewa di Azure.
- Pelajari apa itu zona pendaratan Azure.
- Pelajari tentang area desain zona pendaratan Azure.