Cloud computing spiegato: gli 11 concetti di architettura che devi conoscere (Masterclass 4K).

Contenuto di questo video

• - Il Muro dell'Architettura e il Master Blueprint
• - 01. Scaling Verticale vs. Orizzontale
• - 02. Architettura del Bilanciamento del Carico (L4 vs. L7 e Controlli di Salute)
• - 03. Autoscaling ed Elasticità
• - 04. Serverless (FaaS e MicroVM Firecracker)

Trascrizione tradotta

Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.

- Il Muro dell'Architettura e il Master Blueprint

0:00 Ogni ingegnere del software prima o poi si trova di fronte al muro dell'architettura cloud. Costruisci un'applicazione sul tuo laptop, la metti in produzione, e nel momento in cui arrivano utenti reali, i server vanno in crash, le connessioni al database si esauriscono, e la tua fattura AWS sembra un numero di telefono. La maggior parte degli sviluppatori cerca di risolvere l'ingegneria cloud memorizzando trecento diversi acronimi di prodotti AWS. Ma il vero cloud computing non consiste nel memorizzare cataloghi di fornitori: è costruito su undici primitive architettoniche fondamentali.

0:34 In questa masterclass, esamineremo l'intero blueprint aziendale: dallo scaling e bilanciamento del carico al serverless, al disaccoppiamento basato su eventi, gerarchie di storage e networking cloud. Padroneggia questi undici concetti e potrai progettare qualsiasi backend su AWS, GCP o Azure. Questo è The Daily Diff, dietro le quinte.

- 01. Scaling Verticale vs. Orizzontale

0:57 Concetto numero uno: Scaling. Quando la tua applicazione sperimenta una crescita del traffico, hai due modi fondamentalmente diversi per gestire il carico: scaling verticale o scaling orizzontale. Lo scaling verticale, o scaling up, significa prendere la tua macchina esistente e aggiungere più risorse: aggiornare da quattro core CPU a trentadue, o scambiare trentadue gigabyte di RAM con centoventotto. centoventotto. Lo scaling verticale non richiede modifiche architetturali: il tuo codice

1:28 e il database rimangono esattamente gli stessi. Ma raggiunge un brutale limite hardware. Nessuna singola macchina al mondo ha diecimila core CPU, e le istanze di fascia alta comportano un premio di prezzo esponenziale. Lo scaling orizzontale, o scaling out, significa mantenere i tuoi server piccoli e a prezzo di mercato, ma eseguire più istanze in parallelo dietro un router. Se un'istanza si arresta in modo anomalo, i nodi rimanenti assorbono il traffico con zero tempi di inattività. La regola d'oro dello scaling orizzontale è la

2:01 statelessness: i tuoi server applicativi non possono memorizzare sessioni utente, file caricati o stato sui loro dischi locali. Lo stato deve risiedere in un database o cache esterno, consentendo a qualsiasi nodo di gestire qualsiasi richiesta utente.

- 02. Architettura del Bilanciamento del Carico (L4 vs. L7 e Controlli di Salute)

2:17 Concetto numero due: Bilanciamento del Carico. Lo scaling orizzontale sembra ottimo sulla carta, ma introduce un problema immediato: quando diecimila utenti accedono al tuo nome di dominio, quale server specifico riceve il loro traffico? Un bilanciatore di carico agisce come un proxy inverso che si trova tra l'internet pubblico e il tuo cluster backend privato. Accetta connessioni TCP o HTTP in ingresso e distribuisce le richieste tra le tue istanze sane.

2:47 I bilanciatori di carico operano su due principali livelli di rete. I bilanciatori di carico di rete di livello 4 operano al livello di trasporto, instradando pacchetti TCP e UDP grezzi basati su indirizzo IP e porta con latenza di microsecondi e milioni di richieste al secondo. I bilanciatori di carico di applicazione di livello 7 ispezionano il protocollo HTTP stesso: leggendo percorsi URL, intestazioni di richiesta, cookie e metodi HTTP. Questo consente il routing basato sul percorso: inviare richieste slash-api al tuo cluster backend e richieste slash-static a un

3:25 object store. Fondamentalmente, i bilanciatori di carico eseguono controlli di salute attivi. Ogni pochi secondi, il bilanciatore pinga un endpoint di salute su ogni istanza. Se un'istanza restituisce tre errori consecutivi da cinquecento o non risponde, viene automaticamente rimossa dal pool con zero richieste perse.

- 03. Autoscaling ed Elasticità

3:45 Concetto numero tre: Autoscaling. Se la tua web app necessita di due server alle tre del mattino, ma venti server durante un lancio a mezzogiorno, cliccare manualmente i pulsanti nella console cloud è una strada garantita verso tempi di inattività e bancarotta. L'autoscaling porta elasticità dinamica ai pool di server orizzontali. Un Auto Scaling Group monitora metriche di performance come l'utilizzo medio della CPU, l'I/O di rete o la profondità del backlog della coda. Quando l'utilizzo medio della CPU supera una soglia definita — ad esempio,

4:19 il settanta percento per tre minuti consecutivi — l'autoscaler lancia automaticamente nuove macchine virtuali, le registra con il tuo bilanciatore di carico, e inizia a instradare il traffico. Altrettanto importante è lo scaling in: quando l'onda di traffico si ritira, l'autoscaler termina le istanze in eccesso in modo da smettere di pagare per la computazione inattiva. Per prevenire il flapping — dove i server vengono rapidamente creati e distrutti in un ciclo di thrashing infinito — gli architetti cloud configurano periodi di cooldown. Concetto numero quattro: Serverless.

- 04. Serverless (FaaS e MicroVM Firecracker)

4:53 Per anni, i team di marketing hanno presentato il serverless come codice magico che gira nel cielo. In realtà, il serverless usa ancora server — ma tu non li possiedi, non li patchi o li paghi quando nessun codice è in esecuzione. Con Function-as-a-Service come AWS Lambda o Google Cloud Functions, scrivi una funzione handler autonoma. Quando si verifica una richiesta HTTP, un caricamento di file S3 o una modifica del database, il runtime cloud avvia una micro-macchina virtuale

5:23 effimera come Firecracker in meno di cinque millisecondi. Il tuo codice esegue, restituisce una risposta e si spegne. Se nessuno visita il tuo sito web per tre mesi, la tua fattura di computazione è esattamente zero dollari e zero centesimi. Se un milione di utenti lo访问 contemporaneamente, il provider avvia un milione di microVM concorrenti. I compromessi ingegneristici sono reali: latenza di cold start quando si avviano nuovi runtime, un limite di esecuzione rigido di quindici minuti su Lambda e rigorosa statelessness.

5:55 Serverless è imbattibile per pipeline di eventi e API sporadiche, ma scarso per WebSockets persistenti o cicli di addestramento di più ore.

- 05. Architettura basata su Eventi (EDA e Disaccoppiamento)

6:05 Concetto numero cinque: Architettura basata su Eventi, o EDA. Nelle architetture tradizionali, i servizi comunicano in modo sincrono. Il tuo servizio di checkout chiama il pagamento, il pagamento chiama l'inventario, l'inventario chiama la frode e la frode chiama l'email. Questo crea la cascata sincrona di perdizione. Se il fornitore di email di terze parti subisce un intoppo di rete e impiega dieci secondi per rispondere, l'intera richiesta di checkout del tuo cliente va in timeout con un errore. In un'architettura basata su eventi, i servizi sono completamente disaccoppiati.

6:37 Quando un cliente clicca su "acquista", il servizio di checkout non chiama i servizi a valle. Si limita a pubblicare un evento chiamato OrderPlaced su un Event Bus centrale come Amazon EventBridge o un argomento SNS. Il checkout si completa in cinquanta millisecondi. I worker a valle per il pagamento, la deduzione dell'inventario e le ricevute email estraggono messaggi indipendentemente dalle proprie code SQS dedicate. Se il servizio email si blocca per un'ora, i messaggi attendono in modo sicuro memorizzati nella coda senza un singolo ordine perso.

- 06. Orchestrazione di Container (Docker e Kubernetes)

7:13 Concetto numero sei: Orchestrazione di Container. Docker ha risolto il packaging: racchiude il tuo codice applicativo, librerie di sistema, configurazione e runtime in un'immagine immutabile che funziona in modo identico sul tuo MacBook e nel cloud. Ma impacchettare un container è facile. Eseguire cinquecento container su cinquanta macchine virtuali fisiche è dove l'ingegneria fallisce. Ecco perché esistono orchestratori di container come Kubernetes e AWS ECS.

7:41 Un orchestratore fornisce un piano di controllo: un server API, un archivio di stato etcd e uno scheduler intelligente. Tu dichiari lo stato desiderato: voglio dieci repliche del mio servizio di autenticazione con due gigabyte di RAM ciascuno. Lo scheduler ispeziona il cluster, posiziona i pod sui nodi con memoria libera, configura la rete interna e riconcilia continuamente la realtà. Se un nodo subisce un guasto hardware, Kubernetes rileva la perdita e riprogramma istantaneamente tutti i pod spostati su

- 07. I 4 Pilastri dello Storage Cloud (S3, EBS, DB e Redis)

8:16 nodi sani. Concetto numero sette: La Gerarchia dello Storage Cloud. I principianti spesso trattano lo storage cloud come un unico bucket dove scaricare file. Nell'architettura di produzione, lo storage è diviso in quattro distinti pilastri basati su modelli di accesso e latenza. Il primo è l'Object Storage, come Amazon S3 o Google Cloud Storage. Accedi ai file tramite API REST HTTP usando semplici chiamate PUT e GET. Offre capacità orizzontale infinita a due centesimi per gigabyte al mese,

8:49 rendendolo ideale per video, caricamenti utente, log e backup. Il secondo è il Block Storage, come Amazon EBS. Questi sono dischi rigidi virtuali montati direttamente su una specifica macchina virtuale tramite interconnessioni ad alta velocità. Si formattano in filesystem standard come ext4, supportando l'accesso rapido in lettura e scrittura casuale richiesto dai motori di database. Il terzo sono i Database Gestiti: motori relazionali come PostgreSQL su RDS che fornisce transazioni ACID e join complessi,

9:21 e motori NoSQL come DynamoDB che offrono latenza a singola cifra di millisecondi su larga scala. E il quarto sono le Cache in Memoria come Redis. Leggere dati dalla RAM richiede microsecondi anziché millisecondi. Le cache si trovano davanti al tuo database, proteggendolo dal traffico di lettura ripetuto e gestendo i token di sessione utente volatili.

- 08. Alta Disponibilità e I Nove (Failover Multi-AZ)

9:44 Concetto numero otto: Alta Disponibilità, o HA. La disponibilità risponde a una domanda: quale percentuale del tempo la tua applicazione è operativa e raggiungibile dagli utenti? Nei contratti aziendali, la disponibilità è misurata in "nove". Due nove, o novantanove percento di disponibilità, consente oltre tre giorni e mezzo giorni e mezzo di inattività ogni anno. Quattro nove riducono i tempi di inattività consentiti a cinquantadue minuti, e cinque nove consentono a malapena cinque minuti di tempo di inattività totale all'anno.

10:15 Per ottenere alta disponibilità, è necessario eliminare i punti singoli di fallimento tra i domini di errore. Nel cloud, ciò significa distribuire su più Zone di Disponibilità. Una Zona di Disponibilità non è un singolo rack: è uno o più distinti data center fisici distanti chilometri con alimentazione e raffreddamento indipendenti. Eseguendo istanze attive nella Zona A e nella Zona B con replica di database sincrona, un fulmine o un taglio di fibra che mette fuori uso un'intera struttura fisica si traduce in un failover automatico

10:50 in trenta secondi senza alcun intervento umano.

- 09. Durabilità vs. Disponibilità (Perché 11 Nove non è Uptime)

10:53 Concetto numero nove: Durabilità contro Disponibilità. Questa è la trappola concettuale più comune nelle interviste di architettura cloud Gli ingegneri usano frequentemente le parole in modo intercambiabile, ma misurano proprietà completamente diverse. La disponibilità misura il tempo di attività: posso fare una chiamata API per leggere o scrivere i miei dati in questo preciso istante? dati in questo preciso istante? La durabilità misura la conservazione: i miei dati sopravviveranno senza degrado permanente, corruzione o distruzione per dieci anni?

11:24 Guarda Amazon S3 Standard. Il suo Service Level Agreement offre il novantanove virgola nove percento di disponibilità, che consente circa quarantatré minuti di inattività ogni mese dove una richiesta API potrebbe restituire un errore cinquecento. Ma S3 promette undici nove di durabilità: novantanove virgola nove nove nove nove nove nove nove nove nove percento. Se memorizzi dieci milioni di file in S3, puoi statisticamente aspettarti di perdere in media un file ogni diecimila anni.

11:56 media di un file ogni diecimila anni. S3 lo ottiene codificando gli oggetti con cancellazione e replicando i frammenti su almeno tre strutture dati geograficamente separate. almeno tre strutture dati geograficamente separate. Durante un'interruzione di rete regionale importante, S3 potrebbe essere temporaneamente non disponibile, ma i tuoi dati non vengono mai distrutti.

- 10. Infrastructure as Code (Terraform vs. Console Drift)

12:14 Concetto numero dieci: Infrastructure as Code, o IaC. Agli inizi del cloud computing, gli ingegneri accedevano alla console di gestione web di AWS e cliccavano manualmente per creare macchine virtuali, configurare sottoreti e allegare gruppi di sicurezza. L'industria lo chiama ClickOps, e in produzione è un disastro assoluto. Le modifiche manuali alla console non hanno traccia di audit, nessun meccanismo di rollback e inevitabilmente causano "configuration drift" tra gli ambienti di staging e produzione. Con gli strumenti di Infrastructure as Code come Terraform, produzione. Con gli strumenti di Infrastructure

12:48 as Code come Terraform, OpenTofu, Pulumi o AWS CDK, definisci la tua intera architettura cloud in file di configurazione dichiarativi archiviati in Git. Ogni modifica a una porta aperta o a una replica di database passa attraverso una pull request e una revisione tra pari. L'esecuzione di terraform plan visualizza l'esatto diff API prima che qualsiasi cosa venga toccata, e l'avvio di una replica identica del tuo stack di produzione richiede quattro minuti anziché quattro settimane.

- 11. Networking Cloud (VPC, Subnet, NAT e Gruppi di Sicurezza)

13:20 Concetto numero undici: Cloud Networking e Virtual Private Clouds. Quando distribuisci server nel cloud, non sono esposti direttamente a Internet pubblico. Vivono all'interno di un confine isolato definito da software chiamato VPC. All'interno del tuo VPC, allochi uno spazio di indirizzi IP privati come dieci-punto-zero-punto-zero-punto-zero barra sedici, e lo dividi in sottoreti pubbliche e private. Una sottorete pubblica ha una rotta diretta verso un Internet Gateway.

13:51 Contiene risorse esposte al pubblico come i tuoi Application Load Balancer e NAT Gateway. È l'unica parte della tua rete che possiede indirizzi IP pubblici. I tuoi server applicativi e database di produzione vivono strettamente in sottoreti private senza IP pubblici e zero rotte in ingresso da Internet. Quando i tuoi server backend devono scaricare aggiornamenti di sicurezza, il loro traffico in uscita passa attraverso il NAT Gateway nella sottorete pubblica. Intorno a ogni istanza ci sono i Security Groups: firewall virtuali stateful che applicano il principio del minimo privilegio.

- 12. Il Blueprint Aziendale Completo e il Verdetto

14:28 Il tuo gruppo di sicurezza del database accetta connessioni sulla porta 5432 strettamente dal gruppo di sicurezza dei tuoi server applicativi, rendendo matematicamente impossibile la penetrazione esterna. Quando si allarga la visuale, questi undici primitivi si connettono in un unico sistema coeso. Il tuo DNS si indirizza a un Load Balancer in una sottorete pubblica, i gruppi di autoscaling gestiscono i picchi di traffico attraverso più zone di disponibilità, i bus di eventi disaccoppiano i worker di backend, e l'intero stack è distribuito da Git usando Infrastructure as Code.

15:02 Verdetto della masterclass di oggi: SHIP IT. Smetti di memorizzare centinaia di acronimi di marketing cloud. Padrona questi undici pattern architetturali, disaccoppia il tuo stato, e costruisci sistemi che non possono fallire. Dimmi quale concetto cloud ti ha dato il mal di testa più grande quando hai iniziato a costruire nei commenti. costruire nei commenti. E per ottenere il cheat sheet completo dell'architettura, iscriviti alla newsletter su the daily diff dot dev,

15:28 link qui sotto. E questa è la differenza per oggi. Sono Niko di Axrisi. Unire responsabilmente.

Fonti

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io