Principi di progettazione per le applicazioni Azure

Gli articoli sul principio di progettazione di questa sezione forniscono una base per creare applicazioni cloud in grado di resistere a errori, ridimensionare con la domanda ed evolversi con le esigenze aziendali. Sia che si voglia progettare un nuovo sistema, modernizzare le applicazioni legacy o pianificare carichi di lavoro di produzione, questi principi interconnessi consentono di prendere decisioni informate sull'affidabilità, sulle prestazioni e sulla gestibilità. Insieme, formano un approccio completo alla progettazione di applicazioni native del cloud che bilancia l'eccellenza tecnica con il valore aziendale.

Per rendere l'applicazione più scalabile, resiliente e gestibile, seguire questi principi di progettazione.

Principi di base

• Progettare per l'auto-riparazione. Progettare l'applicazione per rilevare gli errori, rispondere normalmente e ripristinare automaticamente. Nei sistemi distribuiti, gli errori sono inevitabili. Per isolare gli errori e mantenere la disponibilità del sistema, implementare la logica di ripetizione, il monitoraggio degli endpoint di integrità, i circuit breaker e i modelli di compartimentazione.

• Rendere tutte le cose superflue. Integrare ridondanza nell'applicazione per evitare singoli punti di guasto. Usare bilanciatori di carico, istanze multiple, repliche di database e distribuzioni in più zone o regioni diverse. Progettare per il livello di ridondanza corrispondente ai requisiti aziendali e alla tolleranza ai rischi.

• Ridurre al minimo il coordinamento. Ridurre al minimo il coordinamento tra i servizi dell'applicazione per ottenere la scalabilità. Usare componenti disaccoppiati che comunicano in modo asincrono, abbracciano la coerenza finale, se appropriato e applicano gli eventi di dominio per sincronizzare lo stato senza accoppiamento stretto.

• Progettare per aumentare il numero di istanze. Progettare l'applicazione per il ridimensionamento orizzontale aggiungendo o rimuovendo istanze quando cambiano le richieste. Evitare l'aderenza delle sessioni, identificare i colli di bottiglia, scomporre i carichi di lavoro in base ai requisiti di scalabilità, e usare la scalabilità automatica in base alle metriche in tempo reale per gestire in modo efficiente i carichi variabili.

• Partizionamento intorno ai limiti. Usare il partizionamento per aggirare i limiti di database, rete e calcolo. Partizionare i dati orizzontalmente, verticalmente o funzionalmente e progettare chiavi di partizione per evitare hotspot. Considerare il partizionamento a più livelli, inclusi database, code e risorse di calcolo.

Principi operativi

• Progettare per le operazioni. Progettare l'applicazione per fornire ai team operativi gli strumenti necessari per la distribuzione, il monitoraggio e la risposta agli eventi imprevisti. Implementare attività di registrazione complete, traccia distribuita, metriche standardizzate e automatizzare le attività di gestione per consentire una supervisione operativa efficace.

• Usare i servizi gestiti. Usare la piattaforma distribuita come servizio (PaaS) anziché l'infrastruttura distribuita come servizio (IaaS). I servizi gestiti riducono il sovraccarico operativo, offrono funzionalità di scalabilità predefinite e consentono ai team di concentrarsi sulla logica dell'applicazione anziché sulla manutenzione dell'infrastruttura.

• Usare un servizio di gestione delle identità. Usare una piattaforma di gestione delle identità come Microsoft Entra ID invece di creare o gestire il proprio sistema di identità. Le soluzioni gestite offrono archiviazione delle credenziali, funzionalità di autenticazione, funzionalità di federazione e conformità agli standard del settore.

Principi strategici

• Progettare per l'evoluzione. Progettare per l'innovazione continua perché tutte le applicazioni di successo cambiano nel tempo. Applicare l'accoppiamento libero, incapsulare la conoscenza del dominio, usare la messaggistica asincrona ed esporre API ben definite che includono il controllo delle versioni appropriate per abilitare l'evoluzione indipendente del servizio.

• Creare per le esigenze aziendali. Prendere decisioni di progettazione in base ai requisiti aziendali. Definire obiettivi chiari come gli obiettivi del tempo di ripristino (RTO), documentare i contratti di servizio e gli obiettivi del livello di servizio (SLA), modellare le applicazioni per i domini aziendali e pianificare la crescita bilanciando i requisiti funzionali e non funzionali.

• Eseguire l'analisi della modalità di errore per i servizi. Identificare sistematicamente i potenziali punti di errore nel sistema e pianificare le strategie di ripristino. Per creare affidabilità fin dall'inizio, eseguire l'analisi della modalità di errore (FMA) durante le fasi di architettura e progettazione. Valutare ogni modalità di errore in base al rischio e all'impatto, quindi determinare i meccanismi di risposta e ripristino appropriati.

Applicare questi principi

Questi principi interagiscono per creare applicazioni resilienti e scalabili:

• Iniziare con i requisiti aziendali per comprendere cosa si sta creando e perché.

• Progettare per il fallimento implementando capacità di autorigenerazione e ridondanza.

• Pianificare la scalabilità tramite scalabilità orizzontale, partizionamento e coordinamento minimo.

• Usare i servizi di Azure per ridurre la complessità operativa e concentrarsi sulla logica di business.

• Supportare le operazioni tramite il monitoraggio, la registrazione e l'automazione appropriati.

• Progettare per il cambiamento affinché l'applicazione possa evolversi con le esigenze aziendali.