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 fondamentali di progettazione funge da bussola per le successive decisioni di progettazione tra domini tecnici critici.
I principi sono intenzionalmente aspirazioni, per aiutare a cercare una progettazione ottimale dell'architettura di destinazione. Se si sceglie di distribuire un'implementazione che rappresenta un acceleratore di zona di destinazione di Azure o qualsiasi versione della base di codice della zona di destinazione su scala aziendale, compilare 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 al cloud o al cloud rappresenta i modi di lavorare e opzioni tecniche per l'organizzazione che gli approcci tecnologici legacy non offrono in genere.
Acquisire familiarità con questi principi per comprendere meglio il loro 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.
In generale, è bene prepararsi a trovare un equilibrio tra i requisiti e la funzionalità. Il percorso di un'architettura concettuale si evolve nel tempo quando i requisiti cambiano e si apprenderà dall'implementazione. Ad esempio, l'uso dei servizi di anteprima e a seconda delle roadmap del servizio può rimuovere i blocchi tecnici durante l'adozione.
Democratizzazione delle sottoscrizioni
Usare le sottoscrizioni come unità di gestione e scalabilità per accelerare le migrazioni delle applicazioni e il nuovo sviluppo di applicazioni. Allineare le sottoscrizioni alle esigenze e alle priorità aziendali per supportare le aree di business e i proprietari di portfolio. Fornire sottoscrizioni alle business unit per supportare la progettazione, lo sviluppo e il test di nuovi carichi di lavoro e la migrazione di carichi di lavoro esistenti.
Per aiutare l'organizzazione a funzionare in modo efficace su larga scala, supportare una sottoscrizione con una gerarchia del gruppo di gestione appropriata. Questa gerarchia consente la gestione efficiente delle sottoscrizioni e l'organizzazione.
Suggerimento
Per altre informazioni sulla democratizzazione delle sottoscrizioni, vedere il recente video di YouTube Azure Landing Zones - Quanti sottoscrizioni devono essere usati in Azure?
Impatto della deviazione
Operazioni decentralizzate e centralizzate. Un modo per implementare questo principio passa le operazioni alle business unit e ai team del carico di lavoro. Questa riassegnazione consente ai proprietari del carico di lavoro di avere maggiore controllo e autonomia sui carichi di lavoro, all'interno dei guardrail della base della piattaforma. Le organizzazioni che richiedono operazioni centrali potrebbero non voler delegare il controllo degli ambienti di produzione ai team di carico 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. Progettazione dell'architettura concettuale della zona di destinazione di Azure presuppone una gerarchia specifica di gruppo di gestione e sottoscrizione per tutte le sottoscrizioni di gestione delle operazioni. Questa gerarchia potrebbe non essere allineata al modello operativo. Man mano che l'organizzazione cresce ed evolve, il modello operativo potrebbe cambiare. Lo spostamento delle risorse in sottoscrizioni separate può causare migrazioni tecniche complesse. Esaminare le linee guida Allinea prima di eseguire il commit a un approccio.
Governance basata sui criteri
Usare Criteri di Azure per fornire guardrail e assicurarsi che le applicazioni distribuite siano conformi alla piattaforma dell'organizzazione. Criteri di Azure fornisce ai proprietari delle applicazioni l'indipendenza e un percorso sicuro e senza problemi al cloud.
Per altre informazioni, vedere Adottare guardrail basate su criteri.
Impatto della deviazione
Aumento del sovraccarico operativo e di gestione. Se non si usano criteri per creare guardrail all'interno dell'ambiente, aumentare il sovraccarico operativo e di gestione della gestione della conformità. Criteri di Azure consente di limitare e automatizzare lo stato di conformità desiderato all'interno dell'ambiente.
Unico piano di controllo e di gestione
Evitare la dipendenza dai livelli di astrazione, ad esempio i portali sviluppati dal cliente o gli 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. Il piano di controllo è soggetto a controlli basati sui ruoli e sull'accesso basato sui 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 per il controllo e i piani di gestione possono introdurre l'integrazione e la funzionalità supportano la complessità. La sostituzione dei singoli componenti per ottenere una progettazione "migliore di razza" o uno strumento di operatore multivendor presenta limitazioni e potrebbe causare errori imprevisti a causa di dipendenze intrinseche.
Se si sta portando un investimento esistente in operazioni, sicurezza o governance, esaminare i servizi di Azure e le dipendenze.
Modello di servizio incentrato sulle applicazioni
Concentrarsi sulle migrazioni e lo sviluppo incentrate sull'applicazione, anziché sulle migrazioni pure dell'infrastruttura lift-and-shift, ad esempio lo spostamento di macchine virtuali. Le scelte di progettazione non devono distinguere le applicazioni precedenti e nuove, le applicazioni infrastruttura come servizio (IaaS) 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 i carichi di lavoro vengono segmentato in modo diverso dalle opzioni di implementazione della gerarchia del gruppo di gestione, si aumenta la complessità nei criteri di governance e nelle strutture di controllo di accesso che regolano l'ambiente. ad esempio la deviazione dalla struttura gerarchica dell'organizzazione o dal raggruppamento in base al servizio di Azure.
Aumento del sovraccarico operativo. Questo compromesso introduce il rischio di duplicazione e eccezioni di criteri non intenzionali, che aggiungono a sovraccarichi operativi e di gestione.
Dev/Test/Production è un altro approccio comune che le organizzazioni considerano. Per altre informazioni, vedere Come gestire le zone di destinazione del carico di lavoro "dev/test/production" nell'architettura della zona di destinazione di Azure.
Allineamento alla progettazione nativa e alle roadmap di Azure
È consigliabile sfruttare i servizi e le funzionalità nativi della piattaforma Azure, laddove possibile. Questo approccio deve essere allineato alle roadmap della piattaforma Azure per assicurare che le nuove funzionalità siano disponibili all'interno degli ambienti. Le roadmap della piattaforma di 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, l'inserimento di investimenti di soluzioni di terze parti esistenti in un ambiente è ineluttabile. Prendere in considerazione questo principio e i suoi compromessi attentamente per allinearsi ai requisiti.
Passaggi successivi
Le organizzazioni potrebbero essere in fasi diverse dei loro percorsi cloud quando esaminano queste linee guida. Pertanto, le azioni e le raccomandazioni necessarie per progredire verso i risultati precedenti potrebbero variare. Per comprendere le migliori azioni successive per la fase di adozione del cloud, esaminare il percorso dell'architettura di destinazione.
Per scegliere l'opzione di implementazione della zona di destinazione di Azure appropriata, comprendere le aree di progettazione della zona di destinazione di Azure.