Implementazione di servizi cloud e multi-cloud (Parte II)
Nella prima parte (Parte I) di questa serie abbiamo descritto i concetti legati al termine "scaffold", delineato e analizzato le differenti fasi da attraversare durante il viaggio che si intraprende verso l'adozione del cloud.
In questa seconda parte, andremo a sviscerare i successivi due punti della nostra lista e cioè la Traduzione dei KPI aziendali in SLA cloud e l'Utilizzo dei framework di adozione del cloud per definire una vista comune tra i differenti cloud providers.
Traduzione dei KPI aziendali in SLA cloud
E' opinione comune che, l'infrastruttura nel cloud si possa trattare come una scatola nera per l'azienda ed il provisioning di risorse possa essere paragonato all'apertura di un rubinetto dell'acqua, probabilmente è anche per questo che alcune aziende IT si riferiscono all'operatività dell'infrastruttura cloud come ad un "IT liquido" o "fluido", è sempre li, basta aprire ed usare.
Di conseguenza, l'attenzione sugli SLA si è spostata sul business stesso. Poiché le aziende stanno avanzando nel processo di adozione, molte stanno adottando anche un diverso modo di lavorare. Se possiamo avere un'infrastruttura flessibile e agile nel cloud, possiamo anche accelerare lo sviluppo di ambienti e applicazioni. Tuttavia, anche qui, vanno considerati attentamente gli obiettivi relativi agli SLA ed i relativi KPI.
A questo diamo un'occhiata alla tematica SLA cloud. Quali sono di solito gli argomenti che devono essere trattati in uno SLA? La A sta per "Agreement" e, da un punto di vista legale, sostanzialmente può essere accomunato ad un contratto. Pertanto, uno SLA ha in genere il formato e i contenuti che appartengono ad un contratto. Ci saranno definizioni per la sua durata, la data di inizio, le persone giuridiche delle parti che stipulano l'accordo e gli orari di servizio. Più importanti sono gli accordi sui KPI, cosa ci aspettiamo dai servizi cloud che utilizziamo e per cui stiamo pagando? E chi contattiamo se qualcosa non va o abbiamo bisogno di supporto per un determinato servizio? Infine, qual è l'esatta destinazione del servizio?
Tutti argomenti abbastanza normali in qualsiasi contratto di servizio IT, tuttavia, non funziona allo stesso modo quando utilizziamo i servizi cloud pubblici. Il problema con lo SLA è che di solito è corretto per azienda. L'azienda contrae servizi IT, in cui il fornitore adatta i servizi alle esigenze di tale azienda, naturalmente, molti fornitori IT standardizzano e automatizzano il più possibile per ottenere la massima efficienza dei loro servizi, ma ciononostante c'è spazio per gli aggiustamenti custom e le ottimizzazioni. Nel cloud pubblico, tali aspetti sono molto limitati. Un'azienda avrà molti servizi tra cui scegliere per adattarli alle proprie esigenze, ma i singoli servizi sono come sono. In genere, i cloud provider, offrono SLA per servizio e la negoziazione dello SLA per servizio in un ambiente multi-cloud è praticamente impossibile.
Tutto riguarda la progettazione del servizio: l'azienda dovrà decidere di quali componenti ha bisogno per soddisfare le proprie esigenze e valutare se questi componenti sono adatti allo scopo. I componenti, cioè i servizi stessi, non possono essere modificati. Nel modello di servizio basato su IaaS avremo un margine di libertà maggiore, ma acquisendo soluzioni PaaS e SaaS, i servizi saranno preconfezionati e l'azienda dovrà assicurarsi che una soluzione SaaS, disponga realmente delle funzionalità richieste e fornisca i livelli di servizio richiesti.
I KPI comuni nell'IT sono la "availability" (disponibilità), la "durability" (durabilità nel tempo), il "Recovery Time Objective" o RTO (il tempo necessario per ripristinare un sistema in fault) e il "Recovery Point Objective" o RPO (la massima quantità di perdita di lavoro, in termini temporali, ritenuta accettabile), solo per citarne alcuni importanti. Come funzionano questi KPI nei principali cloud pubblici?
La availability è definita come il tempo totale per cui un determinato sistema può essere effettivamente utilizzato e dovrebbe essere misurata nell'interezza di un sistema, cioè, facendo un esempio concreto: Una macchina virtuale con un sistema operativo può essere attiva e funzionante, ma se si verifica un errore in una componente software in esecuzione su quella macchina e/o sul sistema operativo, l'applicazione sarà inutilizzabile e quindi non disponibile per l'utente. in pratica la VM e il sistema operativo sono attivi (e disponibili), ma l'applicazione è inattiva. Ciò significa che l'intero sistema non è disponibile e ciò può portare a gravi conseguenze. Quindi in sostanza, usando i numeri come riferimento, se la disponibilità di una applicazione o di un sistema in genere deve essere del 99,9%, ciò significa che la availability della piattaforma cloud e di ciascuna delle sue componenti costituenti il sistema o l'applicazione, non può essere inferiore a quel 99,9%.
Nei data center tradizionali, è necessario implementare soluzioni specifiche per garantire la availability, assicurando che la rete, i livelli di elaborazione e i sistemi di storage possano fornire la disponibilità richiesta. I cloud provider si occupano in gran parte di questo, anche se non si ottiene una garanzia di disponibilità complessiva su queste piattaforme, tali "hyperscaler" come ad esempio i più noti; Azure, AWS e Google Cloud, offrono livelli di servizio specifici per ciascuna componente presente nelle loro ampie offerte.
A titolo di esempio, una macchina virtuale ad istanza singola in Azure ha una connettività garantita del 99,9%, bisogna fare però attenzione ai termini qui: la connettività alla VM è garantita, ma insieme ad essa, sarà necessario predisporre dello storage di classe premium per tutti i dischi collegati alla VM, ed eventualmente poi aumentare il livello di availability dei sistemi distribuendoli su "Availability Zone" (AZ) e "Region" differenti tra quelle disponibili in Azure. Le "AZ" corrispondono a data center distinti in una stessa "region" di Azure che attualmente dispone di 58 differenti regions distribuite tra i diversi continenti.
In sintesi, è possibile fare in modo che un sistema in Azure sia sempre online da qualche parte nel mondo, ciò rende necessario uno sforzo maggiore nell'implementazione distribuita della soluzione, utilizzando il bilanciamento di carico e la corretta gestione del traffico sulla dorsale di Azure, ma tutto dipende da:
Non è un compito facile confrontare SLA tra i diversi provider, per la maggior parte dei servizi, i concetti di base sono tutti più o meno gli stessi, ma alcune differenze esistono comunque. Basta guardare il modo in cui Azure e AWS dettagliano i loro livelli di servizio relativamente alle componenti "compute" in particolare ai sistemi, in Azure, vengono denominati semplicemente VMs, mentre in AWS, sono denominato EC2, cioè per esteso Elastic Compute Cloud.
Entrambi i provider lavorano con i crediti di servizio se il tempo di attività mensile garantito delle istanze non è soddisfatto e, per essere chiari, l'infrastruttura di sistema (la macchina stessa!) non è disponibile. Se il tempo di attività scende al di sotto del 99,99% in un mese, il cliente riceve un credito di servizio del 10 percento durante il ciclo di fatturazione mensile. Google dal suo canto, calcola i crediti se la disponibilità scende al di sotto del 99,5%.
Di nuovo, i requisiti per gli SLA dovrebbero provenire dal business. Per ogni funzione aziendale e sistema corrispondente, i requisiti dovrebbero essere chiarissimi, e questo che alla fine guida l'architettura e la progettazione del sistema. Le piattaforme cloud offrono un'ampia varietà di servizi per comporre un progetto, permettendo di assicurarsi che i requisiti siano soddisfatti. Per dirla in termini leggermente più forti, gli hyperscaler offrono la possibilità di avere sistemi che sono in definitiva resilienti.
Laddove, nei data center tradizionali, il Disaster Recovey (DR) e la business continuity significano avere almeno un secondo data center, le piattaforme cloud offrono questi meccanismi come servizio. Ad esempio Azure, AWS e GCP sono piattaforme disponibili a livello globale, il che significa si possono effettivamente avere sistemi disponibili in tutto il mondo senza dover fare enormi investimenti. I data center sono lì, pronti per l'uso.
Ogni cloud provider dispone di soluzioni native per l'esecuzione del backup e la loro archiviazione in repository distribuiti in diverse regions oppure offrono soluzioni di terze parti dai loro portali in modo che tu possa continuare a utilizzare il tuo prodotto preferito.
Va comunque sottolineato ancora una volta che il business dovrebbe definire quali sono i propri servizi e sistemi critici, definendoli in termini RTO ed RPO. Sempre il business dovrebbe definire le metriche di DR e, cosa ancora più importante i processi, quando un piano di DR deve essere eseguito. Successivamente, spetta all'IT soddisfare questi requisiti con soluzioni tecniche. Come ad esempio mediante l'uso di un sistema warm standby, completamente speculare ai sistemi di produzione in una region primari, o utilizzare una region secondaria definendo anche quale. La conformità e le normative pubbliche come la GDPR o i frameworks di protezione dei dati nelle differenti parti del mondo svolgono un ruolo importante in queste decisioni.
Consigliati da LinkedIn
Un'opzione potrebbe essere quella di distribuire i sistemi di DR in una regione differente da quella ospitante i sistemi di produzione e sfruttarli per la produzione stessa in caso di eventi disastrosi. Ciò implica che i sistemi di DR siano identici o molto simili a quelli della produzione. Altre decisioni a carico dal business sono legate al tema backups, la loro tipologia (full, incrementali, etc.) e la loro frequenza, senza dimenticarne la retention, oltre a stabilire dove e come archiviarli. Tutto ciò è relativamente facile da implementare sul cloud, anche se, relativamente al tema economico occorre essere estremamente attenti nell'implementazione di ogni soluzione disponibile, il cui costo non è legato agli investimenti iniziali (annoverati quindi tra voci del CAPEX - CApital Expenditure) come con i data center tradizionali, nel caso del cloud verranno fatturati ogni mese come costi operativi (cioè tra le voci dell'OPEX OPerational Expenditure).
In breve, ogni attività o progetto nel cloud va attentamente pianificato.
Utilizzo di framework di adozione del cloud per definire una vista comune tra i differenti cloud providers
La parola magica nel mondo del multi-cloud è single pane of glass. cosa si vuole intendere con questo termine? Immaginiamo di avere un ambiente multi-cloud che comprenda un cloud privato basato su VMware, una piattaforma basata sul cloud pubblico AWS e di utilizzare contemporaneamente anche soluzioni SaaS di altri cloud provider. Come tenere traccia di tutto ciò che accade in questo enorme insieme di componenti distribuite? I differenti cloud provider sono responsabili di molte delle attività operative necessarie, come ad esempio, patch e aggiornamenti, mentre nelle soluzioni SaaS, il provider si occupa dell'intero stack, dagli host fisici sino ai sistemi operativi e al software stesso. Tuttavia, resteranno comunque diverse cose a carico dell'azienda, pensiamo alle questioni quali gli IAM e le policy di sicurezza, chi ha accesso a cosa e quando.
Questa è la nuova realtà legata alla complessità: ambienti multi-cloud composti da diverse soluzioni e piattaforme, ma come è possibile gestire tutto ciò? Gli amministratori dovrebbero monitorare e accedere i vari ambienti in uso mediante più strumenti di gestione e monitoraggio. Cosa che richiede certamente un elevato impegno e conoscenze dettagliate delle differenti piattaforme cloud. Di certo tale approccio non è tra i più efficienti. La cosa ideale dunque sarebbe avere un pannello di controllo unificato dal quale gestire ogni aspetto, piattaforma e componente come se appartenessero ad un unico grande ambiente distribuito.. quello che appunto abbiamo definito il "Single Pane of Glass".
Il single pane of glass è quindi "una console di gestione che presenta i dati provenienti da più fonti in un display unificato. Il "glass", in questo caso, è un monitor del computer o uno schermo di un dispositivo mobile." Il problema con questa definizione è che è puramente una definizione dal punto di vista tecnologico: solo un sistema che ha una visione di tutte le diverse componenti tecnologiche nel nostro panorama IT. Tuttavia, un single pane of glass va ben oltre il singolo sistema di monitoraggio, racchiude anche processi e automazione unificati, concetti fondamentali questi ultimi visto che se non disponiamo di un metodo unificato di automazione, avremmo comunque la necessità di mettere in campo un'elevata mole di lavoro legato all'automazione, all'implementazione e alla gestione delle risorse su un numero elevato di componenti in un panorama IT di tale entità.
Fortunatamente sistemi di gestione dei servizi IT completi che consentono di implementare il single panel of glass esistono, esempi molto validi sono: BMC Helix Multi-Cloud Management e ServiceNow con la piattaforma Now. e altre varie alternative, anche se i due menzionati possono essere considerati i leader di mercato, secondo il Magic Quadrant di Gartner per i sistemi ITSM.
Con riferimento all'ITSM: I tools e la tecnologia sono importanti, ma i processi lo sono altrettanto, se non addirittura in misura maggiore. La gestione dei servizi IT include, come minimo, i seguenti processi:
L'aspetto fondamentale dell'ITSM è la conoscenza: è necssario avere una visione indiscutibile di come appare la nostra piattaforma, come è configurata, che tipo di risorse poggiano e sono implementate su di essa. Gli asset e le risorse sono spesso indicati come elementi di configurazione e sono tutti raccolti e tracciati in un Configuration Management Database (CMDB) o Master Repository (Master Data Records, MDR). Qui, la sfida nel cloud inizia davvero, con risorse scalabili e flessibili o con risorse che esistono solo per un breve periodo di tempo, come i containers o le funzioni serverless, ci troviamo di fronte al rischio che il nostro CMDB o il nostro master repository non sia mai accurato come vorremmo che fosse, sebbene i principali sistemi ITSM forniscano API native per gli strumenti di monitoraggio nei diversi cloud provider, in grado di raccogliere i dati sugli assets in (quasi) tempo reale.
L'agilità del cloud rende la gestione del cambiamento probabilmente il processo più importante negli ambienti multi-cloud. Le pipeline per l'Infrastructure as Code e il Configuration as Code aiutano solo se abbiamo un processo chiaro sul forking del codice, sul suo testing, sulla sua convalida e sul suo nuovo merging nel master branch, in modo che ogni modifica sia completamente recuperabile. Se uno sviluppatore salta un passaggio del processo, si è destinati al fallimento e peggio, senza riuscire a capire cosa è andato storto.
Tutti i framework di adozione del cloud sottolineano l'importanza della governance e dei processi oltre alla tecnologia fornita dal cloud. Tutti i framework approcciano alla governance a partire dal business risk. e ciò ha il suo senso: se non si è d'accordo su come le cose nell'IT debbono essere fatte, sostanzialmente l'azienda è a rischio.
Fondamentalmente, l'obiettivo finale della gestione dei servizi è ridurre i rischi aziendali derivanti da una mancanza di governance IT, proprio per ciò, quest'ultima e l'ITSM sono il linguaggio comune tra i fornitori di tecnologia.
Tornando al Single Pane of Glass, ora abbiamo i nostri processi unificati, definiti in ITSM, nel cui dominio esistono diversi framework (ITIL o Cobit, per esempio), e tutti condividono gli stessi principi. Ciò è sufficiente ad avere un'unica dashboard per sfruttare l'ITSM, controllando il ciclo di vita di tutti i nostri asset e risorse? Abbiamo già menzionato BMC Helix e ServiceNow come strumenti tecnologici, ma questi forniscono anche l'automazione necessaria? In altre parole, possiamo avere un'automazione completamente multipiattaforma? da qui il concetto che Gartner chiama Hyperautomation.
Oggi l'automazione viene spesso eseguita per componente o, nel migliore dei casi, per piattaforma. In questo modo, è impossibile raggiungere l'obiettivo finale dell'automazione, ovvero ridurre al minimo le attività manuali ripetitive. Non stiamo riducendo il lavoro umano e, del resto, non stiamo riducendo il rischio di errore umano. Al contrario, stiamo introducendo più lavoro e di conseguenza aumentando il rischio di fallimento avendo l'automazione divisa in diversi insiemi di strumenti su piattaforme diverse, tutte con workflow, schedulazione e script separati. L'Hyperautomation nasce per automatizzare tutti i processi aziendali integrandoli in un unico ciclo di vita automatizzato, gestito da un'unica piattaforma di automazione.
Gartner definisce questo approccio come "Hybrid Digital Infrastructure Management" (HDIM). Il Machine Learning, il Robotic Process Automation (RPA) e il conseguente AIOps sono tecnologie chiave nell'HDIM, ed in questo ambito sempre Gartner prevede che l'AI-Enabled Automation e l'HDIM saranno sufficientemente avanzati per un'adozione su larga scala nel 2023.
In estrema sintesi, i cloud adoption frameworks di tutti i principali cloud providers supportano sostanzialmente gli stessi principi. Questo perché condividono il linguaggio comune di gestione dei servizi IT, questo aiuta le aziende che desiderano fruire appieno dei vantaggi del multi-cloud ad allineare i processi tra le piattaforme. L'unica sfida realmente complicate è l'implementazione della dashboard unificata per il controllo centralizzato delle varie piattaforme adottate e l'ottenimento di un'unica fonte di automazione tra esse: cioè l'Hyperautomation.
Con la velocità dell'innovazione nel cloud, tutto questo sta diventando sempre più complesso, ma gestibile attraverso gli strumenti e motori di automazione che arriveranno via via sul mercato nei prossimi anni, e l'ascesa nell'adozione dell'AIOps.
Qui si conclude la seconda parte di questa serie di articoli dedicati alla gestione del multi-cloud.