Negli ultimi anni il cloud pubblico è stato uno dei principali motori della trasformazione digitale. La possibilità di attivare rapidamente nuove risorse, scalare in funzione delle esigenze del business e accedere a servizi sempre più evoluti ha portato aziende di ogni dimensione a migrare applicazioni e dati verso le grandi piattaforme globali.
Oggi, tuttavia, il dibattito si sta evolvendo.
Sempre più organizzazioni stanno iniziando a interrogarsi sul rapporto tra costi, benefici e livello di dipendenza tecnologica sviluppato nel tempo. Temi come sovranità digitale, lock-in, prevedibilità dei costi e controllo delle piattaforme stanno entrando nelle agende di CIO, IT Manager e responsabili infrastrutturali.
Non si tratta di una contrapposizione tra cloud e on-premise. Il cloud continua a rappresentare una scelta strategica per moltissime realtà. Piuttosto, stiamo assistendo a una fase di maggiore maturità, nella quale le aziende valutano con maggiore attenzione dove abbia senso mantenere determinati carichi di lavoro e dove, invece, possa essere opportuno ripensare alcune scelte fatte in passato.
In questo contesto si inserisce il fenomeno della Cloud Repatriation, ovvero il ritorno di applicazioni e dati verso infrastrutture proprietarie o gestite da provider alternativi.
Ma quando questa scelta può davvero avere senso?
Il mio punto di vista
Negli ultimi anni ho avuto modo di confrontarmi con numerose organizzazioni che stanno rivalutando le proprie strategie infrastrutturali e database.
Quello che osservo sempre più spesso è che la domanda non riguarda più semplicemente il cloud, ma il valore che il cloud riesce a generare nel tempo rispetto ai costi sostenuti e ai vincoli che inevitabilmente introduce.
Come professionista che si occupa quotidianamente di Database Managed Services, vedo emergere una crescente attenzione verso aspetti che fino a qualche anno fa venivano considerati secondari: la governance delle piattaforme, la sostenibilità economica nel lungo periodo, la dipendenza da tecnologie proprietarie e la capacità di mantenere il controllo sull'evoluzione delle applicazioni.
In questo scenario, la Cloud Repatriation non rappresenta un ritorno al passato, ma una delle possibili opzioni che alcune aziende stanno prendendo in considerazione per riallineare tecnologia e obiettivi di business.
Un caso concreto
Un esempio particolarmente interessante riguarda un operatore software italiano di medie dimensioni che da molti anni eroga ai propri clienti una piattaforma proprietaria in modalità SaaS multitenant.
L'applicazione era ospitata presso un hyperscaler internazionale attraverso un'infrastruttura IaaS dedicata. Una scelta che nel tempo aveva garantito stabilità e continuità operativa, soprattutto considerando che gran parte della logica applicativa era stata sviluppata direttamente all'interno del motore di database.
La spesa annua per la sola infrastruttura aveva raggiunto un valore superiore ai 100.000 euro.
Durante una fase di revisione strategica, il cliente ha iniziato a mettere in discussione il rapporto tra costi sostenuti e valore ricevuto.
L'infrastruttura offriva elevate prestazioni e ridondanza, ma non garantiva direttamente servizi come alta disponibilità applicativa, disaster recovery avanzato o backup pienamente integrati tra applicazione e database. Tutti elementi che avrebbero richiesto ulteriori investimenti.
Le alternative valutate
La prima opzione consisteva nell'evolvere verso un modello PaaS.
Dal punto di vista tecnologico si trattava di una scelta interessante, ma presentava due criticità significative.
La prima riguardava i costi, che sarebbero aumentati ulteriormente per beneficiare dei servizi gestiti offerti dal provider.
La seconda era legata alla compatibilità applicativa. Nel corso degli anni, infatti, una parte importante della logica di business era stata implementata direttamente nel database. Una situazione piuttosto comune nelle applicazioni mature ma che può rappresentare un limite quando si desidera adottare architetture cloud-native moderne.
Di fronte a questo scenario, il cliente ha deciso di valutare due possibili percorsi di repatriation.
Repatriation tradizionale
La prima soluzione prevedeva il trasferimento dell'infrastruttura su server proprietari, mantenendo sostanzialmente invariata l'architettura esistente.
L'investimento iniziale risultava superiore rispetto al mantenimento del cloud, ma le analisi economiche evidenziavano un possibile pareggio tra il terzo e il quarto anno e un risparmio significativo sul medio-lungo periodo.
A questo si aggiungevano benefici legati alla maggiore prevedibilità dei costi e al controllo diretto dell'infrastruttura.
Repatriation con refactoring applicativo
La seconda opzione era più ambiziosa.
Oltre al trasferimento dell'infrastruttura, prevedeva una revisione della logica applicativa accumulata nel tempo e la migrazione verso un DBMS open source.
L'obiettivo non era semplicemente eliminare i costi di licenza, ma cogliere l'opportunità per modernizzare l'applicazione, semplificarne la gestione e renderla più facilmente evolvibile negli anni successivi.
È stata questa la strada scelta dal cliente.
Il falso mito dell'open source gratuito
Uno degli aspetti più interessanti di questo progetto riguarda il tema dei database open source.
Spesso il passaggio da piattaforme proprietarie a soluzioni open source viene valutato esclusivamente in termini di risparmio sulle licenze.
In realtà, il quadro è molto più articolato.
Occorre considerare:
- i costi di analisi e progettazione;
- le attività di refactoring e riscrittura della logica applicativa;
- la formazione delle competenze interne;
- il reperimento di specialisti qualificati;
- il supporto enterprise necessario per applicazioni mission critical;
- il rischio progettuale associato alla trasformazione di sistemi complessi già in produzione.
Per questo motivo il risparmio derivante dall'eliminazione delle licenze rappresenta solo una delle variabili da considerare all'interno del Total Cost of Ownership complessivo.
Una tendenza che vedo sempre più spesso
L'aspetto forse più interessante è che questo non rappresenta un caso isolato.
In una quota crescente degli assessment che seguo emerge un fenomeno ricorrente: quando un'azienda valuta la possibilità di riportare applicazioni e dati su infrastrutture proprietarie, spesso prende contemporaneamente in considerazione anche la sostituzione di tecnologie proprietarie con alternative open source.
La motivazione iniziale è quasi sempre economica. Tuttavia, nel corso delle analisi emergono considerazioni più ampie legate alla governance, alla flessibilità, alla riduzione del lock-in e alla capacità di controllare direttamente l'evoluzione delle proprie piattaforme.
Conclusioni
Il dibattito non dovrebbe essere semplificato in un confronto tra cloud e on-premise.
Ogni organizzazione ha esigenze, applicazioni e obiettivi differenti. Il cloud continua a rappresentare una scelta vincente in moltissimi contesti, così come esistono situazioni nelle quali una revisione dell'architettura può portare benefici concreti.
La vera domanda da porsi non è se il cloud sia giusto o sbagliato.
La domanda corretta è se l'architettura attuale continui a generare valore proporzionato ai costi, ai rischi e ai vincoli che comporta.
Solo attraverso un'analisi completa degli aspetti tecnici, economici e organizzativi è possibile prendere decisioni realmente consapevoli e costruire piattaforme sostenibili, governabili e capaci di evolvere insieme al business.
Leggi l'articolo completo
