Cloud computing - modelli di servizio e distribuzione
Dal CapEx dell'armadio rack al OpEx del pay-per-use: le 5 regole d'oro NIST, chi gestisce cosa in IaaS/PaaS/SaaS, il modello a responsabilità condivisa che decide chi va in prima pagina per un bucket pubblico, e come scegliere tra pubblico, privato, ibrido e multi-cloud senza farsi bloccare dal vendor lock-in.
Dal possesso all’utilizzo — la trasformazione del cloud
Per decenni, gestire l’IT aziendale ha significato possedere l’infrastruttura: acquistare server, installarli in un data center, configurarli, aggiornarli, sostituirli dopo tre-cinque anni. Ogni decisione aveva lead time di settimane o mesi — il tempo di fare un ordine, attendere la consegna, installare, configurare.
Il cloud computing ha invertito questo paradigma: le risorse informatiche diventano un servizio da consumare, come l’energia elettrica. Nessuno possiede una centrale elettrica privata per alimentare la propria casa — si paga il consumo. Con il cloud, nessuno deve più acquistare un server per eseguire un’applicazione — si paga per il tempo di utilizzo, la memoria consumata, i dati trasferiti.
Investimenti in beni fisici: server, storage, switch. Spesa immediata e rilevante, ammortizzata in anni. Le risorse sono disponibili subito ma dimensionate per il picco — spesso sovrastimate e quindi sprecate. Devi comprare per novembre a gennaio.
Costi operativi ricorrenti proporzionali all’uso. Nessun investimento iniziale — si paga solo ciò che si consuma, quando lo si consuma. Scalabilità immediata: se il traffico triplica, le risorse crescono di conseguenza. Se il sito dell'istituto va virale per open day, scala da 2 a 20 VM in 60 secondi.
L'istituto doveva comprare 3 server per registro + Moodle + backup: 18.000€ CapEx + licenze + corrente + armadio. Con OpEx: 3 VM su Azure IaaS a consumo reale, 240€/mese nei 9 mesi scolastici, spento a luglio/agosto. Risparmio primo anno 70%, zero obsolescenza, backup già incluso in altra Availability Zone.
Chiedi: chi ha un generatore diesel a casa? Nessuno. Paghiamo kWh. Cloud uguale: prima compravamo il generatore (server), ora paghiamo i kWh (vCPU/h, GB/mese). Fai confrontare preventivo rack 5 anni vs tabella AWS calculator. L'esercizio fa capire TCO: elettricità, raffreddamento, uomo, sostituzione dischi. Il CapEx nasconde costi invisibili che OpEx rende trasparenti nel measured service.
La definizione NIST — 5 caratteristiche essenziali
Il NIST (National Institute of Standards and Technology) ha pubblicato nel 2011 la definizione di riferimento del cloud computing (SP 800-145), riconosciuta universalmente come standard. Il cloud è definito da cinque caratteristiche essenziali senza le quali un servizio non può essere considerato “cloud” in senso stretto:
L’utente può attivare e configurare risorse autonomamente — macchine virtuali, storage, database — tramite una console web o API, senza intervento umano da parte del provider. Avviare 100 server su AWS richiede meno di un minuto, senza chiamare nessuno.
I servizi sono accessibili tramite rete standard (Internet) da qualsiasi dispositivo — smartphone, laptop, tablet, thin client — attraverso meccanismi standardizzati. Il cloud non richiede software proprietario installato localmente: un browser è sufficiente per la maggior parte dei servizi.
Le risorse fisiche del provider (CPU, RAM, storage, rete) sono raggruppate in pool condivisi e assegnate dinamicamente a più clienti contemporaneamente (multi-tenant). Il cliente non sa né controlla su quale hardware fisico girano le proprie istanze — l’isolamento è garantito a livello software. Un host ESXi da 512 GB RAM ospita VM di 20 clienti diversi.
Le risorse si espandono e contraggono automaticamente in base al carico — in modo rapido e, idealmente, automatico. Per l’utente le risorse sembrano illimitate: può richiederne quante ne ha bisogno, quando ne ha bisogno. Un sito di e-commerce può scalare automaticamente durante il Black Friday e ridursi di notte.
Il consumo di risorse è misurato e fatturato con precisione — ore di CPU, GB di storage, TB di traffico di rete. Il provider garantisce trasparenza sulle metriche di utilizzo, visibili in tempo reale nella console. Si paga solo ciò che si consuma, per il tempo in cui lo si consuma. È la base legale di OpEx.
Hosting condiviso Aruba 2010: manca self-service (ticket umano), manca rapid elasticity (VM fissa), manca measured preciso (paghi annuale). Quindi non è cloud NIST, è hosting tradizionale virtualizzato. Confronto didattico utile per esame: VPS ≠ cloud. Cloud deve avere tutte e 5, non 3 su 5.
Per far memorizzare: O-B-R-R-M → "On Broad, Risorse Rapide Misurate". Fai costruire tabella a 2 colonne: caratteristica | cosa vede lo studente. Es: self-service → student crea VM Moodle senza admin. Broad → accede da phone. Resource pooling → non sa in che rack è. Elasticity → iscrizioni open-day raddoppiano, ASG crea 3 VM. Measured → vede costo in real time in Cost Explorer.
I tre modelli di servizio — IaaS, PaaS, SaaS
La distinzione fondamentale tra i modelli di servizio cloud riguarda chi gestisce cosa. Man mano che si sale da IaaS a PaaS a SaaS, il provider si occupa di sempre più componenti dello stack, mentre l’utente si concentra su livelli sempre più alti di astrazione.
Stack di gestione — chi controlla cosa
| Componente dello stack | On-Premise | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Applicazione | 👤 Utente | 👤 Utente | 👤 Utente | ☁️ Provider |
| Dati | 👤 Utente | 👤 Utente | 👤 Utente | ☁️ Provider (logica) + 👤 dato |
| Runtime / Middleware | 👤 Utente | 👤 Utente | ☁️ Provider | ☁️ Provider |
| Sistema Operativo | 👤 Utente | 👤 Utente | ☁️ Provider | ☁️ Provider |
| Virtualizzazione | 👤 Utente | ☁️ Provider | ☁️ Provider | ☁️ Provider |
| Server / Storage / Rete | 👤 Utente | ☁️ Provider | ☁️ Provider | ☁️ Provider |
| Data center fisico | 👤 Utente | ☁️ Provider | ☁️ Provider | ☁️ Provider |
🏗️ IaaS — Infrastructure as a Service
Il provider fornisce l’infrastruttura virtuale — l’utente gestisce tutto sopra. VM, storage, rete. Analogia: appartamento vuoto da arredare. Es: AWS EC2, Azure VM, GCE, S3.
🧪 PaaS — Platform as a Service
Provider gestisce infra + runtime — utente solo app e dati. Lab già attrezzato. Es: Heroku (git push), App Service, App Engine, RDS.
✉️ SaaS — Software as a Service
Provider gestisce tutto — utente usa via browser. Hotel. Es: Microsoft 365, Workspace, Salesforce, Zoom/Teams.
Il provider mette a disposizione server virtuali (VM), storage e rete. L’utente sceglie il sistema operativo da installare, lo configura, installa il software applicativo e gestisce patch e aggiornamenti. È il modello che più assomiglia a possedere hardware fisico, ma senza doverlo acquistare.
Analogia: appartamento vuoto da arredare – Il proprietario (provider) mette a disposizione muri, pavimento e impianti. L’inquilino (utente) porta i mobili, li sistema e paga l’affitto in base allo spazio usato.
Esempi reali: AWS EC2: istanze VM con centinaia di configurazioni CPU/RAM – Azure Virtual Machines: VM Windows e Linux su Azure – Google Compute Engine: istanze VM su GCP – AWS S3: storage a oggetti scalabile
Patch del SO, aggiornamenti di sicurezza, configurazione firewall — tutto a carico dell’utente. Se lasci SSH aperto su 0.0.0.0/0, non è colpa di AWS. In IaaS sei sysadmin, anche in cloud.
Il provider fornisce un ambiente di esecuzione completo: OS, runtime del linguaggio (Java, Python, Node.js), database, middleware. Lo sviluppatore carica il proprio codice e il provider si occupa del resto: scaling automatico, disponibilità, aggiornamenti del runtime. Lo sviluppatore si concentra esclusivamente sul codice.
Analogia: laboratorio già attrezzato – Il provider fornisce banconi, strumenti e impianti. Il ricercatore (sviluppatore) porta le proprie idee e lavora senza preoccuparsi di installare o manutenere l’attrezzatura.
Esempi reali: Heroku: deploy di app web con git push — zero config server – Azure App Service: hosting di app web e API – Google App Engine: piattaforma per app scalabili – AWS RDS: database gestito (MySQL, PostgreSQL, Oracle)
Registro presenze sviluppato da 5B: team carica solo app.py su Azure App Service. Azure gestisce Python 3.11, patch OS, autoscale 2-10 istanze durante scrutinio. Nessun sysadmin. Se un nodo va giù, PaaS lo rimpiazza. Concentri valutazione su codice, non su apt-get upgrade.
Il livello di astrazione più alto. L’applicazione è già pronta, ospitata e mantenuta dal provider. L’utente accede via browser o app client e si preoccupa solo della configurazione funzionale: account utenti, dati, preferenze. Aggiornamenti, patch di sicurezza, backup, scaling — tutto è trasparente e automatico.
Analogia: servizio alberghiero – L’hotel fornisce stanza, letto, pulizie, colazione. L’ospite porta solo i propri effetti personali e usa il servizio senza preoccuparsi della gestione.
Esempi reali: Microsoft 365: Word, Excel, Outlook, Teams via cloud – Google Workspace: Gmail, Drive, Docs, Meet – Salesforce CRM: gestione clienti e vendite – Zoom / Teams: videoconferenza come servizio
Chiedi: quanto controllo vuoi? Se risposta = voglio root, kernel custom, driver → IaaS. Se voglio solo pushare codice e pensare a business logic → PaaS. Se voglio solo usare → SaaS. Esempio: Moodle. On-premise: installi tu. IaaS: VM tu gestisci LAMP. PaaS: App Service + ClearDB. SaaS: MoodleCloud, paghi account e usi. Stessa app, 4 modelli diversi. Mostra costi nascosti sicurezza.
Shared Responsibility Model — chi è responsabile di cosa
Uno degli aspetti più critici — e più fraintesi — del cloud è la responsabilità condivisa. Il provider si occupa di alcuni aspetti della sicurezza, il cliente di altri. Non capire dove finisce la responsabilità del provider e dove inizia quella del cliente è una delle cause più frequenti di violazioni di sicurezza nel cloud.
| Aspetto di sicurezza | IaaS | PaaS | SaaS |
|---|---|---|---|
| Sicurezza fisica DC | ☁️ Provider | ☁️ Provider | ☁️ Provider |
| Hypervisor e infrastruttura virtuale | ☁️ Provider | ☁️ Provider | ☁️ Provider |
| Patch e sicurezza del SO | 👤 Cliente | ☁️ Provider | ☁️ Provider |
| Sicurezza delle applicazioni | 👤 Cliente | 👤 Cliente (tuo codice) | ☁️ Provider |
| Gestione identità e accessi (IAM) | 👤 Cliente | 👤 Cliente | 👤 Cliente |
| Protezione e classificazione dei dati | 👤 Cliente | 👤 Cliente | 👤 Cliente |
Provider = sicurezza dell' infrastruttura (cimento, guardie, hypervisor). Cliente = sicurezza nella infrastruttura (IAM, dati, config, app). Anche in SaaS: se condividi password M365, responsabilità è tua.
La maggior parte delle violazioni di sicurezza nel cloud non sono causate da vulnerabilità dell’infrastruttura del provider — AWS, Azure e GCP sono tecnicamente molto sicuri. Sono causate da errori di configurazione del cliente: bucket S3 lasciati pubblici, credenziali hardcoded nel codice, politiche IAM troppo permissive, password deboli su account admin. Queste sono tutte responsabilità del cliente, indipendentemente dal modello di servizio usato.
Case history reali: Verizon 2017 – 14M record esposti per S3 public. Capital One 2019 – 100M clienti per IAM misconfig in WAF. Istituto che lascia registro S3 pubblico → sanzione GDPR, non di AWS.
Docente carica backup registro su S3 senza criptare, bucket public-read. Studente scarica. Chi è responsabile? Cliente (istituto) per IAM + protezione dati. AWS non legge contenuto bucket, non sa se è sensibile. Stesso in PaaS: se lasci Firebase Realtime Database con rule .read=true, dati studenti visibili. In SaaS: condividi link Teams "chiunque con link" a compito con dati personali → responsabilità tua su classificazione dati, non di Microsoft.
Dai tabella vuota, chiedi: patch kernel in IaaS? Cliente. In PaaS? Provider. IAM? Sempre cliente. Dati? Sempre cliente. Fai evidenziare riga IAM: anche se Azure AD è gestito da MS, chi metti in gruppo admin sei tu. Prova pratica: mostra portal.azure.com → Cost Management + Security Center → mostra Secure Score basso per NSG aperto. Chi deve chiuderlo? Loro, non Microsoft.
I quattro modelli di distribuzione
Non solo cosa ti offre il cloud, ma dove è e chi lo condivide. NIST ne definisce quattro.
☁️ Cloud Pubblico
Infrastruttura di proprietà del provider, condivisa tra più clienti. Accessibile via Internet. Massima scalabilità, pay-per-use, nessun investimento iniziale.
Esempi: AWS, Azure, Google Cloud
✅ Costi variabili, scalabilità illimitata
✅ Nessuna gestione hardware
❌ Dati su infrastruttura condivisa
❌ Dipendenza da Internet
🏢 Cloud Privato
Infrastruttura dedicata a una singola organizzazione, ospitata on-premise o in un colocation. Controllo totale su dati e configurazioni. Tecnologie come VMware, OpenStack o Nutanix.
Esempi: DC interno con VMware, OpenStack
✅ Controllo completo, conformità normativa
✅ Dati non escono dall’organizzazione
❌ Costi fissi elevati, scalabilità limitata
❌ Team IT specializzato necessario
🔗 Cloud Ibrido ✅ Più adottato nelle enterprise
Combina cloud privato e pubblico, interconnessi e gestiti come un’unica piattaforma. I dati sensibili rimangono on-premise, i carichi variabili scalano nel cloud pubblico (cloud bursting). È il modello dominante nelle grandi organizzazioni.
Es: dati sanitari on-premise, frontend web su AWS
✅ Flessibilità: dati critici on-prem, scalabilità nel cloud
✅ Conformità normativa + efficienza economica
⚠️ Complessità di gestione e integrazione
👥 Community Cloud
Infrastruttura condivisa tra organizzazioni con esigenze comuni — stessa normativa, stesso settore, stesso progetto. Costi divisi, requisiti comuni soddisfatti con un’unica piattaforma condivisa.
Es: cloud sanitario regionale, cloud universitario
✅ Costi condivisi tra organizzazioni
✅ Conformità settoriale condivisa
⚠️ Governance complessa tra più organizzazioni
Dati anagrafici studenti + voti: devono restare on-premise per policy ministeriale → private cloud Proxmox su server istituto, backup criptato. Frontend iscrizioni, sito vetrina, Moodle video: picchi a settembre → pubblico AWS con Auto Scaling + CloudFront. Collegamento con VPN IPSec + Azure AD Connect / AWS Direct Connect. Risultato: conformità + costi contenuti. Community: tutti gli istituti della provincia condividono GARR cloud per conservazione digitale.
Multi-Cloud — la realtà operativa delle grandi aziende
Il multi-cloud è la strategia di usare servizi di due o più provider cloud diversi — ad esempio AWS per il compute, Azure per Active Directory e Google Cloud per l’analisi dei dati. Non è previsto nella classificazione NIST originale ma è diventato la realtà operativa della maggior parte delle organizzazioni medio-grandi.
Motivazioni del multi-cloud
- Evitare il vendor lock-in: non dipendere da un unico provider. Se AWS alza prezzi o Azure ha outage in eu-west, puoi spostare.
- Best-of-breed: usare il servizio migliore per ogni workload. AD è nativo Azure, BigQuery è top per analytics, EC2 ha più instance types.
- Requisiti geografici: dati in regioni specifiche per conformità GDPR – alcuni provider hanno regioni IT, altri no.
- Ridondanza: se un provider ha un’outage, l’altro continua. Active-active su provider diversi.
Multi-cloud non è gratis in complessità:
- Competenze diverse richieste per ogni provider – API, IAM, rete diversa
- Visibility e monitoring unificati più complessi – CloudWatch vs Azure Monitor vs Stackdriver, servono tool terzi (Datadog, Grafana)
- Costi difficili da ottimizzare su più console separate – FinOps complicato, servono CMP
- Sicurezza e governance da mantenere coerenti – policy IAM da replicare, zero trust uguale ovunque
Segreteria usa Microsoft 365 (SaaS) → identità in Azure AD. Sito istituto + backend iscrizioni su AWS EC2 + RDS (IaaS/PaaS). Analisi datiINVALSI + laboratorio ML su Google Colab + BigQuery (PaaS). DNS su Cloudflare. È già multi-cloud senza volerlo. Problema: docente deve ricordarsi 3 console IAM. Soluzione didattica: federazione SAML verso Azure AD, SSO ovunque, log centralizzati su ELK. Così eviti vendor lock-in e usi best-of-breed mantenendo singola identità.
Vendor lock-in = compri lavatrice che usa solo detersivo proprietario a 40€ al kg. Best-of-breed = puoi scegliere detersivo migliore per ogni lavaggio. Ma se hai 3 lavatrici con 3 detersivi diversi, devi ricordarti manuale. Esercizio: fai cercare servizio proprietario AWS (DynamoDB) vs open (PostgreSQL su RDS). Dynamo = più perf, ma lock-in alto. Postgres = portabile su Azure, GCP, on-prem. Scelta = tradeoff.
Confronto finale — scegliere il modello giusto
Mettere insieme servizio e distribuzione è la domanda d'esame. Ecco la guida integrale più checklist.
| Domanda | Risposta modello | Perché |
|---|---|---|
| Scegli IaaS se… | IaaS | Hai bisogno di controllo completo su OS e middleware, migri applicazioni legacy, hai un team sysadmin esperto. Es: lift-and-shift data center scolastico. |
| Scegli PaaS se… | PaaS | Stai sviluppando una nuova applicazione, vuoi concentrarti sul codice, non hai un team infrastrutturale. Es: app registro presenze 5B. |
| Scegli SaaS se… | SaaS | Hai bisogno di un’applicazione standard (email, CRM, videoconferenza) senza personalizzazioni profonde. Es: M365 per docenti. |
| Scegli Cloud Pubblico se… | Pubblico | Hai carichi variabili, vuoi minimizzare CapEx, non hai requisiti di localizzazione dati stringenti. Es: sito istituto. |
| Scegli Cloud Privato se… | Privato | Hai dati sensibili o regolamentati (salute, finanza), carichi stabili e prevedibili, requisiti di latenza bassissima |
| Scegli Ibrido se… | Ibrido ⭐ | Hai sia dati sensibili (on-prem) sia carichi variabili (cloud pubblico), oppure stai migrando progressivamente. 87% enterprise. |
| Scegli Multi-cloud se… | Multi | Vuoi evitare lock-in, best-of-breed, ridondanza geografica – accetti complessità. |
Riepilogo integrale dal sorgente originale – Punti chiave
- Le 5 caratteristiche NIST: on-demand self-service, broad network access, resource pooling (multi-tenant), rapid elasticity (scala automatica), measured service (pay-per-use). Senza tutte e 5 non è “cloud” in senso stretto
- IaaS: VM + storage + rete — utente gestisce OS, app, dati. PaaS: runtime gestito — utente gestisce solo app e dati. SaaS: applicazione pronta all’uso — utente gestisce solo i propri dati e account
- Lo Shared Responsibility Model è critico: il provider gestisce la sicurezza dell’ infrastruttura, il cliente gestisce la sicurezza nella infrastruttura. IAM, protezione dati e configurazioni corrette sono sempre responsabilità del cliente
- Pubblico: condiviso, pay-per-use; Privato: dedicato, controllo totale; Ibrido: il modello enterprise dominante; Community: condiviso tra organizzazioni con requisiti comuni
- Multi-cloud: più provider per evitare vendor lock-in e usare il best-of-breed per ogni workload — più resiliente ma più complesso da gestire
Registro elettronico: privato (dati sensibili) + backup criptato in pubblico (ibrido) – IaaS Proxmox on-prem + S3 Glacier. Mail docenti: SaaS pubblico M365 (costo zero per education). App orientamento: PaaS pubblico (Heroku/Render) – sviluppata da studenti, deploy rapido. Laboratorio AI: PaaS multi-cloud – BigQuery + SageMaker a consumo. Valuta sempre: sensibilità dato, variabilità carico, competenze interne, rischio lock-in.
Verifica / Esercizio guidato — progetta il cloud d'istituto
🔬 Scenario: migrazione istituto 800 studenti, 100 docenti
Sei consulente. Devi rispettare GDPR, minimizzare CapEx, garantire uptime sito iscrizioni a settembre (picco x10). Hai a disposizione: DC con VMware on-prem, account AWS education, Azure AD con M365, crediti GCP.
- NIST: l'attuale Moodle su singolo server fisico senza API né scaling è cloud? Verifica le 5 caratteristiche una per una.
- Servizio: per il nuovo sistema presenze sviluppato da 5A in Node.js, scegli IaaS/PaaS/SaaS e motiva stack chi gestisce cosa + responsabilità patch OS.
- Shared Responsibility: se lo studente espone bucket S3 con verifiche, chi è responsabile? Cosa avrebbe dovuto fare istituto su IAM e classificazione dati?
- Distribuzione: dove metti anagrafiche+valutazioni (dati particolari minori)? Dove metti sito pubblico? Ibrido come? Disegna flusso VPN/bursting. Quando usaresti community GARR?
- Multi-cloud & lock-in: proponi architettura multi-cloud best-of-breed che evita lock-in, con layer Kubernetes. Quali rischi gestione?
1) NIST test: No, non è cloud. Manca self-service (solo admin fisico), broad sì (http), resource pooling no (dedicato), rapid elasticity no (singolo server, scala manuale), measured no (costo fisso server). Al massimo hosting virtualizzato. Per essere cloud deve implementare API self-service + ASG + billing a consumo.
2) Servizio Node.js: PaaS ideale: Azure App Service / Heroku. Stack: Dev (studenti) gestisce App+Dati, Provider gestisce runtime Node, OS, VM, rete. Patch OS e runtime = responsabilità provider, così studenti si concentrano su codice. Se fosse IaaS EC2, patch OS = cliente → overhead esame non valutabile. SaaS non applicabile, app custom.
3) Shared: Responsabile = cliente (istituto). Errore: S3 public, no MFA, policy IAM permissiva. Doveva: bucket private + least privilege IAM role per app + encryption SSE-S3/KMS + bucket policy con Condition MFA + classificazione dati “riservato” + Security Awareness. Provider (AWS) responsabile solo sicurezza fisica DC e hypervisor – non legge contenuto.
4) Distribuzione: Anagrafiche+valutazioni = privato on-prem Proxmox criptato LUKS, replica offsite criptata in S3 Glacier con chiave gestita da istituto (BYOK) → ibrido con dato master on-prem. Sito pubblico iscrizioni = pubblico AWS con ASG 2-20 + ALB + WAF, static su S3+CloudFront, database RDS PaaS. Burst: cloud bursting sett 1-30 sett da on-prem a pubblico via VPN IPSec. Community: backup conservazione a norma + identità SPID su GARR cloud, costi condivisi MIUR.
5) Multi-cloud: IdP = Azure AD (SaaS). Email/Teams = M365 (SaaS pubblico). Frontend istituto → container su K8s (EKS/AKS intercambiabili) image istituto/web. Storage S3-compatibile astratto (MinIO gateway) → portabile su AWS/GCP/Wasabi. Analytics voti anonimizzati → BigQuery (best-of-breed). Rischi: 3 console IAM da allineare, logging unificato (Datadog), FinOps, competenze triple. Mitigo con Terraform + OIDC fedeazione + policy as-code OPA.
Riepilogo e concetti chiave
📚 Prossimo passo — SDN NFV e reti overlay la rete programmabile
Hai capito dove girano le VM; ora capisci come si programma la rete sotto il cloud: separazione control/data plane SDN con OpenFlow, VNF e MANO per NFV, overlay VXLAN/NVGRE e SD-WAN per connettere siti e cloud in modo elastico.