Considerazioni sul fornitore di software indipendente (ISV) per le zone di destinazione di Azure
Per molte organizzazioni, l'architettura concettuale delle zone di destinazione di Azure rappresenta la destinazione del percorso di adozione del cloud. Le zone di destinazione descrivono come creare un ambiente di Azure con più sottoscrizioni. Ogni zona di destinazione è account per scalabilità, sicurezza, governance, rete e identità e si basa su feedback e lezioni apprese da molti clienti.
Suggerimento
Può essere utile considerare le zone di destinazione di Azure come piani di città. Le architetture dei carichi di lavoro distribuite in una zona di destinazione sono come i piani per gli edifici in una città.
Tutti i sistemi di acqua, gas, elettricità e trasporto di una città devono essere distribuiti prima che gli edifici possano essere costruiti. Analogamente, i componenti di una zona di destinazione di Azure, inclusi i gruppi di gestione, i criteri, le sottoscrizioni e il controllo degli accessi in base al ruolo,tutti devono essere implementati prima che tutti i carichi di lavoro di produzione possano essere distribuiti.
In qualità di fornitore di software indipendente (ISV) che crea e opera la soluzione in Azure, è necessario fare riferimento alle risorse seguenti durante la compilazione dell'ambiente Azure:
- Zone di destinazione di Azure: fornisce indicazioni per l'ambiente Azure complessivo.
- Azure Well-Architected Framework: fornisce indicazioni sull'architettura applicabili a tutti i carichi di lavoro.
- Progettazione di soluzioni multi-tenant in Azure: fornisce indicazioni architetturali specifiche per le soluzioni multi-tenant in Azure.
Le zone di destinazione di Azure consentono di scegliere una direzione per l'ambiente Azure complessivo. Tuttavia, in qualità di isv, provider SaaS o avvio, le specifiche esigenze di implementazione potrebbero differire da scenari di clienti più standard. Di seguito sono riportati solo alcuni esempi di scenari di implementazione diversi:
- Si compila il software distribuito dai clienti nelle proprie sottoscrizioni.
- Si dispone di un piano di controllo personalizzato e si usano script di automazione o software per distribuire e configurare le risorse di Azure per le soluzioni SaaS.
- Si è un ISV o un'avvio di piccole dimensioni e si vuole iniziare con il costo più basso possibile e potrebbe non voler usare inizialmente servizi come Firewall di Azure e Protezione DDoS di Azure.
- Si è un isv SaaS di grandi dimensioni e si prevede di suddividere l'applicazione SaaS tra più sottoscrizioni per la scalabilità. Si vogliono anche raggruppare le sottoscrizioni in modo che corrispondano agli ambienti di sviluppo, test, gestione temporanea e produzione.
- Il modello operativo dell'organizzazione separa i ruoli del team IT aziendale e dei team del prodotto SaaS. Il team IT aziendale dell'organizzazione potrebbe gestire risorse come Microsoft Office 365 e Microsoft Teams e il team del prodotto SaaS potrebbe essere responsabile della creazione e del funzionamento del prodotto SaaS (inclusi i relativi componenti centrali di piattaforma e identità).
Nota
In alcuni casi, gli ISV vogliono iniziare con una singola sottoscrizione di Azure che include sia gli aspetti dei "servizi condivisi" della piattaforma che le risorse effettive del carico di lavoro. Anche se questo è tecnicamente possibile, si affronteranno problemi in un secondo momento quando è necessario spostare le risorse tra sottoscrizioni e scoprire che non tutti i tipi di risorse possono essere spostati. Esaminare l'impatto delle deviazioni di progettazione per comprendere quali deviazioni sono possibili e i vari livelli di rischio.
Modelli di distribuzione ISV
Le soluzioni ISV spesso rientrano in uno dei tre modelli di distribuzione: SaaS puro, distribuito dal cliente o SaaS a doppia distribuzione. Questa sezione descrive le diverse considerazioni di ogni modello per le zone di destinazione di Azure.
SaaS puro
Nel modello SaaS puro il software viene distribuito completamente solo nelle sottoscrizioni di Azure. I clienti finali usano il software senza distribuirlo nelle proprie sottoscrizioni di Azure. Nel diagramma seguente gli utenti usano un'applicazione SaaS pura fornita da un ISV:
Esempi di software SaaS puro includono posta elettronica come servizio, Kafka-as-a-service, cloud-data-warehouse-as-a-service e molte presentazioni SaaS in Azure Marketplace.
Se si è un isv SaaS di piccole dimensioni, potrebbe non essere necessario usare più sottoscrizioni di Azure per distribuire immediatamente le risorse. Ma man mano che si ridimensionano, i limiti delle sottoscrizioni di Azure possono influire sulla possibilità di ridimensionare all'interno di una singola sottoscrizione. Esaminare i principi di progettazione della zona di destinazione su scala aziendale, in particolare la democratizzazione delle sottoscrizioni e acquisire familiarità con gli approcci architetturali per la multi-tenancy per pianificare la crescita futura.
Gli ISV che creano soluzioni SaaS pure devono considerare le domande seguenti:
- Tutte le risorse di Azure che costituiscono la soluzione SaaS devono trovarsi in una sottoscrizione di Azure o partizionate in più sottoscrizioni di Azure?
- È consigliabile ospitare ogni cliente nella propria sottoscrizione di Azure dedicata oppure creare risorse all'interno di una o poche sottoscrizioni condivise?
- Come è possibile applicare lo schema Deployment Stamp (unità di scala) a tutti i livelli della soluzione?
- In che modo è possibile usare l'organizzazione delle risorse di Azure nelle soluzioni multi-tenant per evitare di affrontare problemi di scalabilità e limiti delle sottoscrizioni di Azure?
Distribuzione del cliente
Nel modello distribuito dal cliente, i clienti finali acquistano il software dall'utente e quindi lo distribuiscono nelle proprie sottoscrizioni di Azure. Possono avviare la distribuzione da Azure Marketplace oppure eseguire questa operazione manualmente seguendo le istruzioni e usando gli script forniti.
Nel diagramma seguente un ISV fornisce un pacchetto software o un prodotto catalogo di Azure Marketplace e gli utenti distribuiscono tale risorsa nelle proprie sottoscrizioni di Azure insieme agli altri carichi di lavoro:
L'altro elemento del carico di lavoro del cliente nel diagramma può rappresentare il carico di lavoro di un cliente o un altro prodotto ISV distribuito all'interno della sottoscrizione di Azure. I clienti distribuiscono spesso più prodotti da ISV diversi nelle sottoscrizioni di Azure. Combinano questi singoli prodotti per creare soluzioni. Ad esempio, un cliente potrebbe distribuire un prodotto di database da un ISV, un'appliance virtuale di rete da un altro ISV e un'applicazione Web da un terzo ISV.
Esempi di prodotti ISV distribuiti dal cliente includono le numerose immagini di macchine virtuali (ad esempio appliance virtuali di rete e archiviazione) e applicazioni Azure in Azure Marketplace.
Per alcune soluzioni distribuite dal cliente, un'organizzazione potrebbe fornire la gestione e gli aggiornamenti per la soluzione distribuita all'interno delle sottoscrizioni di Azure dei clienti finali usando Azure Lighthouse o Applicazioni gestite di Azure. Gli ISV, gli integratori di soluzioni (SI) e i provider di servizi gestiti possono usare questa strategia quando soddisfa le esigenze specifiche.
Le soluzioni ISV distribuite dal cliente sono considerate un carico di lavoro di applicazioni standard dal punto di vista delle zone di destinazione di Azure. Prendere in considerazione le linee guida sulle zone di destinazione di Azure durante la progettazione del prodotto per lavorare con i principi di progettazione delle zone di destinazione di Azure adottate dai clienti di Azure.
È particolarmente importante avere una buona conoscenza dei concetti relativi alle zone di destinazione di Azure durante la migrazione dei carichi di lavoro dei clienti esistenti ad Azure.
Gli ISV che creano soluzioni distribuite dai clienti devono considerare le domande seguenti:
- Un cliente deve distribuire la soluzione nella propria sottoscrizione dedicata o in una sottoscrizione esistente che contiene carichi di lavoro correlati?
- In che modo i clienti devono stabilire la connettività di rete tra carichi di lavoro esistenti (all'interno e all'esterno di Azure) e la soluzione?
- La soluzione supporta meccanismi di autenticazione da Microsoft Entra ID o richiede altri protocolli come LDAP o Kerberos?
- Come si riducono o eliminano Criteri di Azure violazioni, come quelle causate da conflitti tra i modelli di soluzione e i criteri di Azure di un cliente?
I criteri di Azure dei clienti che possono causare Criteri di Azure violazioni includono esempi come "Tutte le subnet devono avere un gruppo di sicurezza di rete" e "Nessun indirizzo IP pubblico può essere collegato alle interfacce di rete nella zona di destinazione Corp". Tenere presente il potenziale per questi criteri che causano conflitti durante la pianificazione della distribuzione.
SaaS a distribuzione doppia
Alcune soluzioni SaaS interagiscono con o usano risorse distribuite nelle sottoscrizioni di Azure dei clienti. Questo modello di distribuzione è talvolta denominato SaaS a doppia distribuzione o SaaS ibrido. Nel diagramma seguente un ISV fornisce una soluzione SaaS ospitata che interagisce con le risorse distribuite nella sottoscrizione di Azure di un cliente finale:
Un esempio reale di SaaS per la doppia distribuzione è Microsoft Power BI, un servizio SaaS che può usare facoltativamente un gateway dati locale di Power BI distribuito in una macchina virtuale nella sottoscrizione di Azure di un cliente.
Altri esempi di scenari SaaS di distribuzione doppia includono:
- L'organizzazione compila Virtual Desktop Manager, un prodotto che fornisce un'interfaccia della console SaaS per controllare le risorse di Desktop virtuale Azure nella sottoscrizione di Azure di ogni cliente.
- L'organizzazione fornisce una console SaaS per l'analisi dei dati e crea ed elimina dinamicamente le macchine virtuali dei nodi di calcolo nella sottoscrizione di Azure di ogni cliente.
Come ISV a distribuzione doppia, è necessario fare riferimento alla zona di destinazione di Azure per indicazioni in due aree: strutturare il proprio ambiente Azure per ospitare il servizio SaaS e garantire un'interazione appropriata tra le distribuzioni nelle sottoscrizioni di Azure dei clienti e le zone di destinazione dei clienti.
Gli ISV che creano soluzioni SaaS a doppia distribuzione devono considerare le domande seguenti:
- Sono state esaminate tutte le considerazioni per la creazione di soluzioni SaaS pure e distribuite dal cliente?
- Quali componenti della soluzione devono essere ospitati nelle sottoscrizioni di Azure e quali componenti devono essere distribuiti dal cliente?
- Come è possibile garantire il provisioning sicuro e le interazioni con le risorse distribuite nelle sottoscrizioni di Azure dei clienti?
Principi e implementazioni della zona di destinazione di Azure
I principi di progettazione della zona di destinazione di Azure consigliano di allinearsi alle funzionalità della piattaforma nativa di Azure, ad esempio Log Analytics, Monitoraggio di Azure e Firewall di Azure. Le linee guida per la zona di destinazione forniscono anche opzioni di implementazione specifiche della zona di destinazione di Azure.
In qualità di ISV, è possibile decidere di implementare gli ambienti della zona di destinazione. Potrebbe essere necessario usare la propria automazione per distribuire le risorse di Azure tra sottoscrizioni. In alternativa, è possibile continuare a usare gli strumenti già usati per la registrazione, il monitoraggio e altri servizi a livello di piattaforma.
Se si implementano ambienti di zona di destinazione personalizzati, è consigliabile usare le linee guida per la zona di destinazione di Azure e le implementazioni di esempio per riferimento e allineare l'approccio alle progettazioni comprovate delle zone di destinazione di Azure.
Tenant di Microsoft Entra
Ogni zona di destinazione di Azure e la gerarchia dei gruppi di gestione è radicata in un singolo tenant di Microsoft Entra. Ciò significa che la prima decisione da prendere è il tenant di Microsoft Entra da usare come origine delle identità per la gestione delle risorse di Azure. Le identità nell'ID Microsoft Entra includono utenti, gruppi e entità servizio.
Suggerimento
Il tenant di Microsoft Entra selezionato per la zona di destinazione non influisce sull'autenticazione a livello di applicazione. È comunque possibile usare altri provider di identità come Azure AD B2C indipendentemente dal tenant scelto.
Le linee guida per le zone di destinazione di Azure e i tenant di Microsoft Entra consigliano vivamente di usare un singolo tenant di Microsoft Entra e questo è l'approccio corretto per la maggior parte delle situazioni. Tuttavia, come ISV SaaS, potrebbe essere necessario usare due tenant.
Per alcuni ISV SaaS, un team gestisce le risorse aziendali e un team separato gestisce la soluzione SaaS. Questa separazione può essere per motivi operativi o per rispettare i requisiti normativi. Ad esempio, il team IT aziendale non è autorizzato a gestire sottoscrizioni e risorse correlate a SaaS, in modo che non possano essere amministratori del tenant di Microsoft Entra. Se questo scenario si applica all'utente, è consigliabile usare due tenant Microsoft Entra separati: un tenant per le risorse IT aziendali come Office 365 e un tenant per le risorse di Azure che costituiscono la soluzione SaaS.
Ogni tenant di Microsoft Entra deve avere un proprio nome di dominio. Se l'organizzazione usa due tenant, è possibile scegliere un nome come contoso.com per il tenant Microsoft Entra aziendale e contoso-saas-ops.com per il tenant SaaS Microsoft Entra, come illustrato nel diagramma seguente.
Avviso
Quando si usano più tenant di Microsoft Entra, aumenta il sovraccarico di gestione. Se si usano le funzionalità di Microsoft Entra ID P1 o P2 come Privileged Identity Management, è necessario acquistare singole licenze per ogni tenant di Microsoft Entra. È consigliabile usare più tenant di Microsoft Entra solo se la situazione lo richiede veramente.
Evitare di usare tenant Microsoft Entra separati per ambienti di pre-produzione e produzione. Invece di creare due tenant come contoso-saas-ops-preprod.com e contoso-saas-ops-prod.com con sottoscrizioni di Azure separate, è necessario creare un tenant Di Microsoft Entra. È possibile usare i gruppi di gestione e il controllo degli accessi in base al ruolo di Azure per gestire l'accesso alle sottoscrizioni e alle risorse in questo singolo tenant.
Per altre informazioni sull'uso di più tenant di Microsoft Entra, vedere Zone di destinazione di Azure e più tenant di Microsoft Entra e isolamento delle risorse con più tenant.
Gruppi di gestione
L'architettura concettuale della zona di destinazione di Azure consiglia di usare una gerarchia di gruppi di gestione specifica. Tuttavia, gli ISV possono avere requisiti diversi rispetto ad altre organizzazioni. Questa sezione descrive alcuni modi in cui l'organizzazione ISV potrebbe scegliere di adottare procedure diverse rispetto a quelle consigliate dall'architettura concettuale della zona di destinazione.
Gruppo di gestione di primo livello
La gerarchia del gruppo di gestione è annidata nel gruppo di gestione del gruppo radice tenant creato da Azure. Non si usa direttamente il gruppo radice tenant.
Un'organizzazione standard con un team IT aziendale centralizzato che gestisce la piattaforma e i servizi condivisi (ad esempio registrazione, rete, identità e sicurezza) crea in genere un gruppo di gestione di primo livello nel gruppo radice tenant creato da Azure e distribuisce il resto dei gruppi di gestione al di sotto di esso. Questo gruppo di gestione di primo livello è in genere denominato dopo l'organizzazione stessa (ad esempio Contoso).
In qualità di ISV SaaS, si potrebbe avere un prodotto SaaS o si potrebbero avere alcuni prodotti SaaS separati o linee di business. Anche se in genere è consigliabile usare lo stesso tenant di Microsoft Entra per gestire le risorse di Azure in tutti i prodotti (come descritto nella sezione Tenant di Microsoft Entra), in alcuni scenari è possibile scegliere di distribuire più gerarchie di gruppi di gestione.
Considera come indipendenti i tuoi prodotti si trovano l'uno dall'altro e chiediti:
- Tutti i prodotti usano le stesse piattaforme per DevOps, identità, sicurezza, connettività e registrazione?
- Questi servizi condivisi vengono gestiti da un singolo team centrale?
Se si è risposto sì a entrambe le domande, creare un singolo gruppo di gestione del prodotto SaaS di primo livello nel gruppo radice tenant.
Se invece si risponde no e ognuno dei prodotti SaaS viene gestito e gestito da team di piattaforma separati, è consigliabile creare un gruppo di gestione di primo livello separato per ogni prodotto, come i due gruppi di gestione di primo livello SaaS Product-01 e SaaS Product-02.
Suggerimento
Non è raro che un ISV abbia più di pochi gruppi di gestione di primo livello. Spesso, diversi prodotti possono essere combinati insieme a causa di analogie nel modo in cui vengono gestiti e gestiti.
Questo approccio di gestione è simile all'approccio di test per le zone di destinazione su scala aziendale. Tuttavia, invece di creare Contoso e Contoso-Canary nel gruppo radice tenant, in questo approccio la società di esempio creerebbe invece i gruppi di gestione di livello principale Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 e Contoso-SaaS-Product-03 specifici del prodotto. Questo scenario è illustrato nel diagramma seguente:
Gruppo di gestione della piattaforma
Nella gerarchia dell'organizzazione delle risorse della zona di destinazione di Azure il gruppo di gestione della piattaforma contiene tutte le sottoscrizioni di Azure che ospitano componenti e servizi condivisi usati dai carichi di lavoro nelle sottoscrizioni dell'area di destinazione. Esempi di componenti distribuiti nelle sottoscrizioni della piattaforma e dei servizi condivisi includono l'infrastruttura di registrazione centralizzata (ad esempio aree di lavoro Log Analytics), DevOps, sicurezza, strumenti di automazione, risorse di rete centrale (ad esempio i piani hub-VNet e protezione DDos) e i servizi del piano di controllo di un ISV.
Il gruppo di gestione della piattaforma viene spesso partizionato in gruppi figlio Identity, Management e Connectivity per offrire una comoda separazione dei ruoli e dei criteri per i clienti aziendali.
Nell'organizzazione potrebbe essere presente un singolo team che gestisce tutti i componenti della piattaforma condivisa, ad esempio identità, rete e gestione. In tal caso, e se non si prevede di separare tale gestione tra più team, prendere in considerazione l'uso di un singolo gruppo di gestione della piattaforma .
Se invece si avranno team separati che gestiscono parti diverse della piattaforma centralizzata, è necessario distribuire altri livelli nella gerarchia dei gruppi di gestione nel gruppo di gestione della piattaforma . In questo modo è possibile assegnare criteri separati per ogni parte della piattaforma centralizzata.
Il diagramma seguente illustra due potenziali implementazioni del gruppo di gestione della piattaforma . L'opzione A mostra uno scenario più completo, in cui il gruppo di gestione della piattaforma contiene tre gruppi di gestione figlio: Gestione e DevOps, Identità e sicurezza e Connettività. Ogni gruppo di gestione figlio contiene una sottoscrizione con le risorse pertinenti. L'opzione B mostra uno scenario più semplice, in cui il gruppo di gestione della piattaforma contiene una singola sottoscrizione della piattaforma.
Gruppo di gestione zone di destinazione
Il gruppo di gestione zone di destinazione contiene le sottoscrizioni di Azure che ospitano i sottosistemi e i carichi di lavoro effettivi della soluzione SaaS.
Questo gruppo di gestione contiene uno o più gruppi di gestione figlio. Ognuno dei gruppi di gestione figlio in Zone di destinazione rappresenta un archetipo di carico di lavoro o sottosistema, con criteri e requisiti di accesso coerenti che devono essere applicati a tutte le sottoscrizioni. I motivi per l'uso di più archetipi includono:
- Conformità: se un sottosistema del prodotto SaaS deve essere conforme a PCI-DSS, è consigliabile creare un gruppo di gestione figlio archetipo PCI DSS in Zone di destinazione. Tutte le sottoscrizioni di Azure che contengono risorse nell'ambito della conformità PCI-DSS devono essere inserite all'interno di tale gruppo di gestione.
- Livelli: prendere in considerazione la creazione di archetipi di zona di destinazione separati per i clienti del livello dedicato della soluzione SaaS e per i clienti del livello gratuito. Ognuno dei gruppi di gestione figlio contiene impostazioni Criteri di Azure diverse. Ad esempio, i criteri nel livello gratuito potrebbero limitare le distribuzioni solo per abilitare SKU di macchine virtuali specifici e i criteri nel livello dedicato potrebbero richiedere la distribuzione delle risorse in aree specifiche.
Gruppi di gestione specifici dell'ambiente
Gli ISV SaaS spesso organizzano gli ambienti cloud modellando gli ambienti del ciclo di vita dello sviluppo software in una sequenza. Questa operazione richiede in genere la distribuzione in un ambiente di sviluppo , quindi in un ambiente di test , quindi in un ambiente di gestione temporanea e infine in un ambiente di produzione .
Una differenza comune tra gli ambienti è costituita dalle regole di controllo degli accessi in base al ruolo di Azure, ad esempio chi può accedere a ogni gruppo di sottoscrizioni. Ad esempio, i team devOps, SaaSOps, sviluppo e test possono avere tutti livelli diversi di accesso a ambienti diversi.
Importante
La maggior parte dei clienti di Azure ha centinaia di applicazioni e usa sottoscrizioni di Azure separate per ogni team di applicazioni. Se ogni applicazione disponesse di gruppi di gestione di sviluppo, test, staging e produzione propri, esisterebbe un numero elevato di gruppi di gestione con criteri quasi identici. Per la maggior parte dei clienti, le domande frequenti sulla zona di destinazione su scala aziendale consigliano di usare gruppi di gestione separati per ogni ambiente. Consiglia invece di usare sottoscrizioni separate all'interno di un singolo gruppo di gestione.
Tuttavia, gli ISV SaaS possono avere requisiti diversi rispetto alla maggior parte degli altri clienti di Azure e potrebbero avere un buon motivo per usare gruppi di gestione specifici dell'ambiente in alcune situazioni.
Gli ISV SaaS talvolta devono raggruppare più sottoscrizioni che rappresentano partizioni o partizioni dello stesso sottosistema, applicazione o carico di lavoro. Potrebbe essere necessario applicare criteri o assegnazioni di ruolo a gruppi di sottoscrizioni in modo notevolmente diverso rispetto al gruppo di gestione archetipo. In questo caso, prendere in considerazione la creazione di gruppi di gestione figlio che corrispondono a ogni ambiente nel gruppo di gestione archetipo.
I diagrammi seguenti illustrano due possibili opzioni. L'opzione A mostra uno scenario con sottoscrizioni separate per ogni ambiente, ma senza gruppi di gestione specifici dell'ambiente. L'opzione B mostra uno scenario ISV SaaS con gruppi di gestione specifici dell'ambiente nel gruppo di gestione Stamp regolari . Ogni gruppo di gestione specifico dell'ambiente contiene più sottoscrizioni. Nel corso del tempo, l'ISV ridimensiona le risorse di Azure in ogni ambiente in un numero crescente di sottoscrizioni con un set comune di criteri e assegnazioni di ruolo.
Selezionare ogni scheda per visualizzare i due diagrammi.
Gruppi di gestione delle autorizzazioni e sandbox
Le indicazioni per l'organizzazione delle risorse della zona di destinazione di Azure consigliano di includere gruppi di gestione ritirati e sandbox direttamente sotto il gruppo di gestione di primo livello.
Il gruppo di gestione rimosso è un luogo in cui si trovano le sottoscrizioni di Azure che vengono disabilitate e verranno infine eliminate. È possibile spostare una sottoscrizione che non è più in uso in questo gruppo di gestione per tenerne traccia fino a quando tutte le risorse nella sottoscrizione non vengono eliminate definitivamente.
Il gruppo di gestione Sandboxes contiene in genere sottoscrizioni di Azure usate per scopi di esplorazione e non hanno criteri separati o non applicati a tali sottoscrizioni. Ad esempio, è possibile fornire a singoli sviluppatori le proprie sottoscrizioni per lo sviluppo e il test. È possibile evitare di applicare i normali criteri e la governance a queste sottoscrizioni inserendoli nel gruppo di gestione Sandboxes . Questo aumenta l'agilità degli sviluppatori e consente loro di sperimentare facilmente con Azure.
Importante
Le sottoscrizioni nel gruppo di gestione Sandboxes non devono avere connettività diretta alle sottoscrizioni della zona di destinazione. Evitare di connettere sottoscrizioni sandbox ai carichi di lavoro di produzione o a qualsiasi ambiente non di produzione che esegue il mirroring degli ambienti di produzione.
Il diagramma seguente illustra due possibili opzioni. L'opzione A non include i gruppi di gestione Ritirati e Sandbox , mentre l'opzione B.
Aree di destinazione ISV di esempio
Questa sezione include due strutture di zona di destinazione di Azure di esempio per un ISV SaaS. Selezionare ogni scheda per confrontare le due zone di destinazione di esempio.
Il diagramma seguente mostra una gerarchia di zone di destinazione isv di Azure SaaS di esempio con le caratteristiche seguenti:
- L'ISV mantiene tutti i componenti della piattaforma in una singola sottoscrizione di Azure, invece di suddividerli in più gruppi di gestione della piattaforma.
- Esiste un solo gruppo di gestione della zona di destinazione.
- La zona di destinazione include gruppi di gestione specifici dell'ambiente per organizzare le sottoscrizioni e assegnare criteri e ruoli diversi.
- L'ISV non includeva i gruppi di gestione per le sottoscrizioni rimosse e sandbox.
Passaggi successivi
- Se si sta creando una soluzione multi-tenant, vedere Progettare soluzioni multi-tenant in Azure.
- Informazioni su una zona di destinazione di Azure.
- Informazioni sulle aree di progettazione della zona di destinazione di Azure.