Virtualizzazione vs container: differenze e quando usare cosa

"Container o macchina virtuale?" viene posta come una scelta tra alternative, e nella pratica quasi nessuno sceglie: le infrastrutture reali usano entrambi, uno dentro l'altro. Capire cosa isola davvero ciascuno chiarisce sia quando servono sia perché convivono. In questo articolo trovi la differenza che conta.

Cosa isolano

È l'unica differenza che genera tutte le altre.

Una macchina virtuale virtualizza l'hardware. L'hypervisor simula processore, memoria, disco e rete, e sopra ci gira un sistema operativo completo con il proprio kernel.

Un container virtualizza il sistema operativo. Non c'è un kernel dedicato: il container usa quello dell'host, e l'isolamento riguarda i processi, il file system e la rete.

Visivamente:

MACCHINE VIRTUALI          CONTAINER
┌─────┐ ┌─────┐            ┌─────┐ ┌─────┐
│ App │ │ App │            │ App │ │ App │
├─────┤ ├─────┤            ├─────┴─┴─────┤
│ SO  │ │ SO  │            │   Runtime   │
├─────┴─┴─────┤            ├─────────────┤
│ Hypervisor  │            │ SO dell'host│
├─────────────┤            ├─────────────┤
│  Hardware   │            │  Hardware   │
└─────────────┘            └─────────────┘

Il container non porta un sistema operativo: porta l'applicazione e le sue dipendenze. Ecco perché pesa megabyte invece di gigabyte e si avvia in un secondo invece che in un minuto.

Le conseguenze pratiche

	Macchina virtuale	Container
Kernel	Proprio	Condiviso con l'host
Dimensione	GB	MB
Avvio	Minuti	Secondi
Densità	Decine per macchina	Centinaia
Isolamento	Forte	Del processo
Sistemi diversi	Sì	Stesso kernel
Sovraccarico	Significativo	Minimo

Due conseguenze meritano di essere esplicitate:

I container Linux richiedono un kernel Linux. Su Windows e macOS, Docker esegue una macchina virtuale Linux sotto — motivo per cui su quei sistemi i container consumano più di quanto sembri.

La densità cambia l'economia. Su una macchina fisica che ospita dieci macchine virtuali, i container arrivano a centinaia. È il motivo per cui le architetture a microservizi sono diventate praticabili.

La sicurezza

Il punto su cui la differenza è più importante e meno raccontata.

Con le macchine virtuali, l'isolamento è dato dall'hypervisor, che ha una superficie di attacco ridotta e ben delimitata. Uscire da una macchina virtuale per raggiungere l'host è considerato molto difficile.

Con i container, l'isolamento è dato dal kernel condiviso. Se una vulnerabilità del kernel permette di aggirare quell'isolamento, il container compromesso può raggiungere l'host e gli altri container.

La conseguenza operativa: per eseguire codice di cui non ti fidi — codice di terzi, ambienti multi-cliente con isolamento richiesto per contratto o normativa — i container da soli non sono considerati sufficienti.

Le risposte pratiche a questo problema sono due: mettere i container dentro macchine virtuali separate, oppure usare tecnologie di isolamento più forti che stanno a metà strada.

E per i container che gestisci tu, valgono comunque le regole di base: non eseguire come root dentro il container, limitare i permessi, partire da immagini ufficiali. Il principio è quello del privilegio minimo che descrivo in guardrail e sicurezza.

Quando usare cosa

Container, quando:

• Distribuisci applicazioni — è il caso d'uso principale
• Ti serve un ambiente di sviluppo riproducibile
• Vuoi avviare e fermare istanze in fretta
• Hai molti servizi piccoli
• Ti serve che "funzioni uguale ovunque"

Macchina virtuale, quando:

• Ti serve un sistema operativo diverso da quello dell'host
• L'isolamento deve essere forte per ragioni di sicurezza o normative
• Devi simulare un ambiente completo, kernel compreso
• Il software richiede accesso a basso livello
• Vuoi poter fare istantanee dello stato

E molto spesso: entrambi. L'architettura standard nel cloud è container che girano dentro macchine virtuali — isolamento forte tra clienti diversi, densità ed efficienza all'interno.

Il malinteso più comune

"I container sono macchine virtuali leggere."

Non lo sono, e la differenza non è di grado ma di natura: un container non è un computer, è un processo isolato.

Da qui discendono cose che sorprendono chi arriva con quell'idea in testa:

Un container non ha un ciclo di avvio. Non "si accende": esegue un processo. Quando quel processo termina, il container si ferma.

Non è pensato per contenere più servizi. L'idea di metterci dentro applicazione, database e server web insieme — come si farebbe su una macchina virtuale — va contro il modello.

I dati non persistono. Quello che scrivi dentro un container sparisce quando lo ricrei, a meno che non usi volumi espliciti. È l'errore che fanno tutti la prima volta, e il motivo per cui un database va gestito con attenzione.

Il quadro pratico è in cos'è Docker e cos'è un container.

L'aspetto economico

Vale la pena notarlo perché spiega le scelte delle aziende.

Le macchine virtuali costano in risorse: ogni sistema operativo consuma memoria e disco anche quando non fa nulla. Dieci macchine virtuali con 2 GB ciascuna occupano 20 GB, gran parte dei quali per far girare dieci copie dello stesso sistema.

I container condividono tutto quello che possono. Dieci container della stessa applicazione condividono i livelli comuni dell'immagine.

Su scala, la differenza è sostanziale — ed è la ragione economica per cui l'adozione dei container è stata così rapida.

Su piccola scala, invece, non cambia molto: su un VPS con un paio di applicazioni, la scelta si fa per comodità, non per risparmio.

In sintesi

La differenza sta in cosa viene isolato: la macchina virtuale virtualizza l'hardware e porta un kernel proprio; il container isola i processi e condivide il kernel dell'host.

Da lì tutto il resto: i container sono più leggeri, più veloci e più densi; le macchine virtuali offrono isolamento più forte e la possibilità di eseguire sistemi diversi.

Sulla sicurezza la differenza conta davvero: per eseguire codice di cui non ti fidi, o per isolare clienti diversi, i container da soli non bastano.

E il malinteso da smontare: un container non è una macchina virtuale leggera, è un processo isolato. Non ha ciclo di avvio, non è pensato per più servizi insieme, e non conserva i dati se non glielo dici esplicitamente.

Nella pratica non si sceglie: container dentro macchine virtuali è l'architettura standard di quasi tutto il cloud.