Cloud Ibrido: riprendersi i dati dai colossi

Da anni il cloud pubblico è dove il futuro digitale diventa presente, la meta di chiunque voglia innovare. Per anni è stato naturale rivolgersi ad operatori globali americani, che oggi dominano molti mercati. Si può cambiare? E come?  

“Riprendersi i dati”: da chi? In che senso?

Chi sono i “colossi” digitali dai quali vogliamo riprenderci i dati, o almeno capire come si potrebbe fare? Sono fornitori di servizi digitali, software e hardware, così grandi che anche le grandissime organizzazioni clienti faticano a negoziare modifiche a contratti standard progettati per massimizzare il lock-in.  

Oggi, quasi tutti i colossi che contano sono operatori cloud, perché il cloud è la piattaforma dove si va per innovare: organizzazioni piccole e grandi, pubbliche e private, secolari e appena nate. Per semplicità, in questa pagina possiamo concentrarci su quei colossi che sono operatori cloud globali che dominano il proprio mercato. Questi operatori oggi sono quasi esclusivamente di radice americana, nel senso che sono nati e cresciuti nel sistema legale statunitense, sostenuti da investitori e clienti americani, e remunerano questo sostegno facendo convergere profitti e dividendi verso il mercato finanziario americano.

Dove destinare i dati

Cosa significa “riprendersi i dati” da questi operatori? Ci sono due destinazioni possibili, compatibili l’una con l’altra e anzi spesso combinate in ambienti cloud ibridi:

1. Operatori alternativi, meno dominanti, ma sempre di cloud pubblico. Proprio perché non possono imporre le proprie condizioni, devono offrirne di meno vincolanti, quindi limitano le forme di lock-in almeno a livello contrattuale. Sono comunque operatori cloud (CSP, cloud service provider) nel senso della definizione storica del NIST, National Institute of Standards and Technology statunitense: offrono servizi che sono, in prima approssimazione, automaticamente, velocemente e (quasi) illimitatamente scalabili a seconda delle esigenze, e strumenti contrattuali e tecnici capaci di variare effettivamente in minuti o secondi la scala delle risorse impegnate a seconda delle esigenze di ciascun cliente.  

2.  Servizi non cloud (“on premise”) 
   Si tratta di servizi basati su infrastrutture relativamente stabili, di proprietà del cliente stesso o di uno specialista di sua fiducia, progettate e gestite in modo da essere efficienti sotto carichi relativamente stabili, che aumentano con i tempi dell’investimento per acquisire nuove risorse, e diminuiscono nei tempi necessari per dismetterle: settimane, quando va bene giorni, più spesso mesi. Quando non è il cliente stesso a gestirle, gli operatori che lo fanno si chiamano “colocator” o “operatori di data centre” a seconda che i cespiti informatici principali, i componenti hardware chiave, siano di proprietà del cliente finale o del gestore.

Quali sono i dati da considerare

E i “dati” da “riprenderci”? Sono solo una parte, fondamentale (con norme molto specifiche, e spesso oggetto di clausole contrattuali che aiutano il lock-in) ma piccola, di tutto quello che si affida a un operatore. Ai fini di questa pagina consideriamo che “riprendersi i dati” da un colosso significhi “riprendersi i servizi digitali e i dati su cui questi si basano”.

Molti di questi operatori alternativi, cloud e non, hanno spesso dimensioni confrontabili con i fabbisogni di decine o poche centinaia di clienti; questo permette di ingaggiarli in relazioni un po’ meno asimmetriche di quelle con i colossi: se quello che compro da un fornitore è una percentuale non del tutto trascurabile del suo fatturato, con qualche attenzione posso mantenere delle leve negoziali. Questa caratteristica, e la relativa vicinanza geografica e culturale, sono spesso basi per un rapporto di fiducia che rappresenta un fattore chiave nella scelta di un fornitore, soprattutto quando si tratta di affrontare un percorso complesso per “riprendersi i dati dai colossi”.  

Sovranità dei dati: si può? Come si fa?  

Cosa non si può fare

Meglio partire da una base realistica: ci sono almeno due cose che non si possono fare. Non possono neanche le forze di difesa di un paese molto grande e ricco, o le più grandi organizzazioni del mondo (forse, chissà, neanche gli stessi colossi digitali globali – ma a loro probabilmente non serve: cane non mangia cane).

• La prima è eliminare completamente dipendenze dai colossi a tutti i livelli della tecnologia digitale, dalle comunicazioni via satellite a quelle via cavo sottomarino, passando per i chip, le apparecchiature in cui funzionano, data centre e reti globali (“internet”), hypervisor e sistemi operativi, middleware e software applicativo, dispositivi… molti livelli della “pila” hardware e software in Italia e in Europa non li facciamo. In breve: eliminare tutti i “kill switch”, le vulnerabilità che i colossi e i loro governi potrebbero decidere di usare per bloccare gran parte della nostra operatività digitale e quindi, oggi, della vita quotidiana stessa.  

• La seconda è uguagliare o superare le eccellenze dei servizi dei colossi globali: innovatività, potenza bruta delle infrastrutture, ricchezza qualitativa e quantitativa dei servizi propri e dell’ecosistema di competenze e servizi offerti da terzi. I colossi avranno magari ottenuto vantaggi e privilegi, ma la posizione dominante se la sono anche guadagnata, e sono bravissimi a difenderla, investendo e reinvestendo per portare al mercato novità a un ritmo insostenibile per qualsiasi operatore alternativo.  

Eppure, dove e quando abbiamo davvero bisogno dell’eccellenza? Quali processi di ogni organizzazione sono effettivamente all’avanguardia rispetto a quelli dei concorrenti? E anche di queste eccellenze, cosa dipende davvero dall’analoga eccellenza delle piattaforme digitali, e cosa può accontentarsi di piattaforme buone o ottime ma normali, specie se economicamente convenienti?  

Insomma: se domani il governo degli Stati Uniti d’America imponesse di bloccare i servizi cloud pubblici ai clienti europei, o applicasse ai loro canoni una tariffa del 100 per cento non potremmo farci niente e soffriremmo danni gravissimi, ma lo stesso vale per una guerra nucleare; in entrambi i casi, questo è un motivo per cominciare, più che per rinunciare, a mitigare il rischio.

Cosa si può fare 

Proviamo a fare qualche esempio significativo di cose che si possono fare, cominciando subito un percorso incrementale che presenta difficoltà, richiede impegni significativi, eppure può ripagare con risultati e benefici progressivi fin dai primi passi.

1. Un primo ambito, forse quello più alla portata di tutti, è quello delle piattaforme di condivisione e collaborazione su documenti, fondamentali sia per l’operatività quotidiana di tutte le lavoratrici e lavoratori della conoscenza, sia per l’offerta dei colossi cloud globali ai propri clienti. Le offerte alternative a quelle dei colossi sono numerose, mature e capaci di adattarsi ad esigenze anche molto diverse. Nel 2026, la nuova attenzione dell’Unione Europea all’autonomia strategica dagli operatori globali ha cominciato ad accelerare la diffusione dei progetti e la crescita del mercato. Questa attenzione si manifesta sia tramite norme e investimenti, come lo European Tech Sovereignty Package presentato a inizio giugno 2026, sia e soprattutto nei primi passi di evoluzione e riorientamento della domanda delle pubbliche amministrazioni, come a livello UE il Cloud Sovereignty Framework e il Sovereign Cloud Tender, e annunci e progetti di molti governi nazionali e regionali per adottare piattaforme e servizi cloud alternativi. Questo nuovo orientamento del mercato sta portando gli operatori a iniziative e investimenti come “Euro-Office”, che ancora pochi anni fa sarebbero parsi deliri donchisciotteschi e oggi, pur tra discussioni e dubbi sui componenti architetturali e gli standard scelti, mostrano che, quando la domanda si apre, l’offerta di alternative sa rispondere. 

2. Un secondo ambito è quello delle piattaforme di inferenza basate sull’intelligenza artificiale, descritte ad esempio nell’articolo precedente qui: molti operatori propongono soluzioni alternative a quelle dei colossi, e moltissimi altri hanno ormai accumulato esperienza nell’introdurle e usarle con successo.  

3. Il terzo mercato dove le alternative ai colossi abbondano è quello delle infrastrutture di data centre, ancora più maturo e diversificato, anche se frenato dalla frammentazione degli operatori locali, nazionali e internazionali che iniziative di interoperabilità come SECA API, avviata a inizio 2025 e bisognosa ormai di nuovo impulso, cercano di mitigare.  

4. Più in generale ancora, tutte le piattaforme applicative che le organizzazioni usano per i propri servizi digitali – in particolare proprio per applicazioni caratterizzanti, uniche o fortemente personalizzate, come nell’esempio che ha proposto Lodestar più oltre – possono essere rese progressivamente più indipendenti da servizi e infrastrutture dei colossi.  

Le raccomandazioni 

Su come far evolvere la propria piattaforma applicativa, e più in generale tutti i quattro ambiti elencati, per ridurre il lock-in e “riprendersi i dati dai colossi”, IONOS, fornitore europeo di servizi cloud infrastrutturali attivo anche in Italia e meglio descritto in questo articolo precedente, ha proposto per questa pagina sette linee di azione concrete e pragmatiche. Si tratta di criteri importanti per tutti ed essenziali per operatori di mercati regolati come la pubblica amministrazione, la sanità, la difesa, la farmaceutica e i servizi finanziari.

Secondo Mark Neufurth, Enterprise Strategist Public Sector, si può – e conviene:

1. Proteggere i dati con chiavi crittografiche proprie [fuori dal controllo dell’operatore cloud: chi lo fa, mantiene il controllo dei propri dati anche quando sono nel cloud di un operatore globale].  
   IONOS sta per offrire ai propri clienti un servizio completo di gestione chiavi crittografiche e Confidential Computing [ambiente capace di proteggere i dati da accessi non autorizzati non solo quando sono registrati su memoria permanente, ma anche durante l’elaborazione]. [Numerosi operatori di servizi fiduciari e cloud in molti paesi europei già offrono questi servizi.] 

2. Usare il multicloud: sul cloud si può passare da un fornitore all’altro in poco tempo. Usando API standardizzate con specifiche aperte, come SECA, si riduce il lock-in verso ciascun fornitore, e si mantiene la flessibilità di cambiare. 

3. Usare tecnologie a container e strumenti di dispiegamento (deployment) automatici: quando il software è confezionato in container, diventa portabile. Con i container, quel che gira su un server di proprietà oggi, può girare su qualsiasi cloud domani [e viceversa!] 

4. Privilegiare l’open source: offre trasparenza, limita il lock-in e permette di adattare le applicazioni ad esigenze specifiche.  
   Alternative europee come Nextcloud [per la collaborazione e la condivisione, ad esempio, con la quale IONOS ha una partnership significativa] offrono servizi SaaS pienamente concorrenziali con quelli globali, ma trasparenti e personalizzabili. 

5. Diversificare le catene di fornitura: più un’organizzazione è in grado di gestire le proprie risorse per conto proprio, più è sovrana. E dove ci vogliono partner, meglio averne più di uno che dipendere da uno solo. 

6. Controllare invece di fidarsi ciecamente: usare uno strumento di Identity e Access Management (IAM) efficace e privilegi zero-trust. Assegnare diritti chiari, documentarli, renderli tracciabili [in modo da sapere sempre chi se ne sta avvalendo e come li ha ottenuti]. 

7. Diversificare il paesaggio del proprio parco software: progettare il software fin dall’inizio per poter dispiegare i servizi digitali in situazioni diverse. Allo stesso tempo, renderli semplici da usare perché possano lavorarci più persone possibile. 

Sono linee guida impegnative ma accessibili a moltissime organizzazioni, magari tramite un consorzio di categoria, o dei partner di fiducia. Cominciare ad attuarle, anche a piccoli passi, comincia a ridurre la vulnerabilità e la dipendenza da colossi per i quali siamo tutti sostituibili.

CSI Piemonte, un cloud service provider nazionale, nato da e per la pubblica amministrazione e la ricerca pubblica di quella regione, che ora serve 140 soci pubblici e privati in tutta con 1000 professionisti e tre data centre, ha pubblicato a inizio maggio 2026 una lista simile di 10 principi per la sovranità digitale, con due caratteristiche distintive:

• Ogni principio è graduale, espresso in termini progressivi: meglio cominciare subito a muoversi nelle direzioni giuste che progettare una rivoluzione assoluta chissà quando.  

• L’ambito dell’insieme dei principi è molto ampio: per essere sovrani (e anche “solo” per riprendersi i propri dati dai colossi, quindi) occorre farsi carico (verosimilmente con l’aiuto di partner fidati in ecosistemi aperti alla concorrenza) di governare dati e sistemi, di scegliere soluzioni modulari e interoperabili resistendo alla tentazione di scorciatoie al risparmio nel  breve, di sviluppare e tenere aggiornate competenze tecniche interne su cybersecurity, AI e cloud, di potenziare disponibilità, resilienza e continuità operativa,  

Tutti questi punti sono formulati con riferimento esplicito alle pubbliche amministrazioni, in particolare gli ultimi due che riguardano massima condivisione e altruismo e bene comune. In un mondo di rischi e conflitti crescenti, che anche le organizzazioni più grandi e strutturate faticano a gestire, anche le imprese private possono migliorare la propria redditività a lungo termine adottandoli: nessuno si salva da solo.

I quattro ambiti dove ci si può riprendere i dati dai colossi: piattaforme di collaborazione, inferenza AI, infrastrutture di data centre e piattaforme applicative, abbracciano gran parte della spesa ICT di qualsiasi organizzazione, e soprattutto impegnano una quota significativa dell’operatività digitale e degli spazi digitali dove si muovono e si raccolgono i dati che l’organizzazione produce, consuma e tratta. Agire su di essi è complesso, come evidenziano le due liste di IONOS e CSI Piemonte: ci vogliono risorse significative e la capacità di gestire progetti relativamente lunghi e difficili.

Sovranità cloud ibrido, a cosa fare attenzione

Per decidere se, quando e da dove cominciare a riprendersi i dati dai colossi, è importante aver chiaro che è possibile e può convenire, ma anche che esistono costi e rischi, e fattori di complessità, che sfuggono a una narrazione schematica e consolatoria e vanno apprezzati e gestiti consapevolmente. Ci aiutano a inquadrarli Francesco Bonfiglio, esperto in politiche digitali e già CEO di Gaia-X, e Alessandro Molina, cofondatore di beSharp.

Francesco Bonfiglio segnala innanzitutto che in una prospettiva di sistema, al di là degli obiettivi di ciascuna singola organizzazione, “riprendersi” i propri dati è solo uno degli elementi della sovranità digitale: il vero problema per l’autonomia strategica e la sovranità di un sistema come l’Italia o l’Unione Europea è che abbiamo da tempo affidato dati preziosi ad operatori soggetti ad altre sovranità, permettendo loro di costruirci sopra una capacità di valorizzazione economica dei dati personali a livello globale, e addirittura di influenza sociale e politica.

Su questo l’Europa, imprese, amministrazioni pubbliche e cittadini devono ancora attivarsi a un livello paragonabile a quello con il quale stiamo invece cominciando a “riprenderci i dati”. “L’unico modo per riguadagnare terreno nella competitività”, afferma, “è, appunto, creare soluzioni che il mercato riconosca e premi come più competitive di quelle dei colossi americani” anche proprio nell’ambito della valorizzazione dei dati personali. Senza un argine a questo trasferimento di risorse così significativo, che riduce la disponibilità di investimenti per l’intero ecosistema europeo, pubblico e privato, servirà a poco affidarsi alle normative: sia quelle che bandiscano le soluzioni extraeuropee, sia, secondo Bonfiglio, quelle che impongano l’acquisto di soluzioni “targate Europa”.  

A quali dati dare priorità

Per quanto riguarda i dati, per Bonfiglio è essenziale dare priorità a quelli strategici e critici, come per esempio quelli della sanità. “Riprenderseli”, infatti, è in generale complesso e impegnativo, conviene quindi procedere in maniera mirata. Un esempio efficace è la serie di iniziative che il governo francese ha lanciato e sta continuando ad annunciare e avviare, partendo dalla sanità per ampliare via via l’ambito. In aprile, ad esempio, ha affidato a Scaleway, operatore cloud pubblico europeo, la gestione del proprio Health Data Hub, precedentemente realizzato sul cloud globale Azure, di Microsoft.

A questo annuncio se ne affiancano altri, da valutare con maggiore attenzione e un pizzico di sano scetticismo. A febbraio lo stesso governo francese aveva disposto di sostituire entro il 2027 gli strumenti di videoconferenza dei grandi operatori globali con Visio, soluzione sviluppata localmente, un obiettivo importante ma circoscritto e quindi relativamente semplice da raggiungere. Ad aprile, però, si è impegnato a sostituire Windows con Linux su 2,5 milioni di desktop governativi, obiettivo molto più complesso da affrontare – tanto che su questo il governo francese per ora chiede ad ogni amministrazione solo di definire entro l’autunno 2026 un piano di migrazione.  

Bonfiglio segnala che questi piani dovranno prevedere la sostituzione di tutti gli applicativi Windows con equivalenti Linux, la conversione dei dati relativi e soprattutto il mantenimento della compatibilità tra un portafoglio applicativo e l’altro per tutto il periodo della transizione, verosimilmente molto lunga.  Converrà seguire con la stessa attenzione iniziative simili di governi locali e nazionali europei, come quelle riepilogate da Nextcloud, che è un fornitore di soluzioni di questo tipo e quindi portatore di interessi nella trasformazione.  

Una via alternativa all’abbandono degli hyperscaler

Alessandro Molina, e la sua azienda, sono pionieri del cloud pubblico globale in Italia, è cofondatore di beSharp, system integrator italiano. Molina affronta il tema della sovranità digitale in termini di analisi e consapevolezza delle dipendenze dagli operatori cloud globali: dire che l’unica soluzione possibile sia abbandonarli sarebbe falso, oltre che riduttivo e potenzialmente molto costoso. I punti chiave per lui sono due:  

• è la decisione stessa di quanto affidarsi e a quali condizioni a un global hyperscaler – più in generale, a un “colosso” – ad essere complessa, perché è una scelta che implica sempre un compromesso tra indipendenza e accesso ai servizi più innovativi; 

• decisioni così condizionanti scatenano in noi bias cognitivi dei quali è essenziale essere consapevoli, perché in grado di farci compiere scelte affrettate e, in ultimo, sbagliate. 

Un po’ come ragionare oggi di difesa europea: cinque generazioni di europei occidentali sono cresciute accettando che dipendere fortissimamente dagli USA per la propria difesa fosse un bene indiscutibile, che le controindicazioni fossero trascurabili. Oggi che la dipendenza è diventata evidente, per decidere cosa fare dobbiamo ripensare noi stessi e il nostro mondo. 

La necessità di svolgere l’analisi del rischio

Concretamente, l’invito di Molina è a un approccio maturo di analisi del rischio: riconoscere che le alternative sono molteplici, parziali e sovrapposte, che ciascuna ha un costo da pagare oltre che dei vantaggi. Chi si preclude completamente l’accesso ai servizi cloud degli hyperscaler, afferma, nella grande maggioranza dei casi paga un prezzo in termini di maturità tecnologica, disponibilità e costo delle competenze, tempo per arrivare agli obiettivi e persino sicurezza! Riconoscere che questo prezzo potrebbe essere insostenibile è il punto di partenza per decidere consapevolmente quali superare, quali accettare e gestire, e come. Secondo Molina è sempre possibile “progettare la relazione con ciascun fornitore in modo che non diventi una leva contro di noi”.

Cloud ibrido, perché conviene la sovranità

Complessità progettuale, rischi e punti di attenzione del “riprendersi i dati dai colossi” sono chiari, come è chiaro l’interesse per le economie e le comunità europee a ridurre progressivamente la dipendenza dai colossi globali. Alle singole organizzazioni, cosa conviene davvero? Diversi consulenti, system integrator e managed service provider confermano che aumenta il numero delle organizzazioni, prima solo grandi e ora via via medie e piccole, che intraprendono iniziative simili. Chi glie lo fa fare? Per alcune di loro potrebbe essere il progetto digitale più complesso affrontato finora: tornare dal cloud pubblico può essere più complesso che andarci!

L’obiettivo a lungo termine è la mitigazione dei rischi di sovranità, che però ha un ritorno economico difficile da quantificare (almeno finché i rischi non si verificano! dopo, i costi effettivi si dimostrano tristemente facili da calcolare).

I vantaggi della concorrenza

C’è però un risultato positivo immediato, fin da quando un’organizzazione comincia anche solo a valutare alternative ai colossi: valutando e praticando alternative ai colossi globali si impara a metterli in concorrenza tra loro e con operatori alternativi. Questo porta due benefici: 

1. si sviluppa una miglior leva negoziale con ciascun fornitore, vecchio e nuovo, dominante e no. 

2. Si comincia a fare pratica di come ridurre i lock-in: quali servizi proprietari di ciascun fornitore si possono usare in modo generico, preparandosi così a sostituirli con altri in caso di necessità, e dove stanno le difficoltà.  

Quando si tiene conto di questi benefici immediati, diventa evidente che conviene cominciare subito, magari con primi passi poco rischiosi, in aree meno critiche per il business e più semplici tecnologicamente. L’unica condizione è essere pronti e disposti a impegnare e mettere in discussione fornitori vecchi e nuovi su questo nuovo terreno – un’attività impegnativa anche questa, naturalmente.

Come mitigare i rischi

Quali, tra tutti gli ambiti dei servizi digitali che un’organizzazione usa, siano meno critici e più semplici da far evolvere verso piattaforme alternative a quelle dei colossi, dipenderà dal modello di business di ciascuna organizzazione. In più, ciascuna organizzazione può decidere di affrontare per primi servizi digitali più critici, come nell’esempio descritto sopra da Lodestar.

In generale, due aree dove l’offerta è matura, quindi il rischio è basso, e graduabile perché la migrazione si può suddividere in diversi passi, sono proprio quelle delle piattaforme di condivisione e collaborazione sui documenti , e delle infrastrutture di data centre fisiche e virtuali. Se un’organizzazione sta avviando o consolidando casi d’uso di intelligenza artificiale, vale la pena almeno di mettere in programma, per quando le soluzioni si saranno stabilizzate – e usare subito come leva negoziale e criterio di progettazione delle soluzioni, di usare piattaforme di inferenza basate sull’intelligenza artificiale private.  

Insomma, riprendersi almeno una parte dei dati dai colossi è utile, fin dalla fase di programmazione delle iniziative, anche se occorre pianificare e gestire attentamente i progetti per riuscire a recuperare i costi vivi che si affrontano, in tempi per lo più dell’ordine degli anni.  

Visto che il beneficio è immediato, almeno per chi sia in grado di gestire attivamente il proprio rapporto con i fornitori di servizi digitali attuali e potenziali, e i rischi geopolitici e inflazionistici sono già evidenti e crescono, per moltissime organizzazioni ha senso cominciare subito, o almeno cominciare subito a prepararsi e programmare i primi passi di un possibile, futuro recupero dei propri dati dai colossi.

Esempi pratici

In ogni grande Paese europeo, compresa l’Italia, esistono operatori cloud pubblici più o meno specializzati, che si sviluppano proprio come alternativa ai colossi.  

Alcuni sono operatori generalisti, come CSI Piemonte citato prima, Netalia, OVHcloud, Scaleway o STACKIT, che offrono un portafoglio molto ampio di servizi cloud pubblici infrastrutturali e molti tra i servizi applicativi più richiesti. Altri sono fortemente specializzati e offrono, ad esempio, alcuni servizi infrastrutturali di base, o servizi applicativi semplici e molto diffusi, oppure servizi di nicchia per casi d’uso molto specifici.  

Quelli che hanno contribuito a questo articolo hanno proposto una chiave di lettura comune: “tutti i nostri clienti sono esempi di autonomia dai colossi: la maggior parte scegliendoci invece dei colossi fin dall’inizio, altri migrando sulla nostra piattaforma dalle loro”, hanno osservato con parole quasi identiche, magari senza neppure conoscersi, Michele Zunino, AD di Netalia, Public Cloud Service Provider italiano, e Simon Bergsten, Head of Sales di Intric, società svedese specializzata nell’offerta di servizi SaaS di AI generativa per pubbliche amministrazioni europee, erogati proprio tramite il Cloud Service Provider sovrano europeo che ciascun cliente preferisce. Si tratta quindi di “tenersi i propri dati” prima di volerseli o doverseli “riprendere”.

Secondo Zunino, i motivi che portano un cliente a scegliere un cloud pubblico locale sono un po’ diversi da quelli di cui scriviamo abitualmente, sovranità e conformità alle norme di settore. Questi sono fattori significativi per le imprese dei mercati regolati e i loro fornitori; per le organizzazioni medie e piccole la molla della decisione è spesso la prossimità, una vicinanza geografica e di cultura che permette di sviluppare nel tempo un rapporto di collaborazione e fiducia tra organizzazioni confrontabili, che si riconoscono una rilevanza reciproca e negoziano davvero i propri accordi, situazione rara quando si acquista da un colosso.  

Le difficoltà da affrontare

E le difficoltà? Per Bergsten, la difficoltà tecnica principale è la necessità di adattare le proprie soluzioni alle interfacce e alle caratteristiche dello specifico Cloud Service Provider europeo che ciascun cliente di Intric sceglie: sono molto più numerosi e diversi l’uno dall’altro dei colossi. È peraltro Intric ad occuparsene, con i propri tecnici, in collaborazione con il CSP.  

Per Zunino, le complessità tecniche sono “solo” quelle necessarie per superare i lock-in che ciascun cliente aveva accettato in precedenza usando servizi proprietari di ciascun colosso. Più significative possono essere quelle contrattuali come gli impegni a lungo termine sottoscritti per ridurre i canoni, o i costi di estrazione dei dati (egress fee) dalla piattaforma del colosso, Gli operatori alternativi, più esposti alla concorrenza reciproca e a quella con i colossi, non possono e non vogliono imporre vincoli simili.   

Il caso aziendale: medio operatore software italiano

Approfondiamo innanzitutto il caso concreto di un cliente che ha deciso di “riprendersi i dati” da un colosso. Ce lo propone, con un’analisi molto attenta a vantaggi e svantaggi della migrazione, veri e presunti, Emanuele Minelli, Head of Database Managed Services di Lodestar, un system integrator nazionale, abituato a lavorare con i propri clienti nei cloud pubblici degli operatori globali.

Minelli descrive il percorso decisionale di un operatore italiano di medie dimensioni, che da molti anni fornisce ai propri clienti una applicazione proprietaria in modalità SaaS multitenant – quindi il cliente stesso è un operatore cloud alternativo.

Gran parte della logica di questa applicazione, realizzata direttamente all’interno del motore di database, ora gira su un cloud pubblico globale in un’infrastruttura IaaS dedicata (scelta naturale per soluzioni mature di cui si riesce a stimare bene il fabbisogno di infrastrutture). La spesa annua per il solo affitto dell’infrastruttura è dell’ordine dei 100 mila euro.

Il cliente ha rivisto la scelta cloud perché considera questo costo elevato rispetto al valore che ne riceve. Il modello IaaS, infatti, offre macchine ad alte prestazioni stabili e ridondate, ma non alta disponibilità dell’applicazione, né disaster recovery, né un modo semplice per fare backup coerenti tra database e applicazioni. Questi servizi si possono realizzare anche in IaaS, ma a costi ancora maggiori. 

La strategia

Naturalmente l’alternativa pienamente cloud esisterebbe: passare ad una architettura PaaS, nella quale l’operatore cloud offre insieme al database il servizio che lo gestisce. Di fronte a queste alternative, il cliente ha scelto di “riprendersi i dati” per due motivi: 

• Anche il costo del PaaS, a parità di risorse, è maggiore – il fornitore monetizza il maggior valore che il servizio gestito offre.  

• La logica applicativa incorporata nel database tradizionale, accumulatasi nel tempo, potrebbe non essere compatibile con i criteri più restrittivi e moderni (“cloud-native”) che la versione PaaS dello stesso database impone proprio per garantire la massima scalabilità e gestibilità. 

Le strade possibili per “riprendersi i dati” erano due, e con l’aiuto di DOIT il cliente le ha valutate entrambe:

1. “rimpatrio” (repatriation) classico: trasferire il database, con le sue logiche applicative incorporate, su nuovi server fisici nel data centre del cliente, e allestire da soli una configurazione ad alta disponibilità che superi i limiti della configurazione IaaS attuale.  

Come per molti casi di passaggio da spesa corrente a investimenti in conto capitale, l’impegno economico iniziale è superiore, ma la proiezione del costo a lungo termine permette di stimare un pareggio tra il terzo e il quarto anno, e un risparmio complessivo al quinto anno, confrontabile con il costo annuo attuale. (A questi, osserva chi scrive, si aggiunge la maggior controllabilità e prevedibilità dei costi diretti rispetto a quelli di un canone in cloud con un operatore dominante nel suo mercato, che ha ampi margini per aumentarlo, soprattutto per clienti medi, “qualsiasi”, ampiamente sostituibili.)

2. Rimpatrio con riscrittura (refactoring) dell’applicazione: trasformare la logica applicativa incorporata nel database, stratificatasi nel corso degli anni, per ottenere una nuova versione dell’applicazione più facile da gestire per il futuro – sempre in combinazione con il trasferimento su infrastrutture di proprietà. Questo comporta costi maggiori – e maggiori benefici potenziali – che però, è utile osservare, rappresentano investimenti nell’area di core business del cliente, quella dello sviluppo di applicazioni. A parziale compenso di questi nuovi costi, se si indirizza la riscrittura della logica applicativa verso un nuovo DBMS open source è possibile eliminare il costo delle licenze del DBMS, che nella struttura dei costi di rimpatrio classico rappresentano una quota significativa del totale, e ricorrente. 

Alla fine, il cliente ha scelto la seconda soluzione, compreso il passaggio a un DBMS open source. Sembra ragionevole ipotizzare che un fattore nella decisione, per un produttore di software, sia stata l’opportunità che si crea di investire nelle risorse che meglio conosce e controlla, una nuova versione del proprio software più facile da gestire e far evolvere negli anni a venire – e magari un’altra ragione sia l’insoddisfazione verso il fornitore globale che offre entrambi i software in uso oggi: il DBMS proprietario, a pagamento, e la piattaforma cloud pubblica.  

I costi

Naturalmente, osserva Minelli, come in ogni decisione di passare a open source, considerare “risparmiati” i costi di licenza del database attuale quando lo si sostituisce con uno “gratuito” sottovaluta diverse voci di costo specifiche delle soluzioni open source, in particolare:

• I costi di riprogettazione e riscrittura in un nuovo linguaggio di applicazioni che si sono evolute per molti anni 

• Il maggior costo degli specialisti dello strumento open source, meno diffuso di quello dell’operatore globale – o di portare i propri specialisti attuali allo stesso livello di competenza sul nuovo strumento 

• Il supporto a pagamento da parte del fornitore del DBMS open source, necessario per un’applicazione così complessa e vitale per il cliente e il suo business, del tutto equivalente ai costi ricorrenti di manutenzione del software a pagamento,  

• Il rischio progettuale insito nel rifacimento di gran parte della logica di un’applicazione multitenant già in produzione.  

Questo esempio, segnala Minelli in conclusione, è più rappresentativo di quanto possa sembrare: “Non è un caso isolato: in una porzione crescente degli studi di fattibilità di rimpatrio on premise dal cloud emerge un secondo movimento: cambiare il motore di database mentre si cambia piattaforma, per eliminare il costo delle licenze proprietarie. Se la motivazione finanziaria è chiara, l’esito operativo dipende dalla maturità tecnica con cui si affronta un progetto così complesso. Valutando tutte le voci che concorrono al costo a lungo termine, il differenziale (“risparmio”) si riduce notevolmente e può arrivare ad annullarsi, o a diventare positivo solo su un orizzonte temporale più lungo di quello che la prima percezione suggerisce.”

SAMU, il ‘118 francese’ con Thales Services Numériques e Cloud Temple

Il Service d’Aide Médicale Urgente (SAMU) francese, un coordinamento nazionale di servizi dei singoli dipartimenti paragonabile al Servizio Sanitario di Urgenza ed Emergenza Medica (SSUEM) italiano, ha bisogno di servizi digitali estremamente sicuri ed affidabili, e disponibili 24 ore su 24. Nel 2022, l’ANS (Agence du numérique en santé, agenzia digitale per la sanità francese) decise di riorientare i servizi digitali del SAMU verso una strategia di piattaforme aperte, per facilitare l’integrazione con i fornitori di software sanitario regolamentati dei quali si serviva ciascuno dei SAMU dipartimentali, e la condivisione di informazioni e la collaborazione tra i diversi SAMU in caso di necessità.

Quando a questo requisito ANS scelse di combinare un obiettivo di sovranità tecnica, organizzativa e legale (l’immunità da ingiunzioni legali di altri paesi), divenne naturale rivolgersi ai servizi cloud certificati SecNumCloud (certificazione di cybersicurezza nazionale analoga al livello 3 di ACN in Italia). Tra questi, ANS scelse il CSP francese Cloud Temple, meglio descritto in questo articolo precedente, Con l’aiuto di Thales Services Numériques, SAMU si “riprese i propri dati” da un altro CSP, pure francese e certificato, ma che presentava altre limitazioni. Secondo ANS e Cloud Temple, per gestire le difficoltà della migrazione di sistemi così critici fu sufficiente una programmazione attenta delle attività e dei collaudi, comprese alcune simulazioni di migrazioni complete.  

Dunque, si può cambiare operatore cloud anche per un sistema estremamente critico e tecnicamente complesso. Come per il caso precedente, occorrono motivi che vanno al di là del cambio di fornitore: qui un’apertura profonda dell’architettura per prepararsi al futuro.   

Il caso di Villanova.ai

Per Danilo Rivalta, Presidente di FINIX Technology Solutions, società specializzata nella progettazione di “AI Factory” e infrastrutture per data centre all’avanguardia, in diverse situazioni FINIX ha aiutato i propri clienti a prevenire la dipendenza dai grandi hyperscaler globali (“tenersi i propri dati”) adottando fin dall’inizio soluzioni cloud ibride gestite da operatori italiani.

L’esempio più recente e significativo è quello di Villanova.ai, società che partecipa al progetto EU IPCEI-CIS per sviluppare servizi IA generativi multimodali: servizi in grado di ricevere e produrre contenuti multimediali di diverso tipo con alta qualità in tempo reale e fornire contemporaneamente previsioni accurate basate sulle serie temporali, tramite modelli specializzati per singoli settori come la sanità, i trasporti, smart city e l’agricoltura. In questo caso il data centre dove girano i modelli è gestito da Retelit, operatore italiano con capitali spagnoli, mentre i dati che lo alimentano stanno sull’infrastruttura di un diverso operatore cloud nazionale. Tutte le risorse strategiche del progetto, quindi, nascono e rimarranno in piattaforme che sono diversi operatori ad offrire, in piena concorrenza anziché legate a un operatore globale in posizione dominante.