Cloud Computing — modelli di servizio e distribuzione

di
📋 Obiettivi di apprendimento
✓Enunciare le 5 caratteristiche essenziali del cloud secondo la definizione NIST e spiegare cosa significa ciascuna in pratica
✓Distinguere IaaS, PaaS e SaaS spiegando cosa gestisce il provider e cosa gestisce l’utente in ciascun modello
✓Descrivere lo Shared Responsibility Model e applicarlo a IaaS, PaaS e SaaS identificando le responsabilità di sicurezza di provider e cliente
✓Confrontare i quattro modelli di distribuzione cloud (pubblico, privato, ibrido, community) e il concetto di multi-cloud
📄
Slides
Data Center — architettura, topologie e Tier

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.

📌 CapEx vs OpEx — la differenza economica fondamentale
CapEx — Capital Expenditure (DC tradizionale)

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.

OpEx — Operational Expenditure (cloud)

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.

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:

🖱️
On-demand self-service
Caratteristica 1
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.
🌐
Broad network access
Caratteristica 2
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.
🏊
Resource pooling
Caratteristica 3
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.
📈
Rapid elasticity
Caratteristica 4
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.
📊
Measured service
Caratteristica 5
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.

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 stackOn-PremiseIaaSPaaSSaaS
Applicazione👤 Utente👤 Utente👤 Utente☁️ Provider
Dati👤 Utente👤 Utente👤 Utente☁️ Provider
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

🏗️
IaaS — Infrastructure as a Service
Il provider fornisce l’infrastruttura virtuale — l’utente gestisce tutto sopra

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
⚠️ Massima flessibilità ma massima responsabilità: patch del SO, aggiornamenti di sicurezza, configurazione firewall — tutto a carico dell’utente

PaaS — Platform as a Service

🧪
PaaS — Platform as a Service
Il provider gestisce l’infrastruttura e il runtime — l’utente si occupa solo dell’applicazione e dei dati

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)
✅ Focus sul codice: il provider gestisce SO, patch, scaling. Lo sviluppatore non si preoccupa dell’infrastruttura

SaaS — Software as a Service

✉️
SaaS — Software as a Service
Il provider gestisce tutto — l’utente usa l’applicazione tramite browser o client

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

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.

Shared Responsibility Model — responsabilità per modello
Aspetto di sicurezzaIaaSPaaSSaaS
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☁️ Provider
Gestione identità e accessi (IAM)👤 Cliente👤 Cliente👤 Cliente
Protezione e classificazione dei dati👤 Cliente👤 Cliente👤 Cliente
⚠️ L’errore più comune: “il cloud è sicuro — ci pensa il provider”

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.

I quattro modelli di distribuzione

☁️ 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

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
  • Best-of-breed: usare il servizio migliore per ogni workload
  • Requisiti geografici: dati in regioni specifiche per conformità
  • Ridondanza: se un provider ha un’outage, l’altro continua
⚠️ Complessità del multi-cloud
  • Competenze diverse richieste per ogni provider
  • Visibility e monitoring unificati più complessi
  • Costi difficili da ottimizzare su più console separate
  • Sicurezza e governance da mantenere coerenti

Confronto finale — scegliere il modello giusto

Guida alla scelta del modello cloud
Scegli IaaS se…

Hai bisogno di controllo completo su OS e middleware, migri applicazioni legacy, hai un team sysadmin esperto

Scegli PaaS se…

Stai sviluppando una nuova applicazione, vuoi concentrarti sul codice, non hai un team infrastrutturale

Scegli SaaS se…

Hai bisogno di un’applicazione standard (email, CRM, videoconferenza) senza personalizzazioni profonde

Scegli Cloud Pubblico se…

Hai carichi variabili, vuoi minimizzare CapEx, non hai requisiti di localizzazione dati stringenti

Scegli Cloud Privato se…

Hai dati sensibili o regolamentati (salute, finanza), carichi stabili e prevedibili, requisiti di latenza bassissima

Scegli Ibrido se…

Hai sia dati sensibili (on-prem) sia carichi variabili (cloud pubblico), oppure stai migrando progressivamente

📌 Riepilogo — 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

Lascia un commento