Una volta presa la decisione di far evolvere l'IT verso il cloud ibrido, il problema si sposta su come gestire il passaggio, quindi sulla decisione se fare in autonomia oppure comprare soluzioni che il mercato offre "già pronte" a fronte di un differente impegno di tempo e denaro. Se da una parte l'approccio "fai da te" consente di minimizzare l'investimento, dall'altro appare estremamente vantaggioso poter disporre di soluzioni pre-ingegnerizzate e preconfigurate per l'hybrid cloud. L'approccio "buy" riduce il numero dei fornitori, i tempi di rilascio e di test e, in generale, di trasformazione dell'IT aziendale mentre i tempi del "fai da te" dipendono molto dalla capacità tecnica dello staff che si ha in casa. In ogni caso, ogni azienda ha le proprie peculiarità e il percorso verso l'hybrid cloud non può essere univoco. È, quindi, fondamentale, prima di intraprendere questa strada, compiere un approfondito assessment tecnologico e organizzativo, comprendendo realmente le esigenze del business nell'ambito del contesto competitivo di riferimento.

I casi d'uso dell'hybrid cloud

Un aspetto chiave della migrazione al cloud ibrido è quello relativo a quante e quali applicazioni migrare nella nuvola: tutte quelle esistenti, oppure solo quelle nuove, già progettate per sostenere e ottimizzare gli ambienti cloud ibridi? In generale, è soprattutto nei progetti e sistemi cosiddetti "greenfield" (cioè quelli in cui si può partire senza dover considerare implementazioni precedenti e applicazioni legacy) che diventa conveniente disaggregare le funzionalità di un'applicazione, distribuendole su cloud pubblici e privati: ad esempio, le attività di elaborazione su cloud pubblico e i dati sulla nuvola privata. Una pratica diffusa è l'uso di servizi cloud pubblici per realizzare una sorta di data center con funzionalità di disaster recovery (DR) o continuità operativa (BC) che opera come infrastruttura di backup per un cloud privato. Ma esistono anche alcune implementazioni di cloud ibrido più evolute e complesse, che implicano la suddivisione delle funzioni dell'applicazione tra differenti cloud. In questo scenario, alcuni componenti (spesso i data store e le directory di autenticazione o autorizzazione) girano in un private cloud, mentre altri componenti, come i front end web, il middleware applicativo e i motori di analisi dei big data (Hadoop, Spark, ecc.), girano sul cloud pubblico. Anche qui bisogna fare attenzione perché se è vero che questa implementazione ibrida mira a fondere il meglio dei due mondi (ossia abbinare lo stretto controllo sulla sicurezza dei dati e dell'utente che l'infrastruttura privata fornisce con la scalabilità dinamica tipica dei servizi cloud pubblici) occorre sempre considerare l'ulteriore difficoltà di gestione del cloud ibrido, derivante dal fatto di disaccoppiare i dati e le attività di elaborazione nei sistemi legacy.

Cosa migrare (e come)

Un recente report di Forrester fornisce consigli su come progettare l'introduzione dell'hybrid cloud in azienda, giustificandolo con effettivi vantaggi in termini di risparmi economici e aumento della competitività di business.

Premesso che nell'IT non esistono modelli validi per tutte le circostanze, lo studio invita prima di tutto a valutare l'efficienza offerta dai diversi ambienti IT ipotizzati (sia di tipo tradizionale, sia cloud) a fronte degli obiettivi che ci si pone con le nuove iniziative di business. I Systems of Records – sistemi che memorizzano e garantiscono la fornitura di grandi quantità di dati necessari per lo svolgimento di processi cruciali di business, come la gestione finanziaria, quella dei cicli attivi e passivi o dei magazzini – sono destinati nella maggior parte dei casi a restare on premise. Questi sistemi, come gli ERP, tendono a consolidare dati provenienti dall'interno e dall'esterno dell'azienda in pochi grandi database. Le applicazioni che utilizzano questi dati hanno bisogno di interagire in modo continuativo e alla minore latenza possibile con le fonti di dati. Allo stesso tempo, trattandosi soprattutto di dati strutturati, lo storage deve essere sì performante, ma la scalabilità necessaria può essere facilmente prevedibile. Questo fatto, unito a quello della permanente necessità di queste tecnologie, può giustificare la scelta di effettuare investimenti in conto capitale (CapEx) per l'acquisto di tecnologie, piuttosto che adottare un approccio pay-per-use (OpEx).

Diverso è il caso di un'azienda nata da poco (startup), che non disponga ancora di Systems of Records interni. Quest'ultima potrebbe trarre vantaggi dal non installare sistemi transazionali all'interno delle proprie mura, ma optare per business application erogate in modalità SaaS e un'infrastruttura scalabile e gestibile in modalità fluida (IaaS), orchestrando le capacità e i servizi di provider differenti.

I Systems of Engagements si prestano molto bene alla fruizione in cloud. A differenza dei grandi sistemi transazionali, una buona parte di essi tende a essere utilizzata in modo non continuativo ma "intermittente" (si pensi, per esempio, alle applicazioni con cui vengono comunicate le promozioni in corso nelle vetrine dei negozi) e può, quindi essere spostata nel data center virtuale di un cloud provider ma integrata con l'ERP gestito in casa o "appaltato" a un provider diverso.

Un altro esempio di attività che può trarre vantaggio dall'integrazione di ambienti cloud pubblici con i sistemi informativi on premise è quello delle soluzioni di sviluppo e testing delle nuove applicazioni.

La politica dei "piccoli passi"

Nella gestione delle iniziative di cloud ibrido è consigliabile partire con progetti di piccole dimensioni, che l'azienda utente è in grado di controllare meglio e completare nel giro di qualche settimana. Questa strategia permette anche di ridurre i rischi, sviluppare con gradualità le competenze cloud richieste, identificare i cambiamenti necessari nei processi IT e preparare lo staff per le nuove respon sabilità.

Chi migra verso il cloud ibrido non può, poi, esimersi dal ridefinire i ruoli e responsabilità dell'IT, per ottemperare ai cambiamenti e agli obblighi che si hanno quando si utilizzano servizi nella nuvola. Un aspetto chiave è relativo alla necessaria formazione del personale sulle nuove competenze richieste dal cloud: secondo i dati dell'Osservatorio Cloud & ICT as a Service quelle più richieste (citate dal 52% degli intervistati) sono relative alla gestione delle architetture enterprise, seguite dalle capacità di collaborare con le LOB (47%), gestire la sicurezza (38%) e i fornitori (36%). È fondamentale, poi, monitorare con attenzione l'uso della nuvola, per stimare con cura i costi dei servizi.

L'IT gestito in autonomia: il ruolo dei portali self-service

Il provisioning self service rappresenta il cuore pulsante del cloud computing e di quello ibrido in particolare. I servizi di hybrid cloud sono un aggregato di diversi elementi: macchine virtuali, settaggi a livello di rete, indirizzi IP, indirizzi DNS (Domain Name Systems), settaggi a livello di firewall e bilanciatori dei carichi di lavoro (load balancer). Questo insieme di elementi genera solitamente (al variare del loro mix) un certo numero di servizi cloud diversi, che saranno a loro volta oggetto di una configurazione specifica in relazione ai diversi casi d'uso. In linea di principio le funzionalità di provisioning in modalità autonoma includono diverse opzioni di configurazione del servizio in termini di definizione, per esempio, dello spazio su disco o del numero di nodi utilizzabili, così come altre possibili personalizzazioni a livello di configurazione dei firewall.

Con il cloud self service, gli utenti accedono a un portale web based dal quale potranno richiedere o configurare server o lanciare applicazioni. In questi casi, tutto è automatizzato per sollevare il dipartimento IT dai compiti più ripetitivi e gravosi. Questo approccio assicura una trasparenza di gestione puntuale, fornendo agli utenti finali accesso diretto al cloud in base alle loro necessità. Le funzionalità più spesso gestibili in modalità self service sono legate alla migrazione delle applicazioni, al provisioning automatico delle macchine virtuali e al monitoraggio delle prestazioni. Il tutto gestibile in modo intuitivo, attraverso template e meccanismi di spostamento drag-and-drop che permettano una selezione rapida dei servizi identificati e corredato da una forte componente grafica, che consente di avere una visione d'insieme dell'andamento, per esempio, delle prestazioni di un'applicazione facilmente condivisibile con gli altri utenti interni all'azienda.

Un portale è, di fatto, una finestra che si affaccia su un elenco di funzionalità IT preconfigurate e disponibili "su richiesta". I portali cloud stanno diventando molto popolari, tanto che secondo Forrester, il 46% delle grandi e grandissime aziende li stanno adottando per gestire i propri data center interni e i servizi erogati in cloud agli end user. Molti provider offrono opzioni di "accesso on the go" ai propri portali self service, supportando gli ambienti operativi mobile più diffusi come Android e iOS tanto che lo stesso analista stima che circa il 25% degli utenti di portali cloud sia rappresentato da accessi mobile, destinato a salire nei prossimi anni.

I portali self service vanno, quasi sempre, abbinati ai cataloghi dei servizi, che non solo forniscono un elenco descrittivo dei servizi preconfigurati e disponibili immediatamente per gli utenti (identificati sulla base delle policy aziendali), ma spesso includono funzionalità automatizzate di fatturazione dei consumi al singolo centro di costo, al dipartimento o anche al singolo utente. In area storage, le funzionalità "fai da te" vanno dal settaggio automatico delle policy di deduplica attraverso un'interfaccia di tipo grafico, quindi particolarmente intuitiva e facile da usare, alla sincronizzazione automatica dei file su diversi dispositivi e ambienti – PC, Mac, file server, cloud –. Il portale deve abilitare una serie di funzionalità chiave per gli IT manager che comprenda, al minimo, un sistema di tracciamento delle performance delle applicazioni, funzionalità di ottimizzazione della configurazione dei servizi cloud e del load balancing.

Gli sviluppatori richiedono, invece, una consolle facile da utilizzare per identificare e selezionare i template di servizi che intendono mettere a disposizione dei propri utenti finali, mentre sono meno interessati a tutte le configurazioni relative alle performance delle applicazioni o alle opzioni di pagamento dei servizi richiesti. Generalmente, la scelta dei provider è di affidarsi, per la creazione del proprio portale di abilitazione self service, a tecnologie e linguaggi di programmazione e automazione ampiamente condivisi e standardizzati, come DevOps. Quest'ultimo rappresenta, ormai, la scelta d'elezione per le piattaforme di automazione dei servizi IT cloud-centriche. L'integrazione stretta che DevOps rende possibile tra gli ambienti cloud pubblici e privati, infatti, riduce sensibilmente i costi di deployment del cloud ibrido e assicura una governance e un controllo centralizzati di tutti i servizi in uso. Inoltre permette di stimare e imputare in modo puntuale l'utilizzo delle risorse nella nuvola al singolo reparto, applicazione, utente o categoria di dati.

Come sottolineato dai dati dell'Osservatorio Cloud & ICT as a Service, anche in Italia si assiste alla progressiva, massiccia, diffusione dei servizi di cloud ibrido e alla conseguente maggior richiesta di ambienti che permettano di integrare e rendere interoperabili sistemi differenti e servizi erogati da una pletora di provider diversi. Il trend delineato impone un ripensamento del ruolo del Chief Information Officer, che dovrà essere coinvolto direttamente nelle modalità di realizzazione di queste nuvole ibride, nella scelta dei provider che verranno coinvolti e, soprattutto, nella definizione delle policy di accesso automatico ai microservizi disponibili sui portali self service che, ormai pare assodato, spopoleranno nel prossimo futuro.

18 giugno 2018