La visione di AWS sul cloud ibrido

In un momento storico in cui è evidente che le multinazionali si stanno tutte muovendo verso il cloud, siamo costretti a porci il problema di come definire una sua architettura. Purtroppo, il modello iniziale che vedeva il cloud come un unico sistema distribuito indistinguibile non è più sostenibile, e la colpa di tutto questo è dei dati. Ce ne ha parlato Chiara Bradle (Principal solution architecture AWS) durante l’AWS Summit Milano, illustrandoci la visione di AWS relativa al cloud ibrido.

Perché i dati sono un problema?

I dati sono un problema all’interno di un’architettura cloud a causa del loro spostamento. Ora che la tecnologia del cloud è più matura e consolidata le grandi realtà aziendali si sono rese conto che è necessario prendere delle decisioni su quali dati spostare e come spostarli.

L’elaborazione delle informazioni è preferibile farla dove l’uso delle CPU virtuali è economico. Tuttavia, è anche vero che ci sono dei dati che abbiamo bisogno di elaborare per ottenere delle risposte in tempo reale. Se la parte di cloud dove il tempo di CPU è a buon mercato si trova molto lontano da noi, allora abbiamo bisogno di trovare un compromesso.

A quanto appena detto si aggiunge anche la problematica dei dati sensibili. Alcuni dati, per legge (e questo non vale solo per il nostro Paese) non possono uscire dai confini nazionali. Altri, invece, devono essere ben localizzati per poter essere ispezionabili; come nel caso dei sistemi dedicati alla Magistratura nel Data Center di un operatore telefonico.

I fornitori di servizi cloud, tra i quali AWS ricopre nettamente un ruolo di spicco, hanno recepito queste problematiche. Di conseguenza, propongono ai propri clienti delle soluzioni tecnologiche dinamiche in grado di combinare i sistemi a casa del cliente con il cloud classico. Stiamo parlando del cosiddetto cloud ibrido.

Il cloud ibrido secondo AWS: Cloud Continuum

AWS ha battezzato la sua soluzione architetturale per il cloud ibrido con il nome di Cloud Continuum. Continuum sta a significare che la transizione tra i sistemi nel Data Center del cliente e l’architettura cloud centrale (la cosiddetta AWS Region) deve svolgersi senza soluzione di continuità.

La proposta Cloud Continuum vede diverse soluzioni tecnologiche, principalmente a seconda della latenza tollerabile per accedere alle informazioni.

Outpost

In pratica, AWS installa un sistema di calcolo nel Data Center del cliente. Questo sistema di calcolo (sarebbe riduttivo chiamarlo server) contiene gran parte dei servizi che si trovano nella AWS Region. In più, un Outpost è una specie di scatola nera. Le applicazioni del cliente lo usano esattamente come userebbero una AWS Region, ma siccome i dati solo locali all’infrastruttura i tempi di accesso quasi inesistenti.

Un altro aspetto positivo di un Outpost, essendo indistinguibile dalla AWS Region, è che diventa possibile usarlo per sviluppare dei servizi personalizzati. Questi servizi potranno poi essere spostati nella Region di riferimento senza nessun tipo di problema.

Local Zone

Una Local Zone è una possibile soluzione per quei dati per cui posso permettermi un po’ di latenza nell’accesso ai dati ma non è desiderabile arrivare fino alla AWS Region. Una Local Zone non si colloca dal cliente ma si trova nel Data Center di una terza parte (solitamente un operatore di rete) per servire più clienti sul territorio circostante.

La grande capacità computazionale e di storage rispetto ad un Outpost unita a dei tempi di accesso ridotti rendono possibili una serie di casi d’uso che arrivano fino alla multimedia in tempo reale e ai giochi in streaming. In generale, si parla di latenze inferiori al 10 millisecondi.

Uno sguardo al 5G

Capita spesso che sia necessaria una latenza limitatissima soprattutto in mobilità. La rete 5G fa esattamente questo attraverso il concetto di Edge Computing. La proposta di AWS per cloud ibrido, in questo caso, prende il nome di Wavelength. Wavelength non viene fornito da AWS in autonomia ma vede sempre una partnership con un operatore di telefonia mobile. I casi d’uso, come prevedibile, sono gli stessi della Local Zone. Tuttavia, si ottiene un guadagno in termini di tempo per il fatto che il traffico non lascia mai la rete 5G fino a che non raggiunge il primo punto di elaborazione.

Cloud disconnesso

Fino a ora abbiamo parlato di soluzioni a latenza sempre più bassa. Ma che succede se ci troviamo dall’altra parte dello spettro? Ovverosia, cosa succede se abbiamo a che fare con dei dispositivi non sempre connessi o in condizioni di rete instabile? Potrebbe essere il caso, per esempio, di un drone impegnato in una raccolta dati su un territorio particolarmente sfavorevole.

In questo caso è necessario ci sia una prima elaborazione locale per poi trasferire i dati in maniera opportunistica (quando se ne presenta l’occasione) verso il cloud. AWS propone una serie di dispositivi fisici chiamati Snow Family. Questi dispositivi sono particolarmente resistenti in quanto pensati per operazioni sul campo. Raccolgono dati localmente e forniscono anche una decente capacità di elaborazione. Un dispositivo della Snow Family può essere poi trasportato (o spedito) dove c’è presenza di connettività per sincronizzarsi con il resto del cloud.

Anche IoT è cloud

Nel contesto del cloud disconnesso, i dispositivi Internet of Things rappresentano un problema aggiuntivo. Non solo per la grande quantità di dati raccolti, che necessitano di elaborazione locale. Ma soprattutto a causa di una connettività ridotta e un disponibilità hardware minimale. Per i dispositivi IoT, la proposta di AWS si chiama AWS IoT Greengrass. Greengrass è un middleware in grado di gestire il software sui singoli dispositivi e di collezionare i dati raccolti per poi incanalarli vero la Region più vicina.

Enel come caso di studio

L’ultima parte dell’intervento vede sul palco Marco Pennacchioni (Digital Project Manager, Enel Green Power – Global Digital Solutions) che racconta l’esperienza di Enel nell’usare Greengrass per i processi di manutenzione degli impianti in aree disagiate; soprattutto per le attività robotizzate.

L’esempio portato al pubblico è stata la verifica dell’integrità di pannelli solari. Un drone equipaggiato con Greengrass sorvola i pannelli con una telecamera e raccoglie i dati. Quando possibile, viene richiesta una valutazione con sistemi di intelligenza artificiale a un dispositivo Snow Family locale. Nel momento un cui viene rilevata un’anomalia, questa è subito segnalata all’operatore che, tramite smartphone, innesca il processo di manutenzione attraverso il cloud della Region.

L’adozione di Greengrass, ci spiega Pennacchioni, ha permesso a Enel di ridurre i tempi di intervento sulle installazioni remote da una durata media misurata in mesi a una misurata in giorni se non addirittura ore.