Compilazione per le esigenze aziendali

  • Articolo

Ogni decisione di progettazione deve essere giustificata da un requisito aziendale. Questo principio di progettazione potrebbe sembrare ovvio, ma è fondamentale tenere presente quando si progettano applicazioni di Azure.

L'applicazione deve supportare milioni di utenti o alcune migliaia? Ci sono picchi di traffico di grandi dimensioni o un carico di lavoro costante? Quale livello di interruzione dell'applicazione è accettabile? In definitiva, i requisiti aziendali determinano queste considerazioni di progettazione.

I consigli 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 l'interruzione massima tolerabile (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ù elevato, l'aggiunta di ridondanza potrebbe aggiungere costi aggiuntivi per nessun vantaggio aziendale.

  • Prendere in considerazione i rischi di errore necessari per attenuare. Seguire la guida 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 che riscontra un grave disastro naturale che potrebbe influire su tutte le zone di disponibilità nell'area. La mitigazione di questi rischi non comuni è generalmente più costosa e comporta significativi compromessi, quindi avere una chiara comprensione della tolleranza dell'azienda per il rischio.

  • Documenti contratti di servizio (contratti di servizio) e obiettivi del livello di servizio (CONTRATTI di servizio), inclusi le metriche relative alla disponibilità e alle prestazioni. Ad esempio, una soluzione proposta potrebbe offrire la disponibilità del 99,95%. Se SLO soddisfa il contratto di servizio è una decisione aziendale.

  • Modelli di applicazioni per il dominio aziendale. Analizzare i requisiti aziendali e usare questi requisiti per modellare la soluzione. È consigliabile usare un approccio DDD (Domain-Driven Design) per creare modelli di dominio che riflettono i processi aziendali e i casi d'uso.

  • Definire requisiti funzionali e non funzionali. I requisiti funzionali determinano se un'applicazione esegue l'attività. I requisiti non funzionali determinano la modalità di esecuzione 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.

  • Decomponere i carichi di lavoro. Il carico di lavoro in questo contesto indica una funzionalità discreta o un'attività di calcolo che può essere separata logicamente da altre attività. I carichi di lavoro diversi potrebbero avere requisiti diversi per disponibilità, scalabilità, coerenza dei dati e ripristino di emergenza.

  • 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. Si consideri anche che il modello aziendale e i requisiti aziendali possano 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.

  • Gestire i costi. In un'applicazione locale tradizionale si paga in anticipo per l'hardware come spesa capitale. In un'applicazione cloud si paga per le risorse usate. Assicurarsi di comprendere il modello di 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.

Passaggi successivi