L'aumento della potenza di calcolo e lo sviluppo delle tecnologie di virtualizzazione della piattaforma x86 da un lato, e la diffusione dell'outsourcing IT dall'altro, hanno portato al concetto di utility computing (IT come servizio pubblico). Perché non pagare per l'IT come per l'acqua o l'elettricità: solo quanto e quando necessario, e non di più.
È in questo momento che è emerso il concetto di cloud computing: il consumo di servizi IT dal "cloud", ovvero da un pool esterno di risorse, senza preoccuparsi di come e da dove provengano queste risorse. Proprio come non ci preoccupiamo dell'infrastruttura delle stazioni di pompaggio dell'acqua. A quel punto, è stato sviluppato anche l'altro aspetto del concetto: vale a dire la definizione dei servizi IT e come gestirli nel contesto di ITIL / ITSM.
È stata elaborata una serie di definizioni per i cloud (per il cloud computing), ma non bisogna considerarli come verità assolute - sono solo un modo per formalizzare le modalità di erogazione dell'utility computing.
- «Il cloud computing è una tecnologia di elaborazione distribuita dei dati in cui le risorse e le capacità informatiche sono fornite all'utente come servizio Internet.» Wikipedia
- «Il cloud computing rappresenta un modello per fornire un accesso di rete conveniente a una risorsa computazionale condivisa e configurabile (come reti, server, sistemi di archiviazione dati, applicazioni e servizi) su richiesta, che può essere rapidamente allocata e fornita con il minimo sforzo gestionale o intervento da parte del fornitore di servizi.» NIST
- «Il cloud computing è una paradigma per fornire accesso di rete a un pool scalabile e flessibile di risorse fisiche o virtuali distribuite, fornite in modalità self-service e gestite on demand.» ISO/IEC 17788:2014. Tecnologie dell'informazione — Cloud computing — Panoramica e vocabolario.
Secondo NIST, ci sono tre principali tipi di cloud:
- IaaS – Infrastructure as a Service — Infrastruttura come servizio
- PaaS – Platform as a Service — Piattaforma come servizio
- SaaS — Software as a Service — Software come servizio
Per una comprensione semplificata della differenza, consideriamo il modello Pizza-as-a-Service:
Il NIST definisce le seguenti caratteristiche necessarie per un servizio IT affinché possa essere considerato cloud.
- Accesso alla rete universale (broad network access) – il servizio deve avere un'interfaccia di rete universale che consenta a chiunque di collegarsi e utilizzare il servizio con requisiti minimi. Ad esempio, per utilizzare una rete elettrica a 220V basta collegarsi a qualsiasi presa con un'interfaccia universale standard (spina), che non cambia che si tratti di un bollitore, di un aspirapolvere o di un laptop.
- Misurabilità del servizio (measured service) – una caratteristica chiave del servizio cloud è la misurabilità del servizio. Ritornando all'analogia con l'elettricità, pagherai esattamente quanto hai consumato con la granularità minima, fino ai costi per far bollire un bollitore, se sei stato in casa solo una volta al mese e hai bevuto una tazza di tè.
- Configurazione autonoma dei servizi su richiesta (on demand self service) – il fornitore cloud offre al cliente la possibilità di configurare il servizio in modo ragionevole, senza la necessità di interagire con il personale del fornitore. Per accendere un bollitore non è necessario contattare in anticipo il fornitore di energia per informarli e ricevere il permesso. Una volta che la casa è collegata (contratto stipulato), tutti i consumatori possono gestire autonomamente la potenza fornita.
- Elasticità istantanea (rapid elasticity) – il fornitore cloud offre risorse con la possibilità di aumentare o diminuire immediatamente la potenza (entro limiti ragionevoli). Non appena il bollitore è acceso, il fornitore eroga immediatamente 3 kW di potenza in rete, e non appena è spento, riduce l'erogazione a zero.
- La combinazione delle risorse in un pool (resource pooling) – i meccanismi interni del fornitore di servizi consentono di unire singole capacità di generazione in un pool comune di risorse, offrendo successivamente queste risorse come servizio a vari utenti. Compreso il kettle, a noi interessa poco da quale centrale elettrica proviene la potenza. E tutti gli altri utenti consumano questa potenza insieme a noi.
È importante comprendere che le caratteristiche del cloud sopra descritte non sono arbitrarie, ma sono una logica conseguenza del concetto di utility computing. E un servizio pubblico deve possedere queste caratteristiche nel contesto di questo concetto. Se una caratteristica non è rispettata, il servizio non diventa automaticamente peggiore o 'tossico', semplicemente smette di essere un servizio cloud. E chi ha detto che tutti i servizi devono esserlo?
Perché ne parlo separatamente? Negli ultimi 10 anni, dal momento in cui è stata introdotta la definizione NIST, ci sono stati molti dibattiti su cosa significhi "vera nuvola" secondo quella definizione. Negli Stati Uniti, a volte si usa ancora in ambito legale l'espressione "corrisponde alla lettera della legge, ma non allo spirito" — e nel caso del cloud computing, ciò che conta è proprio lo spirito: risorse affittate con due clic del mouse.
È importante notare che le 5 caratteristiche sopra elencate si applicano al cloud pubblico, ma nel passare al cloud privato, la maggior parte di esse diventa opzionale.
- Accesso universale alla rete (broad network access) – all'interno del cloud privato, l'organizzazione controlla completamente sia le risorse generatrici sia i clienti-consumatori. Pertanto, questa caratteristica può essere considerata automaticamente soddisfatta.
- La misurabilità del servizio (measured service) è una caratteristica chiave del concetto di utility computing, ovvero il pagamento in base al consumo effettivo. Ma come può un'organizzazione pagare a se stessa? In questo caso, si divide la generazione e il consumo all'interno dell'azienda: l'IT diventa un fornitore e le divisioni aziendali consumatori di servizi. E il compenso avviene tra le divisioni. Possono esistere due modalità operative: chargeback (con compensi reali e movimento di fondi) e showback (sotto forma di report sui consumi di risorse in rubli, ma senza movimento di fondi).
- La configurazione autonoma dei servizi su richiesta (on demand self service) – all'interno dell'organizzazione può esserci un'unica struttura IT, e in questo caso la caratteristica perde senso. Tuttavia, in presenza di propri specialisti IT o amministratori di applicazioni nelle divisioni aziendali, è necessario organizzare un portale di self-service. In sintesi, la caratteristica è opzionale e dipende dalla struttura del business.
- L'elasticità rapida perde significato all'interno dell'organizzazione a causa della rigidità dell'hardware per il cloud privato. Può essere applicata in modo limitato per i regolamenti interni. Conclusione: non è applicabile al cloud privato.
- Il pooling delle risorse è ormai una caratteristica standard, poiché praticamente tutte le organizzazioni utilizzano la virtualizzazione dei server.
Domanda: Che cos'è esattamente il vostro cloud privato? Cosa deve acquistare e implementare un'azienda per costruirlo?
Risposta: il cloud privato rappresenta una nuova modalità di interazione tra IT e business, composta per l'80% da misure amministrative e solo per il 20% da tecnologie.
Il pagamento solo per le risorse consumate e la facile accessibilità, senza la necessità di investire milioni in costi di capitale, hanno creato un nuovo panorama tecnologico e hanno permettendo la nascita di aziende miliardarie. Per esempio, giganti moderni come Dropbox e Instagram sono emersi come startup su AWS con zero infrastruttura propria.
È importante sottolineare che gli strumenti di gestione dei servizi cloud stanno diventando significativamente più indiretti, e una delle principali responsabilità del Chief Information Officer è la selezione dei fornitori e il controllo della qualità. Esaminiamo la problematica di queste due nuove responsabilità.
Nato come alternativa all'infrastruttura tradizionale con datacenter e hardware proprietari, i servizi cloud appaiono sorprendentemente semplici. È facile accedere al cloud, ma la questione dell'uscita viene spesso trascurata. Come in qualsiasi altro settore, i fornitori cloud mirano a proteggere il proprio business e complicare la concorrenza. Il vero momento competitivo si presenta solo nella scelta iniziale del fornitore di servizi cloud; successivamente, il fornitore farà di tutto per evitare che il cliente lo abbandoni. Inoltre, non tutte queste azioni saranno focalizzate sulla qualità dei servizi o sulla loro varietà. Prima di tutto, si tratta di fornire servizi unici e di utilizzare software di sistema non standard che rendono difficile la transizione a un altro fornitore. Pertanto, nella scelta del fornitore di servizi è necessario contemporaneamente elaborare un piano per il passaggio da questo fornitore (fondamentalmente un vero e proprio DRP - disaster recovery plan) e considerare l'architettura per l'archiviazione dei dati e il backup.
Un secondo aspetto importante delle nuove responsabilità del direttore IT è il controllo della qualità dei servizi forniti dal fornitore. Praticamente tutti i fornitori di servizi cloud rispettano gli SLA basandosi su metriche interne, che possono avere un significato estremamente indiretto sui processi aziendali del cliente. Di conseguenza, l'implementazione di un sistema di monitoraggio e controllo diventa uno dei progetti chiave nel trasferimento di sistemi IT significativi a un fornitore di servizi cloud. Continuando il tema degli SLA, è necessario sottolineare che la stragrande maggioranza dei fornitori di servizi cloud limita la responsabilità per l'inadempimento degli SLA al pagamento mensile del servizio o a una percentuale di tale pagamento. Ad esempio, AWS e Azure applicano uno sconto del 100% sulla tariffa mensile se la disponibilità supera il 95% (36 ore al mese), mentre Yandex.Cloud offre uno sconto del 30%.
E naturalmente, non bisogna dimenticare che ci sono nuvole non solo nella versione dei colossi come Amazon e Yandex. Ci sono anche nuvole più piccole, delle dimensioni di un gatto o addirittura di un topo. Come dimostra l'esempio di CloudMouse, a volte il servizio cloud semplicemente si interrompe. Non riceverete né un risarcimento né uno sconto — non otterrete nulla, tranne una totale perdita di dati.
A causa delle problematiche sopra menzionate relative all'implementazione di sistemi IT ad alta criticità commerciale nelle infrastrutture cloud, negli ultimi anni si è osservato il fenomeno della 'repatriazione cloud'.
Entro il 2020, per il calcolo cloud, si è raggiunto il picco delle aspettative gonfiate e il concetto si trova in una fase di delusione (secondo il ciclo di hype di Gartner). Secondo le ricerche e fino all'80% dei clienti aziendali stanno riportando e pianificano di riportare i carichi di lavoro dalle nuvole ai propri data center per motivi:
- Aumentare l'affidabilità / le prestazioni;
- Ridurre i costi;
- Per conformarsi ai requisiti di sicurezza delle informazioni.
Cosa fare e come sono realmente le cose?
Non c'è dubbio che il cloud sia qui per restare. E ogni anno il suo ruolo aumenterà. Tuttavia, non viviamo in un futuro lontano, ma nel 2020, in una situazione ben definita. Cosa fare con il cloud se non siete una startup, ma un classico cliente aziendale?
- Il cloud è soprattutto uno spazio per servizi con carichi di lavoro imprevedibili o fortemente stagionali.
- Nella maggior parte dei casi, i servizi con carichi di lavoro prevedibili e stabili sono più economici da mantenere nel proprio data center.
- È necessario iniziare a lavorare con il cloud partendo da ambienti di test e servizi a bassa priorità.
- La considerazione per la collocazione dei sistemi informativi nel cloud inizia con lo sviluppo di una metodologia di migrazione da un cloud a un altro (o di ritorno al proprio data center).
- La collocazione di un sistema informativo nel cloud inizia con lo sviluppo di uno schema di backup verso un'infrastruttura controllata da voi.
Fonte: habr.com
