Macchina virtuale, container o bare metal? La modalità adatta dipende dall’applicazione, dal supporto del produttore e da chi la gestirà nel tempo. Un container non rende automaticamente manutenibile un vecchio ERP. Un server fisico non è automaticamente più veloce. E una VM non giustifica trascurare backup e aggiornamenti. DAXS parte quindi dal carico concreto: sistema operativo, dipendenze, dati, ripartenza e carico misurabile.
Il confronto risponde alla domanda dove convenga eseguire un servizio. Se la scelta dei container applicativi è già fatta, segue un’altra domanda: Docker Compose o Kubernetes per la gestione? Sono due decisioni da prendere separatamente.
Che cosa viene separato?
Una macchina virtuale riceve hardware virtuale e un proprio sistema operativo guest. Permette, per esempio, un guest Windows Server accanto a guest Linux sullo stesso hypervisor. La VM è un’unità ben delimitata per patch del sistema, snapshot e ripristino; l’applicazione deve comunque essere salvata in modo coerente. In Proxmox VE questa modalità si basa su KVM.
Un container condivide il kernel dell’host. Vanno distinte due forme: un container Proxmox LXC è un sistema Linux leggero, mentre un container applicativo OCI racchiude normalmente una singola applicazione con le sue dipendenze. Nessuno dei due è una VM Windows o offre un kernel isolato separato. Per OCI servono anche build delle immagini curate, un registry, aggiornamenti di sicurezza e una soluzione esplicita per i dati persistenti. Una VM Linux come host dei container può delimitare utilmente gestione, backup e permessi; non è obbligatoria tecnicamente in ogni scenario.
Bare Metal esegue sistema operativo e applicazione direttamente su un server fisico. Può essere adatto a vincoli del produttore, hardware speciale o requisiti di latenza dimostrati. Riduce però il consolidamento di quell’host e lega maggiormente manutenzione, ricambi e ripartenza alla macchina fisica. Anche qui contano misure e impegni di supporto, non affermazioni generiche sulle prestazioni.
Cinque carichi tipici e il primo percorso di verifica
I percorsi seguenti sono punti di partenza per una prova, non approvazioni generali di prodotti. Documentazione del produttore, contratto di licenza e prova di ripristino rendono la decisione solida.
| Applicazione | Percorso di verifica | Domanda critica |
|---|---|---|
| ERP Windows con database e supporto del produttore | VM come naturale punto di partenza | Quale combinazione di sistema guest, hypervisor, SQL e licenze è effettivamente supportata? |
| Servizio web Linux sviluppato internamente con build riproducibile | Container applicativo OCI, eventualmente su VM Linux | Chi crea e aggiorna le immagini, verifica le vulnerabilità e gestisce registry, segreti e log? |
| Appliance Linux di un produttore | Verificare prima una VM supportata | Il produttore accetta virtualizzazione, dispositivi virtuali e percorso di backup/ripristino previsto? |
| Database con carico elevato in scrittura | VM o bare metal in base alle misure; container solo con persistenza collaudata | Come si comportano latenza p95/p99, IOPS, replica e ripristino coerente durante i picchi? |
| Servizio con dongle, scheda speciale o accesso diretto ai dispositivi | Provare il passthrough della VM; considerare bare metal | Supporto, assegnazione dei dispositivi e ripartenza restano possibili dopo la sostituzione dell’host? |
Un container per database non è sbagliato in sé. Il suo filesystem scrivibile non è però il posto per dati che devono sopravvivere alla sostituzione del container. Volumi, coerenza, backup e ripristino vanno pianificati esplicitamente. Viceversa, una VM non trasforma un backup non collaudato del database in una ripartenza affidabile.
Sei verifiche per decidere
- Produttore e licenza: Verificare per iscritto sistemi, hypervisor, runtime dei container e vincoli hardware supportati. I diritti Windows Server dipendono, fra l’altro, da edizione, core licenziati, numero di ambienti virtuali e contratto; «una VM» non implica un prezzo fisso.
- Isolamento e permessi: Quale servizio può influenzarne un altro? I container hanno namespace e limiti alle risorse, ma condividono il kernel dell’host. Runtime, privilegi, mount, rete e aggiornamenti fanno parte della verifica di sicurezza.
- Misurare le prestazioni: Rilevare con dati reali carico CPU, RAM e I/O, latenza p95/p99, picchi e finestre batch. Scegliere bare metal solo per un presunto «overhead di virtualizzazione» può impegnare capacità costosa senza risolvere il problema reale di storage o rete.
- Dati e ripristino: Definire RPO e RTO per servizio. Provare un ripristino completo su un altro host, includendo database, configurazione, credenziali e dipendenze.
- Modifiche e personale: Chi applica le patch al guest o al kernel host? Chi ricrea le immagini? Chi sa gestire di notte un rollback fallito o un cambio hardware? Le competenze disponibili limitano il numero di piattaforme gestibili sensatamente in parallelo.
- Dominio di guasto: Considerare separatamente host, storage, rete e backup. Né un solo server bare metal né più container su un unico host diventano altamente disponibili grazie al loro nome.
Confrontare l’impegno prima di promettere risparmi
Su tre o cinque anni, confrontare in ogni colonna la stessa applicazione con uguale carico e obiettivo di ripartenza. Registrare migrazione e avvio iniziali, hardware e ricambi, diritti di sistemi e applicazioni, supporto di hypervisor o runtime, energia, backup, monitoraggio e ore annue del personale. Per OCI si aggiungono, ad esempio, pipeline di build, registry, manutenzione delle immagini ed eventuale orchestrazione. Bare metal può richiedere hardware sostitutivo e finestre di manutenzione diverse. Per le VM contano capacità host e sistemi guest. Un cluster esistente è «gratuito» per il nuovo servizio solo se riserve, licenze e risorse operative sono realmente disponibili.
La formula di base verificabile è: costo totale su n anni = avvio e migrazione iniziali + n × (licenze annue + supporto + energia + backup + ore operative × tariffa oraria interna) + rinnovo pianificato. n è tre o cinque. Nessuna modalità offre un vantaggio generale senza offerte concrete, misure di carico e condizioni di supporto. Nel confronto deve emergere anche il costo del mancato raggiungimento di RPO/RTO, senza escluderlo dal calcolo.
Come DAXS definirebbe la modalità operativa
DAXS preparerebbe prima un breve elenco di applicazioni con responsabile, flusso dati, supporto del produttore, dipendenze e obiettivo di ripristino. Seguono prove tecniche su due candidati realistici: carico simile alla produzione, patch e upgrade, guasto di host o dispositivo e ripristino su un’altra macchina. Il risultato è una decisione motivata per applicazione, non l’obbligo di spostare tutti i servizi sulla stessa piattaforma.
Le VM Windows e Linux esistenti si possono spesso valutare gradualmente; Proxmox in azienda descrive la base di virtualizzazione. Se i container convincono, il confronto tra Docker Compose e Kubernetes aiuta nel passo successivo. Per un carico concreto, tramite Contatti DAXS può tradurre supporto, misure e ripristino in una scelta operativa condivisa.
Fonti: Proxmox VE: KVM e LXC · Docker Engine: modello di sicurezza · Docker Engine: dati persistenti · Microsoft: Windows Server Virtualization Licensing Guidance.
