Applicare i modelli WAF ad architetture reali

Applicare i pattern WAF alle architetture reali non è un esercizio teorico: richiede di valutare ogni decisione progettuale rispetto ai cinque pilastri e di adottare compromessi consapevoli. Un punto di partenza comune è il diagramma dell'architettura: segua il percorso di una richiesta dell'utente attraverso ogni componente e si chieda, per ogni passaggio, cosa accadrebbe se il componente non funzionasse, quanto costerebbe e come sarebbe protetto.

Consideri una tradizionale applicazione web monolitica: una singola macchina virtuale che esegue insieme un server Web e un database, dietro un indirizzo IP pubblico. Rispetto ai pilastri WAF, questa soluzione ottiene risultati scarsi in tutti e cinque: nessuna ridondanza (affidabilità), database sullo stesso host del livello Web (sicurezza), macchina virtuale sempre attiva indipendentemente dal traffico (costi), nessun CI/CD (eccellenza operativa) e solo scalabilità verticale (efficienza delle prestazioni).

Per affrontare il pilastro Affidabilità, distribuisca il livello web su più VM in diverse zone di disponibilità, protegga il database con la replica geografica verso una regione secondaria e posizioni un Azure Load Balancer davanti al livello web. In questo modo elimina il singolo punto di errore e consente all'applicazione di continuare a funzionare in caso di interruzione di una zona o di un'intera regione, senza interventi manuali.

Per il pilastro Sicurezza, separi il livello web e il database in subnet diverse, usando regole NSG che consentano al livello web di connettersi esclusivamente alla porta del database. Archivi la stringa di connessione del database in Azure Key Vault e usi una identità gestita nell'app Web per recuperarla in fase di esecuzione, eliminando così le credenziali codificate direttamente nel codice dell'applicazione e nei file di configurazione.

Per l'Ottimizzazione dei costi, sostituisca le VM sempre attive con un Virtual Machine Scale Set che riduca il numero di istanze nelle ore non di punta. Per il database, valuti se un servizio PaaS gestito come Azure SQL Database, con un livello DTU appropriato, sia meno costoso di una VM completa con SQL Server. Acquisti istanze riservate per la capacità di base che può prevedere con 12 mesi di anticipo.

Migliori l'Eccellenza operativa definendo l'intera infrastruttura tramite template Bicep o ARM archiviati nel controllo del codice sorgente. Crei una pipeline CI/CD in Azure Pipelines o GitHub Actions che distribuisca automaticamente le modifiche all'infrastruttura e il codice dell'applicazione. Aggiunga gate di distribuzione, ovvero smoke test automatizzati e approvazione manuale, prima che le modifiche raggiungano l'ambiente di produzione.

Per l'Efficienza delle prestazioni, introduca Azure Cache for Redis davanti al database per memorizzare nella cache le query lette più frequentemente e ridurre il carico sul database. Distribuisca gli asset statici (immagini, CSS, JavaScript) tramite Azure CDN, in modo da servirli dai nodi edge più vicini agli utenti di tutto il mondo. Esegua test di carico sull'applicazione dopo ogni modifica per verificare che i miglioramenti siano misurabili.

Ogni modifica architetturale comporta un compromesso. Ad esempio, il passaggio a un'architettura multi-zona migliora l'affidabilità, ma aumenta i costi (due zone significano due VM). L'aggiunta della memorizzazione nella cache Redis migliora le prestazioni, ma aggiunge complessità operativa (un altro servizio da monitorare e gestire). Una buona documentazione dell'architettura registra esplicitamente questi compromessi, così gli architetti futuri possono comprendere le motivazioni delle decisioni.

Eviti di cercare la perfezione in una singola riprogettazione: questo approccio è costoso, rischioso e lento. Adotti invece un ciclo di miglioramento iterativo: esegua una Well-Architected Review, individui i tre problemi con l'impatto maggiore, li risolva, misuri i miglioramenti e ripeta il ciclo. Questo approccio allinea i miglioramenti architetturali alla distribuzione agile e rende visibili i progressi agli stakeholder a ogni sprint.

Microsoft pubblica architetture di riferimento per i più comuni modelli di carico di lavoro nell'Azure Architecture Center. Tra queste sono incluse architetture per applicazioni Web, microservizi in AKS, pipeline di analisi dei dati e molte altre. Ogni architettura di riferimento è già stata valutata rispetto ai pilastri WAF e include note sui compromessi adottati per quello specifico modello.

Usi gli Architecture Decision Records (ADR) per documentare le scelte architetturali significative, il contesto in cui sono state effettuate, le alternative considerate e le implicazioni per i pilastri WAF. Gli ADR archiviati nel controllo del codice sorgente insieme alla codebase creano una cronologia verificabile che aiuta i nuovi membri del team a comprendere le motivazioni dell'architettura attuale.

Verifichi la sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che gli schemi WAF vengono applicati valutando ogni decisione architetturale rispetto a tutti e cinque i pilastri; i miglioramenti possono essere apportati in modo iterativo iniziando dai problemi con l'impatto maggiore; e i compromessi devono essere documentati, affinché gli architetti futuri comprendano le motivazioni. Nella prossima lezione esamineremo gli SLA di Azure e come calcolare gli SLA compositi per le architetture con più servizi.