Creare per esigenze aziendali
Ogni decisione di progettazione deve essere giustificata da un requisito aziendale. Questo principio di progettazione può sembrare ovvio, ma è fondamentale tenere presente quando si progettano applicazioni Azure.
L'applicazione deve supportare milioni di utenti o poche migliaia? Sono presenti picchi di traffico di grandi dimensioni o un carico di lavoro costante? Quale livello di interruzione dell'applicazione è accettabile? In definitiva, i requisiti aziendali guidano queste considerazioni di progettazione.
Le raccomandazioni seguenti consentono di progettare e creare soluzioni per soddisfare i requisiti aziendali:
Definire obiettivi aziendali, ad esempio l'obiettivo del tempo di ripristino (RTO), l'obiettivo del punto di ripristino (RPO) e il numero massimo di interruzioni tollerabili (MTO). Questi dati devono guidare le decisioni sull'architettura.
Si supponga, ad esempio, che l'azienda richieda un RTO molto basso e un RPO molto basso. È possibile scegliere di usare un'architettura con ridondanza della zona per soddisfare questi requisiti. Se l'azienda può tollerare un RTO e un RPO più elevati, l'aggiunta di ridondanza potrebbe comportare costi aggiuntivi per nessun vantaggio aziendale.
Prendere in considerazione i rischi di errore che è necessario attenuare. Seguire il materiale sussidiario Progettazione per la riparazione automatica per progettare la soluzione in modo che sia resiliente a molti tipi di modalità di errore comuni. Valutare se è necessario tenere conto di situazioni meno probabili, ad esempio un'area geografica in cui si verifica una grave calamità naturale che potrebbe influire su tutte le zone di disponibilità nell'area. La mitigazione di questi rischi non comuni è in genere più costosa e comporta compromessi significativi, quindi avere una chiara comprensione della tolleranza dell'azienda per il rischio.
Documentare i contratti di servizio e gli obiettivi del livello di servizio ,inclusi le metriche relative alla disponibilità e alle prestazioni. Ad esempio, una soluzione proposta potrebbe offrire una disponibilità del 99,95%. Se tale SLO soddisfa il contratto di servizio è una decisione aziendale.
Modellare le applicazioni per il dominio aziendale. Analizzare i requisiti aziendali e usare questi requisiti per modellare la soluzione. Prendere in considerazione l'uso di un approccio DDD (Domain Driven Design) per creare modelli di dominio che riflettano i processi aziendali e i casi d'uso.
Definire i requisiti funzionali e non funzionali. I requisiti funzionali determinano se un'applicazione esegue l'attività. I requisiti non funzionali determinano il livello di prestazioni dell'applicazione. Assicurarsi di comprendere i requisiti non funzionali, ad esempio scalabilità, disponibilità e latenza. Questi requisiti influiscono sulle decisioni di progettazione e sulle scelte tecnologico.
Scomporre i carichi di lavoro in funzionalità discrete. Un carico di lavoro è una raccolta di risorse, dati e infrastrutture di supporto dell'applicazione che funzionano insieme per ottenere risultati aziendali definiti. Un carico di lavoro è costituito da componenti e anche procedure operative e di sviluppo. I carichi di lavoro spesso possono essere scomposti in funzionalità discrete che si allineano ai flussi utente, dati o di sistema e tali flussi possono essere attribuiti e hanno requisiti non funzionali.
I diversi flussi utente, dati o sistema spesso hanno requisiti diversi per la disponibilità, la scalabilità, la coerenza dei dati e il ripristino di emergenza. I sistemi ben progettati consentono di ottimizzare la progettazione per ogni flusso. A tale scopo, è necessario suddividere i carichi di lavoro in componenti regolabili. Una strategia tipica prevede la categorizzazione dei componenti in base al relativo valore. Ad esempio, i componenti di livello 1 sono fondamentali e devono essere ottimizzati senza considerare le spese. I componenti di livello 2 sono significativi, ma possono essere ridotti temporaneamente con conseguenze minime. I componenti di livello 3 sono facoltativi; mantenerli convenienti e facilmente gestibili. La definizione di una comprensione condivisa del valore dei flussi consente a tutti di progettare ed evolvere un carico di lavoro mantenendo un equilibrio tra i costi e altri requisiti non funzionali.
Pianificare la crescita. Una soluzione potrebbe supportare le esigenze correnti per il numero di utenti, il volume delle transazioni e l'archiviazione dei dati, ma deve anche gestire la crescita senza modifiche principali dell'architettura. Considerare anche che il modello aziendale e i requisiti aziendali potrebbero cambiare nel tempo. È difficile evolvere una soluzione per nuovi casi d'uso e scenari se il modello di servizio e i modelli di dati dell'applicazione sono troppo rigidi.
Allineare il modello di business e i costi. La longevità di un sistema è influenzata dal modo in cui i costi sono allineati al modello aziendale. In qualità di architetto, è necessario prendere in considerazione i driver di valore e usare tali informazioni per guidare le decisioni. È necessario identificare la dimensione in cui la soluzione fornirà valore ,ad esempio la redditività, quindi assicurarsi che l'architettura segua il flusso di valori. In questo modo, l'architettura può massimizzare il valore degli investimenti, producendo un ritorno sugli investimenti (ROI) allineato alle aspettative aziendali.
Gestire i costi. In un'applicazione locale tradizionale si paga in anticipo per l'hardware come spesa in conto capitale. In un'applicazione cloud si paga per le risorse usate. Assicurarsi di comprendere il modello di determinazione prezzi dei servizi. I costi totali possono includere l'utilizzo della larghezza di banda di rete, l'archiviazione, gli indirizzi IP e l'utilizzo del servizio.
Prendere in considerazione anche i costi delle operazioni. Nel cloud non è necessario gestire hardware o infrastruttura, ma è comunque necessario gestire l'applicazione DevOps, la risposta agli eventi imprevisti e il ripristino di emergenza.