{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibvert45kyasmcsjmvlukhysurp3wh47342pnler6snynxzc3m2ti",
    "uri": "at://did:plc:eewzvbj23ozqm6r3zr3tcq7m/app.bsky.feed.post/3mhi2kb5eikb2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreid7daltq6avvhxs7wx733xc42rhli6eqdrtwwjkrekewbsf6zkfum"
    },
    "mimeType": "image/png",
    "size": 3230396
  },
  "description": "Quando tornare a casa ha più senso che restare in affitto",
  "path": "/cloud-repatriation/",
  "publishedAt": "2026-03-20T08:03:42.000Z",
  "site": "https://tech.wpc.education",
  "textContent": "# Il conto che non torna\n\nC'è 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?**\n\nLa **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.\n\n# Di cosa stiamo parlando, esattamente\n\nVale 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.\n\nLa 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**.\n\n# Perché il cloud non è sempre la scelta giusta\n\n## Il problema dei costi fissi travestiti da variabili\n\nIl 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.\n\nÈ 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.\n\n## La sovranità dei dati non è un dettaglio burocratico\n\nC'è 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à.\n\nMa 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.\n\n## Le prestazioni che non si possono negoziare\n\nNon 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.\n\nUn 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.\n\n## Il lock-in che non si vede finché non si cerca di uscire\n\nUno 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.\n\nA 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.\n\n## L'intelligenza artificiale cambia i conti\n\nC'è 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.\n\nCostruire 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.\n\n# Tre storie da cui si può imparare\n\n## Basecamp: quando i conti tornano solo on-premises\n\nIl 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.\n\nLa 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.\n\nLa 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**.\n\n## GEICO: 600 applicazioni e un conto da rifare\n\nL'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.\n\nLa 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.\n\n## Dropbox: 75 milioni di motivi per farlo prima del previsto\n\nMeno 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.\n\nL'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.\n\n# I vantaggi, ma anche le complicazioni\n\nSarebbe 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.\n\nC'è 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.\n\nInfine, 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.\n\n# Come ragionare sulla propria situazione\n\nIl 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.\n\nI 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.\n\nAl 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.\n\nUna 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.\n\n# Con cosa si torna a casa: le alternative alla virtualizzazione\n\nRiportare 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.\n\nPer 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.\n\nLa buona notizia è che le alternative mature esistono, e alcune erano già consolidate ben prima che Broadcom cambiasse le regole del gioco.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\nPer 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.\n\nLa 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.\n\n#\n\n# Dove stiamo andando\n\nLa 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.\n\nI 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.\n\nAnche 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.\n\nIl 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.\n\n# Il punto vero\n\nC'è 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.\n\nLa **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.\n\nSe 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.",
  "title": "Cloud Repatriation",
  "updatedAt": "2026-03-20T08:03:43.855Z"
}