In pratica la giusta unità di decisione è il carico di lavoro. Un database con carico piatto e prevedibile, un sito di marketing con picchi di traffico settimanali e un job di analisi batch che gira due volte al mese hanno esigenze molto diverse, e forzarli su un unico modello significa di solito pagare troppo per alcuni e servire male gli altri.
Questa guida confronta server dedicati bare metal, server privati virtuali (VPS) e cloud gestito secondo i criteri che contano di più per chi acquista infrastruttura: costanza delle prestazioni, costi con carico stabile e variabile, isolamento, conformità, scalabilità e impegno operativo richiesto da ciascun modello.
Tre modelli, tre promesse diverse
Bare metal indica un server fisico assegnato a un solo cliente. Si dispone di ogni core, di ogni gigabyte di memoria e dell'intero throughput dei dischi locali. Non c'è alcun hypervisor tra il sistema operativo e l'hardware, a meno di installarne uno.
Un VPS è una macchina virtuale su un host fisico condiviso, gestita da un hypervisor come KVM. Si riceve una quota definita di CPU, memoria e storage, con accesso root al proprio sistema operativo. Il provider gestisce l'host; tutto ciò che si trova all'interno del guest è responsabilità del cliente.
Il cloud gestito è un livello di servizio sopra un'infrastruttura virtualizzata, che sia la piattaforma del fornitore o un grande cloud pubblico, in cui un team gestisce lo stack al posto tuo: patching, backup, monitoraggio, scalabilità e spesso caching, ricerca e distribuzione dei contenuti. Si cede un po' di controllo e di efficienza dei costi in cambio di un carico operativo minore e di un'elasticità più rapida.
Ciascuno fa una promessa diversa, e la vera domanda è quale promessa serva davvero a ogni carico di lavoro.
Costanza delle prestazioni
Su bare metal le prestazioni sono una proprietà dell'hardware scelto. Una query che oggi impiega 40 ms impiegherà 40 ms anche la settimana prossima a parità di carico, perché nessun altro tenant compete per la stessa cache, la stessa banda di memoria o la stessa coda del disco.
Gli ambienti virtualizzati aggiungono due fonti di variabilità. La prima è l'hypervisor stesso, che costa tipicamente qualche punto percentuale di throughput della CPU e aggiunge un piccolo overhead all'I/O. La seconda, più rilevante, è la contesa: le altre macchine virtuali sullo stesso host condividono core fisici, banda di memoria, interfacce di rete e storage. Sui guest Linux lo si vede direttamente nella metrica steal time (la colonna st in top o vmstat), che indica quanto tempo la tua CPU virtuale ha atteso una CPU fisica.
L'NVMe locale su un server dedicato offre centinaia di migliaia di IOPS con latenze nell'ordine delle decine di microsecondi. Lo storage a blocchi di rete aggiunge un round trip di rete ma offre volumi che sopravvivono a un guasto hardware e possono crescere ben oltre un singolo chassis.
- Scegliere il bare metal quando la latenza p99 è una metrica contrattuale o di fatturato, quando il carico di lavoro satura CPU o disco per lunghi periodi, oppure quando serve il pieno controllo di funzionalità hardware come la topologia NUMA e specifici set di istruzioni.
- Un VPS è sufficiente per applicazioni web, API, runner CI, ambienti di staging e strumenti interni, dove qualche millisecondo di variabilità è invisibile agli utenti.
- Il cloud gestito è adatto quando il livello applicativo scala orizzontalmente e assorbe la variabilità aggiungendo istanze, anziché richiedere che ogni istanza sia veloce.
Costi con carico stabile e con carico variabile
I confronti di costo sbagliano quando confrontano i prezzi di listino anziché l'utilizzo. La domanda utile è semplice: quale frazione delle ore pagate viene effettivamente utilizzata?
Un server dedicato è un costo mensile fisso. Se il carico di lavoro lo tiene occupato 24 ore su 24, il costo effettivo per unità di calcolo è di solito il più basso dei tre modelli, perché non si paga la capacità di riserva del provider, il suo livello di orchestrazione o l'elasticità. Se lo stesso server resta al 10 percento di utilizzo, quel costo fisso diventa elevato.
Paghi un sovrapprezzo orario per il diritto di smettere di pagare quando la domanda cala. Per carichi di lavoro con picchi marcati, come il retail stagionale, la biglietteria per eventi o la reportistica di fine mese, quel sovrapprezzo è spesso più conveniente che possedere abbastanza capacità fissa per il picco.
I dati trasferiti in uscita da molte piattaforme cloud vengono fatturati a gigabyte, mentre i server dedicati sono spesso venduti con una porta a traffico illimitato. Una porta da 1 Gbps trasferisce circa 10 TB al giorno a pieno carico, quindi un carico di lavoro di media, backup o distribuzione di dati che spinge decine di terabyte al mese può vedere i costi di traffico superare la fattura del calcolo.
Un metodo pratico consiste nell'esportare l'utilizzo orario di CPU, memoria e rete di ogni carico di lavoro negli ultimi 90 giorni e confrontare la base (il livello sotto cui scende raramente) con il picco.
- Profilo piatto. Se il carico di base resta per la maggior parte del tempo sopra il 60-70 percento circa del picco, la capacità fissa su server dedicati o VPS di solito costa meno.
- Profilo con picchi. Se il picco è pari ad almeno tre volte la base e dura ore o giorni anziché mesi, per la quota sopra la base di solito conviene la capacità elastica del cloud.
- Profilo misto. La maggior parte dei sistemi di produzione è costituita da una base costante più dei picchi. Eseguire la base su capacità fissa e gestire i picchi nel cloud, secondo il pattern ibrido descritto più avanti in questa guida.
- Costi nascosti. Includere traffico in uscita, snapshot, load balancer, licenze software, livelli di supporto e ore di ingegneria, non solo i prezzi delle istanze.
Isolamento, sicurezza e conformità
La single tenancy è il modello di isolamento più forte disponibile, a meno di gestire una propria struttura. Su un server dedicato nessun codice di altri clienti gira sulla tua CPU, il che elimina un'intera classe di problemi legati ai side-channel e rende l'ambiente più semplice da spiegare ai revisori.
L'isolamento tramite virtualizzazione è maturo e adeguato per la stragrande maggioranza dei carichi di lavoro. Il rischio residuo è l'hardware condiviso, motivo per cui alcuni framework e alcune policy di sicurezza interne richiedono host dedicati per i sistemi più sensibili.
La conformità riguarda soprattutto controlli ed evidenze, non la piattaforma. Framework come PCI DSS, HIPAA e GDPR si concentrano su chi può accedere ai dati, dove sono conservati, come sono cifrati, come vengono registrate le modifiche e come vengono gestiti gli incidenti. Ciò che cambia è la ripartizione delle responsabilità condivise: su bare metal si è responsabili di quasi tutto ciò che sta sopra l'hardware, mentre nel cloud gestito il provider si fa carico di patch, backup e parte del monitoraggio, e quella ripartizione va documentata nel proprio insieme di controlli.
- Residenza dei dati. Verificare di poter scegliere il paese di ciascun server e che dati, backup e repliche non vengano spostati senza la propria approvazione.
- Evidenze sulle strutture. Chiedere quali certificazioni possiedono le strutture del data center e richiedere i report di cui i propri auditor avranno bisogno.
- Protezione della rete. Verificare se la mitigazione DDoS è inclusa sull'edge di rete o deve essere acquistata separatamente.
- Accessi e logging. Definire chi detiene l'accesso root o amministrativo, come vengono registrati gli accessi del personale del fornitore e con quale rapidità si viene informati di un incidente.
Scalabilità e impegno operativo
Scalare su bare metal è un esercizio di pianificazione. I fornitori moderni possono predisporre un server dedicato in pochi minuti a partire da configurazioni a stock, ma si scala comunque per macchine intere, e qualcuno deve configurarle e unirle al cluster.
La scalabilità di un VPS è più rapida e granulare: ridimensionare un piano, clonare un'immagine, aggiungere un nodo dietro un load balancer.
Il cloud gestito è pensato per l'elasticità. Gruppi di autoscaling, database gestiti, cache e content delivery network permettono all'applicazione di reagire al carico in pochi minuti senza intervento manuale.
L'impegno operativo è il fattore che gli acquirenti sottovalutano più spesso. Una flotta di server dedicati richiede patching del sistema operativo, aggiornamenti del kernel, attenzione al firmware, verifica dei backup, monitoraggio, gestione degli avvisi e reperibilità.
- Chiedere chi applica le patch. Per ogni carico di lavoro, indicare la persona o il team responsabile del sistema operativo, del middleware e del livello applicativo.
- Chiedere chi ripristina. Un backup che non è mai stato sottoposto a un test di ripristino è un'ipotesi, non un controllo.
- Chiedere chi interviene di notte. Definire per ciascun modello il percorso di reperibilità per un disco guasto alle 3 del mattino, prima che serva.
Architetture ibride su un'unica rete privata
Un pattern comune e duraturo colloca ogni tier dove si adatta meglio e collega i tier tramite una rete privata, così il traffico tra di essi non attraversa mai la rete internet pubblica.
- Livello dati su bare metal. Database primari, indici di ricerca e message broker girano su server dedicati con NVMe locale, dove I/O costante e costi fissi contano di più.
- Livello applicativo su VPS o cloud gestito. I server web e API stateless girano su istanze virtuali che possono essere ridimensionate, clonate o scalate automaticamente al variare della domanda.
- Picchi ed edge nel cloud gestito. Distribuzione dei contenuti, object storage e job batch o di analytics di breve durata usano capacità elastica che viene rilasciata al termine del job.
- Backup fuori dalla piattaforma primaria. Repliche e backup risiedono in una struttura separata, così che un singolo incidente non possa colpire sia la produzione sia le sue copie.
Mantieni il traffico del database e di replica su interfacce private o su una VLAN dedicata, cifralo comunque in transito e usa un unico piano di indirizzamento in tutti gli ambienti, così i servizi possono spostarsi da un modello all'altro senza rinumerazione.
Un approccio ibrido riduce anche il lock-in. Quando il nucleo con stato gira su Linux standard e software open source, e il livello elastico è definito come infrastructure as code, si possono spostare singoli carichi di lavoro da un modello all'altro man mano che il loro profilo di carico cambia, invece di migrare tutto in una volta.
Checklist decisionale
Applicare queste domande a ciascun carico di lavoro separatamente. Quando due o più risposte vanno nella stessa direzione, la scelta è di solito fatta.
- Profilo di carico. L'utilizzo è costante nell'arco delle 24 ore (bare metal o VPS), oppure ha picchi di un fattore tre o più (cloud gestito per i picchi)?
- Sensibilità alla latenza. La latenza p99 è una metrica di business? Se sì, preferire hardware dedicato per i componenti stateful.
- Dimensione dell'istanza. Un singolo nodo ha bisogno di più core, memoria o throughput del disco di quanti ne offra il piano VPS più grande? Se sì, usare il bare metal o una grande istanza cloud.
- Banda. Il carico di lavoro invierà più di qualche terabyte al mese verso internet? Se sì, modellare con attenzione i costi di traffico e preferire porte con traffico illimitato.
- Isolamento. Policy o normative richiedono hardware single-tenant? Se sì, usare server dedicati.
- Residenza dei dati. I dati devono restare in un paese specifico? Verificare di poter vincolare ciascun server e i suoi backup a quel paese.
- Capacità del team. Il team è in grado di applicare patch, monitorare e ripristinare questo sistema 24 ore su 24? In caso contrario, scegliere un'opzione gestita o acquistare servizi operativi gestiti.
- Tempo di scalabilità. Serve nuova capacità in pochi minuti senza intervento umano (cloud gestito), oppure basta una crescita pianificata in giornata (bare metal o VPS)?
- Durata. Il carico di lavoro girerà per anni, caso in cui la capacità fissa ripaga, o per mesi, caso in cui vanno evitati impegni lunghi?
- Via d'uscita. Sarebbe possibile spostare questo carico di lavoro su un altro modello entro una settimana, se costi o requisiti cambiassero?
Annota le risposte su una scheda di una pagina per ogni carico di lavoro e rivedile almeno una volta l'anno.
Come può aiutare Vonahost
Vonahost offre tutti e tre i modelli, così ogni workload può essere collocato dove è più adatto: server dedicati AMD EPYC single-tenant con NVMe locale o storage a blocchi di rete, una porta dedicata da 1 Gbps a traffico illimitato e mitigazione DDoS Arbor; VPS NVMe basati su KVM e VPS SSD enterprise; e cloud gestito operato sulla nostra piattaforma o su AWS e Google Cloud, con backup, monitoraggio, CDN e staging inclusi.
Se stai pianificando una migrazione o un'architettura ibrida, condividi i profili dei carichi di lavoro e i requisiti. Ogni proposta Vonahost indica configurazione, località, responsabilità e prezzo mensile in dollari statunitensi.