IaaS significa Infrastructure as a Service: è un modello di cloud computing in cui utilizzi risorse infrastrutturali come capacità di calcolo, storage e rete senza dover acquistare e mantenere direttamente i server fisici che le erogano.
Il provider gestisce il data center, l’hardware e gran parte dell’infrastruttura sottostante. Tu mantieni invece un controllo molto maggiore rispetto a PaaS e SaaS: con una macchina virtuale IaaS, per esempio, devi normalmente occuparti del sistema operativo, delle applicazioni installate, delle configurazioni, degli accessi e di buona parte della sicurezza del workload.
È questa divisione delle responsabilità a rendere IaaS utile quando vuoi la flessibilità del cloud senza rinunciare al controllo dell’ambiente.
Il modello rientra nella classificazione classica del cloud computing descritta dal NIST nella SP 800-145, insieme a PaaS e SaaS. Se vuoi partire dal quadro generale prima di entrare nell’infrastruttura, la nostra guida al cloud computing approfondisce caratteristiche, modelli di servizio e modalità di deployment.
Cos’è IaaS e cosa significa Infrastructure as a Service
Infrastructure as a Service può essere tradotto come infrastruttura fornita come servizio.
In un ambiente tradizionale, per eseguire un’applicazione potresti dover acquistare server, predisporre storage e networking, installare sistemi operativi, dimensionare l’hardware e sostituirlo quando non è più sufficiente.
Con IaaS una parte di questo problema viene trasformata in risorse software che puoi provisionare quando servono.
Invece di ordinare un nuovo server fisico, puoi creare una macchina virtuale. Invece di installare fisicamente nuovi dischi, puoi collegare storage. Invece di cablare una rete nel data center, puoi definire reti virtuali, subnet, regole di routing e controlli di accesso attraverso console, API o strumenti di automazione.
Il risultato non è l’eliminazione dell’infrastruttura. L’infrastruttura continua a esistere, ma una parte importante viene astratta e resa disponibile come servizio.
IaaS non significa semplicemente “server nel cloud”
Ridurre IaaS a una macchina virtuale remota è comodo, ma incompleto.
Una VM è spesso il componente più visibile, ma un ambiente IaaS può comprendere anche:
- capacità di calcolo;
- storage a blocchi;
- immagini delle macchine;
- reti virtuali e subnet;
- indirizzi IP;
- firewall o security group;
- load balancer;
- snapshot;
- componenti per alta disponibilità;
- API e strumenti di orchestrazione.
A seconda del provider, altri servizi come object storage, database gestiti, sistemi di backup o Kubernetes possono essere collegati all’infrastruttura pur avendo un livello di gestione differente.
Per questo conviene distinguere il modello IaaS dal catalogo commerciale di un cloud provider. Nello stesso account puoi utilizzare contemporaneamente infrastruttura, piattaforme gestite, database, funzioni serverless e software SaaS.
Dove si colloca IaaS nel cloud computing
Il modo più semplice per capire IaaS è osservare quanto controllo rimane al cliente.
Con un’infrastruttura on-premise controlli praticamente tutto lo stack. Con IaaS deleghi l’hardware e il livello fisico, ma continui a gestire gran parte del sistema software. Con PaaS deleghi anche sistema operativo e piattaforma applicativa. Con SaaS utilizzi direttamente l’applicazione.
Più scendi verso l’infrastruttura, quindi, aumentano controllo e libertà, ma aumentano anche le attività operative che devi gestire.
Come funziona IaaS: dal data center alle risorse virtuali
Dietro una console cloud apparentemente semplice esiste un’infrastruttura fisica fatta di server, storage, apparati di rete e data center.
Il provider costruisce e gestisce questo livello, poi utilizza virtualizzazione, software-defined networking, sistemi di orchestrazione e API per trasformarlo in risorse che il cliente può richiedere in modo dinamico.
Un flusso molto semplificato può essere rappresentato così:
hardware fisico → virtualizzazione → risorse IaaS → sistema operativo → applicazioni → dati
Quando crei una VM non stai quindi “creando un computer dal nulla”. Stai chiedendo alla piattaforma di allocare capacità all’interno della propria infrastruttura e di presentartela come una risorsa amministrabile.
Compute: macchine virtuali, CPU, RAM e bare metal
Il compute rappresenta la capacità di elaborazione.
La forma più riconoscibile è la macchina virtuale, alla quale assegni una determinata quantità di CPU, memoria, storage e capacità di rete.
Puoi scegliere un’immagine con Linux o Windows, creare immagini personalizzate e, nei limiti previsti dal provider, modificare la dimensione della macchina quando cambia il carico.
Esistono inoltre offerte bare metal, nelle quali utilizzi un server fisico dedicato attraverso un modello cloud. Questo è un buon esempio del perché “IaaS = macchina virtuale” sia una definizione troppo stretta: anche l’hardware dedicato può essere erogato con provisioning e gestione tipici dell’infrastruttura come servizio.
Storage: blocchi, file e object storage
Una VM senza persistenza sarebbe utile solo in scenari molto specifici.
Per questo l’infrastruttura cloud include normalmente diverse forme di storage.
Lo storage a blocchi viene spesso utilizzato come disco per le macchine virtuali. Puoi creare un volume, collegarlo a un’istanza, aumentarne la capacità o creare snapshot secondo le funzionalità offerte dal provider.
File storage e object storage rispondono invece a esigenze differenti. Non bisogna però assumere che tutte le forme di storage abbiano lo stesso modello di responsabilità di una VM: alcuni servizi sono molto più gestiti e astratti.
La domanda corretta non è quindi soltanto “questo storage è cloud?”, ma quali aspetti devo configurare, proteggere, replicare e monitorare io?
Networking: reti virtuali, IP, firewall e load balancer
Una delle differenze più importanti rispetto a un semplice hosting è il livello di controllo sulla rete.
In un ambiente IaaS puoi normalmente definire reti virtuali, segmentare subnet, assegnare IP, costruire regole di routing e controllare quali flussi possono entrare o uscire dalle diverse risorse.
È un vantaggio potente, ma introduce anche responsabilità.
Una porta aperta verso Internet per errore, una regola firewall troppo permissiva o una segmentazione progettata male possono creare problemi anche quando il provider protegge perfettamente il proprio data center.
Il cloud rende la rete programmabile. Non la rende automaticamente corretta.
Virtualizzazione, API e provisioning on demand
La virtualizzazione separa le risorse logiche dall’hardware fisico sottostante.
Per il cliente, però, il vero salto operativo arriva quando queste risorse diventano gestibili tramite API.
Una VM può essere creata da una console grafica, ma può anche essere descritta come configurazione e generata automaticamente. Lo stesso vale per reti, storage, regole di accesso e altri componenti.
Questo consente di passare da:
configuro manualmente un server
a:
descrivo l’infrastruttura che mi serve e la piattaforma la provisiona
È la base dell’Infrastructure as Code, dell’automazione degli ambienti e di molti workflow DevOps.
Cosa gestisce il provider IaaS e cosa resta al cliente
Questa è la parte più importante dell’intero modello.
Un’infrastruttura cloud non trasferisce automaticamente tutte le responsabilità al provider.
La documentazione sul modello di responsabilità condivisa di Microsoft distingue chiaramente IaaS da PaaS e SaaS: con IaaS il provider protegge l’infrastruttura fisica, mentre il cliente continua a gestire sistema operativo, applicazioni, dati, identità, configurazioni e gran parte dei controlli di rete. Anche AWS descrive lo stesso principio per Amazon EC2.
| Area | Provider IaaS | Cliente |
|---|---|---|
| Data center fisico | gestisce | non gestisce direttamente |
| Server fisici | gestisce | non gestisce direttamente |
| Rete fisica | gestisce | non gestisce direttamente |
| Virtualizzazione | normalmente gestisce | utilizza le risorse esposte |
| Macchina virtuale | fornisce la capacità | crea e configura l’istanza |
| Sistema operativo guest | fornisce immagini/opzioni | configura, aggiorna e protegge |
| Runtime e middleware | può fornire immagini o servizi | gestisce ciò che installa sulla VM |
| Applicazioni | fornisce infrastruttura | installa, configura e protegge |
| Dati | protegge il servizio sottostante | governa dati, accessi e utilizzo |
| Identità e permessi | offre sistemi IAM | configura account, ruoli e privilegi |
| Controlli di rete | offre gli strumenti | configura firewall, segmentazione e regole |
| Backup e recovery | può offrire servizi dedicati | decide strategia, policy e verifiche |
La tabella è un modello mentale. La divisione precisa cambia in base al servizio.
Sistema operativo, patch, applicazioni, identità e dati
Con una VM IaaS, avere accesso amministrativo al sistema operativo significa anche esserne responsabili.
Se utilizzi Linux, devi pianificare aggiornamenti, patch, utenti e servizi. Se utilizzi Windows, valgono gli stessi principi con gli strumenti e i cicli di manutenzione dell’ambiente Microsoft.
Su questo sistema operativo installi poi web server, database, runtime, agent, applicazioni e altri componenti.
Ogni elemento aggiunto aumenta ciò che devi mantenere.
Questa libertà è uno dei motivi per scegliere IaaS, ma diventa facilmente un costo operativo se il team non ha competenze o processi adeguati.
Backup e sicurezza non sono automaticamente “risolti dal cloud”
Due frasi andrebbero eliminate da qualsiasi valutazione seria:
“È nel cloud, quindi è sicuro.”
e:
“È nel cloud, quindi è già ridondato.”
Il provider può offrire data center sicuri, snapshot, zone di disponibilità, backup gestiti, firewall e altri strumenti. Sta al cliente scegliere e configurare quelli necessari per il proprio workload.
Una singola VM senza replica può rimanere un single point of failure.
Uno snapshot esistente ma mai testato non equivale a una strategia di disaster recovery.
Un servizio affidabile deve quindi progettare esplicitamente disponibilità, backup, ripristino e sicurezza in base all’impatto reale di un’interruzione.
IaaS, PaaS e SaaS: cosa cambia davvero
IaaS, PaaS e SaaS risolvono problemi diversi.
La differenza principale non è quanto un servizio sia “moderno”. È quale parte dello stack vuoi continuare a gestire direttamente.
| Modello | Cosa ricevi | Gestisci soprattutto | Il provider gestisce soprattutto | Scenario tipico |
|---|---|---|---|---|
| IaaS | infrastruttura | OS, runtime, applicazioni, dati, rete logica | hardware, data center, rete fisica, virtualizzazione | workload che richiedono controllo |
| PaaS | piattaforma applicativa | codice, applicazioni, dati, configurazioni | infrastruttura, OS, runtime e piattaforma | sviluppo e deployment |
| SaaS | applicazione completa | utenti, accessi, dati e configurazioni disponibili | applicazione e gran parte dello stack | software pronto all’uso |
| On-premise | intero stack | praticamente tutto | nessuna parte per definizione | infrastruttura gestita direttamente |
Se vuoi sviluppare un’applicazione senza amministrare sistemi operativi e macchine virtuali, approfondisci il modello PaaS (Platform as a Service).
Se invece vuoi utilizzare direttamente un’applicazione già gestita, la guida al SaaS (Software as a Service) sposta il confronto sul livello più alto di astrazione.
Più controllo significa anche più responsabilità
Il passaggio da SaaS a IaaS può sembrare una progressione verso una soluzione “più professionale”.
Non è così.
Se utilizzi un CRM, non ottieni necessariamente alcun vantaggio dal creare una VM e installare manualmente un software equivalente. Stai semplicemente assumendoti attività che un SaaS avrebbe gestito per te.
IaaS diventa interessante quando quel controllo serve davvero: sistema operativo specifico, configurazioni di rete particolari, software legacy, dipendenze custom, appliance, requisiti di migrazione o workload che non si adattano bene a piattaforme più astratte.
Quando conviene salire verso PaaS o SaaS
Se la parte di infrastruttura che stai gestendo non crea alcun vantaggio per il progetto, probabilmente è un candidato alla delega.
Un team che passa metà del proprio tempo a patchare VM per far funzionare un’applicazione standard potrebbe ottenere più valore da PaaS o SaaS.
Non è una regola universale. È un criterio di progettazione:
mantieni il controllo dove crea valore; delegalo dove produce soprattutto lavoro operativo.
IaaS vs VPS, cloud hosting e server dedicato: non sono la stessa cosa
Questi termini vengono spesso messi sullo stesso piano, ma descrivono cose differenti.
IaaS è un modello di servizio.
VPS e server dedicato descrivono soprattutto il tipo di risorsa informatica che utilizzi.
Cloud hosting è invece un termine commerciale e architetturale più ampio, che può essere implementato in modi molto diversi.
Quando una VM IaaS assomiglia a un VPS
Una macchina virtuale IaaS può sembrare quasi identica a un VPS.
In entrambi i casi potresti ricevere:
- CPU virtuali;
- RAM;
- storage;
- un indirizzo IP;
- accesso amministrativo;
- Linux o Windows.
La differenza emerge quando osservi il sistema nel suo insieme.
Un VPS viene spesso acquistato come prodotto server con determinate risorse e un determinato piano. Un ambiente IaaS tende invece a trattare compute, storage, rete e servizi collegati come componenti separati, programmabili e combinabili.
Puoi approfondire il funzionamento dei Virtual Private Server nella guida ai VPS.
Cosa cambia rispetto al cloud hosting
Cloud hosting non è sinonimo di IaaS.
Un servizio di cloud hosting gestito può nascondere quasi completamente VM, networking e storage dietro un pannello semplificato. Il cliente vede un piano hosting, mentre il provider amministra la complessità sottostante.
Con IaaS, invece, quella complessità è spesso proprio ciò che vuoi controllare.
La nostra guida al cloud hosting approfondisce questa distinzione e spiega perché “cloud” non definisce automaticamente il livello di gestione offerto al cliente.
IaaS e server dedicato possono anche sovrapporsi
Server dedicato e IaaS non sono necessariamente alternative incompatibili.
Un server dedicato descrive il fatto che utilizzi hardware fisico riservato. IaaS descrive invece il modo in cui una risorsa infrastrutturale viene messa a disposizione e gestita come servizio.
Alcuni cloud provider offrono quindi bare metal IaaS: server fisici dedicati, ma provisionati e integrati nell’ecosistema cloud attraverso API, networking, storage e sistemi di automazione.
La domanda non è semplicemente “virtuale o fisico?”. È quale modello operativo serve al workload.
Quali sono i vantaggi dell’IaaS
IaaS diventa interessante quando risolve un vincolo concreto. La flessibilità, da sola, non è un risultato.
Provisioning rapido e scalabilità
Acquistare e installare nuovo hardware richiede tempo.
Con un’infrastruttura cloud puoi normalmente creare una nuova capacità di calcolo in tempi molto più brevi e modificare il dimensionamento quando cambiano le esigenze.
Questo è utile negli ambienti di sviluppo, nei workload stagionali, durante una migrazione o quando la domanda non è ancora sufficientemente prevedibile da giustificare un investimento hardware.
Scalabilità, però, non significa che qualsiasi applicazione possa crescere automaticamente.
Una VM più grande può risolvere un limite di capacità. Scalare un sistema distribuito richiede invece che applicazione, database, sessioni, storage e rete siano progettati per farlo.
Controllo dell’ambiente senza acquistare hardware
IaaS ti permette di conservare un livello elevato di libertà su:
- sistema operativo;
- configurazione della VM;
- software installato;
- runtime;
- networking;
- policy;
- architettura.
Questa libertà è particolarmente utile quando devi eseguire un’applicazione che non può essere adattata facilmente a una piattaforma gestita.
Automazione e infrastruttura programmabile
Creare manualmente una VM da una console è utile per iniziare.
Descrivere l’intera infrastruttura come configurazione è molto più interessante quando l’ambiente cresce.
L’automazione permette di ricostruire ambienti coerenti, ridurre configurazioni manuali, creare deployment ripetibili e tenere sotto controllo le modifiche.
Questo non elimina gli errori: sposta gli errori dalla configurazione manuale al codice e ai processi che governano l’infrastruttura.
La qualità dell’automazione rimane quindi fondamentale.
Capacità temporanea, test e disaster recovery
IaaS può essere molto utile quando la capacità serve solo per periodi limitati.
Un team può creare ambienti di test temporanei, eseguire elaborazioni intensive, predisporre infrastrutture di recovery o aumentare la capacità durante determinati eventi.
Il vantaggio è evitare di dimensionare l’hardware fisico per un picco che si presenta poche volte.
Anche qui, però, la possibilità tecnica non equivale a una strategia: disaster recovery e alta disponibilità devono essere progettati, provati e mantenuti.
Limiti e svantaggi dell’IaaS
Il principale limite di IaaS è anche il suo principale vantaggio: ti lascia molte decisioni.
Più controllo significa più lavoro operativo
Ogni macchina virtuale richiede una gestione.
Con poche istanze il problema può sembrare ridotto. Con decine o centinaia di sistemi, patch, immagini, configurazioni, monitoring, inventario e sicurezza possono diventare un’attività consistente.
Senza automazione e standardizzazione rischi di creare server apparentemente simili ma configurati in modi diversi.
Configurazioni errate e sicurezza del workload
Il provider può proteggere il data center, ma non può impedire ogni errore nella parte che controlli tu.
Credenziali esposte, permessi eccessivi, porte aperte, sistemi operativi non aggiornati, immagini obsolete o storage configurato male possono compromettere un workload anche sopra un’infrastruttura cloud perfettamente funzionante.
Il modello di responsabilità condivisa non serve a stabilire di chi sia “la colpa”. Serve a capire quali controlli non puoi permetterti di ignorare.
Costi variabili e risorse dimenticate
La flessibilità rende semplice creare risorse.
La stessa semplicità può rendere facile dimenticarle.
VM inattive, dischi non collegati, snapshot, IP pubblici, load balancer, traffico, ambienti di test e servizi collegati possono continuare a produrre costi.
Per questo un ambiente IaaS serio ha bisogno anche di governance finanziaria: tagging, budget, alert, ownership e revisione periodica delle risorse.
Vendor lock-in e portabilità
Una macchina virtuale standard può sembrare molto portabile.
L’infrastruttura reale raramente è composta soltanto da una VM.
Quando aggiungi sistemi IAM proprietari, load balancer, storage, database, code, monitoring, networking, autoscaling e API specifiche, la migrazione verso un altro provider può diventare molto più complessa.
Non significa che i servizi proprietari vadano evitati.
Significa che la portabilità ha un costo e deve essere valutata prima, non scoperta quando vuoi uscire dalla piattaforma.
Quanto costa un’infrastruttura IaaS
Uno degli errori più comuni è confrontare il prezzo di una VM cloud con il prezzo di un server fisico e concludere che uno dei due sia “più economico”.
Il costo reale è più articolato.
La documentazione dei prezzi Amazon EC2, per esempio, permette di capire come compute e altri componenti dell’ambiente contribuiscano alla spesa complessiva. La VM non coincide con l’intera fattura cloud.
Compute, storage, rete e trasferimento dati
Un modello semplificato può essere:
compute + storage + rete + traffico + IP + backup + servizi collegati = costo infrastrutturale
A questo vanno aggiunti i costi umani.
Un ambiente IaaS deve essere amministrato. Se per risparmiare sul servizio devi dedicare molte ore ogni mese a patch, incidenti e attività manuali, quella spesa appartiene al TCO anche se non compare nella fattura del provider.
On-demand, commitment e capacità spot
I provider offrono normalmente più modelli di acquisto.
La capacità on-demand privilegia la flessibilità: utilizzi risorse senza un impegno lungo.
Le formule a commitment permettono invece di ottenere condizioni differenti in cambio di un consumo o di una durata concordati.
La capacità spot o preemptible utilizza risorse disponibili secondo condizioni specifiche, accettando però che possano essere interrotte. Ha quindi senso per workload progettati per tollerare questa eventualità, non semplicemente perché costa meno.
Perché pay-as-you-go non significa sempre spendere meno
Pay-as-you-go significa che la spesa segue l’utilizzo.
Non significa che l’utilizzo sarà efficiente.
Un server sovradimensionato che rimane acceso tutto il mese può costare più di un’alternativa progettata meglio. Una macchina ridimensionata correttamente e spenta quando non serve può invece utilizzare in modo molto più efficiente il modello a consumo.
La capacità di modificare rapidamente le risorse è quindi un vantaggio solo quando esistono processi che la governano.
TCO: cosa confrontare davvero con l’on-premise
Per confrontare IaaS e infrastruttura proprietaria dovresti considerare almeno:
| Voce | IaaS | On-premise |
|---|---|---|
| Acquisto hardware | sostituito dal servizio | diretto |
| Data center | incluso nel servizio secondo il contratto | diretto o esternalizzato |
| Energia e raffreddamento | provider | cliente/data center |
| Manutenzione fisica | provider | cliente/fornitore |
| Sistema operativo | cliente secondo il servizio | cliente |
| Applicazioni | cliente | cliente |
| Capacità inutilizzata | possibile costo a consumo | capitale già investito |
| Espansione | provisioning di nuove risorse | nuovo hardware |
| Competenze operative | necessarie | necessarie |
| Uscita/migrazione | da pianificare | da pianificare |
Il confronto corretto riguarda quindi costo, rischio, velocità e competenze, non soltanto il prezzo della CPU.
Esempi di servizi IaaS
I grandi cloud provider offrono servizi che rientrano chiaramente nel modello Infrastructure as a Service.
| Provider | Servizio | Esempio di utilizzo |
|---|---|---|
| AWS | Amazon EC2 | macchine virtuali per applicazioni e workload |
| Microsoft Azure | Azure Virtual Machines | VM Linux e Windows |
| Google Cloud | Compute Engine | VM autogestite sull’infrastruttura Google |
| Oracle Cloud Infrastructure | OCI Compute | macchine virtuali e bare metal |
Google descrive Compute Engine come prodotto IaaS con VM autogestite, mentre Azure Virtual Machines e OCI Compute rappresentano lo stesso tipo di problema infrastrutturale con cataloghi e caratteristiche differenti.
Questi esempi non sono una classifica.
La scelta del provider deve arrivare dopo la definizione dei requisiti: regioni, workload, rete, compliance, competenze, servizi collegati, supporto e modello di costo.
Quando viene utilizzato IaaS: i principali casi d’uso
IaaS ha senso soprattutto quando il problema richiede controllo infrastrutturale senza giustificare la proprietà diretta dell’hardware.
Migrazione lift-and-shift
Un’applicazione esistente può dipendere da un determinato sistema operativo, da configurazioni specifiche o da componenti difficili da sostituire.
In questi casi una migrazione verso VM cloud può essere meno invasiva di una riscrittura immediata verso PaaS o serverless.
Questo approccio viene spesso chiamato lift-and-shift o rehosting.
Riduce la trasformazione iniziale, ma non bisogna confonderlo con la fine del percorso: un’applicazione trasferita su VM può continuare ad avere gli stessi limiti architetturali che aveva nel data center precedente.
Hosting di applicazioni con requisiti personalizzati
IaaS è adatto quando devi controllare runtime, servizi di sistema, networking o altre impostazioni che una piattaforma più gestita non espone.
Potresti dover installare un software particolare, utilizzare una versione specifica del sistema operativo o creare una topologia di rete personalizzata.
In questi casi il controllo aggiuntivo non è un vezzo: è un requisito.
Ambienti di sviluppo e test
Un ambiente temporaneo è uno dei casi in cui il provisioning rapido produce un vantaggio immediato.
Puoi creare infrastrutture per test, QA o staging quando servono e rimuoverle quando il lavoro è concluso.
Automazione e Infrastructure as Code rendono questo scenario ancora più interessante perché permettono di ricreare configurazioni coerenti invece di mantenere server di test accesi permanentemente.
Backup e disaster recovery
IaaS può fornire infrastrutture da utilizzare come destinazione di backup, capacità di recovery o ambiente secondario.
Ma il cloud non decide automaticamente RPO e RTO, non verifica da solo che il ripristino funzioni e non stabilisce quali dati siano davvero critici.
Queste rimangono decisioni architetturali e aziendali.
Workload variabili, HPC e calcolo intensivo
Alcuni carichi richiedono grandi quantità di CPU, RAM o acceleratori solo per determinati periodi.
Acquistare hardware dimensionato per il picco può significare lasciarlo inutilizzato per gran parte del tempo.
IaaS permette di associare la capacità al workload con maggiore flessibilità, purché l’applicazione possa realmente sfruttare questa elasticità.
IaaS nel cloud moderno: container, Kubernetes e serverless
Il modello IaaS/PaaS/SaaS rimane utile, ma non descrive ogni servizio cloud moderno con confini perfetti.
I cataloghi dei provider affiancano oggi macchine virtuali IaaS a servizi di container, piattaforme gestite e soluzioni serverless. Per questo l’etichetta conta meno della domanda operativa: quale parte dello stack continua a essere sotto la tua responsabilità?
Quando IaaS resta il layer sottostante
Anche quando lavori con container, per esempio attraverso un workflow basato su Docker, l’infrastruttura continua a esistere.
Se installi e amministri direttamente Kubernetes sopra un gruppo di VM, stai ancora assumendoti molta responsabilità infrastrutturale.
Se utilizzi invece un Kubernetes gestito, il provider può farsi carico di una parte maggiore del control plane e delle attività operative. È qui che entra nel quadro il CaaS (Containers as a Service): mantieni i container come unità di deployment, ma deleghi al provider una parte dell’infrastruttura e dell’orchestrazione necessarie a eseguirli.
CaaS non coincide però con il solo Kubernetes gestito, perché può comprendere anche orchestratori gestiti e piattaforme container con livelli di astrazione differenti. Il risultato si colloca quindi in una zona più sfumata rispetto al diagramma classico IaaS/PaaS/SaaS.
Il risultato si colloca in una zona più sfumata rispetto al diagramma classico.
Container e Kubernetes gestito
I container aumentano la portabilità dell’unità applicativa, ma non eliminano la necessità di compute, rete, storage, sicurezza e orchestrazione.
Un servizio Kubernetes gestito trasferisce alcune attività al provider. Quanto venga realmente gestito cambia da piattaforma a piattaforma.
Per questo l’etichetta commerciale conta meno dell’elenco concreto delle responsabilità.
Quando serverless riduce ulteriormente la gestione infrastrutturale
Con serverless il team smette normalmente di provisionare direttamente le VM che eseguono il codice.
Il provider gestisce più aspetti di provisioning e scaling e il cliente lavora a un livello di astrazione superiore.
Se stai creando una nuova applicazione e non hai bisogno di controllare il sistema operativo, partire da IaaS soltanto perché “offre più libertà” può aggiungere complessità senza produrre valore.
Quando scegliere IaaS e quando preferire PaaS, SaaS o on-premise
La scelta migliore emerge dal livello di controllo che serve realmente.
| Scenario | Modello da valutare per primo |
|---|---|
| Devi controllare OS, runtime e networking | IaaS |
| Devi migrare software legacy con poche modifiche | IaaS |
| Vuoi creare applicazioni senza amministrare VM e OS | PaaS |
| Vuoi utilizzare direttamente un software pronto | SaaS |
| Hai hardware locale non sostituibile o requisiti fisici specifici | on-premise / hybrid |
| Il workload è event-driven e non richiede server persistenti | serverless |
| Vuoi hardware dedicato ma provisioning cloud | bare metal IaaS |
Non significa che la prima opzione della tabella sia sempre quella corretta.
Un’applicazione può utilizzare contemporaneamente VM IaaS, database gestiti, object storage, code, servizi serverless e software SaaS.
L’obiettivo non è scegliere una sigla unica per tutta l’architettura. È delegare ogni componente al livello più sensato.
Come scegliere un servizio IaaS
La comparazione tra provider dovrebbe iniziare dai requisiti, non dalla loro homepage.
Workload e livello di controllo richiesto
Prima domanda: perché ti serve IaaS?
Se la risposta è soltanto “perché dobbiamo andare sul cloud”, il requisito non è ancora abbastanza preciso.
Definisci:
- sistemi operativi necessari;
- CPU e memoria;
- storage;
- pattern di traffico;
- requisiti di rete;
- dipendenze applicative;
- disponibilità richiesta;
- necessità di GPU o hardware particolare;
- modalità di scaling.
Solo dopo ha senso confrontare le offerte.
Regioni, data residency e compliance
La localizzazione dell’infrastruttura può avere conseguenze tecniche, operative e normative.
Non basta controllare se un provider “ha data center in Europa”.
Devi capire quali regioni supportano i servizi necessari, dove vengono archiviati dati e backup, quali trasferimenti avvengono e quali requisiti derivano dal tuo settore, dai contratti e dalla normativa applicabile.
Networking, performance e disponibilità
Le prestazioni non dipendono soltanto dalla CPU.
Latenza, storage, throughput, architettura di rete e distanza dagli utenti possono cambiare radicalmente il comportamento di un’applicazione.
Allo stesso modo, uno SLA del provider non sostituisce un’architettura resiliente.
Devi stabilire cosa succede se perdi:
- una VM;
- una zona;
- un servizio;
- una regione, quando il rischio lo giustifica.
Sicurezza, IAM e supporto
Valuta il sistema di identity and access management, le possibilità di segmentazione della rete, i log disponibili, la gestione delle chiavi, gli strumenti di monitoring e le modalità di risposta agli incidenti.
Guarda anche il supporto.
Quando un’infrastruttura diventa critica, la differenza tra documentazione self-service e accesso rapido a un team competente può avere un valore molto maggiore di una piccola differenza nel prezzo della VM.
API, Infrastructure as Code e automazione
Un provider IaaS dovrebbe essere valutato anche come piattaforma programmabile.
API coerenti, CLI, provider per strumenti Infrastructure as Code e servizi di automazione possono ridurre molto il lavoro operativo.
La facilità con cui crei una VM manualmente è importante durante una prova.
La facilità con cui governi centinaia di risorse in modo ripetibile è molto più importante quando l’ambiente cresce.
Cost visibility, portabilità ed exit strategy
Prima di migrare un workload dovresti sapere anche come potresti spostarlo altrove.
Non significa progettare tutto per il provider meno comune o rinunciare a ogni servizio proprietario.
Significa conoscere le dipendenze che stai introducendo.
Documenta almeno:
- dati da esportare;
- immagini e configurazioni;
- dipendenze proprietarie;
- meccanismi IAM;
- networking;
- servizi gestiti;
- modalità di backup;
- Infrastructure as Code;
- costi e tempi plausibili di uscita.
L’exit strategy non serve perché prevedi di abbandonare il provider. Serve perché una dipendenza conosciuta è gestibile; una dipendenza scoperta troppo tardi diventa un vincolo.
Domande frequenti sull’IaaS
IaaS e cloud computing sono la stessa cosa?
No. Cloud computing è il modello generale con cui risorse informatiche vengono erogate on demand. IaaS è uno dei modelli di servizio che può essere costruito all’interno di quell’ecosistema.
Amazon EC2 è un servizio IaaS?
Sì. AWS classifica Amazon EC2 come Infrastructure as a Service e lascia al cliente la gestione del sistema operativo guest, delle applicazioni installate e di numerosi controlli di configurazione e sicurezza. Puoi approfondire la divisione dei compiti nel modello di responsabilità condivisa AWS.
IaaS è sempre public cloud?
No. IaaS descrive che cosa viene fornito e quali responsabilità vengono trasferite, mentre public, private e hybrid cloud descrivono il modello di deployment. I due concetti rispondono a domande diverse.
IaaS include automaticamente backup e disaster recovery?
No. Il provider può offrire snapshot, backup, replica e altri servizi, ma devi verificare cosa viene realmente attivato, configurare le policy necessarie e testare il ripristino.
IaaS è più economico di un server tradizionale?
Non necessariamente. Dipende da utilizzo, dimensionamento, traffico, storage, servizi collegati, competenze operative e orizzonte temporale. Il confronto corretto deve considerare il Total Cost of Ownership, non soltanto il prezzo della VM.
Conclusione
IaaS ha senso quando vuoi delegare l’hardware senza delegare il controllo dell’ambiente.
È una buona scelta per workload che richiedono configurazioni specifiche, migrazioni di sistemi esistenti, networking personalizzato o un livello di libertà che PaaS e SaaS non possono offrire.
Quella libertà, però, ha un prezzo operativo. Sistema operativo, patch, applicazioni, identità, rete, backup e costi rimangono in buona parte problemi tuoi.
Per questo la domanda migliore non è “IaaS è meglio di PaaS o SaaS?”.
È:
quale parte dello stack abbiamo davvero bisogno di controllare e quale possiamo affidare al provider senza perdere qualcosa che crea valore?
Quando la risposta è il sistema operativo e l’infrastruttura logica, IaaS è probabilmente il livello giusto. Quando quel controllo non serve, salire verso servizi più gestiti può ridurre complessità, rischio e lavoro quotidiano.