Il conto che non torna

C'è un momento preciso in cui molti responsabili IT si trovano a fissare una fattura cloud e pensare: ma come è possibile? Non avevamo detto che sarebbe costato meno? Quel momento, per molte aziende, arriva puntuale dopo due o tre anni di migrazione entusiasta. E spesso segna l'inizio di una conversazione che fino a poco tempo fa sembrava quasi tabù: e se riportassimo qualcosa a casa?

La cloud repatriation, cioè lo spostamento di applicazioni o dati dal cloud pubblico verso infrastrutture proprie, non è un passo indietro. È la conseguenza logica di un processo di maturazione. Abbiamo imparato a usare il cloud, ne abbiamo capito i vantaggi reali, e ora stiamo imparando anche a riconoscere i casi in cui non conviene. Questo articolo prova a raccontare quel percorso: perché succede, cosa spinge le aziende a riconsiderare le scelte fatte, e come si può affrontare il ritorno con la testa sulle spalle.

Di cosa stiamo parlando, esattamente

Vale la pena essere precisi, perché il termine viene spesso usato in modo impreciso. La repatriation non significa abbandonare il cloud. Nessuna azienda seria sta cancellando i propri account AWS o Azure e tornando ai server degli anni Novanta. Significa qualcosa di più selettivo: prendere alcuni workload specifici, magari un database, un sistema di elaborazione dati, un'applicazione critica, e spostarli su un'infrastruttura fisica gestita direttamente, in un data center proprio o in colocation.

La distinzione è importante perché cambia completamente il ragionamento. Non si tratta di scegliere tra cloud e non-cloud come se fosse un'ideologia. Si tratta di chiedersi, workload per workload: questo specifico sistema gira meglio qui o lì? E soprattutto: costa di più o di meno? La risposta non è mai universale, ma per una categoria di applicazioni, quelle stabili, prevedibili, con un carico costante, sempre più spesso la risposta è: meglio on-premises.

Perché il cloud non è sempre la scelta giusta

Il problema dei costi fissi travestiti da variabili

Il modello pay-per-use o pay-as-you-go è geniale per i picchi. Se avete un e-commerce che a Natale riceve dieci volte il traffico normale, il cloud è la risposta giusta: pagate di più quando serve, meno quando non serve. Ma cosa succede quando il carico è sempre lo stesso, giorno dopo giorno, mese dopo mese? Pagate comunque come se fosse variabile.

È un po' come affittare un appartamento in un hotel invece di comprare casa. Se ci state una settimana all'anno, l'hotel ha senso. Se ci vivete tutto l'anno, a un certo punto fate i conti e vi accorgete che con quello che avete speso in affitto avreste già pagato il mutuo. Il cloud funziona allo stesso modo: è straordinario per l'elasticità, meno brillante per i carichi stabili e prevedibili che non si spengono mai.

La sovranità dei dati non è un dettaglio burocratico

C'è poi un tema che in Europa sentiamo sempre di più, e che non riguarda solo le grandi banche o i ministeri. Il GDPR, la direttiva DORA per il settore finanziario, l’AI Act: tutte queste normative pongono vincoli precisi su dove certi dati possono essere elaborati e conservati. Affidarsi a un provider americano per i dati più sensibili dei propri clienti significa navigare in acque sempre più agitate dal punto di vista della conformità.

Ma al di là delle normative, c'è un ragionamento più semplice: quando i dati sono sui vostri server, sapete esattamente dove sono, chi ci accede e come vengono protetti. Quando sono nel cloud, avete una garanzia contrattuale, che è una cosa seria, ma non il controllo diretto. Per molte organizzazioni, specie in settori regolamentati come sanità, finanza e pubblica amministrazione, quella differenza conta enormemente.

Le prestazioni che non si possono negoziare

Non tutti i sistemi tollerano l'imprevedibilità. Ci sono applicazioni (sistemi di trading ad alta frequenza, piattaforme di collaborazione in tempo reale, pipeline di rendering) che hanno bisogno di latenza bassissima e throughput costante. Nel cloud condiviso, le risorse sono per definizione contese: state usando la stessa infrastruttura fisica di migliaia di altri clienti. La maggior parte delle volte non si nota. Ma quando conta davvero, quella variabilità può fare la differenza.

Un server dedicato, configurato esattamente per il vostro carico di lavoro, con la rete sotto il vostro controllo, elimina quella variabile. Non è nostalgia del passato: è ingegneria.

Il lock-in che non si vede finché non si cerca di uscire

Uno dei costi nascosti del cloud è quello che emerge solo quando si prova ad andarsene. I grandi provider hanno costruito ecosistemi di servizi che funzionano benissimo finché si rimane all'interno. Appena si prova a migrare, ci si accorge che ogni pezzo è legato agli altri con API proprietarie e formati non standard.

A questo si aggiungono le egress fee: i costi per estrarre i propri dati dal cloud possono essere significativi, e sono stati progettati (difficile non pensarci…) anche per rendere scomodo il cambio di provider. Riportare i dati su infrastrutture proprie è anche un modo per riprendere in mano la leva negoziale.

L'intelligenza artificiale cambia i conti

C'è infine una spinta nuova, molto concreta, che sta accelerando il fenomeno: l'esplosione dell'AI. Addestrare e far girare modelli linguistici o di visione richiede hardware specifico (GPU ad alte prestazioni, memoria veloce, reti a bassa latenza) che nel cloud costa moltissimo. E molte aziende, comprensibilmente, non vogliono mandare i propri dati aziendali su un'infrastruttura condivisa per addestrare un modello.

Costruire una piccola infrastruttura AI privata, anche solo un cluster di GPU dedicato, sta diventando una scelta economicamente razionale per chi usa l'AI in modo intensivo. Ed è spesso il primo passo concreto verso una strategia di repatriation più ampia.

Tre storie da cui si può imparare

Basecamp: quando i conti tornano solo on-premises

Il caso più discusso degli ultimi anni è quello di 37signals, la piccola software house americana che sviluppa Basecamp e HEY. Nel 2022 il loro CTO, David Heinemeier Hansson, ha cominciato a pubblicare i conti in modo trasparente: la spesa su AWS aveva raggiunto 3,2 milioni di dollari l'anno.

La decisione è stata radicale: comprare hardware fisico (server Dell per circa 700.000 dollari) e rimpatriare quasi tutto. Risultato: nel 2024 il conto cloud era sceso a 1,3 milioni, con un risparmio vicino ai 2 milioni l'anno. Parallelamente, nel 2025, hanno avviato la migrazione di 18 petabyte di storage da Amazon S3 a sistemi Pure Storage. Le proiezioni cumulative parlano di oltre 10 milioni di risparmio in cinque anni.

La lezione non è "il cloud fa schifo". Heinemeier Hansson lo ha ripetuto più volte: per una startup che parte da zero, il cloud è ancora la scelta giusta. La lezione è che a una certa scala e con certi profili di utilizzo, i numeri cambiano radicalmente.

GEICO: 600 applicazioni e un conto da rifare

L'assicuratore americano GEICO ha percorso la strada classica: migrazione massiva al cloud pubblico, entusiasmo iniziale, poi la doccia fredda. Dopo anni di operatività su più provider, i costi erano cresciuti del 150% rispetto alle previsioni. Non un aumento marginale: due volte e mezza quello che si aspettavano.

La risposta è stata costruire un cloud privato basato su OpenStack, riportando on-premises i workload più pesanti. I risultati documentati parlano di una riduzione del 50% dei costi per compute core e di oltre il 60% per gigabyte di storage. Una storia che dimostra come la repatriation non sia necessariamente un processo lungo e doloroso: con la giusta architettura, i benefici arrivano in tempi ragionevoli.

Dropbox: 75 milioni di motivi per farlo prima del previsto

Meno recente ma forse ancora più istruttivo è il caso di Dropbox. Nel 2015, quando il dibattito sulla repatriation non esisteva nemmeno come categoria, l'azienda ha silenziosamente spostato il 90% dei dati dei propri utenti da AWS alle proprie infrastrutture, completando la migrazione in meno di un anno.

L'annuncio pubblico è arrivato solo nel 2016, ma i numeri erano già chiari: nei due anni successivi alla migrazione, Dropbox ha risparmiato quasi 75 milioni di dollari. Per un servizio che fondamentalmente è storage e quindi  un carico prevedibile, costante, senza picchi improvvisi, gestire i propri server si è rivelato la scelta ovvia. Una lezione che molte aziende SaaS con profili simili potrebbero applicare ancora oggi.

I vantaggi, ma anche le complicazioni

Sarebbe disonesto presentare la repatriation come una soluzione senza costi. Il risparmio operativo nel tempo è reale e per i workload giusti, il costo totale di proprietà on-premises può essere il 40-50% inferiore rispetto al cloud pubblico, ma richiede un investimento iniziale in hardware, infrastruttura di rete e, soprattutto, competenze. Gestire server fisici è un mestiere diverso rispetto a configurare risorse cloud, e molti team hanno perso quella muscolatura negli anni della migrazione.

C'è poi il rischio del lock-in tecnologico al contrario: molte applicazioni che girano nel cloud sono state scritte per sfruttare servizi specifici del provider (Lambda di AWS, Cloud Functions di Google, servizi di database gestiti) che non hanno un equivalente diretto on-premises. Riscriverle o sostituirle ha un costo che va calcolato onestamente prima di decidere.

Infine, c'è la questione del dimensionamento. Nel cloud, sbagliare la stima del carico ha un costo relativo: si aggiusta in pochi minuti. Con l'hardware fisico, un sottodimensionamento significa comprare nuovo hardware, con i tempi e i costi che comporta. La pianificazione della capacità torna ad essere una disciplina critica, e non tutti i team sono pronti a rimetterla al centro.

Come ragionare sulla propria situazione

Il punto di partenza non è la tecnologia: è la domanda giusta. Non "dobbiamo tornare on-premises?", ma "quali dei nostri workload hanno un profilo compatibile con un'infrastruttura dedicata?". La risposta cambia radicalmente da azienda ad azienda, e anche all'interno della stessa organizzazione.

I candidati naturali alla repatriation sono i sistemi con carico prevedibile e costante: database transazionali sempre accesi, pipeline di elaborazione dati che girano h24, sistemi di storage massivo. Tutto ciò che è stabile, tutto ciò che non ha bisogno di scalare improvvisamente, tutto ciò che genera una spesa cloud mensile piatta come un binario. Se il vostro grafico dei costi cloud assomiglia a una linea retta, probabilmente state pagando un premium per un'elasticità che non usate mai.

Al contrario, ha ancora pieno senso nel cloud pubblico tutto ciò che è imprevedibile, stagionale, sperimentale. I nuovi prodotti che non sapete ancora come scala. Le campagne marketing con picchi di traffico. I progetti di ricerca e sviluppo che potrebbero decollare o non andare da nessuna parte. Per questi, la flessibilità del cloud vale ogni centesimo.

Una volta identificati i candidati, il passo successivo è un calcolo onesto del TCO (Total Cost of Ownership) che includa non solo l'hardware, ma energia, spazio, personale, manutenzione, e i costi di migrazione iniziale incluse le egress fee. Spesso quel calcolo sorprende in positivo. Qualche volta no. Ma farlo è l'unico modo per decidere con la testa invece che con l'ideologia.

Con cosa si torna a casa: le alternative alla virtualizzazione

Riportare workload on-premises nel 2026 non significa rimettere in piedi l’infrastruttura di dieci anni fa. Il mercato è cambiato molto, e in alcuni casi, come quello di VMware, è cambiato in modo brusco e costoso.

Per anni VMware è stato lo standard di fatto per la virtualizzazione aziendale. Funzionava, era ovunque, i team sapevano usarlo. Poi nel 2023 Broadcom ha acquisito VMware e ha ridisegnato completamente il modello di licenza: addio versioni perpetue, addio prodotti standalone, benvenuti bundle obbligatori con prezzi aumentati in molti casi dal 200 al 500% rispetto a prima. Per molte aziende la bolletta VMware è diventata improvvisamente il problema più urgente e paradossalmente ha accelerato la riflessione sulla repatriation, perché tornare on-premises con VMware oggi costa quanto o più che restare nel cloud.

La buona notizia è che le alternative mature esistono, e alcune erano già consolidate ben prima che Broadcom cambiasse le regole del gioco.

Proxmox VE è probabilmente la più discussa in questo momento. È open source, basata su KVM e LXC, con un’interfaccia web completa e supporto commerciale opzionale. Non ha la profondità enterprise di vSphere su ogni fronte, ma per la grande maggioranza dei workload aziendali funziona molto bene e il costo è radicalmente diverso.

Microsoft Hyper-V è spesso sottovalutato nel dibattito, ma per chi vive già nell’ecosistema Microsoft è una scelta concreta e matura. È incluso in Windows Server, supporta ambienti misti Linux e Windows, si integra nativamente con Active Directory e System Center, e per molte realtà aziendali già strutturate su stack Microsoft rappresenta il percorso di migrazione da VMware con il minor attrito operativo.

OpenStack rimane la scelta per chi ha bisogno di un cloud privato vero e proprio, multi-tenant, con orchestrazione avanzata e API compatibili con quelle dei principali provider pubblici. È complesso da installare e gestire, richiede un team dedicato o un partner specializzato, ma aziende come GEICO lo hanno adottato con successo proprio in un percorso di repatriation.

Nutanix occupa uno spazio commerciale interessante: è una piattaforma iperconvergente a pagamento, ma offre un percorso di migrazione esplicito da VMware e una gestione molto semplificata rispetto a OpenStack. Per chi vuole lasciare vSphere senza affrontare un cambiamento radicale, è spesso l’atterraggio più naturale.

Per chi guarda al futuro con un’ottica cloud-native, infine, Kubernetes su bare metal, con distribuzioni come k3s o Talos Linux, permette di gestire workload containerizzati direttamente sull’hardware fisico, senza uno strato di virtualizzazione tradizionale. Non è adatto a tutti i casi, ma per le applicazioni moderne è un’opzione sempre più percorribile.

La scelta giusta dipende dal profilo del team, dalla complessità dell’ambiente e dal budget. Ma il messaggio di fondo è uno: il monopolio pratico di VMware è finito, e chi sta valutando la repatriation ha oggi più opzioni reali di quante non ne abbia mai avute.

Dove stiamo andando

La traiettoria che vedo è quella di un ecosistema sempre più ibrido e consapevole. Non "tutto cloud" come si predicava dieci anni fa, non "tutto on-premises" come si faceva vent'anni fa. Ma un mix ragionato in cui ogni workload trova la collocazione più adatta al suo profilo.

I grandi provider lo hanno capito e si stanno attrezzando: AWS Outposts, Azure Arc, Google Anthos sono tutti prodotti che portano l'esperienza cloud  (automazione, orchestrazione, interfacce familiari) su hardware che fisicamente si trova nei vostri data center. È una risposta intelligente alla repatriation: invece di combatterla, la incorporano nel proprio modello.

Anche gli strumenti stanno evolvendo in questa direzione. Le pratiche FinOps, cioè la disciplina di governo finanziario del cloud, stanno diventando più sofisticate e stanno iniziando a includere nel confronto anche l'opzione on-premises, non solo i diversi provider pubblici.

Il risultato è che la scelta tra cloud e on-premises sta diventando più fluida, meno definitiva, più reversibile. Ed è una buona notizia: significa che le aziende possono ottimizzare continuamente, seguendo l'evoluzione dei costi e dei requisiti invece di essere bloccate da decisioni prese anni prima.

Il punto vero

C'è una frase che mi torna spesso in mente quando si parla di questo tema e che spesso cito a lezione: il cloud non è una destinazione, è uno strumento. Come tutti gli strumenti, è formidabile quando viene usato per ciò per cui è stato progettato, e costoso quando viene usato per tutto il resto.

La cloud repatriation non è un fallimento del cloud. È la prova che l'industria sta crescendo: stiamo passando dall'adozione entusiastica e un po' acritica alla gestione matura e consapevole. Le aziende che stanno riportando alcuni workload on-premises non stanno tornando indietro ma stanno diventando più brave a usare gli strumenti che hanno a disposizione.

Se state valutando se ha senso anche per voi, il mio consiglio è di iniziare dai numeri, non dalle opinioni. Prendete i vostri workload più stabili, calcolate quanto costate davvero nel cloud e quanto costerebbe gestirli internamente. Lasciate che siano quei numeri a guidare la decisione. Il resto (ideologia, trend, annunci di conference) conta molto meno di quanto sembra.