Il cloud computing è un modello che permette di utilizzare risorse informatiche come server, capacità di calcolo, storage, database, reti e applicazioni attraverso una rete e su richiesta, senza dover possedere e amministrare direttamente tutta l’infrastruttura fisica necessaria.
La parte importante della definizione non è quindi la parola “cloud”, ormai utilizzata per descrivere servizi molto diversi. È il modo in cui le risorse vengono fornite: disponibili quando servono, condivisibili, configurabili, scalabili e gestibili con un livello di automazione che sarebbe difficile ottenere acquistando e configurando ogni volta nuovo hardware.
La definizione di cloud computing del NIST rimane un riferimento particolarmente utile perché descrive il modello attraverso cinque caratteristiche essenziali, tre modelli di servizio e quattro modelli di deployment.
Questo significa anche che cloud computing, cloud storage e cloud hosting non sono sinonimi. Il primo è il modello generale; gli altri sono servizi o applicazioni specifiche che possono essere costruiti sopra quel modello.
Cloud computing: cos’è davvero
Dire che il cloud computing consiste semplicemente nel “salvare dati su Internet” è troppo riduttivo.
Quando utilizzi un’infrastruttura cloud, stai accedendo a risorse informatiche che possono essere allocate, modificate e rilasciate senza dover installare fisicamente un nuovo server ogni volta che cambia il carico di lavoro.
Per capire meglio la differenza, pensa a un’azienda che deve avviare una nuova applicazione. Con un’infrastruttura tradizionale potrebbe dover acquistare hardware, installarlo, configurare rete e storage, preparare il sistema operativo e dimensionare tutto in anticipo. Nel cloud una parte rilevante di questo lavoro può essere trasformata in risorse ottenibili tramite console, API o automazioni.
Il cloud non elimina l’hardware. L’hardware esiste ancora nei data center del provider. Cambia il rapporto fra chi utilizza il servizio e l’infrastruttura sottostante.
Se vuoi partire dall’elemento fisico e logico su cui poggia buona parte di questa infrastruttura, la guida su cos’è un server e come funziona chiarisce la differenza fra ruolo server, macchina fisica, server virtuale e risorse erogate dal cloud.
Cloud, cloud computing e cloud storage non sono la stessa cosa
Nel linguaggio comune “cloud” viene spesso usato come termine ombrello, ma conviene distinguere i concetti.
Cloud computing indica il modello generale di erogazione delle risorse informatiche.
Cloud storage indica invece un servizio specifico: spazio di archiviazione fornito attraverso un’infrastruttura cloud.
Cloud hosting applica principi e infrastrutture cloud all’hosting di siti e applicazioni. Se il tuo interesse riguarda specificamente l’hosting web, l’approfondimento su cos’è il cloud hosting e come funziona entra nel merito di questo particolare servizio senza confonderlo con l’intero modello cloud.
Questa distinzione evita un errore frequente: pensare che utilizzare un servizio di archiviazione online equivalga a comprendere tutto ciò che rientra nel cloud computing.
Perché si parla di risorse on demand
Una delle caratteristiche che rende il cloud diverso da una semplice infrastruttura remota è la possibilità di ottenere risorse quando servono, spesso attraverso procedure automatizzate.
Puoi, per esempio, creare una macchina virtuale, aumentare la capacità di storage o attivare un database senza attendere l’installazione manuale di un nuovo server fisico.
Questo non significa che qualsiasi servizio cloud possa crescere senza limiti o che ogni aumento sia istantaneo. Quote, capacità disponibili, architettura dell’applicazione, limiti del servizio e costi continuano a esistere.
Il vantaggio reale è che il provisioning delle risorse viene separato dalla necessità di acquistare e installare ogni volta nuova infrastruttura fisica.
Come funziona il cloud computing
Dietro una risorsa cloud ci sono data center, server, reti, sistemi di storage e software di gestione. Il provider organizza questi componenti in una piattaforma capace di fornire capacità ai diversi clienti mantenendo isolamento, controllo e automazione.
La virtualizzazione ha avuto un ruolo centrale in questo modello perché permette di dividere le risorse di una macchina fisica tra più ambienti indipendenti. Il cloud moderno, però, non coincide con la sola virtualizzazione: può includere macchine virtuali, container, servizi gestiti, infrastrutture bare metal e piattaforme serverless.
Data center, virtualizzazione e pool di risorse
In un’infrastruttura tradizionale un server può essere dedicato a un singolo carico di lavoro. La virtualizzazione consente invece di creare più ambienti isolati sopra una stessa infrastruttura fisica.
Il cloud porta questa logica su una scala più ampia. CPU, memoria, storage e capacità di rete vengono organizzati in pool di risorse che la piattaforma può assegnare secondo necessità.
Il cliente vede la risorsa richiesta — per esempio una macchina virtuale con una determinata quantità di RAM — mentre il provider gestisce l’hardware fisico, parte della rete, i sistemi di orchestrazione e gli altri componenti previsti dal servizio.
Provisioning e automazione
Il passaggio decisivo è l’automazione.
Invece di chiedere manualmente a un tecnico di preparare un server, molte piattaforme permettono di dichiarare o selezionare le caratteristiche necessarie e creare la risorsa in modo automatizzato.
La stessa logica permette di utilizzare l’Infrastructure as Code, cioè descrivere configurazioni e infrastrutture attraverso file e procedure versionabili anziché affidarsi esclusivamente a configurazioni manuali.
È uno dei motivi per cui il cloud interessa non soltanto chi vuole “spostare server online”, ma anche chi vuole rendere più ripetibile l’intero ciclo di deployment.
Scalabilità ed elasticità non sono esattamente la stessa cosa
I due termini vengono spesso utilizzati come sinonimi.
La scalabilità è la capacità di un sistema di gestire un carico maggiore aumentando le risorse disponibili. Può avvenire aumentando la potenza di una singola istanza oppure distribuendo il lavoro tra più istanze.
L’elasticità aggiunge una dimensione dinamica: le risorse possono aumentare o diminuire in risposta al carico.
Un ecommerce che riceve molto più traffico durante una campagna può avere bisogno di capacità aggiuntiva solo per alcune ore. In un’architettura progettata correttamente, l’elasticità permette di adattare le risorse invece di dimensionare permanentemente l’infrastruttura sul picco massimo.
La parola importante è però correttamente. Mettere un’applicazione nel cloud non la rende automaticamente scalabile: software, database, sessioni, storage e dipendenze devono essere progettati per supportare quel comportamento.
Misurazione dell’utilizzo e costi a consumo
Molti servizi cloud misurano l’uso di capacità di calcolo, storage, richieste, trasferimento dati o altre risorse.
Da qui nasce il modello spesso riassunto con pay as you go. Non significa però che ogni servizio venga fatturato nello stesso modo o che il cloud sia sempre più economico.
Alcune risorse vengono addebitate per tempo di utilizzo, altre per capacità riservata, numero di operazioni, utenti, traffico o combinazioni di queste metriche.
Il cloud rende il costo più legato al consumo; non rende automaticamente il costo più basso.
Le 5 caratteristiche che distinguono il cloud computing
Cinque caratteristiche permettono di capire perché un’infrastruttura cloud non coincide semplicemente con un server collocato in un data center remoto.
- On-demand self-service. Il cliente può ottenere capacità informatiche quando ne ha bisogno senza richiedere un intervento umano per ogni singola operazione.
- Broad network access. Le risorse sono accessibili attraverso la rete utilizzando meccanismi standard e diversi tipi di client.
- Resource pooling. Le risorse del provider vengono aggregate e assegnate dinamicamente a più clienti secondo il modello adottato.
- Rapid elasticity. La capacità può essere aumentata o ridotta rapidamente in relazione alla domanda.
- Measured service. Il sistema misura l’utilizzo delle risorse, rendendo possibile controllo, monitoraggio e modelli economici basati sul consumo.
Questo schema impedisce di chiamare “cloud” qualsiasi server raggiungibile da Internet.
Un semplice server remoto, per esempio, non diventa automaticamente cloud solo perché si trova in un data center esterno.
IaaS, PaaS e SaaS: i tre principali modelli di servizio
Un altro punto che genera confusione è la differenza fra IaaS, PaaS e SaaS.
Non sono tre tipi di cloud pubblico. Descrivono invece quanto dello stack tecnologico viene gestito dal provider e quanto rimane sotto la responsabilità del cliente.
| Modello | Tu gestisci soprattutto | Il provider gestisce soprattutto | Scenario tipico |
|---|---|---|---|
| IaaS | sistema operativo, applicazioni, configurazioni e dati | hardware, data center e infrastruttura di base | server virtuali e infrastrutture personalizzate |
| PaaS | applicazione, codice, dati e configurazioni | infrastruttura, sistema operativo e piattaforma runtime | sviluppo e deployment di applicazioni |
| SaaS | utenti, dati, accessi e configurazioni disponibili | applicazione e gran parte dello stack sottostante | software pronto da usare |
La tabella è una semplificazione: la divisione precisa cambia in base al servizio acquistato.
IaaS: Infrastructure as a Service
Con l’Infrastructure as a Service ottieni risorse infrastrutturali come capacità di calcolo, rete e storage senza dover possedere l’hardware fisico sottostante.
È il modello che offre più controllo fra i tre principali, ma proprio per questo lascia anche più attività operative al cliente.
Se utilizzi una macchina virtuale IaaS, per esempio, il provider può occuparsi di data center, server fisico e livello di virtualizzazione, mentre tu continui a gestire sistema operativo, configurazioni, patch applicative e software installato.
È quindi indicato quando serve controllo sull’ambiente, ma non vuoi acquistare e mantenere direttamente l’hardware.
PaaS: Platform as a Service
Una Platform as a Service sposta più responsabilità verso il provider.
Lo sviluppatore distribuisce l’applicazione sulla piattaforma senza dover amministrare direttamente ogni macchina virtuale o sistema operativo sottostante.
Questo riduce il lavoro infrastrutturale, ma significa anche accettare più vincoli della piattaforma: runtime supportati, modalità di deployment, servizi disponibili e architettura possono essere meno liberamente configurabili rispetto a IaaS.
PaaS ha quindi senso quando la velocità di sviluppo e gestione conta più del controllo completo sull’infrastruttura.
SaaS: Software as a Service
Con il Software as a Service utilizzi direttamente un’applicazione fornita dal provider.
Email aziendale, CRM, strumenti di collaborazione e software gestionali accessibili tramite browser sono esempi comuni.
L’utente non gestisce server, sistema operativo o runtime. Continua però a essere responsabile di aspetti come account, permessi, configurazioni e utilizzo corretto dei dati.
È un punto importante perché “gestito dal provider” non significa “non ho più nessuna responsabilità”.
Serverless e FaaS: dove si collocano
Il termine serverless può essere fuorviante: i server continuano a esistere.
La differenza è che lo sviluppatore non deve normalmente provisionare e amministrare direttamente l’infrastruttura che esegue il codice. Anche la spiegazione di AWS sul serverless computing parte da questo principio: il cloud provider effettua provisioning, scaling e manutenzione dei componenti server sottostanti in base alla domanda.
Le Function as a Service, o FaaS, rappresentano uno dei modelli serverless più riconoscibili: una funzione viene eseguita in risposta a un evento senza richiedere la gestione esplicita di un server persistente.
Non è però corretto trattare serverless come un “quarto modello NIST” alla pari di IaaS, PaaS e SaaS. È più utile considerarlo un’evoluzione dell’astrazione infrastrutturale e dei modelli di esecuzione cloud.
Cloud pubblico, privato, community e ibrido
I modelli di servizio rispondono alla domanda “che cosa gestisce il provider?”.
I modelli di deployment rispondono invece a una domanda diversa: “come e per chi viene predisposta l’infrastruttura cloud?”
La distinzione è fondamentale.
Public cloud
Nel cloud pubblico l’infrastruttura viene fornita da un cloud provider a più clienti, con meccanismi di isolamento e separazione delle risorse.
Non significa che i dati siano “pubblici”. Il termine riguarda il modello con cui l’infrastruttura viene messa a disposizione.
È la soluzione associata più spesso a scalabilità, ampia disponibilità di servizi e provisioning rapido.
Private cloud
Un private cloud viene predisposto per l’utilizzo esclusivo di una singola organizzazione.
Può essere ospitato nei data center dell’organizzazione oppure gestito da un soggetto esterno.
Questo chiarisce un’altra distinzione importante: private cloud e on-premise non sono sinonimi. Un’infrastruttura privata può essere cloud pur essendo gestita fuori dalla sede dell’azienda; allo stesso modo, possedere alcuni server in azienda non significa automaticamente aver costruito un private cloud.
Community cloud
Il modello community cloud identifica un’infrastruttura destinata a una specifica comunità di organizzazioni con esigenze condivise.
È molto meno centrale nella comunicazione commerciale dei principali provider rispetto a public, private e hybrid cloud, ma rimane utile per comprendere la classificazione canonica.
Hybrid cloud
Un hybrid cloud integra ambienti differenti — tipicamente infrastruttura privata e cloud pubblico — mantenendo una forma di interoperabilità o coordinamento tra i due.
Un’organizzazione può, per esempio, conservare alcuni workload in un ambiente privato e utilizzare il cloud pubblico per altri servizi o per gestire picchi di capacità.
Il vantaggio è la flessibilità. Il prezzo da pagare è una maggiore complessità architetturale e operativa.
Multicloud: perché non è semplicemente un altro deployment model
Con multicloud si indica normalmente l’utilizzo di servizi cloud provenienti da più provider. La spiegazione di IBM sul multicloud aiuta a distinguere questa strategia dall’hybrid cloud, che riguarda invece l’integrazione tra ambienti differenti.
Un’azienda potrebbe utilizzare due cloud pubblici diversi senza possedere alcun private cloud: sarebbe un ambiente multicloud, ma non necessariamente hybrid.
E soprattutto, multicloud non significa automaticamente maggiore resilienza. Rendere un’applicazione realmente portabile o attiva su più provider può aumentare costi, duplicazioni e complessità operativa.
Esempi di cloud computing nella pratica
Il concetto diventa più semplice da capire quando viene collegato a problemi concreti.
Applicazioni SaaS e collaborazione
Quando utilizzi un software aziendale tramite browser senza installare e amministrare il suo stack server, stai probabilmente utilizzando un servizio SaaS.
Il provider gestisce l’applicazione e l’infrastruttura; l’organizzazione gestisce utenti, permessi, configurazioni e dati secondo le funzionalità disponibili.
Hosting di siti e applicazioni
Un sito può essere distribuito su macchine virtuali, piattaforme gestite, container o servizi serverless.
Qui è importante non confondere il modello generale con il servizio commerciale: il cloud hosting è una possibile applicazione dell’infrastruttura cloud all’hosting web, non un sinonimo dell’intero modello.
Database e storage gestiti
Un database gestito permette di utilizzare un motore database senza dover amministrare direttamente ogni componente dell’infrastruttura sottostante.
Il provider può occuparsi, in misura diversa a seconda del servizio, di provisioning, aggiornamenti, disponibilità, backup e scaling.
Anche qui “gestito” non significa “senza responsabilità”: progettazione dei dati, accessi, query, configurazioni e costi rimangono aspetti da controllare.
Backup e disaster recovery
Il cloud consente di mantenere copie dei dati in infrastrutture geograficamente separate e di predisporre risorse che possono essere utilizzate in caso di guasto.
Ma avere un backup nel cloud non equivale ad avere una strategia di disaster recovery.
Servono procedure di ripristino, obiettivi di recovery, test e una comprensione chiara delle dipendenze dell’applicazione.
Analytics e intelligenza artificiale
Uno dei vantaggi del cloud è poter utilizzare servizi che richiederebbero infrastrutture complesse da installare autonomamente: data warehouse, piattaforme di analytics, GPU, servizi di machine learning e sistemi di elaborazione distribuita.
Un esempio concreto è Google BigQuery, un data warehouse serverless che permette di lavorare su grandi quantità di dati senza amministrare direttamente un cluster di calcolo tradizionale.
Vantaggi del cloud computing: dove crea davvero valore
Molti elenchi sui vantaggi del cloud partono da “costa meno”. È un approccio pericoloso perché riduce una decisione architetturale a uno slogan commerciale.
Il valore dipende soprattutto da come cambia la capacità di ottenere, modificare e gestire risorse informatiche.
Provisioning più rapido
Attivare una nuova risorsa può richiedere molto meno tempo rispetto all’intero ciclo di acquisto, consegna e installazione dell’hardware.
Questo può ridurre il tempo necessario per test, sviluppo e lancio di nuovi servizi.
Scalabilità ed elasticità
Il cloud rende più semplice accedere a capacità aggiuntiva quando un workload cresce.
Il beneficio è particolarmente interessante quando la domanda è variabile. Un’infrastruttura dimensionata per il picco massimo potrebbe rimanere inutilizzata per gran parte del tempo; un modello elastico può adattare la capacità più dinamicamente.
Minore gestione dell’hardware
Una parte della gestione fisica passa al provider: server, alimentazione, networking del data center e sostituzione dell’hardware non sono normalmente attività del cliente.
Salendo verso PaaS e SaaS possono essere trasferite anche responsabilità sul sistema operativo, runtime e altri livelli dello stack.
Accesso a servizi gestiti
Il vero vantaggio competitivo del cloud moderno spesso non è la semplice macchina virtuale.
Database gestiti, code di messaggi, sistemi di osservabilità, piattaforme container, servizi di sicurezza, analytics e AI permettono di utilizzare componenti complessi senza costruirli interamente da zero.
Distribuzione geografica
I grandi provider permettono di distribuire risorse in più aree geografiche.
Questo può essere utile per disponibilità, continuità operativa o latenza, ma richiede comunque un’architettura progettata per sfruttare quella distribuzione.
Usare un provider con molti data center non rende automaticamente una singola applicazione altamente disponibile.
Il cloud fa sempre risparmiare?
No.
Può evitare investimenti hardware iniziali e rendere la spesa più collegata al consumo, ma può anche generare costi importanti se le risorse vengono dimensionate male, lasciate attive inutilmente o producono molto traffico.
La panoramica di Google Cloud sui vantaggi e sugli svantaggi del cloud computing mostra bene perché flessibilità e riduzione degli investimenti iniziali vadano valutate insieme a controllo, costi e dipendenza dalla connettività.
Per questo il confronto corretto non è:
server fisico costoso → cloud economico
ma:
costo totale, competenze, flessibilità, rischio e requisiti operativi di una soluzione → costo totale e caratteristiche dell’altra.
Limiti e rischi del cloud
Il cloud risolve alcuni problemi infrastrutturali ma ne introduce altri. Ignorarli significa prendere decisioni sulla base del marketing del provider anziché dell’architettura.
Costi difficili da prevedere
Il modello a consumo può essere efficiente quando l’utilizzo è variabile, ma richiede controllo.
Macchine sovradimensionate, storage dimenticato, snapshot, servizi gestiti, richieste API e traffico in uscita possono accumulare costi.
Per workload stabili e prevedibili, una soluzione alternativa può risultare economicamente competitiva.
Vendor lock-in
Più un’applicazione dipende da servizi proprietari di un provider, maggiore può diventare il costo tecnico di spostarla.
Una macchina virtuale relativamente standard è normalmente più portabile di un’applicazione costruita attorno a numerosi database, code, runtime e API specifici di una singola piattaforma.
Questo non significa che i servizi proprietari vadano evitati. Possono offrire vantaggi importanti.
Il punto è valutare consapevolmente il trade-off fra velocità e portabilità.
Outage e dipendenza dal provider
Anche i grandi cloud possono avere interruzioni.
Un sistema affidabile non deve quindi limitarsi a “essere nel cloud”: bisogna capire come reagisce alla perdita di una singola istanza, di una zona, di un servizio esterno o, nei casi in cui il rischio lo giustifica, di una regione.
Ridondanza e resilienza devono essere progettate.
Sicurezza e shared responsibility
Uno degli errori più pericolosi è pensare:
“È nel cloud, quindi la sicurezza è responsabilità del provider.”
Il modello reale è di responsabilità condivisa. La documentazione Microsoft sul modello di shared responsibility rende molto chiaro come il confine cambi fra IaaS, PaaS e SaaS: salendo verso servizi più gestiti il provider prende in carico una parte maggiore dello stack, ma dati, account, identità, endpoint e gestione degli accessi restano comunque responsabilità rilevanti del cliente.
In IaaS puoi essere responsabile anche del sistema operativo e delle applicazioni. In SaaS non amministri l’infrastruttura, ma un account privilegiato configurato male può comunque esporre informazioni sensibili.
Cloud gestito non significa sicurezza automatica.
Privacy, compliance e posizione dei dati
Quando sposti dati e workload in un servizio cloud devi sapere quali dati stai trattando, dove possono essere elaborati o conservati, quali soggetti vi accedono e quali controlli mette a disposizione il provider.
Per progetti sottoposti a requisiti normativi o contrattuali, la scelta della regione e del servizio non è quindi soltanto una questione di latenza.
Latenza e dipendenza dalla rete
Un servizio remoto richiede connettività.
Per molte applicazioni questo non rappresenta un problema significativo; per sistemi industriali, applicazioni real-time o workload vicini alla sorgente dei dati può diventare invece un limite decisivo.
Da qui nasce anche l’interesse per edge computing e architetture ibride.
Cloud computing vs cloud hosting, VPS e server dedicato
Questi termini appartengono allo stesso territorio tecnologico ma non descrivono la stessa cosa.
| Soluzione | Che cosa descrive | Controllo tipico | Risorsa caratteristica | Quando ha senso |
|---|---|---|---|---|
| Cloud computing | modello generale di erogazione delle risorse IT | varia da SaaS a IaaS | servizi, compute, storage, database, piattaforme | quando servono risorse e servizi erogati secondo un modello cloud |
| Cloud hosting | servizio di hosting basato su infrastruttura cloud | dipende dal piano | risorse distribuite per siti e applicazioni | hosting con maggiore flessibilità infrastrutturale |
| VPS | ambiente server virtuale isolato | medio-alto | quota di risorse virtualizzate | quando serve più controllo rispetto all’hosting condiviso |
| Server dedicato | infrastruttura riservata a un singolo cliente o progetto | alto | macchina o risorse dedicate secondo il servizio | workload che richiedono controllo e risorse riservate |
Un VPS è un ambiente virtuale isolato. Può essere erogato sopra una singola macchina fisica oppure, a seconda dell’architettura del provider, essere inserito in un’infrastruttura cloud.
Un server dedicato privilegia invece la disponibilità di risorse riservate e un livello elevato di controllo sull’ambiente.
Il cloud computing è più ampio di entrambi: comprende non soltanto macchine virtuali, ma anche database gestiti, storage, piattaforme applicative, serverless, analytics e numerosi altri servizi.
Se la decisione riguarda esclusivamente l’hosting di un sito, il confronto dedicato fra cloud hosting e VPS hosting entra più in profondità sulle differenze operative ed economiche fra queste due soluzioni.
Come scegliere il modello cloud adatto
La domanda giusta non è “qual è il cloud migliore?”, ma quale livello di controllo vuoi mantenere e quale complessità vuoi delegare.
Vuoi semplicemente utilizzare un software?
Parti da SaaS.
Se esiste già un’applicazione che risolve il problema, gestire direttamente server e runtime raramente aggiunge valore.
Devi sviluppare un’applicazione ma non vuoi gestire il sistema operativo?
PaaS o una piattaforma serverless possono ridurre il lavoro infrastrutturale.
In cambio accetti più vincoli del provider e una minore libertà su alcuni livelli dello stack.
Hai bisogno di controllo su sistema operativo e rete?
IaaS è generalmente più appropriato.
Hai una flessibilità maggiore, ma devi anche assumerti più responsabilità operative e di sicurezza.
Hai workload legacy o requisiti molto specifici?
Private cloud o hybrid cloud possono essere più coerenti quando una parte dell’infrastruttura non può essere spostata facilmente su un cloud pubblico.
Non significa però che hybrid sia automaticamente la scelta più “professionale”: mantenere due ambienti può aumentare sensibilmente complessità, integrazione e costi.
Vuoi usare più provider per evitare dipendenze?
Una strategia multicloud può avere senso, ma solo quando il beneficio supera il costo operativo.
Gestire identità, networking, monitoraggio, competenze e deployment su piattaforme differenti richiede più lavoro. Usare due provider soltanto per poter dire di essere “multicloud” aggiunge complessità senza risolvere un problema concreto.
Una matrice semplificata può aiutare:
| Esigenza principale | Punto di partenza |
|---|---|
| software pronto all’uso | SaaS |
| sviluppo senza gestione diretta dell’OS | PaaS |
| esecuzione event-driven con infrastruttura fortemente astratta | Serverless / FaaS |
| massimo controllo sul sistema operativo | IaaS |
| ambiente esclusivo per una organizzazione | Private cloud |
| integrazione fra infrastrutture differenti | Hybrid cloud |
| uso deliberato di più cloud provider | Multicloud |
Non è una tabella di equivalenze assolute. Molte architetture reali combinano più modelli.
Cloud native, serverless, multicloud e AI: come si collegano al cloud computing
Il cloud computing non è rimasto fermo alla macchina virtuale.
Cloud native descrive un modo di progettare applicazioni pensato per sfruttare caratteristiche come automazione, distribuzione, container, microservizi e infrastruttura programmabile. Non significa semplicemente “applicazione ospitata nel cloud”.
Serverless aumenta l’astrazione: il team sviluppa codice o utilizza servizi senza gestire direttamente l’infrastruttura di esecuzione.
Multicloud riguarda invece l’impiego di più provider.
L’intelligenza artificiale sfrutta spesso infrastrutture cloud perché training, inferenza, storage e analisi possono richiedere GPU e capacità di calcolo molto elevate. I provider offrono inoltre modelli e servizi AI già gestiti.
Questi concetti sono collegati, ma nessuno sostituisce la definizione di cloud computing.
Il punto di partenza resta lo stesso: risorse informatiche erogate come servizi attraverso un’infrastruttura programmabile, condivisa o dedicata secondo il modello scelto, con diversi livelli di gestione delegata al provider.
Domande frequenti sul cloud computing
Cloud e Internet sono la stessa cosa?
No. Internet è la rete attraverso cui molti servizi cloud vengono raggiunti. Il cloud computing è un modello con cui risorse e servizi informatici vengono erogati e gestiti.
Google Drive è cloud computing?
È un servizio cloud, più precisamente un’applicazione SaaS con funzioni di cloud storage. Non rappresenta però tutto il cloud computing, che comprende anche infrastruttura, piattaforme, database, networking e numerosi altri servizi.
Il cloud costa sempre meno di un server tradizionale?
No. Può ridurre investimenti iniziali e migliorare l’utilizzo delle risorse, ma il risultato dipende dal workload, dalla configurazione, dal traffico, dai servizi utilizzati e dalle competenze necessarie per gestirli.
Un private cloud deve trovarsi dentro l’azienda?
No. Un private cloud è definito dall’uso esclusivo dell’infrastruttura da parte di una singola organizzazione; può essere gestito internamente oppure da un soggetto esterno.
Serverless significa che non esistono server?
No. Significa che la gestione diretta dei server viene astratta per chi sviluppa o utilizza il servizio. L’infrastruttura fisica continua a essere necessaria e viene amministrata dal provider.
Conclusione
Il cloud computing non è semplicemente “mettere qualcosa online”. È un modello diverso di ottenere e gestire risorse informatiche, nel quale una parte dell’infrastruttura e delle attività operative viene trasferita a un provider e resa disponibile come servizio.
Se vuoi utilizzare un’applicazione pronta, SaaS può essere sufficiente. Se sviluppi software senza voler amministrare sistemi operativi, PaaS o serverless possono ridurre il lavoro operativo. Se ti serve controllo sull’ambiente, IaaS lascia più responsabilità nelle tue mani. Public, private e hybrid cloud rispondono invece a una domanda differente: come viene predisposta l’infrastruttura e a chi è destinata.
Il cloud è particolarmente efficace quando elasticità, velocità di provisioning e servizi gestiti hanno un valore concreto per il progetto. Ha meno senso sceglierlo per moda, dando per scontato che sia sempre più economico, più sicuro o più affidabile.
La scelta corretta parte quindi dal workload: quale controllo ti serve, quale complessità vuoi gestire, come varia la domanda, quali dati utilizzi e quanto ti costerebbe cambiare architettura in futuro.