L'aumento della potenza di calcolo e lo sviluppo delle tecnologie di virtualizzazione della piattaforma x86 da un lato, e la diffusione dell'IT outsourcing 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à – esattamente 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 certo pool esterno di risorse, senza preoccuparsi di come e da dove provengono queste risorse. Proprio come non ci preoccupiamo dell'infrastruttura delle stazioni di pompaggio dell'acqua. A quel punto, era stata sviluppata anche un'altra parte del concetto – vale a dire l'idea dei servizi IT e come gestirli nell'ambito di ITIL / ITSM.
È stata sviluppata una serie di definizioni di cloud (cloud computing), ma non bisogna considerarli come verità definitiva – sono solo un modo per formalizzare i metodi di fornitura dell'utility computing.
- «Il cloud computing è una tecnologia di elaborazione distribuita dei dati, in cui le risorse e la potenza informatica sono fornite all'utente come servizio Internet» Wikipedia
- «Il cloud computing è un modello per fornire un accesso di rete conveniente a un pool condiviso di risorse informatiche configurabili (ad esempio, reti, server, sistemi di archiviazione dei dati, applicazioni e servizi) su richiesta, che possono essere rapidamente allocate e fornite con sforzi di gestione minimi o con un intervento minimo da parte del fornitore di servizi» NIST
- «Il cloud computing è un paradigma per fornire accesso di rete a un pool scalabile e flessibile di risorse fisiche o virtuali distribuite, fornite in modalità self-service e amministrate on demand» ISO/IEC 17788:2014. Information technology — Cloud computing — Overview and vocabulary.
Secondo il NIST esistono tre tipi principali 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 molto 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 di rete universale (broad network access) – il servizio deve avere un'interfaccia di rete universale, che consenta la connessione e l'utilizzo del servizio praticamente da chiunque con requisiti minimi. Esempio – per utilizzare una rete elettrica a 220V è sufficiente collegarsi a qualsiasi presa con un'interfaccia universale standard (spina), che non cambia se si tratta di un bollitore, un aspirapolvere o un laptop.
- Misurabilità del servizio (measured service) – una caratteristica chiave di un servizio cloud è la misurabilità del servizio. Ritornando all'analogia con l'elettricità – pagherai esattamente quanto hai consumato con una granularità minima, fino ai costi per far bollire un bollitore, se per tutto il mese sei stato a casa solo una volta e hai bevuto una tazza di tè.
- Autoconfigurazione dei servizi su richiesta (on demand self service) – il fornitore di cloud offre al cliente la possibilità di configurare il servizio in modo sensato, senza necessità di interagire con il personale del fornitore. Per far bollire un bollitore non è affatto necessario contattare in anticipo l'azienda elettrica per avvisarli e ottenere il permesso. Dal momento in cui la casa è connessa (è stato stipulato un contratto), tutti i consumatori possono gestire autonomamente la potenza fornita.
- Elasticità rapida (rapid elasticity) – il fornitore cloud fornisce risorse con la possibilità di aumentare / ridurre istantaneamente la potenza (entro determinati limiti ragionevoli). Non appena il bollitore viene acceso, il fornitore fornisce immediatamente 3 kW di potenza in rete, e non appena è spento, riduce l'erogazione a zero.
- Pooling delle risorse (resource pooling) – i meccanismi interni del fornitore di servizi consentono di unire potenze generative separate in un pool comune di risorse, fornendo poi le risorse come servizio a diversi consumatori. Compreso il bollitore, a noi interessa poco da quale centrale elettrica proviene la potenza. E tutti gli altri consumatori utilizzano questa potenza insieme a noi.
È importante comprendere che le caratteristiche sopra descritte del cloud non sono frutto dell'immaginazione, ma derivano logicamente dal concetto di utility computing. E il servizio pubblico deve possedere queste caratteristiche all'interno di questo concetto. Se qualche caratteristica non è rispettata, il servizio non diventa peggiore e non diventa "tossico", semplicemente smette di essere cloud. Ma chi ha detto che tutti i servizi devono farlo?
Perché ne parlo separatamente? Negli ultimi 10 anni, da quando è stata introdotta la definizione NIST, ci sono stati molti dibattiti sulla "vera cloudiness" secondo quella definizione. Negli Stati Uniti si usa ancora a volte nel contesto legale la formulazione "rispetta la lettera della legge, ma non lo spirito" — e nel caso del cloud computing, lo spirito è ciò che conta, le risorse in affitto sono a portata di clic.
È fondamentale notare che le 5 caratteristiche sopra elencate sono applicabili al cloud pubblico, ma nel passaggio al cloud privato la maggior parte di esse diventa opzionale.
- Accesso di rete universale (broad network access) – nel contesto del cloud privato, l'organizzazione controlla completamente sia le capacità di generazione che i clienti-consumatori. Pertanto, questa caratteristica può essere considerata automaticamente soddisfatta.
- Misurabilità del servizio (measured service) – è la caratteristica chiave del concetto di utility computing, pagamento in base al consumo. Ma come può un'organizzazione pagare se stessa? In questo caso, c'è una separazione tra generazione e consumo all'interno dell'azienda, l'IT diventa fornitore e le unità aziendali diventano consumatori dei servizi. E il regolamento avviene tra i dipartimenti. Sono possibili due modalità operative: chargeback (con reali regolamenti e flussi finanziari) e showback (sotto forma di report sul consumo delle risorse in rubli, ma senza movimenti finanziari).
- Autoconfigurazione dei servizi su richiesta (on demand self service) – all'interno dell'organizzazione potrebbe esserci un servizio IT comune, e in questo caso la caratteristica perde significato. Tuttavia, in presenza di propri specialisti IT o amministratori di applicazioni nelle unità aziendali, è necessario organizzare un portale di self-service. La conclusione è che la caratteristica è opzionale e dipende dalla struttura aziendale.
- L'elasticità rapida (rapid elasticity) perde significato all'interno dell'organizzazione a causa della fissità dell'insieme delle attrezzature per l'organizzazione del cloud privato. Può essere applicata in modo limitato per i calcoli interni. Conclusione: non è applicabile al cloud privato.
- La combinazione delle risorse in un pool (resource pooling) è ormai una prassi comune per quasi tutte le organizzazioni che utilizzano la virtualizzazione dei server. Pertanto, possiamo considerare questa caratteristica come automaticamente implementata.
Domanda: Cos'è esattamente il vostro cloud privato? Cosa deve acquistare e implementare un'azienda per costruirlo?
Risposta: un cloud privato rappresenta un passaggio a un nuovo modello amministrativo nell'interazione IT-Business, composto per l'80% da misure amministrative e solo per il 20% da tecnologie.
Il pagamento solo per le risorse utilizzate e l'accesso semplificato, senza la necessità di investire centinaia di milioni in spese in conto capitale, hanno determinato un nuovo panorama tecnologico e l'emergere di aziende miliardarie. Ad esempio, i moderni giganti Dropbox e Instagram sono nati come startup su AWS con zero infrastruttura propria.
È importante sottolineare che gli strumenti di gestione dei servizi cloud stanno diventando significativamente più mediati, e la responsabilità chiave del direttore IT diventa la selezione dei fornitori e il controllo della qualità. Esaminiamo le problematiche di queste due nuove responsabilità.
Fermandosi come un'alternativa all'infrastruttura tradizionale pesante con i propri data center e hardware, i cloud sono ingannevolmente leggeri. È facile entrare nel cloud, ma la questione di come uscirne viene spesso trascurata. Come in ogni altro settore, i fornitori di cloud cercano di proteggere il business e rendere più complicata la concorrenza. L'unico vero momento competitivo si presenta solo nella scelta iniziale del fornitore di servizi cloud, dopodiché il fornitore farà del suo meglio perché il cliente non se ne vada. E non tutte le nostre energie saranno concentrate sulla qualità dei servizi o sulla loro varietà. Prima di tutto, si tratta della fornitura di servizi unici e dell'uso di software di sistema non standard, che rende difficile il passaggio a un altro fornitore. Pertanto, al momento della scelta di un fornitore di servizi, è necessario elaborare contemporaneamente un piano di transizione da questo fornitore (quasi un vero DRP – disaster recovery plan) e riflettere sull'architettura dello storage dei dati e dei backup.
Un secondo aspetto importante dei nuovi compiti del direttore IT è il controllo della qualità dei servizi offerti dal fornitore. Praticamente tutti i fornitori di cloud rispettano SLA basati su proprie metriche interne, il che può avere un valore estremamente indiretto per i processi aziendali del cliente. Di conseguenza, l'implementazione di un proprio sistema di monitoraggio e controllo diventa uno dei progetti chiave nel trasferimento di sistemi IT significativi a un fornitore di cloud. Continuando sul tema SLA, è necessario sottolineare che la stragrande maggioranza dei fornitori di cloud limita la responsabilità per la mancata osservanza dell'SLA al pagamento mensile del canone o a una percentuale del pagamento. Ad esempio, AWS e Azure, superando la soglia di disponibilità del 95% (36 ore al mese), offriranno sconti del 100% sul canone mensile, mentre Yandex.Cloud offrirà uno sconto del 30%.
E naturalmente, non bisogna dimenticare che i cloud non sono solo realizzati da colossi come Amazon e Yandex. Ci sono cloud più piccoli — delle dimensioni di un gatto o addirittura di un topo. Come dimostra l'esempio di CloudMouse, a volte il cloud semplicemente si esaurisce. Non si riceverà alcun risarcimento, né sconto — non si ottiene nulla, se non una totale perdita di dati.
A causa dei problemi sopra menzionati legati all'implementazione di sistemi IT ad alta criticità per il business nelle infrastrutture cloud, negli ultimi anni si è verificato il fenomeno della "repatriamentazione cloud".
Entro il 2020, il picco delle aspettative gonfiate per il cloud computing è stato superato e il concetto sta avviandosi verso la trincea delle delusioni (secondo il ciclo di hype di Gartner). Secondo le ricerche e fino all'80% dei clienti aziendali restituisce e pianifica di restituire i carichi di lavoro dai cloud ai propri data center per i seguenti motivi:
- Aumentare la disponibilità / le prestazioni;
- Ridurre i costi;
- Per conformarsi ai requisiti di sicurezza delle informazioni.
Cosa fare dunque e come stanno le cose "realmente"?
Non c'è dubbio che i cloud siano arrivati per restare. E ogni anno il loro ruolo crescerà. Tuttavia, non viviamo in un lontano futuro, ma nel 2020, in una situazione ben definita. Cosa fare con i cloud se non sei una startup, ma un cliente aziendale classico?
- I cloud sono innanzitutto un luogo per servizi con carichi di lavoro imprevedibili o chiaramente stagionali.
- Nella maggior parte dei casi, i servizi con carichi di lavoro prevedibili e stabili sono più economici da mantenere nei propri data center.
- È necessario iniziare a lavorare con i cloud da ambienti di test e servizi a bassa priorità.
- La valutazione dell'allocazione dei sistemi informatici nel cloud inizia con lo sviluppo di una metodologia per il passaggio da un cloud a un altro (o di nuovo al proprio data center).
- L'allocazione di un sistema informatico nel cloud inizia con lo sviluppo di uno schema di backup nell'infrastruttura da voi controllata.
Fonte: habr.com
