Che cos'è IaaS (Infrastructure as a Service)?

IaaS è un modello cloud che affitta a richiesta risorse di calcolo fondamentali – macchine virtuali, archiviazione, rete – con fatturazione a consumo. La definizione del NIST traccia il confine con precisione: il provider controlla l’infrastruttura fisica; il cliente controlla sistemi operativi, archiviazione e applicazioni distribuite. È il piolo più basso della scala del cloud – quello che sostituisce l’acquisto dei server con il loro affitto.

Punti chiave

Che aspetto ha l’uso di IaaS

L’esperienza per eccellenza è una macchina in pochi minuti – seguita da tutto ciò che una macchina ha sempre richiesto:

# Minuto uno: si affitta la macchina
$ cloud compute create --size medium --image ubuntu-24.04
   ✓ vm-7f3a running — 203.0.113.40

# Dal minuto due in poi: tutto il resto resta in casa
$ ssh [email protected]
$ apt update && apt upgrade          # le patch: in casa
$ apt install nginx postgresql       # lo stack: in casa
$ ufw allow 443 && configure-tls…    # la sicurezza: in casa
$ crontab -e                         # backup, rotazione, monitoring: in casa

Questo scambio – hardware in pochi minuti, operazioni per sempre – è tutto il modello. Per contrasto, ecco lo stesso obiettivo “mettere in piedi un backend” in cima alla scala, dove l’infrastruttura non affiora mai:

// JavaScript / Node.js — Back4app JS SDK
const note = new Parse.Object('Note');
note.set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched, no firewall rules

// Flutter / Dart — Back4app Flutter SDK
final note = ParseObject('Note')
  ..set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched

// iOS / Swift — Back4app Swift SDK
var note = Note()
note.text = "Shipped without touching a VM"
note.save { result in
  if case .success = result { print("saved — zero infrastructure managed") }
}

// Android / Kotlin — Back4app Android SDK
val note = ParseObject("Note").apply {
  put("text", "Shipped without touching a VM")
}
note.saveInBackground { e ->
  if (e == null) Log.d("Note", "saved — zero infrastructure managed")
}

Chi gestisce cosa

Questa divisione è anche il modello di sicurezza: il provider mette in sicurezza il cloud, il cliente mette in sicurezza tutto ciò che sta dentro. Gli errori di configurazione sul lato cliente – bucket di archiviazione aperti, regole di firewall permissive, sistemi senza patch – sono la prima causa delle violazioni nel cloud, ed è per questo che il riquadro “gestisce il cliente” merita più rispetto di quanto se ne prenda di solito.

IaaS vs. PaaS vs. BaaS vs. on-premises

Una precisazione che ritorna in ogni confronto “IaaS vs.”: i modelli serverless non sono una quarta colonna dello stesso tipo – astraggono l’unità di calcolo (per invocazione) invece del livello di gestione, ed è per questo che una piattaforma serverless può a sua volta girare su IaaS al di sotto.

Casi d’uso tipici

• Migrazioni lift-and-shift. Le applicazioni server esistenti si spostano su VM affittate quasi senza modifiche – stesso stack, niente più cicli di rinnovo dell’hardware.
• Stack su misura e legacy. Runtime inusuali, software sotto licenza o messa a punto al livello del sistema operativo che le piattaforme gestite non permettono.
• Controllo imposto dalla conformità. Regimi normativi che richiedono di sapere e configurare esattamente che cosa gira sotto l’applicazione.
• Carichi ad alte prestazioni e specializzati. Flotte di GPU, elaborazione dati su larga scala e tutto ciò che ha requisiti a forma di hardware.
• Disaster recovery e capacità di picco. Ambienti di standby e margine per i picchi di traffico che sarebbe rovinoso possedere come hardware a riposo.

Conviene costruire su IaaS? Matrice decisionale

Il motivo che vale la pena interiorizzare: IaaS raramente sbaglia quando si tratta di spostare sistemi esistenti, e raramente ha ragione quando si tratta di avviarne di standard – un backend applicativo nuovo assemblato a mano su VM sono settimane di lavoro che i pioli più alti consegnano prima di pranzo.

Limiti e trade-off

• Le operazioni restano in casa. Applicazione delle patch, hardening, scalabilità, backup, monitoring: il runbook sopravvive intatto, è cambiato solo l’hardware sotto di esso.
• Lo shock da fattura è un problema di competenze che si eredita. Istanze a riposo, VM sovradimensionate e archiviazione dimenticata fatturano ventiquattr’ore al giorno; la gestione dei costi diventa una disciplina permanente.
• L’egress è il pedaggio di uscita. I dati entrano gratis ed escono a pagamento – un meccanismo che si accumula in silenzio fino a diventare vendor lock-in man mano che i dati si depositano.
• Gli errori di configurazione della sicurezza sono la modalità di guasto numero uno. La metà del provider nella responsabilità condivisa è eccellente; le violazioni avvengono in modo schiacciante nella metà del cliente.
• La tassa sulle competenze. Gestire bene l’infrastruttura richiede persone che la gestiscano bene – un requisito di assunzione che la pagina dei prezzi a consumo non menziona.

IaaS su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Rispetto a IaaS è l’estremo opposto dello scambio: nessun accesso al sistema operativo, nessun controllo sull’infrastruttura – e nessun runbook, perché l’intero riquadro “gestisce il cliente” del diagramma qui sopra è lavoro della piattaforma. I team che hanno bisogno di infrastruttura grezza per un singolo carico specializzato possono farla girare accanto a un backend BaaS; i team che costruiscono backend applicativi standard possono saltare del tutto il piolo più basso. E poiché lo stack è open source, scendere la scala in un secondo momento – ospitare in proprio la piattaforma su un’infrastruttura IaaS controllata direttamente – resta un’opzione reale, non una riscrittura.