In queste ultime settimane il progetto Gaia-X, un’iniziativa europea per riguadagnare almeno un po’ il terreno perduto dall’Europa in tema di cloud, è tornato sotto i riflettori con l’annuncio della costituzione dell’associazione Gaia-X Hub Italia sostenuta da tre ministeri (Sviluppo economico, Innovazione e transizione digitale, Università e ricerca) e da altri attori rilevanti nel panorama nazionale.
Allo stesso tempo uno dei 22 fondatori del consorzio Gaia-X, Scaleway attore francese del public cloud, ha annunciato l’intenzione di non rinnovare l’adesione al consorzio assumendo posizioni molto critiche sul progetto. Il provider francese contesta infatti l’ingresso nel consorzio che oggi conta oltre 300 organizzazioni dei big player del cloud pubblico mondiale come AWS, Microsoft, Google, IBM se si pensa all’America o Huawei se si pensa alla Cina. È evidente che se l’aspetto centrale nel progetto Gaia-X era quello di assicurare un’autonomia europea in materia di cloud l’ingresso di questi grandi player extracomunitari può influenzare il progetto fino a farne perdere l’identità, che è l’essenza dell’accusa mossa da Scaleway.
Cloud, l’infrastruttura non basta: ecco le priorità per trasformare le organizzazioni
Gli elementi oggetto del contendere
Come è possibile da una parte che il consorzio cresca con il contributo degli stati membri e allo stesso tempo alcuni costituenti ne denuncino un primo fallimento? Per capire i conflitti e le sfide al centro di questo importante progetto è necessario capire quali siano gli elementi oggetto del contendere e capire se la costruzione di un consorzio di player dell’industria IT abbia in sé la stessa forza che ha portato alla storia di successo di Airbus come risposta europea nel settore dell’aviazione. Il software ha sempre sfuggito logiche industriali tradizionali, a causa della sua natura fortemente legata all’opera di puro ingegno in cui pochi individui possono fare la differenza. Grandi progetti Open Source come Linux hanno infatti raggiunto un successo planetario anche grazie ad un’organizzazione interna capace di assicurare l’opportuno livello di governance e al ruolo del cosiddetto “benevolent dictator” ovverosia un individuo (nel caso di Linux Linus Torvalds) a cui la comunità riconosce il diritto di prendere le decisioni centrali allo sviluppo del progetto.
Cerchiamo quindi di capire l’anatomia di un cloud e le sfide che ne caratterizzano sia il funzionamento che la sua capacità di interoperare con altri cloud, e di conseguenza come definire il concetto di lock-in, elemento centrale nelle riflessioni sulla sovranità digitale.
Anatomia di un cloud
È bene innanzitutto ricordare che il cloud è partito nella seconda metà degli anni duemila come un modello di business e non una tecnologia. Il problema era quello di usare la capacità extra che i grandi provider di servizi dell’epoca avevano per vendere servizi trasformando la loro gestione da investimento a costo (come si dice spesso da CAPEX a OPEX).
Dal PaaS al SaaS
I primi servizi erano fortemente legati agli algoritmi e alle funzioni che i singoli player implementavano, Google ad esempio offriva la “big table” ovvero la possibilità di usare la stessa struttura dati alla base del motore di ricerca, si trattava del primo embrione dei servizi cloud di tipo Platform as a Service (PaaS).
L’ingresso di Amazon in questo business con l’offerta di Infrastructure as a Service (IaaS) cambiò radicalmente la prospettiva offrendo alle aziende la possibilità di noleggiare macchine virtuali capaci di eseguire i sistemi operativi già in uso in azienda e promettendo di ridurre i costi nella gestione dei servizi IT rispetto al modello tradizionale in cui si è proprietari dell’infrastruttura che esegue un servizio. Nello stesso periodo cominciò l’affermarsi di un terzo modello di servizio cloud in cui si acquisisce direttamente un software da configurare, come ad esempio nel caso dei software CRM su cui Salesforce ha costruito la propria fortuna, in esecuzione da qualche secondo una modalità ormai universalmente nota come Software as a Service.
Durante i primi anni di affermazione del cloud si pensava solo a come disaccoppiare i servizi dalle infrastrutture fisiche, sfruttando largamente i benefici delle tecnologie di virtualizzazione che consentono addirittura la migrazione di un servizio mentre è in esecuzione da un server ad un altro, portando a risparmi promessi dal non doversi preoccupare di realizzare e manutenere la propria infrastruttura e limitarsi a pagare chi già la possiede per il tempo che serve. E infatti il tema della cosiddetta elasticità dominava molte di queste discussioni: la possibilità di allocare grandi quantità di risorse per brevi periodi di tempo consentiva di poter gestire picchi di servizio senza dover sovradimensionare i sistemi per l’uso ordinario.
Si trattava comunque di convincere intere organizzazioni ad affidare i propri dati e servizi ad un ente terzo, avendo solo il contratto che definiva il livello di servizio mediante il Service Level Agreement (SLA), documento responsabile per definire quale livello è garantito da un particolare servizio cloud. L’eterogeneità dell’offerta era poco rassicurante, soprattutto se per realizzare un servizio era necessario legarsi a un particolare vendor da cui finiva per dipendere (vendor lock-in).
Il pizza box cloud model
Un passaggio chiave per rendere più comprensibile il modello e pertanto ridurre il senso di lock-in nell’affidarsi ad un cloud provider è stato dato dal cosiddetto “pizza box cloud model” che usando la metafora della pizza nelle sue varianti descriveva il funzionamento di un sistema standard fatto di hardware, sistema operativo, runtime, middleware e applicazioni come un sistema la cui responsabilità di gestione non era più interamente in mano all’organizzazione ma si poteva decidere cosa far gestire al fornitore del servizio cloud e cosa invece si manteneva di propria responsabilità.
Questa visione consentiva anche la realizzazione in proprio di un cloud “privato” secondo la stessa logica e così quello che era nato come un business model si è lentamente trasformato in un insieme di tecnologie per gestire le risorse IT in modo da disaccoppiare i servizi dall’hardware su cui sono in esecuzione, e che alla fine sono realizzati da macchine virtuali sia se sono eseguite in un cloud pubblico che in un cloud privato realizzato all’interno di un’organizzazione.
In questo processo di definizione tecnologica degli strumenti necessari alla realizzazione di un cloud è emerso un modello largamente accettato per rappresentare a macroblocchi le funzioni di un cloud. In sostanza il livello fisico viene trasformato in pool di risorse (storage, calcolo e rete) grazie alle tecnologie di virtualizzazione, e controllato mediante un livello di controllo responsabile per offrire una visione omogenea delle risorse e consentirne quindi l’allocazione gestita dai livelli superiori mediante tecnologie di orchestrazione e automazione. Il cloud, infatti, si caratterizza per la sostanziale assenza di intermediazione nell’erogazione di risorse IT agli utenti, in accordo a un modello dei costi e alla raffinata capacità di misurare l’uso delle risorse. È responsabilità del cloud provider gestire gli aspetti di sicurezza, riservatezza, resilienza, e operatività in accordo ai livelli di servizio promessi.
Il multi-cloud e l’interoperabilità
Poter pensare a un cloud come ad un enorme silos pieno di macchine virtuali è sicuramente utile a mantenere una sensazione di controllo, costruendo un’astrazione in un cui un utente può decidere di eseguire una macchina virtuale su un cloud in accordo alla convenienza.
È però meno semplice di quanto possa sembrare a prima vista lo spostamento di risorse da un cloud all’altro, largamente perché è difficile caratterizzare un servizio in termini di requisiti funzionali e non e di conseguenza assicurare che questi siano soddisfatti spostando il servizio da un cloud all’altro. È comunque prassi comune oggigiorno per un’organizzazione avere i propri servizi in esecuzione su più piattaforme cloud, e sono sorti numerosi strumenti per la gestione del cosiddetto “multi-cloud”, ovverosia uno strato software che promette di selezionare dinamicamente il cloud su cui eseguire particolari servizi al fine di ottimizzare i costi e ridurre, se non eliminare, il vendor lock-in.
Gaia-X si può pensare come il tentativo di definire standard per la descrizione dell’offerta cloud in modo tale che si possano federare più cloud consentendo la realizzazione di un multi-cloud che insiste su cloud service provider europei evitando di dover affidare i servizi ai soliti noti. A questo livello di astrazione sembra una buona idea e soprattutto che sia semplice da attuare. Purtroppo, i computer sono tremendamente pignoli e caratterizzare gli innumerevoli servizi di un cloud mediante delle API che ne consentano la gestione in modo agnostico è un compito assolutamente complesso e i tentativi effettuati negli ultimi dieci anni hanno largamente fallito, anche perché la necessità del sistema di evolvere tende a contrastare la necessità di stabilità che ha una API per potersi consolidare. Anche il tentativo di descrivere l’orchestrazione di servizi (come, ad esempio, la proposta OASIS di TOSCA) in modo standard ha stentato a decollare.
Mi è difficile essere sorpreso di questa difficoltà nell’interoperare: gli utenti continuano a scegliere lo stesso sistema operativo per garantirsi interoperabilità e facilità d’uso e si tratta di un sistema ben più semplice di un Cloud. I nuovi servizi, come ad esempio quelli di AI, sono poco standardizzabili, e il loro uso su un cloud piuttosto che un altro porta a risultati completamente differenti anche se invocati usando le stesse API. Si pensi ad esempio ad un servizio per il riconoscimento delle frodi che fa uso di intelligenza artificiale: un fornitore come Amazon può usare i dati del proprio store on-line per addestrare il sistema offrendo un servizio superiore ad un altro realizzato da chi non gestisce una piattaforma di vendita mondiale, a parità di capacità di invocazione delle API.
Le sfide di Gaia-X
Le preoccupazioni manifestate da Scaleway sono legittime: se i giganti del cloud partecipano in modo diffuso alle attività del consorzio premeranno affinché le proprie API siano il più vicino possibile allo standard proposto, mantenendo di fatto il predominio attuale poiché per gli utenti sarà possibile continuare ad usare il servizio beneficiando di infrastrutture così grandi da rendere difficile una competizione per nuovi attori. Non sembrano essere presenti nel consorzio quelle leve necessarie a supportare la creazione di un ecosistema europeo, e la standardizzazione multi-cloud delle funzioni non è vista come sufficiente a garantire un mercato capace di sostenere la formazione di player europei.
Va però detto che l’esistenza di standard è importante, e che in questo Gaia-X può dare un contributo, anche se la Commissione europea dovrà fare in modo di sostenere la formazione di operatori cloud capaci di competere con i giganti mondiali, nella consapevolezza che sempre meno servizi oggi sono esattamente gli stessi se eseguiti su cloud differenti. In particolare, i servizi che dipendono da modelli di intelligenza artificiale esibiranno comportamenti differenti vanificando, almeno in parte, lo sforzo di standardizzazione.
Solo il tempo ci dirà se questa iniziativa sarà capace di spostare l’ago della bilancia, ma sicuramente è necessario sostenere non solo aggregazioni di imprese, ma anche la costituzione in Europa di attori prevalentemente tecnologici che siano capaci di dare quella sostanza su cui si può poi pensare di costruire un multi-cloud che non finisca a dipendere dai soliti noti. Sicuramente la carenza di ingegneri e di un ecosistema di programmatori sufficientemente ampio rende questo scenario difficile da raggiungere e iniziative degli stati membri possono cercare di contrastare questa tendenza.
La verticalizzazione di Gaia-X sui dati sicuramente aiuta a definire un perimetro più definito su cui competere, ma non si possono affidare a un solo consorzio di aziende il futuro della sovranità digitale di un continente.
