Costruire Azure che resiste al mondo reale — con Mike Martin [MVP]

L'architettura Azure sembra semplice quando tutto funziona. La vera prova arriva quando le dipendenze falliscono, le regioni diventano non disponibili, il traffico aumenta improvvisamente, le ipotesi si rivelano sbagliate, i requisiti cambiano e qualcuno alla fine pone la domanda scomoda: perché abbiamo progettato il sistema in questo modo?

In questo episodio di M365.FM, Mirko Peters parla con Mike Martin [MVP] di come appare un'architettura Azure quando deve sopravvivere alle condizioni reali di produzione, e non soltanto apparire bene su un diagramma.

Mike porta con sé decenni di esperienza in sviluppo, infrastrutture, architettura, leadership, coaching, formazione e Microsoft Azure. Una delle sue osservazioni più significative è che molti dei problemi che gli architetti affrontano oggi non sono realmente nuovi. Il DNS continua a rompersi, le dipendenze dagli IP continuano a contare, i costi continuano a diventare un problema, le integrazioni continuano a fallire e le dipendenze continuano a scomparire nel momento peggiore.

Ciò che è cambiato è il livello di complessità che costruiamo attorno a questi problemi.

DA VISUAL BASIC ALL'ARCHITETTURA MODERNA DI AZURE
Mike ripercorre quasi trent'anni di IT, partendo come sviluppatore Visual Basic negli anni '90 e passando attraverso sistemi distribuiti, networking, software enterprise, infrastrutture e infine Azure.

La sua osservazione chiave è semplice: il settore continua a risolvere molti degli stessi problemi di fondo, ma le architetture che li circondano sono diventate molto più complesse.

I sistemi moderni sono passati da applicazioni client-server ad architetture distribuite, piattaforme cloud, container, microservizi, Kubernetes, ambienti ibridi e ora sviluppo assistito dall'IA.

Questo crea enormi possibilità, ma introduce anche un nuovo rischio: l'overengineering.

Mike sostiene che molti team oggi rendono inutilmente complicati problemi semplici. Una buona architettura spesso non consiste nell'aggiungere altra tecnologia, ma nel sapere che cosa non aggiungere.

CHE COSA FA REALMENTE UN ARCHITETTO AZURE?
Per Mike, l'architettura non riguarda la scelta del maggior numero possibile di servizi Azure né la produzione di un diagramma impressionante.

Si tratta di capire quali componenti appartengono insieme, quali andrebbero evitati, quali sono necessari e come costruire qualcosa di manutenibile, scalabile, sicuro e resiliente.

L'architettura comprende molto più del calcolo.

• Identità
• Networking
• Flussi di dati
• Sicurezza
• Monitoraggio
• Integrazione
• Dipendenze
• Scalabilità
• Operazioni
• Ripristino
• Deployment
• Costi

Mike mette anche in discussione l'idea che cloud-native significhi automaticamente Kubernetes o container. Azure offre molti servizi gestiti e nativi che possono risolvere i problemi senza introdurre un carico operativo non necessario.

Il ruolo dell'architetto è comprendere la soluzione nel suo complesso e scegliere l'architettura più semplice che soddisfi comunque i requisiti reali.

INIZIARE DAI REQUISITI DI BUSINESS, NON DAI SERVIZI AZURE
Una delle lezioni più importanti di questo episodio è semplice: non partire dalla tecnologia.

Prima di decidere tra Azure Kubernetes Service, App Service, Azure Functions, container, Service Bus o un'altra piattaforma, i team dovrebbero capire che cosa deve realmente fare la soluzione.

Domande da porsi:

• È interna o rivolta ai clienti?
• Quanti utenti dipenderanno da essa?
• Deve scalare a livello globale?
• Per quanto tempo può restare non disponibile?
• Quanti dati può permettersi di perdere il business?
• Quali requisiti di conformità si applicano?
• Che cosa succede se l'applicazione scompare per diverse ore?
• Chi ne è coinvolto?
• Quale livello di supporto operativo è richiesto?

Queste domande portano direttamente a concetti come SLA, SLO, RTO e RPO. Determinano anche se l'architettura debba essere a singola regione, multi-regione, active-active, active-passive o molto più semplice.

RTO E RPO SENZA IL GERGO
RTO e RPO sono spesso discussi come acronimi tecnici, ma il loro significato reale è orientato al business.

• RTO — Recovery Time Objective: entro quanto tempo il sistema deve tornare operativo dopo un guasto?
• RPO — Recovery Point Objective: quanta perdita di dati è accettabile?

Un sistema usato per un monitoraggio non critico può tollerare diverse ore di indisponibilità o di dati persi. Un sistema che supporta i primi soccorritori, le operazioni finanziarie, il commercio o infrastrutture critiche può richiedere il ripristino in pochi minuti.

Il punto importante è che questi valori non dovrebbero essere inventati dall'architetto. Devono derivare dall'impatto effettivo del guasto sul business.

Una volta comprese queste esigenze, possono essere tradotte in decisioni di progettazione tecniche.

LA RESILIENZA NON È LA STESSA COSA DELL'ALTA DISPONIBILITÀ
Mike usa una semplice analogia per spiegare la differenza tra disponibilità e resilienza.

Un sistema ad alta disponibilità può avere un altro componente pronto a subentrare quando quello principale fallisce.

Un sistema resiliente è progettato per assorbire i problemi, continuare a funzionare, recuperare con gradualità e tornare alla normalità senza collassare completamente.

Questa distinzione è importante. Un'applicazione può essere tecnicamente disponibile pur offrendo un'esperienza scadente. Può essere:

• Lenta
• Soggetta a throttling
• Parzialmente non disponibile
• Dipendente da un backend in difficoltà
• Colpita da un problema di integrazione
• Sotto pressione a livello regionale

La vera resilienza richiede quindi più del semplice uptime. Richiede un'architettura in grado di gestire il carico, gli errori applicativi, i guasti parziali, i problemi regionali, le dipendenze interrotte, gli incidenti operativi e il ripristino una volta superato l'incidente.

AZURE NON RENDE LA TUA APPLICAZIONE RESILIENTE AUTOMATICAMENTE
Un'ipotesi pericolosa è che, poiché Azure stesso è altamente disponibile, qualsiasi applicazione in esecuzione su Azure erediti automaticamente quella resilienza.

Non è così. Microsoft fornisce i servizi e le funzionalità che rendono possibili architetture resilienti. I clienti devono comunque progettare per la resilienza.

È qui che i pattern architetturali contano:

• Circuit breaker
• Accoppiamento debole
• Elaborazione asincrona
• Scalabilità indipendente
• Più zone di disponibilità
• Più regioni
• Meccanismi di failover
• Monitoraggio
• Infrastructure as Code
• Procedure di ripristino testate

Microsoft fornisce i mattoni fondamentali. È l'architettura a determinare se questi mattoni creano effettivamente un sistema resiliente.

PERCHÉ LA PROGETTAZIONE ASINCRONA CONTA
Uno degli esempi più efficaci dell'episodio riguarda i sistemi che sperimentano picchi di traffico prevedibili, come i portali fiscali governativi.

Un problema progettuale comune si verifica quando ogni azione dipende da un'operazione backend sincrona. L'utente clicca un pulsante. Il frontend attende il backend. Il backend attende un altro servizio. Una dipendenza rallenta e alla fine l'intera esperienza utente ne risente.

Mike spiega perché i sistemi a basso accoppiamento sono spesso più resilienti. Invece di costringere il frontend ad attendere ogni operazione backend, le applicazioni possono inserire il lavoro in code o in sistemi event-driven e lasciare che i componenti elaborino le attività in modo indipendente.

Questo porta diversi vantaggi:

• Componenti diversi possono scalare in modo indipendente
• Un servizio può fallire senza far crollare l'intera piattaforma
• I backend possono elaborare il lavoro in modo asincrono
• I picchi di traffico diventano più facili da assorbire
• I componenti rivolti all'utente dipendono meno dai tempi del backend
• I guasti diventano più facili da isolare

IL MITO DELL'UPTIME AL 100 PERCENT
Un altro tema centrale della discussione è l'ossessione per la disponibilità al 100 percento. Mike è molto chiaro: l'uptime del 100 percento non è un obiettivo architetturale realistico.

Una soluzione è di solito composta da più servizi. Ogni servizio ha il proprio SLA. Una volta combinate diverse dipendenze, la