Per cloud ibrido si intende una modalità, coordinata e ‘policy-based’, di gestione, utilizzo e provisioning dei servizi IT nell’ambito di un insieme di servizi cloud interni ed esterni. La definizione è della società di ricerche di mercato Gartner, che proprio di recente ha fatto una nuova previsione: per il 2020, il 90% delle organizzazioni adotterà servizi di infrastruttura ibrida.
La crescita del cloud e il declino del tradizionale data center outsourcing (DCO) indicano infatti, secondo Gartner, una massiccia transizione verso servizi di infrastruttura ibrida. Più in dettaglio, stando alle stime della società, il tradizionale mercato DCO a livello mondiale sta restringendosi, con una spesa che è prevista in declino, passando dai 55,1 miliardi di dollari del 2016, ai 45,2 miliardi di dollari del 2020. I servizi cloud, d’altra parte, sono previsti in forte espansione: dai 23,3 miliardi di dollari del 2016, arriveranno a 68,4 miliardi di dollari nel 2020.
Via via che la domanda di agilità e flessibilità cresce, ha dichiarato DD Mishra, Research Director di Gartner, le organizzazioni che adottano un’infrastruttura ibrida potranno ottimizzare i costi e incrementare l’efficienza. Tuttavia, questa transizione non sarà facile, perché essa incrementa anche la complessità di selezione del corretto insieme di strumenti per fornire servizi ‘end-to-end’, in un ambiente in cui le risorse IT vengono sempre più approvvigionate in maniera composita, attingendo da molteplici fonti.
Cloud ibrido, il modello migliore di IT
Nel caso specifico del cloud ibrido, un dato emerge con evidenza da un’indagine di RightScale (RightScale 2017 State of the Cloud Report) sullo stato del cloud nel 2017: il modello ‘hybrid cloud’ risulta essere la strategia enterprise preferita dal 58% delle organizzazioni, con un 85% delle imprese che ha una strategia multi-cloud, in salita rispetto all’82% del 2016 (figura 1). Ma attenzione: prima di cedere a facili entusiasmi e partire subito con un progetto è meglio valutare con attenzione i passi chiave da compiere per arrivare all’obiettivo.
Fonte: RightScale 2017 State of the Cloud Report
Proprio perché, come prima si accennava, il viaggio verso la realizzazione di un’infrastruttura cloud ibrida non è banale, è bene che gli amministratori di tali ambienti ne siano consapevoli, apprendendo quelle ‘best practice’ utili a riconoscere, ed evitare, sbagli ed errori comuni, già commessi in implementazioni cloud precedenti.
Cosa bisogna tenere presente nel progetto di cloud ibrido
Giusto per citare un esempio, una pratica diffusa di creazione del cloud ibrido è l’uso di servizi cloud pubblici per realizzare una sorta di data center, con funzionalità di disaster recovery (DR) o continuità del business (BC), che opera come infrastruttura di backup per un cloud privato. Qui però va chiarita una differenza sostanziale tra DR e BC: mentre nell’infrastruttura di business continuity il public cloud è sempre attivo, nel caso del disaster recovery la nuvola pubblica resta in stand-by, e viene attivata solo durante un’interruzione del servizio. In entrambi i casi, comunque, occorre tenere ben presente che l’intera infrastruttura richiesta per far funzionare le applicazioni colpite dev’essere dispiegata, o preconfigurata e pronta per essere attivata, su entrambi i cloud, pubblici e privati.
Un altro esempio sono le 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 distribuiti 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.
Le decisioni strategiche per l’adozione di un cloud ibrido
Quando si pianifica l’adozione di un cloud ibrido, un punto chiave è ad esempio valutare se è il caso di suddividere e migrare tutte le applicazioni esistenti, oppure soltanto quelle nuove, progettate per gli ambienti ibridi. In genere è 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 su nuvola privata.
Nel caso in cui si voglia usare il cloud pubblico come sito di ripristino, per esempio scegliendo Microsoft Azure come sito DR/BC basato su nuvola ibrida, il servizio Azure Site Recovery è in grado di automatizzare processi come l’inventario e la replica delle macchine virtuali (VM), dei dati, e il dispiegamento del servizi.
IaaS o PaaS: quali servizi scegliere
Quando si realizzano nuove applicazioni, l’opzione può essere scegliere un servizio IaaS (infrastructure as a service) o PaaS (platform as a service). Se si sceglie quest’ultimo (ad esempio una delle offerte Azure App Service, Google App Engine o IBM Bluemix) può diventare più agevole la fruizione di servizi cloud evoluti, tra cui, solo per citarne alcuni: i database gestiti, gli strumenti di analisi di big data, o le funzionalità di apprendimento automatico (machine learning). Infatti, le piattaforme PaaS sollevano gli sviluppatori dai problemi che riguardano la selezione dell’infrastruttura di runtime, consentendo loro di focalizzarsi sulla progettazione del database e dell’applicazione. Va però anche precisato che l’uso di servizi PaaS può accrescere il rischio del cosiddetto ‘cloud provider lock-in’, ossia, incrementare la dipendenza tecnologica da un determinato fornitore cloud. Questo perché un PaaS provider, nel fornire il proprio servizio PaaS, può utilizzare tecnologie proprietarie, che diventano limitazioni quando l’utente, in seguito, decide di migrare l’applicazione verso altre piattaforme cloud: ad esempio, il servizio PaaS Google App Engine (GAE) utilizza API (application programming interface) proprietarie di Google, che rendono problematico migrare l’applicazione verso altri servizi PaaS, come quelli di Cloud Foundry o Microsoft Azure.
Invece, la scelta del modello IaaS appare in genere più appropriata quando si deve far migrare verso il cloud applicazioni client-server proprietarie (legacy).
Quali sono gli errori da evitare nel passaggio al cloud
Figura 2
Lo stato delle implementazioni cloud
Fonte: RightScale 2017 State of the Cloud Report
Passare al paradigma del cloud ibrido comporta trasformazioni che, se non affrontate con la corretta impostazione, possono creare in seguito debolezza e vulnerabilità nell’infrastruttura IT aziendale, e mettere a rischio la stabilità del business. Pertanto, è utile enumerare qualche aspetto chiave da non trascurare durante il processo di migrazione verso la nuvola ibrida.
Una prima raccomandazione è di non dimenticare di completare un’attenta analisi del contratto di servizio o SLA (service level agreement). Ad esempio, l’azienda utente di servizi cloud deve cercare di raccogliere e comprendere quanti più dettagli possibile riguardo la modalità operativa del cloud provider: è importante stabilire se i servizi erogati soddisfano i requisiti richiesti in termini di prestazioni, disponibilità e protezione dei dati; quali sono le metriche per misurare l’utilizzo e le performance dei servizi; e anche comprendere nel dettaglio quali sono i ruoli, le responsabilità e le conseguenze in caso di non conformità dei servizi stessi. Non meno importante è stabilire quali misure il cloud provider predispone per proteggere l’utente in caso di perdite di dati, ma anche quali sono le sue politiche sui dati raccolti circa il funzionamento dell’infrastruttura, e quali sono le opzioni disponibili in caso si desideri migrare i propri dati e le misurazioni raccolte dal provider su un altro servizio cloud o su un data center interno.
Bisogna preferire piccoli progetti a breve termine
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, di sviluppare con gradualità le competenze cloud richieste, di identificare i cambiamenti necessari nei processi IT e di preparare lo staff per le nuove responsabilità.
Ancora, chi migra verso il cloud ibrido non può, come accennato, evitare di ridefinire i ruoli e responsabilità dell’IT, per ottemperare ai cambiamenti nei doveri e obblighi che si hanno quando si utilizzano servizi nella nuvola. Altri aspetti chiave spaziano dalla necessità di formazione del personale sulle nuove competenze richieste dal cloud; all’importanza di monitorare con attenzione l’uso della nuvola, per stimare con cura i costi dei servizi; alla criticità di non creare progetti DR incompleti, incapaci di coprire e proteggere tutta l’infrastruttura e le fonti di dati. Non certo per ultimo viene il tema security: le politiche di sicurezza IT vanno tradotte e migrate nell’infrastruttura cloud, perché l’uso dei servizi nella nuvola cambia la modalità d’implementazione delle misure di protezione e, se non correttamente indirizzato, può dar luogo allo sviluppo di nuove falle e vulnerabilità.
