Cloud pubbliche: sai (davvero) cosa compri?

Un vademecum per aiutare gli utenti delle reti della ricerca a scegliere consapevolmente i servizi in cloud pubblica ed evitare brutte sorprese

Nel mondo delle reti della ricerca, il disegno, la realizzazione e la gestione dei servizi, siano essi di connettività che above-the-network, sono da sempre concertati direttamente con gli utilizzatori. Si può anzi dire che una delle ragioni d’essere delle reti della ricerca sia proprio quella di governare l’evoluzione tecnologica mantenendo un’ottimale trasparenza e visibilità della rete, con la possibilità di gestire specifici requisiti degli utenti.

Tuttavia l’offerta di servizi anche da parte di soggetti al di fuori dell’ambiente della ricerca si è moltiplicata negli anni e oggi il ricorso all’adozione di servizi applicativi e di information technology offerti sul cloud pubblico è ormai una realtà piuttosto diffusa anche nell’ambiente scientifico, accademico e culturale e una rete nazionale della ricerca non può che prenderne atto e cercare di adottare delle politiche tali da offrire il miglior supporto alle organizzazioni della propria comunità che scelgono questa opzione. Tuttavia è importante sottolineare che questa scelta ha delle implicazioni importanti e ci impone di prestare attenzione ad alcuni aspetti tecnici e funzionali, oltre che strategici. Gli effetti del passaggio di uno o più servizi del dominio della ricerca sul cloud pubblico possono infatti avere un impatto immediato sulle prestazioni e sulla capacità di controllo di dati e applicazioni, ma anche effetti a medio-lungo termine sulla capacità tecnica ed economica di passare a soluzioni più adatte alle esigenze dell’utente e in ultima analisi costituire una limitazione alla libertà di farlo.

Parliamo del concetto di sovranità digitale, che per noi significa avere il controllo diretto degli strumenti, delle tecnologie e delle condizioni per fare la propria ricerca, ma anche la conoscenza del contesto e le competenze tecniche per scegliere opportunamente.Il nostro obiettivo è quindi quello di diffondere il più possibile questa cultura e offrire degli elementi fondamentali per decidere consapevolmente e ottenere le condizioni migliori nel caso si opti per l’utilizzo di soluzioni in cloud pubblica. Questo è un aspetto ancor più importante oggi, con la partenza di decine di progetti PNRR che costruiranno nuove infrastrutture digitali o ne potenzieranno di esistenti, di cui vanno garantite le prestazioni, la portabilità di dati e applicazioni e la sostenibilità.

Public cloud provider: le relazioni pericolose?

Negli ultimi anni GARR, come altre reti della ricerca, ha ricevuto numerose sollecitazioni che arrivano, direttamente o indirettamente, dai cloud provider e che hanno come obiettivo la configurazione di interconnessioni dedicate che spesso però non sono nell’interesse dell’utente: vediamo il perché. I cloud provider cercano di “avvicinarsi” il più possibile all’ambiente di lavoro dell’utilizzatore (atenei, laboratori di ricerca, ecc.), prospettando condizioni di erogazione dei servizi in cloud che simulano un cloud privato: vengono quindi proposte configurazioni tecniche che permettano all’utente di estendere logicamente il proprio dominio di rete locale all’interno del data centre del provider di cloud pubblico, ad esempio attraverso un servizio di trasporto di rete a livello 2 che necessariamente dovrebbe essere erogato da GARR sulla sua infrastruttura. Tuttavia questa richiesta implica che la rete GARR entri in maniera importante nell’erogazione del servizio end-to-end, ma senza averne la visibilità all’interno dei domini di competenza dei cloud provider, che normalmente sono chiusi su se stessi per motivi commerciali. Non vi è quindi possibilità di fissare punti di demarcazione tra i domini di gestione e controllo e quindi di garantire qualità e affidabilità end-to-end del servizio dal punto di vista funzionale e prestazionale tra sito dell’utente e del cloud provider.

Alcuni grandi player come Microsoft o AWS hanno già proposto soluzioni ad hoc come “Expressroute” e “Direct Connect” per risolvere parzialmente il loro problema ed estendere e arricchire la propria offerta, ma potenzialmente i cloud provider sono centinaia e seguire solo le specifiche dei big potrerebbe a una polarizzazione del mercato che non è desiderabile per il mondo della ricerca.

Le domande “giuste” da porre

In ragione di queste criticità, GARR, come altre reti della ricerca, ritiene che soluzioni di collegamento come quelle proposte dai 2 big player, che prevedono l’estensione del dominio di un utente su cloud pubblica al di fuori del loro perimetro di azione siano quindi da evitare. Questo non significa necessariamente che gli utenti che abbiano necessità di rivolgersi a fornitori di cloud pubblici per le loro attività di ricerca debbano rinunciarvi: è però fondamentale che lo facciano consapevolmente e siano in grado di inquadrare correttamente lo scenario in cui si situano queste proposte in cloud pubblico o ibrido, ponendo alcune domande fondamentali ai propri fornitori e al proprio interno.

Il primo passo è quello di conoscere l’architettura dell’applicazione o delle applicazioni che si intende utilizzare in cloud pubblica: si tratta di una applicazione multisito o singolo sito? Quali sono i meccanismi di affidabilità? Qual è la capacità di rete richiesta per accedervi e le prestazioni funzionali? Quali sono i siti geografici nei quali sono ospitati i data centre e da cui ci si aspetta che il servizio sarebbe erogato? Quali sono infine le politiche di instradamento dello specifico cloud provider (o del suo fornitore di connettività) verso la rete GARR e quali sono le possibilità e la disponibilità di ottimizzarle? Esiste da parte del cloud provider la disponibilità ad attivare un peering diretto con la rete GARR?

Questione di peering (diretto)

Da un punto di vista di rete, il peering diretto rappresenta un elemento in più a garanzia delle prestazioni e dell’interoperabilità dei servizi. Vi sono vari modi per realizzarlo, il più diffuso e naturale dei quali è stabilire un collegamento di peering all’interno di un NAP (Neutral Access Point). In base alle esigenze e alle capacità coinvolte, è possibile sia utilizzare le infrastrutture di switching usate collettivamente dai vari soggetti presenti nel NAP che realizzare singole cross-connessioni. Ad esempio ormai da diversi anni GARR ha stabilito un peering diretto a 40 Gbps con Google, visto che lo scambio di traffico della comunità della ricerca con Google sui NAP era predominante.

Imporre la presenza nei NAP nazionali come requisito per la fornitura del servizio in cloud è quindi un buon suggerimento. In subordine, si potrebbe prevedere che questo provider abbia la disponibilità ad attivare i peering sui NAP europei, dove la dorsale europea delle reti della ricerca GÉANT è presente con capacità molto elevate. L’altro requisito che noi consideriamo qualificante è la capacità di banda con cui si è presente nei punti di interscambio.

In ogni caso, quali che siano la soluzione tecnica prescelta e le capacità di banda passante coinvolte, avere delle politiche di routing appropriate o la disponibilità a modificarle in questo senso dovrebbe essere un requisito irrinunciabile per chi voglia proporsi come fornitore di cloud per la ricerca: non si tratta solo di ottimizzare le prestazioni, ma anche di proteggersi da alcuni problemi indipendenti dal nostro controllo che possono avere un impatto sui servizi in cloud pubblica o ibrida. In particolare, i DDoS più massivi sovraccaricano i link con gli upstream provider verso l’internet globale dai quali provengono la stragrande maggioranza degli attacchi. In assenza di politiche di routing e peering dedicati, i DDoS possono quindi avere un impatto molto significativo su questi servizi con evidente degrado delle prestazioni o addirittura della loro funzionalità anche quando non sono loro ad essere l’oggetto del DDoS.

Vendor lock-in: un rischio da evitare

Il secondo aspetto su cui bisogna avere le idee chiare quando si decide per una soluzione di cloud pubblico è il modello di trasferimento dei dati nel caso si cambi fornitore. Sia per motivi economici e contrattuali che per motivi tecnici e di requisiti che evolvono nel tempo è infatti possibile che si renda necessario cambiare fornitore, ma senza perdere i nostri dati ed applicazioni. I cloud provider si muovono in un regime di libero mercato e non hanno interesse a collaborare spontaneamente: al contrario, senza accordi ben precisi potrebbero rendere la vita difficile a chi vuole cambiare, è pertanto importante documentarsi in anticipo su quali garanzie vengano offerte in questo caso.

Quello dell’importazione e l’esportazione di dati da e verso fornitori di servizi cloud commerciali, è un tema preoccupante non solo sotto l’aspetto economico. Le grandi collaborazioni scientifiche in molti settori sono nella posizione di generare dati nell’ordine di centinaia di petabyte all’anno, ma molti fornitori addebitano un costo per spostare i dati al di fuori della loro cloud. Inoltre i collegamenti tra fornitori di cloud commerciale diversi sono spesso insufficienti per garantire condizioni ottimali per trasferimenti massivi né ci si aspetta in un prossimo futuro grande interesse da parte loro a incrementarli. Oltre agli aspetti economici, predominanti soprattutto nel caso si voglia cambiare fornitore senza perdere il proprio patrimonio di dati, vi sono quindi quelli legati all’efficienza e tempestività di questi trasferimenti ma la preoccupazione maggiore è legata al tema dell’interoperabilità.

Interoperabilità e collaborazione

L’interoperabilità in caso di collaborazione con altre organizzazioni che non usino la stessa infrastruttura cloud è l’ultimo punto di attenzione che vogliamo esaminare. Vi sono innumerevoli collaborazioni internazionali tra enti o infrastrutture di ricerca che potrebbero adottare diversi provider commerciali: in questo caso, è necessario garantire che dati e servizi sviluppati siano reciprocamente accessibili e fruibili. Secondo il modello per cui si paga per spostare il dato fuori dalla cloud del provider, queste collaborazioni si troverebbero a pagare due fornitori di servizi cloud contemporaneamente. Vi sono deroghe in scenari come quello di OCRE che potrebbero mitigare questo problema dal punto di vista economico, ma non sono sufficienti per garantire efficienza e interoperabilità e vi è un concreto rischio che questi scenari influiscano negativamente sulla FAIRness dei dati scientifici, limitandone l’accessibilità da parte dei ricercatori.

L’aspetto internazionale è fondamentale, anche perché l’ecosistema delle reti della ricerca è caratterizzato da soluzioni nativamente interoperabili in ambiente multidominio trans-nazionale e intercontinentale: oltre ad avere sempre maggiore controllo dell’infrastruttura, da sempre concordiamo e applichiamo politiche comuni per l’instradamento, l’accesso, la separazione dei traffici di trasferimento dati e per la qualità di servizio (QoS) applicata a certe tipologie di traffico (ad esempio, realtime). Tra reti della ricerca, lo sviluppo è concertato e governato, in modo da garantire la trasparenza e visibilità della rete, ma anche di attuare modifiche concordate quando se ne abbia la necessità ed ottimizzare le prestazioni di applicazioni transnazionali.

In conclusione: anche se ricorrere a un cloud provider commerciale può sembrare una soluzione semplice alle nostre esigenze, non è tutt’oro quello che luccica: se si intende utilizzare queste soluzioni per le proprie esigenze di ricerca, è necessario fare una valutazione attenta e consapevole, anche nell’ottica della collaborazone scientifica internazionale e questa valutazione va fatta “by design”, per capire se le scelte che stiamo facendo sono interoperabili e compatibili con gli obiettivi che ci siamo dati nella nostra organizzazione e per le nostre collaborazioni.