Principi di progettazione della zona di destinazione di Azure

L'architettura concettuale della zona di destinazione di Azure si applica universalmente a qualsiasi processo o implementazione della zona di destinazione di Azure. Alla base dell'architettura, un set di principi di progettazione di base funge da bussola per le successive decisioni di progettazione in tutti i domini tecnici critici.

I principi sono intenzionalmente ispiratori, per aiutarti a mirare a un design ottimale dell'architettura di destinazione. Se si sceglie di distribuire un'implementazione che sia un acceleratore della zona di atterraggio di Azure o qualsiasi versione della base di codice della zona di atterraggio di scala aziendale, sfruttare l'architettura applicando i principi di progettazione descritti in questo articolo.

Usare questi principi nell'implementazione come guida utile per realizzare i vantaggi delle tecnologie cloud. Questo approccio nativo orientato al cloud o cloud rappresenta le modalità di lavoro e le opzioni tecniche per l'organizzazione che in genere non offrono approcci tecnologici legacy.

Acquisire familiarità con questi principi per comprendere meglio l'impatto e i compromessi associati alla deviazione.

Impatto delle deviazioni di progettazione

Potrebbero esserci motivi validi per deviare dai principi di progettazione. Ad esempio, i requisiti dell'organizzazione possono determinare risultati o approcci specifici per la progettazione di un ambiente Di Azure. In questi casi, è importante comprendere l'impatto della deviazione sulla progettazione e sulle operazioni future. Considerare attentamente i compromessi di ogni principio.

Come regola generale, essere pronti a bilanciare i requisiti e le funzionalità. Il percorso verso un'architettura concettuale si evolve nel tempo man mano che cambiano i requisiti e si apprende dall'implementazione. Ad esempio, l'uso dei servizi di anteprima e, a seconda delle roadmap dei servizi, può rimuovere i blocchi tecnici durante l'adozione.

Democratizzazione delle sottoscrizioni

La democratizzazione delle sottoscrizioni offre un modo scalabile per accelerare le migrazioni delle applicazioni e lo sviluppo di nuove applicazioni. Questo approccio consente ai team del carico di lavoro di accedere e gestire le sottoscrizioni di Azure in modo indipendente, pur rimanendo all'interno della governance della piattaforma e delle protezioni operative.

1. Usare le sottoscrizioni come unità di gestione. Le sottoscrizioni rappresentano il limite fondamentale per organizzare e gestire le risorse di Azure. Assegnare sottoscrizioni alle business unit per supportare la progettazione, lo sviluppo, il test e la migrazione dei carichi di lavoro. Questo allineamento con le esigenze aziendali e le priorità consente ai proprietari del portfolio e ai team del carico di lavoro di offrire valore più velocemente.

2. Usare le sottoscrizioni per separare gli ambienti dell'applicazione. Le sottoscrizioni devono essere usate anche per controllare e separare gli ambienti nel ciclo di vita di sviluppo software (SDLC), ad esempio sviluppo, test e produzione. Questa separazione migliora la governance, riduce i rischi e supporta la gestione coerente del carico di lavoro. Seguire le indicazioni in Gestire gli ambienti di sviluppo di applicazioni nelle zone di destinazione di Azure.

3. Abilitare un processo di distribuzione automatica delle sottoscrizioni self-service. Stabilire un processo che consenta ai team di applicazioni e servizi di richiedere e ricevere sottoscrizioni con un attrito minimo. Un modello self-service o quasi self-service riduce i ritardi causati da approvazioni manuali e accessi aziendali complessi. Seguire le indicazioni riportate nella distribuzione automatica delle sottoscrizioni per semplificare il provisioning e accelerare l'innovazione.

4. Offrire più tipi di sottoscrizione per supportare requisiti diversi. Fornire una gamma di linee di prodotto di sottoscrizione personalizzate per diversi scenari di carico di lavoro. Questa flessibilità consente ai team di scegliere il tipo di sottoscrizione più appropriato per le proprie esigenze. Fare riferimento a stabilire linee di prodotto comuni per la distribuzione automatica di sottoscrizioni.

5. Supportare le sottoscrizioni con una gerarchia di gruppi di gestione scalabile. Usare una gerarchia di gruppi di gestione ben definita per gestire, gestire e proteggere le sottoscrizioni in modo efficace su larga scala. Questa gerarchia consente l'applicazione centralizzata dei criteri e un'organizzazione efficiente con più sottoscrizioni. Seguire le considerazioni e le raccomandazioni per la progettazione della gerarchia e delle sottoscrizioni consigliate per la zona di destinazione di Azure.

Impatto della deviazione

• Gestione condivisa e operazioni centralizzate. Un modo per implementare questo principio è trasformare le operazioni nelle unità di business e nei team di lavoro. Questa riassegnazione consente ai proprietari del carico di lavoro di avere maggiore controllo e autonomia sui carichi di lavoro, all'interno dei limiti stabiliti dalla struttura della piattaforma. Le organizzazioni che richiedono operazioni centrali potrebbero non voler delegare il controllo degli ambienti di produzione ai team dei carichi di lavoro o alle business unit. Queste organizzazioni potrebbero dover modificare la progettazione dell'organizzazione delle risorse per deviare da questo principio.

• Errore di allineamento del modello operativo. La progettazione dell'architettura concettuale della zona di atterraggio di Azure presuppone un gruppo di gestione e una gerarchia delle sottoscrizioni specifiche per la gestione operativa di tutte le sottoscrizioni. Questa gerarchia potrebbe non essere allineata all'approccio operativo. Man mano che l'organizzazione cresce e si evolve, il modello operativo potrebbe cambiare. Lo spostamento di risorse in sottoscrizioni separate può comportare migrazioni tecniche complesse. Esaminare le linee guida per l'allineamento prima di eseguire il commit in un approccio.

• Mancanza di processo di distribuzione automatica delle sottoscrizioni e automazione. Se non si fornisce un processo di distribuzione delle sottoscrizioni e l'automazione associata, sia essa self-service o meno, i team di applicazioni e servizi subiranno ritardi nel fornire valore all'organizzazione, poiché le sottoscrizioni devono essere create per loro e collocate nel gruppo di gestione appropriato nella gerarchia. Se il processo per ottenere nuove sottoscrizioni è complicato e richiede molto tempo, i team di applicazioni e servizi possono scegliere di creare sottoscrizioni autonomamente tramite account di fatturazione alternativi e forse anche in tenant Microsoft Entra non gestiti o regolamentati, il che significa che lo shadow IT è ora presente.

Governance basata su criteri

Utilizzare Azure Policy per fornire limiti di sicurezza e assicurarsi che le applicazioni distribuite siano conformi ai controlli di sicurezza, governance e normative dell'organizzazione, indipendenti dagli strumenti di implementazione e configurazione. Criteri di Azure offre ai team della piattaforma gli strumenti necessari per implementare, applicare, controllare e controllare le operazioni e le configurazioni del piano dati e del controllo di Azure. In questo modo le sottoscrizioni possono essere democratizzate, idealmente tramite un processo self-service, ai team di applicazioni e servizi in modo che possano offrire rapidamente valore aziendale per l'organizzazione.

Per altre informazioni sull'uso di Criteri di Azure, vedere Adottare protezioni guidate dai criteri.

Impatto della deviazione

Aumento del sovraccarico operativo e di gestione. Se non si usa Criteri di Azure per creare protezioni all'interno dell'ambiente, si aumenta il sovraccarico operativo e di gestione per mantenere la conformità. Criteri di Azure consentono di limitare e automatizzare lo stato di conformità desiderato all'interno dell'ambiente.

Singolo controllo e piano di gestione

Evitare la dipendenza dai livelli di astrazione, ad esempio portali sviluppati dal cliente o strumenti. È consigliabile avere un'esperienza coerente sia per le operazioni centrali che per le operazioni del carico di lavoro. Azure offre un piano di controllo unificato e coerente che si applica a tutte le risorse di Azure e ai canali di provisioning, noti come Azure Resource Manager. Il piano di controllo è soggetto ai controlli degli accessi in base al ruolo e ai controlli basati su criteri. È possibile usare questo piano di controllo di Azure per stabilire un set standardizzato di criteri e controlli che regolano l'intero patrimonio aziendale.

Impatto della deviazione

Maggiore complessità di integrazione. Un approccio multivendor ai piani di controllo e gestione potrebbe introdurre una complessità nell'integrazione e nel supporto delle funzionalità. La sostituzione dei singoli componenti per ottenere una progettazione "migliore della categoria" o strumenti operativi multivendor presenta limitazioni e potrebbe causare errori imprevisti a causa di dipendenze intrinseche.

Se stai portando un investimento in strumenti esistente nel campo delle operazioni, della sicurezza o della governance, esamina i servizi di Azure e le eventuali dipendenze.

Modello di servizio incentrato sulle applicazioni

Concentrarsi sulle migrazioni e sullo sviluppo incentrate sulle applicazioni, anziché sulle migrazioni in modalità lift-and-shift dell'infrastruttura pura, ad esempio lo spostamento di macchine virtuali. Le scelte di progettazione non devono distinguere le applicazioni precedenti e nuove, le applicazioni IaaS (Infrastructure as a Service) o le applicazioni PaaS (Platform as a Service).

Indipendentemente dal modello di servizio, cercare di fornire un ambiente sicuro per tutte le applicazioni distribuite nella piattaforma Azure.

Impatto della deviazione

• Maggiore complessità dei criteri di governance. Se si segmentano i carichi di lavoro in modo diverso dalle opzioni di implementazione della gerarchia dei gruppi di gestione, si aumenta la complessità nei criteri di governance e nelle strutture di controllo di accesso che regolano l'ambiente. Gli esempi includono la deviazione dalla struttura della gerarchia organizzativa o dal raggruppamento in base al servizio di Azure.

• Aumento del sovraccarico operativo. Questo compromesso introduce il rischio di duplicazione ed eccezioni involontarie dei criteri, che aggiungono a sovraccarichi operativi e di gestione.

• Sviluppo/test/produzione è un altro approccio comune che le organizzazioni considerano. Per altre informazioni, vedere Come gestire le zone di destinazione del carico di lavoro "sviluppo/test/produzione" nell'architettura della zona di destinazione di Azure.

Allineamento con la progettazione e le roadmap native di Azure

Usare i servizi e le funzionalità della piattaforma nativa di Azure ogni volta che è possibile. Questo approccio deve essere allineato alle roadmap della piattaforma Azure per garantire che le nuove funzionalità siano disponibili all'interno degli ambienti. Le roadmap della piattaforma Azure devono aiutare a informare la strategia di migrazione e la traiettoria concettuale della zona di destinazione di Azure.

Impatto della deviazione

Maggiore complessità di integrazione. L'introduzione di soluzioni di terze parti nell'ambiente Azure può creare una dipendenza da tali soluzioni per fornire supporto e integrazione delle funzionalità con i servizi di prima parte di Azure.

A volte gli investimenti in soluzioni di terze parti esistenti in un ambiente sono inevitabili. Prendere in considerazione questo principio e i relativi compromessi con attenzione per allinearsi ai propri requisiti.

Passaggi successivi

Le organizzazioni potrebbero trovarsi in diverse fasi dei percorsi cloud quando esaminano queste linee guida. Pertanto, le azioni e le raccomandazioni necessarie per progredire verso i risultati precedenti possono variare. Per comprendere le migliori azioni successive per la fase di adozione del cloud, vedere il percorso all'architettura di destinazione.

Per scegliere l'opzione di implementazione corretta della zona di destinazione di Azure, comprendere le aree di progettazione della zona di destinazione di Azure.