Oggi la risposta automatica è "metti tutto in cloud". Per una startup senza team infrastrutturale e con carichi che variano in modo imprevedibile, spesso è la scelta corretta. Ma per la PMI italiana tipica - carico prevedibile, dati sensibili, budget definito - il default cloud merita di essere messo in discussione: non perché il cloud sia sbagliato, ma perché la decisione viene presa quasi sempre sui fattori meno rilevanti. Dichiaro subito il mio orientamento: per le piccole aziende tendo a preferire il self-host. È però una valutazione caso per caso, e quello che segue è il framework per farla con i dati alla mano - norme, costi reali e casi documentati inclusi.
Il costo che cresce: egress e per-seat
Il cloud appare economico all'inizio, ed è qui che si annida l'errore di valutazione: i costi che pesano davvero sono quelli che crescono nel tempo e che raramente entrano nel preventivo iniziale. Il primo è l'egress: i grandi provider fanno pagare il traffico in uscita, cioè il costo di spostare i tuoi dati fuori dalla loro infrastruttura - una voce che cresce con i volumi e che, di fatto, scoraggia anche solo il backup verso l'esterno. Il secondo è il per-seat: ogni servizio SaaS a un tot per utente al mese, moltiplicato per il numero di dipendenti e per la quantità di strumenti adottati, diventa una spesa ricorrente che sale di pari passo con la crescita aziendale.
Non è teoria. Nel 2022 37signals - l'azienda dietro Basecamp e HEY - ha annunciato pubblicamente l'uscita dal cloud, documentando la migrazione su hardware proprio: una spesa una tantum dichiarata intorno ai 600.000 dollari in server e un risparmio stimato di oltre un milione di dollari l'anno, circa sette milioni su cinque anni. Anni prima Dropbox aveva intrapreso un percorso analogo spostando lo storage da AWS alla propria infrastruttura (il progetto "Magic Pocket"), riportando nei documenti per la quotazione in borsa un risparmio dell'ordine dei 75 milioni di dollari. Sono aziende grandi, con carichi enormi e prevedibili: il dato non si trasferisce in automatico su una PMI. Ma il principio è chiaro - oltre una certa stabilità del carico, possedere l'infrastruttura costa meno che affittarla. L'on-prem richiede un investimento iniziale maggiore (l'hardware), ma a regime è prevedibile, e la prevedibilità a regime per molte realtà batte il "pago solo quello che uso".
Dove vivono i tuoi dati: sovranità e GDPR
È l'aspetto più sottovalutato in Italia, e per molte aziende è quello che chiude la discussione. "Cloud" significa, alla lettera, dati su computer di qualcun altro - spesso in un'altra giurisdizione - e questo apre un problema giuridico concreto, non ideologico.
Due norme si scontrano. Da un lato il GDPR, che limita il trasferimento di dati personali fuori dall'Unione Europea. Dall'altro il CLOUD Act statunitense del 2018, che consente alle autorità USA di obbligare un provider americano a consegnare i dati che gestisce indipendentemente da dove sono fisicamente archiviati - anche se risiedono in un data center europeo. Le due cose non si conciliano facilmente, ed è il cuore della vicenda Schrems II: nel 2020 la Corte di Giustizia dell'Unione Europea ha invalidato il Privacy Shield, l'accordo che reggeva i trasferimenti di dati UE-USA, proprio per l'insufficiente protezione dei dati europei dalla sorveglianza statunitense. Non è rimasta una questione teorica: nel 2022 il Garante per la protezione dei dati personali italiano - in linea con le autorità austriaca e francese - ha dichiarato non conforme l'uso di Google Analytics, perché trasferiva dati personali verso gli Stati Uniti senza garanzie adeguate.
La reazione dell'industria conferma quanto il tema sia serio: l'iniziativa europea Gaia-X per un'infrastruttura dati sovrana, e le offerte "sovrane" annunciate dagli stessi hyperscaler (l'EU Data Boundary di Microsoft, l'European Sovereign Cloud di AWS) nascono esattamente per rispondere a questa esigenza. Per una PMI che tratta dati di clienti, sanitari o finanziari, la domanda da porsi è netta: dove risiedono fisicamente i miei dati, e quale autorità può legalmente obbligarne l'accesso? Tenere il dato in casa, o su infrastruttura europea sovrana, offre una risposta verificabile. Non è paranoia: è due diligence.
Lock-in: la dipendenza che si costruisce un servizio alla volta
Il cloud lega attraverso i servizi gestiti, le API proprietarie e i formati che esistono solo su quella piattaforma, con l'egress che funziona da costo d'uscita. Migrare da uno stack cloud profondo è oneroso, e non per caso: la difficoltà di andarsene fa parte del modello di business. Più ci si appoggia ai servizi specifici del provider, meno si è liberi di cambiarlo. Software open source e infrastruttura portabile mantengono questa leva nelle proprie mani. È lo stesso ragionamento di build vs buy, applicato all'infrastruttura: ogni servizio gestito è comodità oggi e dipendenza domani.
Latenza, controllo e la dipendenza dalla rete
Per certi carichi - gestionali locali, sistemi di produzione, il punto vendita - l'on-prem dà latenza bassa e disponibilità che non dipendono dalla linea internet. Il cloud aggiunge una dipendenza dura: se cade la connettività, cade l'operatività. E c'è il controllo: la macchina la vedi, la tocchi, sai dov'è. Per un'azienda che non può permettersi di fermarsi quando salta la fibra, è un fattore concreto.
Quando invece il cloud è la scelta giusta
Sarebbe disonesto dipingere il cloud come l'avversario. Il cloud è la risposta corretta quando manca il personale per gestire l'infrastruttura - e soprattutto la continuità per mantenerla nel tempo (lo stesso "problema delle 3 di notte" di build vs buy): è preferibile pagare chi se ne occupa piuttosto che ritrovarsi un server che nessuno sa più amministrare. È la scelta giusta quando il carico è variabile, perché pagare a consumo batte un hardware inattivo per gran parte del tempo; quando serve scalare rapidamente o raggiungere mercati globali; e quando si vogliono certificazioni di compliance e disaster recovery geo-ridondante già pronti, difficili da replicare su un singolo server in sede. La regola resta: non gestire in casa ciò che non si è in grado di gestire.
- non hai chi gestisce un server (continuità)
- il carico è variabile o a picchi
- ti serve scalare in fretta o reach globale
- vuoi compliance e DR geo-ridondante pronti
- è una commodity gestita meglio da altri
- i dati sono sensibili o regolati (sovranità)
- il carico è prevedibile e costante
- vuoi costi prevedibili (no egress, no per-seat)
- il lock-in è un rischio strategico
- hai chi sa gestire la macchina
Il terzo modo: architettura ibrida e self-host professionale
Quasi nessuna PMI è interamente cloud o interamente on-prem: il punto di equilibrio realistico è ibrido. Si tiene vicino - in sede o su infrastruttura europea sovrana - ciò che è sensibile e stabile, e si affida al cloud ciò che è variabile, di commodity, o destinato al disaster recovery. Va però sgombrato il campo da un equivoco: "self-host" oggi non significa un server dimenticato in uno sgabuzzino, ma un'infrastruttura piccola e gestita con criterio - virtualizzazione, container, backup verificati, monitoraggio.
È il principio su cui sono progettate le piattaforme che sviluppo. Presidio, la piattaforma XDR che ho costruito, è deliberatamente self-hosted: i dati di sicurezza di un cliente - log, alert, indicatori di compromissione - restano sotto il suo controllo e sulla sua infrastruttura, senza transitare per una piattaforma di terze parti e senza un costo che cresce a ogni endpoint aggiunto. Per un prodotto che raccoglie le informazioni più sensibili di un'organizzazione, la sovranità del dato non è un dettaglio accessorio: è un requisito di progetto.
Una checklist per decidere
- Quanto è sensibile il dato? Più è regolato, più la sovranità pesa verso il tenerlo vicino.
- Il carico è prevedibile o a picchi? Stabile → on-prem conviene; a picchi → cloud.
- Hai chi opera la macchina, con continuità? Se no, il cloud è più onesto.
- Qual è il TCO a tre anni? Conta egress e per-seat al tuo numero reale di utenti, non il prezzo iniziale.
- Quanto fa male uscire? Misura il lock-in prima di entrare, non dopo.
- La connettività è un punto singolo di guasto? Se fermarsi è inaccettabile, valuta l'on-prem.
La conclusione
"Cloud o on-prem" non è un'identità da abbracciare una volta per tutte: è il problema di collocare ogni carico dove appartiene. Il mio orientamento, per una piccola azienda italiana, resta quello dichiarato all'inizio: tenere vicino ciò che è sensibile e stabile, affidare al cloud ciò che è variabile e di commodity. Non scegliere il cloud per inerzia, né l'on-prem per principio, ma valutare ogni carico per quanto costa davvero - in denaro, in rischio normativo, e nella capacità reale di gestirlo nel tempo.
Se vuoi approfondire questo argomento o ti serve una consulenza specializzata, parliamone.
Parliamone →