Modelli di architettura applicativa su AWS

Distribuire applicazioni su AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Conosci il tuo docente

Docente del corso Dunieski Otano, AWS Solutions Architect, con circa dieci anni di esperienza cloud

Perché la giusta architettura conta

Diagramma decisionale in tema chiaro dove una scelta architetturale si dirama in tre fattori: coupling, stato e comunicazione, sopra una piccola icona di bilancia per i compromessi

L'architettura è un insieme di compromessi, non una sola risposta giusta
- Tre domande guidano ogni scelta:
  - Quanto sono accoppiati i componenti?
  - Dove vive lo stato?
  - La comunicazione è sincrona o asincrona?
- Abbina il pattern al carico di lavoro, non alla moda

La cascata del venerdì sera

Una payment API lenta blocca tutto il checkout
Ogni servizio la aspettava in modo sincrono
La soluzione è l'architettura, non un'API più veloce

Confronto affiancato tra servizi strettamente accoppiati che si bloccano e servizi disaccoppiati da una coda di messaggi

Perché le scelte architetturali determinano il deploy

Diagramma che confronta un'architettura fragile e strettamente accoppiata, dove un servizio in errore causa una cascata, con un design resiliente dove una coda isola il guasto e gli altri servizi continuano a servire

Il pattern scelto definisce come l'app scala e va in errore
- Un design stretto si rompe sotto carico
Il pattern giusto rende il deploy prevedibile
- Stesso codice, comportamento in produzione molto diverso

I pattern architetturali base

Monolite: un'unità distribuibile, semplice per iniziare
Microservizi: servizi indipendenti, distribuiti separatamente
Event-driven: i componenti reagiscono a eventi, non a chiamate dirette
- Fanout è un sotto‑pattern event-driven: un evento raggiunge molti consumer

Tre pattern architetturali affiancati: monolite come un unico blocco, microservizi come servizi distribuibili indipendenti ed event-driven con un event bus; nel pannello event-driven il fanout invia un evento a molti consumer

Stateful vs stateless

Stateless: nessun dato client tra le richieste
- Qualsiasi istanza può gestire qualsiasi richiesta
Stateful: l'istanza ricorda interazioni precedenti
Lo stateless consente di scalare orizzontalmente
- Sposta lo stato condiviso su DynamoDB o ElastiCache

A sinistra istanza stateless che può ricevere qualsiasi richiesta; a destra istanza stateful legata a una sessione client

Accoppiamento stretto vs lasco

Accoppiamento stretto con il chiamante bloccato in attesa di un callee lento vs accoppiamento lasco con coda SQS che bufferizza i messaggi così il producer continua a lavorare

Accoppiamento stretto: il chiamante aspetta la risposta del callee
Un servizio lento blocca l'intera catena
Accoppiamento lasco: una coda Amazon SQS tra i servizi
Il producer continua anche se il consumer è down

Sincrono vs asincrono

Sincrono: il chiamante si blocca e aspetta il risultato
Usa quando serve la risposta subito
Asincrono: il chiamante delega il lavoro e torna subito
Usa per lavoro lento, a picchi o non urgente

Chiamata sincrona con chiamante bloccato finché arriva la risposta a sinistra vs delega asincrona che ritorna subito con elaborazione in background a destra

Pattern di resilienza per chiamate a terze parti

Retry con backoff esponenziale: attese crescenti tra i tentativi
Circuit breaker: smetti di chiamare un servizio in errore per un po'
Dead-letter queue: parcheggia i messaggi che falliscono sempre
Combinali; retry indiscriminati peggiorano i disservizi

Tre pattern di resilienza: curva di retry con backoff esponenziale, circuit breaker che ferma le chiamate a un servizio in errore e dead-letter queue che cattura i messaggi che esauriscono i retry

Esercitiamoci!

Distribuire applicazioni su AWS