Cloud Computing

Guida di riferimento per Sistemi e Reti — classe quinta. Dal modello IaaS/PaaS/SaaS alla virtualizzazione con Docker e Kubernetes, dall’SDN ai database cloud, fino a SLA, costi e GDPR.

1. Introduzione al Cloud Computing

Il Cloud Computing è un modello di erogazione di servizi informatici attraverso la rete Internet. Invece di acquistare e gestire server fisici in proprio (on-premise), un’azienda o un privato può affittare risorse computazionali — processori, memoria, storage, reti — da un fornitore specializzato, pagando solo per ciò che effettivamente utilizza.

Il National Institute of Standards and Technology (NIST) identifica cinque caratteristiche essenziali del cloud:

• On-demand self-service: le risorse si attivano autonomamente, senza intervento umano del fornitore.
• Broad network access: accessibilità da qualsiasi dispositivo connesso alla rete.
• Resource pooling: le risorse fisiche sono condivise tra più utenti (multi-tenancy).
• Rapid elasticity: le risorse si scalano automaticamente in base alla domanda.
• Measured service: consumo monitorato e tariffato con precisione (pay-as-you-go).

Concetto chiave: Il cloud non è «il computer di qualcun altro»: è un’infrastruttura distribuita, ridondante e scalabile che offre livelli di affidabilità e sicurezza spesso superiori a quelli raggiungibili in autonomia da una PMI.

2. Modelli di Servizio: IaaS, PaaS, SaaS

Il modo più semplice per distinguere i tre modelli è chiedersi: «Cosa gestisce il fornitore e cosa gestisce il cliente?».

2.1 IaaS — Infrastructure as a Service

Il fornitore mette a disposizione l’infrastruttura grezza: macchine virtuali, storage, reti virtuali e firewall. Il cliente è responsabile di tutto ciò che va sopra: sistema operativo, middleware, runtime e applicazioni.

Esempi commerciali

• Amazon EC2 (AWS): istanze virtuali in pochi secondi, disponibili in decine di regioni globali.
• Microsoft Azure Virtual Machines: integrazione nativa con Active Directory e ambienti Windows Server.
• Google Compute Engine (GCP): ottimizzato per carichi di lavoro big data e machine learning.
• Hetzner Cloud: provider europeo (tedesco) apprezzato per il rapporto qualità/prezzo e la conformità GDPR.

Quando si usa IaaS: Quando si ha già un team IT strutturato e si vuole la massima flessibilità: migrare un data center fisico, ospitare ambienti di test e sviluppo, gestire picchi di traffico stagionali.

2.2 PaaS — Platform as a Service

Il fornitore aggiunge uno strato di piattaforma: runtime di linguaggi (Node.js, Python, Java…), database gestiti, code di messaggi, CI/CD pipeline. Il cliente si concentra solo sul codice dell’applicazione e sui dati.

Esempi commerciali

• Google App Engine / Firebase: deploy di app web e mobile con scalabilità automatica e database realtime.
• Heroku (Salesforce): piattaforma molto usata da startup per la semplicità del workflow git push → deploy.
• Azure App Service: supporto nativo per .NET, PHP, Node.js, Python con integrazione DevOps.
• AWS Elastic Beanstalk: orchestrazione automatica di EC2, load balancer e auto-scaling per applicazioni web.
• Red Hat OpenShift: PaaS enterprise basata su Kubernetes, disponibile on-premise e in cloud ibrido.

Quando si usa PaaS: Per team di sviluppo che vogliono concentrarsi sul prodotto senza occuparsi di aggiornamenti del sistema operativo, patch di sicurezza o configurazione del web server.

2.3 SaaS — Software as a Service

Il fornitore gestisce l’intera pila tecnologica: infrastruttura, piattaforma e applicazione. L’utente accede al servizio direttamente tramite browser o app mobile, senza installare nulla. È il modello cloud più diffuso nella vita quotidiana.

Esempi commerciali

• Microsoft 365 (ex Office 365): Word, Excel, Outlook, Teams in abbonamento mensile/annuale per utente.
• Google Workspace: Gmail, Drive, Docs, Meet — concorrente diretto di Microsoft 365.
• Salesforce CRM: gestione di clienti e pipeline di vendita, pioniere del modello SaaS enterprise.
• Dropbox / Google Drive: storage e sincronizzazione file multipiattaforma.
• Zoom / Microsoft Teams: videoconferenza e collaborazione, esplosi durante la pandemia del 2020.
• Notion / Confluence: knowledge base e documentazione collaborativa.

Quando si usa SaaS: Quasi sempre, per applicazioni orizzontali (email, office, CRM, HR) dove la personalizzazione profonda non è necessaria e la velocità di adozione è prioritaria.

2.4 Tabella di confronto IaaS vs PaaS vs SaaS

3. Virtualizzazione nel Cloud

La virtualizzazione è il fondamento tecnologico del cloud computing. Essa consente di eseguire più sistemi operativi o ambienti isolati (macchine virtuali o container) sullo stesso hardware fisico, massimizzando l’utilizzo delle risorse e abilitando la multi-tenancy.

3.1 Hypervisor e macchine virtuali (VM)

Un hypervisor (o Virtual Machine Monitor, VMM) è il software che astrae l’hardware fisico e crea macchine virtuali indipendenti. Si distinguono due tipologie:

• Tipo 1 (bare-metal): gira direttamente sull’hardware (es. VMware ESXi, Microsoft Hyper-V, KVM). Offre prestazioni superiori, è il modello adottato nei data center cloud.
• Tipo 2 (hosted): gira sopra un sistema operativo ospite (es. VirtualBox, VMware Workstation). Usato per sviluppo e test locali.

Ogni VM include un sistema operativo completo (kernel incluso), il che la rende isolata ma anche pesante in termini di memoria e tempo di avvio (decine di secondi).

3.2 Container e Docker

I container condividono il kernel del sistema operativo ospite e isolano solo l’applicazione e le sue dipendenze tramite namespace Linux e cgroup. Questo li rende molto più leggeri delle VM:

Docker è lo strumento più diffuso per creare e gestire container. Kubernetes (K8s) è il sistema open source di orchestrazione che automatizza deployment, scaling e gestione di container in produzione.

Nota: I provider cloud offrono servizi Kubernetes gestiti: Amazon EKS, Google GKE, Azure AKS. Il team non deve occuparsi del control plane di Kubernetes, solo dei workload applicativi.

3.3 Serverless (Function as a Service)

Il modello serverless porta l’astrazione al livello massimo: il developer scrive solo funzioni stateless, senza pensare a server, container o scalabilità. L’infrastruttura si attiva solo quando la funzione viene chiamata.

• AWS Lambda: esegue codice in risposta a eventi (HTTP, S3, DynamoDB…).
• Azure Functions: integrazione nativa con l’ecosistema Microsoft.
• Google Cloud Functions / Cloud Run: ideali per microservizi e pipeline di elaborazione dati.

Il costo è calcolato al millisecondo di esecuzione e al numero di invocazioni. Per carichi irregolari o molto bassi, il serverless può essere estremamente economico.

4. Software Defined Networking (SDN)

Le reti tradizionali sono composte da dispositivi (router, switch) che integrano sia il piano di controllo (decisione del percorso) sia il piano dati (inoltro dei pacchetti). SDN separa questi due piani, centralizzando la logica di controllo in un software chiamato controller SDN.

4.1 Architettura SDN

• Piano di dati (Data Plane): gli switch hardware o virtuali inoltrano i pacchetti seguendo le regole ricevute.
• Piano di controllo (Control Plane): il controller SDN (es. OpenDaylight, ONOS) calcola i percorsi e programma il piano dati tramite protocolli come OpenFlow.
• Piano di gestione (Management Plane): interfacce REST/API che permettono agli amministratori di configurare la rete via software o script.

4.2 SDN nel contesto cloud

Nel cloud, SDN è imprescindibile per:

• Creare reti virtuali isolate (VPC — Virtual Private Cloud) per ogni cliente, in multi-tenancy.
• Configurare firewall, routing, VPN e load balancer via API, senza toccare hardware fisico.
• Automatizzare il provisioning di reti in pochi secondi (Infrastructure as Code).
• Implementare microsegmentazione: ogni microservizio ha il proprio perimetro di sicurezza.

4.3 Esempi di SDN nel cloud

NFV (Network Function Virtualization) è il complemento di SDN: virtualizza le funzioni di rete (firewall, IDS, load balancer) rendendole istanze software eseguibili su hardware commodity.

5. Database nel Cloud

I database cloud si dividono in due grandi famiglie: relazionali (SQL) e non relazionali (NoSQL). I provider offrono entrambi come servizi gestiti (DBaaS — Database as a Service), eliminando le operazioni di installazione, backup, patching e replica.

5.1 Database relazionali gestiti

• Amazon RDS: supporta MySQL, PostgreSQL, MariaDB, Oracle, SQL Server. Backup automatici, Multi-AZ per alta disponibilità.
• Amazon Aurora: database cloud-native compatibile MySQL/PostgreSQL, fino a 5× più veloce, storage auto-scalante.
• Azure SQL Database: SQL Server gestito, con AI integrata per ottimizzazione delle query.
• Google Cloud SQL / AlloyDB: PostgreSQL e MySQL gestiti; AlloyDB è la versione cloud-native ad alte prestazioni.

5.2 Database NoSQL gestiti

• Amazon DynamoDB: key-value e document store, latenza inferiore al millisecondo, serverless e auto-scaling.
• Google Firestore / Bigtable: Firestore per applicazioni mobile/web real-time; Bigtable per time-series e analytics a grande scala.
• Azure Cosmos DB: database multi-modello (document, graph, key-value, colonnare) con SLA di disponibilità 99,999%.
• MongoDB Atlas: database documentale NoSQL leader di mercato, disponibile su AWS, Azure e GCP.

5.3 Data Warehouse e Big Data

• Amazon Redshift: data warehouse colonnare per analisi su petabyte di dati.
• Google BigQuery: serverless data warehouse; prezzi basati sui dati scansionati (5 $/TB per query).
• Azure Synapse Analytics: piattaforma integrata per data warehouse, data lake e Apache Spark.

Nota: I database cloud offrono funzionalità impossibili on-premise a costi accessibili: replica multi-regione con failover automatico, point-in-time recovery, crittografia at-rest e in-transit inclusa nel prezzo base.

6. Cloud Ibrido e Strategia Multi-vendor

6.1 Cloud Ibrido

Il cloud ibrido (hybrid cloud) combina infrastruttura on-premise (o private cloud) con uno o più cloud pubblici, interconnessi in modo da formare un ambiente unificato. È il modello preferito dalle grandi organizzazioni e dalle PA.

Motivazioni principali

• Compliance e sovranità del dato: i dati sensibili (sanitari, finanziari, della PA) rimangono on-premise o in cloud privato, mentre i workload meno critici vanno nel cloud pubblico.
• Investimenti legacy: le organizzazioni hanno già hardware, licenze e competenze on-premise che non conviene abbandonare immediatamente.
• Latenza: alcune applicazioni industriali (SCADA, sistemi real-time) richiedono latenze inferiori a quelle garantibili da un cloud pubblico remoto.
• Cloud bursting: in caso di picchi di carico, l’applicazione «trabocca» nel cloud pubblico mantenendo la base on-premise.

Tecnologie e soluzioni ibride

• AWS Outposts: rack fisici AWS installati nel data center del cliente, gestiti via console AWS.
• Azure Arc: estende i servizi Azure (Kubernetes, database, policy) a qualsiasi infrastruttura, on-premise o altri cloud.
• Google Anthos: piattaforma Kubernetes ibrida che unifica la gestione di cluster su GCP, on-premise e altri cloud.
• VMware Cloud Foundation: stack di virtualizzazione (compute, storage, rete) uniforme dal datacenter privato a AWS/Azure/GCP.

6.2 Multi-cloud e il rischio di Lock-in

Il vendor lock-in è la condizione in cui un’organizzazione diventa eccessivamente dipendente da un singolo fornitore, rendendo costoso o tecnicamente difficile cambiarlo. Nel cloud il lock-in si manifesta attraverso:

• API proprietarie: servizi esclusivi del fornitore (es. AWS Lambda, DynamoDB) non replicabili su altri cloud senza riscrivere il codice.
• Formati dati proprietari: storage o database con formati non standard che complicano la migrazione.
• Costi di egress: i provider addebitano il traffico uscente (bandwidth out) ma non quello entrante, rendendo la migrazione dei dati costosa.

Strategie per evitare il lock-in

• Architettura cloud-agnostic: usare Kubernetes per i container, Terraform per l’Infrastructure as Code, PostgreSQL invece di Aurora.
• Standard aperti: preferire protocolli e formati interoperabili (S3-compatible object storage, OpenTelemetry per il monitoring).
• Multi-cloud attivo: distribuire deliberatamente workload su più provider (es. ML su GCP, produzione su AWS, disaster recovery su Azure).

Regola pratica: Per ogni servizio cloud-specifico scelto, chiedersi: «Esiste un equivalente open source o standard che potrei usare senza cambiare provider?». Se la risposta è no, valutare attentamente il trade-off tra convenienza e dipendenza.

7. Service Level Agreement (SLA)

Uno SLA (Accordo sul Livello di Servizio) è il contratto che definisce le garanzie di qualità offerte dal provider: disponibilità, prestazioni, tempi di ripristino e penali in caso di inadempimento.

7.1 Metriche principali

• Uptime / Disponibilità: percentuale di tempo in cui il servizio è operativo. Tipicamente espressa come «numero di nove».
• RTO (Recovery Time Objective): tempo massimo entro cui il servizio deve essere ripristinato dopo un’interruzione.
• RPO (Recovery Point Objective): massima perdita di dati tollerabile, espressa come intervallo di tempo (es. max 1 ora di dati persi).
• MTTR (Mean Time To Repair): tempo medio di ripristino dopo un guasto.
• Latenza e throughput: garanzie sulle prestazioni di rete e del servizio.

7.2 I livelli di disponibilità

7.3 SLA dei principali provider

Attenzione: Lo SLA riguarda solo la disponibilità dell’infrastruttura, non la correttezza dell’applicazione. Bug nel codice del cliente non sono coperti. Leggere sempre le esclusioni: manutenzione programmata, force majeure, errata configurazione del cliente.

8. Modelli di Pricing e Stima dei Costi

Il cloud adotta un modello OPEX (Operational Expenditure) in sostituzione del tradizionale CAPEX (Capital Expenditure): nessun acquisto di hardware, ma un canone variabile basato sul consumo effettivo.

8.1 Modelli di fatturazione

• On-demand / Pay-as-you-go: si paga al secondo o all’ora, senza impegno. Flessibilità massima, costo unitario più alto.
• Reserved Instances (RI): impegno di 1 o 3 anni con sconto del 30–72% rispetto all’on-demand. Adatto per carichi stabili e prevedibili.
• Spot / Preemptible Instances: VM in surplus del provider, interrompibili con preavviso di 2 minuti, sconto 60–90%. Ideali per batch job, ML training.
• Savings Plans (AWS): flessibilità maggiore delle RI: impegno su una spesa oraria, non su un tipo specifico di istanza.
• Abbonamento mensile/annuale (SaaS): prezzo fisso per utente/mese. Semplice da budgettare.

8.2 Esempi di costo indicativi (2024–2025)

A) Startup web — piccola applicazione (IaaS/PaaS)

B) PMI — Applicazione enterprise (20 dipendenti)

C) Big Data — Training di un modello ML (spot instances)

Strumenti di stima gratuiti: AWS Pricing Calculator, Azure Pricing Calculator, Google Cloud Pricing Calculator. Sempre verificare i prezzi ufficiali: cambiano frequentemente.

8.3 Costi nascosti da considerare

• Egress bandwidth: il traffico dati uscente dal cloud costa (tipicamente 0,08–0,09 $/GB dopo i primi 100 GB gratuiti). Tra regioni dello stesso provider costa meno, verso internet costa di più.
• Licenze software: portare le proprie licenze (BYOL) può ridurre i costi, ma non sempre è consentito o conveniente.
• Supporto: il piano di supporto base è gratuito; il livello «Business» (AWS) costa almeno 100 $/mese o 3% della spesa.
• Idle resources: VM ferme il weekend costano quanto quelle attive. Automatizzare lo spegnimento con scheduler.

9. GDPR e Cloud Computing

Il GDPR (General Data Protection Regulation, UE 2016/679) è entrato in vigore il 25 maggio 2018 e si applica a qualsiasi organizzazione che tratti dati personali di cittadini dell’Unione Europea, indipendentemente da dove ha sede il provider cloud.

9.1 Concetti fondamentali

• Dato personale: qualsiasi informazione che identifichi o renda identificabile una persona fisica (nome, email, IP, dati biometrici, posizione GPS…).
• Titolare del trattamento (Controller): chi determina le finalità e i mezzi del trattamento (l’azienda cliente che usa il cloud).
• Responsabile del trattamento (Processor): chi tratta i dati per conto del titolare (il provider cloud: AWS, Azure, GCP…).
• Data Protection Officer (DPO): figura obbligatoria per PA, ospedali e chi tratta dati su larga scala. Supervisiona la conformità GDPR.

9.2 Principi chiave del GDPR

• Liceità, correttezza e trasparenza: i dati sono trattati con una base giuridica valida (consenso, contratto, obbligo legale…).
• Limitazione della finalità: i dati si raccolgono per scopi specifici e non si riutilizzano per finalità incompatibili.
• Minimizzazione dei dati: si raccoglie solo ciò che è strettamente necessario (data minimization).
• Esattezza: i dati devono essere aggiornati e corretti.
• Limitazione della conservazione: i dati si eliminano quando non più necessari (retention policy).
• Integrità e riservatezza: misure tecniche e organizzative adeguate per proteggere i dati (cifratura, controllo accessi, audit log).
• Responsabilizzazione (Accountability): il titolare deve essere in grado di dimostrare la conformità.

9.3 Impatto del GDPR sul cloud

Utilizzare un provider cloud non esonera il cliente dalle responsabilità GDPR.

Trasferimento dati fuori dall’UE

Se il provider (o i suoi sub-processor) archivia o processa dati in Paesi extra-UE privi di «adeguata protezione», il trasferimento è illegale senza misure aggiuntive. Le soluzioni valide includono:

• Clausole Contrattuali Standard (SCC): contratti tipo approvati dalla Commissione UE, adottati da tutti i major provider.
• Regioni UE: AWS (Francoforte, Irlanda, Milano, Parigi, Stoccolma), Azure (molte regioni EU), GCP (Francoforte, Parigi, Torino, Varsavia) permettono di vincolare i dati all’Europa.
• EU Sovereign Cloud: offerte specifiche come Azure for Sovereign Clouds, AWS European Sovereign Cloud, T-Systems Open Telekom Cloud garantiscono che i dati non lascino mai il territorio UE.

Data Processing Agreement (DPA)

Il GDPR obbliga a stipulare un contratto scritto (DPA / Accordo di Trattamento Dati) tra titolare e responsabile. AWS, Azure e GCP offrono DPA standard scaricabili.

Diritti degli interessati

• Diritto di accesso (Art. 15): l’utente può richiedere copia dei propri dati.
• Diritto alla portabilità (Art. 20): i dati devono essere forniti in formato strutturato e leggibile da macchina (JSON, CSV…).
• Diritto alla cancellazione — «diritto all’oblio» (Art. 17): il provider deve garantire la cancellazione definitiva dai propri storage e dai backup.

Notifica delle violazioni

In caso di data breach, il titolare deve notificarlo al Garante Privacy entro 72 ore dalla scoperta (Art. 33) e, se il breach è grave, informare anche gli interessati (Art. 34). I provider cloud offrono sistemi di alert automatici per eventi di sicurezza (AWS GuardDuty, Azure Defender, GCP Security Command Center).

9.4 Sanzioni

Esempi reali: Amazon Luxembourg S.A.R.L. — 746 milioni € (2021, CNPD Lussemburgo); Meta Platforms — 1,2 miliardi € (2023, DPC Irlanda) per trasferimento dati UE→USA. Il GDPR si applica ovunque se i dati sono di cittadini UE.

9.5 Checklist GDPR per l’adozione del cloud

• Scegliere un provider con regioni EU e DPA conforme.
• Vincolare il trattamento dei dati sensibili a regioni EU (region lock).
• Abilitare la cifratura at-rest e in-transit (sempre inclusa nei servizi gestiti moderni).
• Configurare audit log (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs).
• Definire una retention policy e automatizzare la cancellazione dei dati scaduti.
• Documentare il registro dei trattamenti (obbligatorio per org. >250 dipendenti e per dati sensibili).
• Verificare la catena dei sub-processor (il provider cloud usa a sua volta altri fornitori?).

10. Sintesi e Conclusioni

Il futuro del cloud è ibrido, edge e AI-driven: la computazione si avvicina sempre di più alla fonte dei dati (edge computing), l’intelligenza artificiale è integrata nei servizi cloud come commodity, e la complessità crescente richiede strumenti di FinOps per ottimizzare la spesa. Chi sa leggere un’architettura cloud, stimare un budget e valutare i rischi di lock-in e compliance, ha già un vantaggio competitivo significativo nel mercato del lavoro.

Per approfondire: AWS Skill Builder (skillbuilder.aws), Microsoft Learn (learn.microsoft.com), Google Cloud Skills Boost (cloudskillsboost.google) — tutti con corsi gratuiti e certificazioni riconosciute dall’industria.