Principi di progettazione per le zone di destinazione di Azure
L'architettura concettuale per le zone di destinazione di Azure viene applicata universalmente a qualsiasi processo o implementazione di zone di destinazione. Alla base dell'architettura c'è un set di principi di progettazione fondamentali che orientano le successive decisioni di progettazione negli ambiti tecnici critici.
I principi aiutano a ottenere una progettazione ottimale dell'architettura di destinazione. Se si decide di distribuire un acceleratore della zona di destinazione di Azure o qualsiasi versione della base di codice della zona di destinazione su scala aziendale, è consigliabile creare l'architettura applicando i principi di progettazione qui descritti.
Nell'ambito di un'implementazione, questi principi rappresentano una guida utile per cogliere i vantaggi delle tecnologie cloud. Questa prospettiva orientata al cloud, spesso indicata con l'espressione nativa del cloud, rappresenta modi di lavorare e opzioni tecniche disponibili all'organizzazione che gli approcci tecnologici tradizionali non offrono.
Impatto delle deviazioni di progettazione
Ci possono essere validi motivi per deviare dai principi, come nel caso di Tailwind Traders. I requisiti organizzativi potrebbero prescrivere risultati o approcci specifici nella progettazione di un ambiente Azure. In questi casi, è importante comprendere l'impatto che la deviazione avrà sulla progettazione e sulle operazioni future. Valutare con attenzione i compromessi delineati per ogni principio.
In generale, è bene prepararsi a trovare un equilibrio tra i requisiti e la funzionalità. Il percorso verso l'architettura concettuale evolverà nel tempo man mano che cambieranno i requisiti e che si acquisiranno informazioni dall'implementazione. Ad esempio, l'uso di servizi di anteprima e l'acquisizione delle dipendenze dalle roadmap dei servizi possono rimuovere gli ostacoli tecnici in fase di adozione.
Democratizzazione delle sottoscrizioni
È consigliabile usare le sottoscrizioni come unità di gestione e di scalabilità per accelerare la migrazione delle applicazioni e lo sviluppo di nuove 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 consentire all'organizzazione di operare in modo efficace su vasta scala, si può supportare una sottoscrizione con una gerarchia di gruppi di gestione appropriata. In questo modo la sottoscrizione potrà essere gestita e organizzata in modo efficiente.
Impatto della deviazione
Un modo per implementare questo principio consiste nel decentralizzare le operazioni trasferendole alle business unit e ai team dei carichi di lavoro. Questo approccio consente ai proprietari dei carichi di lavoro di avere maggiore controllo e più autonomia sui carichi di lavoro all'interno delle protezioni che le basi della piattaforma hanno stabilito.
Le aziende che devono decentralizzare le operazioni e che non vogliono delegare il controllo degli ambienti di produzione alle business unit o ai team dei carichi di lavoro potrebbero avere la necessità di modificare la progettazione dell'organizzazione delle risorse e di deviare da questo principio.
La progettazione dell'architettura concettuale per le zone di destinazione di Azure presuppone la presenza di un gruppo di gestione e di una gerarchia di sottoscrizione specifici per tutte le sottoscrizioni di gestione delle operazioni. Questo presupposto potrebbe non essere in linea con il modello operativo della propria azienda.
Con questa deviazione, man mano che l'organizzazione cresce ed evolve, il modello operativo potrebbe cambiare. Questa modifica può portare di nuovo a una migrazione di risorse in sottoscrizioni separate, con conseguenti migrazioni tecniche complesse. Prima di impegnarsi in un approccio, esaminare le linee guida dell'allineamento.
Governance basata sui criteri
Usare Criteri di Azure per fornire misure di protezione e assicurare la continuità della conformità con la piattaforma dell'organizzazione e le applicazioni che vi sono distribuite. Anche Criteri di Azure offre ai proprietari di applicazioni l'indipendenza e un percorso sicuro e privo di ostacoli verso il cloud.
Impatto della deviazione
Se non si usa Criteri di Azure per creare protezioni all'interno dell'ambiente, si aumenta il sovraccarico operativo e di gestione dovuto al mantenimento della conformità. Criteri di Azure consente di limitare e automatizzare lo stato di conformità desiderato all'interno dell'ambiente.
Come parte degli aspetti da considerare per la progettazione, esaminare come usare Criteri di Azure nell'implementazione di una zona di destinazione.
Unico piano di controllo e di gestione
Evitare la dipendenza dai livelli di astrazione, ad esempio portali o strumenti sviluppati dai clienti. È consigliabile avere una buona esperienza sia con le operazioni centrali sia con le operazioni del carico di lavoro.
Azure fornisce un piano di controllo unificato e coerente, soggetto al controllo degli accessi in base al ruolo e ai controlli basati sui criteri. Questo vale per tutte le risorse e i canali di provisioning di Azure. È possibile usare Azure per definire un set di criteri e controlli standardizzato per la gestione dell'intero ambiente aziendale.
Impatto della deviazione
La scelta di un approccio con più fornitori per applicare i piani di controllo e di gestione può introdurre complessità in termini di integrazione e di supporto delle funzionalità. La sostituzione di singoli componenti per ottenere un design "ottimale" o l'uso di strumenti operativi di più fornitori potrebbe presentare limitazioni e generare errori imprevisti a causa delle dipendenze intrinseche.
Per i clienti che intendono usare strumenti in cui hanno già investito per le operazioni, la sicurezza o la governance, è consigliabile esaminare i servizi di Azure e le eventuali dipendenze.
Modello di servizio incentrato sulle applicazioni
Concentrarsi su migrazioni incentrate sulle applicazioni e sullo sviluppo anziché su migrazioni pure in modalità lift-and-shift dell'infrastruttura, come ad esempio lo spostamento di macchine virtuali. Le scelte progettuali non devono distinguere tra applicazioni vecchie e nuove, tra applicazioni IaaS (infrastruttura distribuita come servizio) o PaaS (piattaforma distribuita come servizio).
A prescindere dal modello di servizio, cercare di fornire un ambiente sicuro per tutte le applicazioni distribuite sulla piattaforma Azure.
Impatto della deviazione
La segmentazione dei carichi di lavoro in un modo diverso rispetto alle opzioni di implementazione per la gerarchia dei gruppi di gestione può creare una struttura complessa di criteri e di controllo degli accessi per la governance dell'ambiente, ad esempio la deviazione dalla struttura gerarchica dell'organizzazione o dal raggruppamento in base al servizio di Azure. Questo compromesso introduce il rischio di duplicazione non intenzionale dei criteri e il rischio di generare eccezioni, che si aggiungono ai sovraccarichi operativi e di gestione.
Un altro approccio comune che i clienti considerano è l'uso delle zone di destinazione per carichi di lavoro di sviluppo, test e produzione. Per altre informazioni, vedere la domanda Come si gestiscono le zone di destinazione del carico di lavoro "sviluppo/test/produzione" nell'architettura su scala aziendale? tra le Domande frequenti.
Allineamento alla progettazione nativa e alle roadmap di Azure
È consigliabile sfruttare i servizi e le funzionalità nativi della piattaforma Azure, laddove possibile. Allineare questo approccio alle roadmap della piattaforma Azure per assicurare che le nuove funzionalità siano disponibili all'interno degli ambienti. Le roadmap della piattaforma Azure aiutano a definire la strategia di migrazione e la traiettoria concettuale delle zone di destinazione di Azure.
Impatto della deviazione
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 Azure.
A volte è inevitabile integrare gli investimenti esistenti in soluzioni di terze parti all'interno di un ambiente. Occorre prestare particolare attenzione a questo principio e ai suoi compromessi per l'allineamento ai propri requisiti.
Consigli
Prepararsi a disattivare le funzionalità perché è improbabile che tutti gli elementi siano necessari da subito. Usare i servizi in anteprima e basarsi sulle roadmap per rimuovere i blocchi tecnici.
Quando si usa questo approccio, non tutti gli aspetti del modello operativo desiderato saranno disponibili a livello generale.