Il Cloud

Citando Aristotele<<C’è più ricchezza nell’uso che non nel possesso>>

Il cloud computing (o volgarmente cloud) è un servizio informatico in grado di soddisfare richieste elaborative in maniera sicura, affidabile e a prescindere dall’ubicazione del sistema utilizzato… in uno slogan: L’informazione sempre comunque e ovunque.

Detta così il cloud sembra solo un’evoluzione dell’hosting; ma se analizziamo bene la composizione delle applicazioni in cloud, emergono alcune differenze sostanziali. Prima di tutto il cloud è un paradigma che rispetta le regole di sicurezza, scalabilità e affidabilità, e a loro volta declinate in 3 forme principali: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) e Software as a Service (SaaS). In secondo luogo un sistema cloud deve rispettare anche regole di portabilità, integrazione e di gestione che costituiscono la vera e propria differenza tra i sistemi cloud e l’hosting tradizionale.

 

In passato (solo pochi anni fa…)

Quando si parla di hosting spesso ci si riferisce all’hosting di pagine web, cioè una porzione condivisa o dedicata di un sistema che costituisce un servizio vero e proprio, in grado di elaborare codice php, asp, java in contenuti HTML, fruibili dai browser presenti nei dispositivi client (PC, MAC, iPhone, iPad). Rimanendo nel campo dell’hosting possiamo pensare anche alla posta elettronica, cioè al servizio di ricezione, stoccaggio, gestione e invio dei messaggi di posta elettronica. I servizi di hosting, come ogni servizio che si rispetti, prevede quindi la presenza di un hosting provider, cioè di colui che si preoccupa di gestire e manutenere il sistema informatico e di un consumatore (o cliente del servizio), che alimenta di dati il sistema al fine di ottenerne le informazioni.

In questo gioco il provider ha il compito di approvvigionare l’intero sistema, manutenerlo, scalarlo per soddisfare i cosiddetti “Service Level Agreement”, cioè i gli accordi circa i livelli di servizio pattuiti nei confronti del cliente; solitamente questi Service Level Agreement (in gergo SLA) vengono pattuiti all’atto della sottoscrizione del contratto.

Il rispetto dei service level agreement unito all’approvvigionamento di hardware e risorse umane implica:

– spese capitali

– pesanti situazioni di change management da gestire con poco margine temporale per attuarle,

– implementazioni di livelli di sicurezza idonei a garantire stabilità della piattaforma

– isolamento logico tra diversi utenti della piattaforma.

Quindi se da un lato l’hosting ha rappresentato un trampolino di lancio dei primi servizi informatici, dall’altro costituisce << un grosso carico sulla schiena dei service provider >>, dato che dovendo garantire separazione logica (multi tenancy), scalabilità e sicurezza è costretto ad un impegno di soldi, tempi e risorse umane che a volte creano margini di guadagno veramente minimi.

 

 

L’evoluzione… o la rivoluzione

Analizziamo qual è stata la forza motrice che ha dato vita al cloud e che tutt’ora incentiva l’utilizzo delle soluzioni cloud oriented: l’esigenza crescente e al passo coi tempi. 

Il mercato IT ci comunica un concetto fondamentale: << un servizio efficiente è formato dall’intreccio di apparecchiature informatiche, software e risorse umane unite da processi che ne garantiscono stabilità, sicurezza e qualità>>. Declinando il concetto, per avere un servizio efficiente occorre:

• allineare il servizio stesso con i bisogni correnti e futuri del business e dei clienti;
• migliorare la qualità dei servizi IT erogati;
• ridurre i costi fissi di erogazione dei servizi.

Considerando quindi un service provider, la maggior parte dei costi implicati nell’allestimento delle infrastrutture vengono ammortizzati dal ricavo del servizio offerto. Mentre per quanto riguarda l’utente finale, le continue richieste del business, la quantità sempre crescente di dati e i cambiamenti cercati per essere sempre al passo coi tempi, in alcuni casi costringono i reparti IT delle aziende stesse a trasformarsi in service provider, con conseguenze economiche che poco ne sostengono il ruolo. Prendendo in considerazione un caso reale, proviamo a pensare alle esigenze IT di un’azienda che produce prodotti alimentari: come si giustificano pesanti investimenti hardware, software e di persone per un sistema gestionale?

Molte aziende ricorrono all’outsorcing come risposta al problema, ma spesso si verificano spiacevoli inconvenienti come:

1. solution provider che “legano” le aziende al loro operato ( il cosiddetto approccio <<io l’ho fatto, io so come funziona, gli altri non lo sanno far funzionare>>)
2. conflitti tra il solution provider e l’IT interno: spesso il system administrator vede “invaso” il suo campo dal cosiddetto “mangia soldi a tradimento” e smette di collaborare per cercare di essere sempre più indispensabile ( oops! l’ho detto, spero di non causare il loro licenziamento )
3. Costi, costi, costi, che se anche trasformati da capex a opex, restano ancora alti e difficili da giustificare ( non posso raddoppiare il costo della scatola di pomodori solo perché ho cambiato il sistema gestionale )

Allora occorre rivoluzionare il sistema introducendo i seguenti vincoli:

1. risorse pressoché illimitate e/o fruibili on demand
2. nessun legame con il provider
3. garanzie di sicurezza, scalabilità e portabilità dei miei dati

Per dare vita a tutto questo occorre investire ancora una volta in hardware (e datacenter), in software e in risorse umane (progettazione, realizzazione e manutenzione); ma ripensando al modello citato all’inizio, cioè alle declinazioni IaaS, PaaS e SaaS, scopriamo che il mio ipotetico gestionale potrebbe essere fornito da un service provider, il quale ha acquistato una piattaforma da un’altro service provider che a sua volta ha comprato potenze elaborative, di rete e di storage da un terzo soggetto.

Ma funzionerà l’appalto del sub appalto con un terzista? Se il sistema è governato dai principi di scalabilità, portabilità e sicurezza, posso affermare che il modello di erogazione del servizio è assolutamente efficiente, dato che, riprendendo l’esempio di prima, chi costruisce l’applicativo gestionale in cloud, non dovrà occuparsi della manutenzione la piattaforma operativa (anche per limiti di competenze) e chi governa la piattaforma non dovrà occuparsi di approvvigionare l’hardware sottostante. Inoltre la possibilità di spostare dati e processi elaborativi da una piattaforma ad un’altra, garantisce sempre che l’investimento sia in linea con i prezzi a mercato, evitando di legarsi completamente alle piattaforme

 

 

L’architettura (iaaS)

Parlando di architettura vediamo come tale modello prende vita e quali tecnologie vanno in sopporto in fase realizzativa.

Partendo dal basso, esistono provider di risorse computazionali formate da hardware e da strutture software in grado di comunicare con tutto quello che si trova al di sopra delle stesse. Quindi più semplicemente troviamo server, arrray di storage locali o condivisi e apparati di networking. In questo ambito, la virtualizzazione costituisce l’elemento fondamentale per costruire la base di un sistema cloud efficiente, dato che astrae tutto lo strato fisico in un contesto software che ne garantisce stabilità, portabilità, sicurezza, affidabilità, maneggevolezza senza però doversi preoccupare dell’hardware sottostante. In poche parole, le unità consumabili da server fisici diventano semplici files, denominate macchine virtuali, che utilizzano risorse hardware per creare istanze di sistema operativi isolate. Per questo fondamentale motivo, la virtualizzazione, soprattutto quella di tipo hypervisor, costituisce il punto di partenza necessario per un buon sistema cloud.

Esistono hardware vendor che possiedono “connettori” in grado di interfacciarsi con sistemi di gestione on-demand dei componenti hardware stessi. Tra questi spiccano nomi come:

– CISCO, DELL, HP per la parte computazionale

– EMC2, Netapp, HP per la parte storage

– CISCO, Juniper e Hawey per la parte swiching, routing ecc.

Esistono poi elementi software che vanno a costituire il virtual datacenter (o software defined datacenter SDDC ): VMWare con vSphere, NSX e vSAN e EMC2 con ViPR. In ultimo, ma non per importanza, troviamo l’elemento base de “infrastructure as a service” : il cloud director. Quest’ultimo è un broker/orchestrator in grado di:

1. gestire risorse hardware aggregandole secondo le richieste
2. creare istanze multi-tenant
3. fornire i connettori per amministrare e federare l’istanza

 

 

I prodotti che meglio esprimono questo concetto di aggregazione e utilizzo delle risorse sono: VMware vCloud Director e OpenStack. Chiunque sottoscriva un contratto con un cloud provider verifichi sempre l’aderenza agli standard di portabilità definiti da i brand appena citati.

Restando sui cloud provider occorre verificare alcuni “parametri” che giocano a favore o meno sulla stabilità, continuità e agilità nella gestione del workload:

1. Datacenter o meglio reti di datacenter utilizzati: un buon cloud provider fornisce sempre queste informazioni e soprattutto espone i tear, le certificazioni e valori di SLA (compresi MAR e TTR) dei datacenter utilizzati
2. Tolleranza al fault dell’hardware, Disaster Recovery e Business Continuity: chiaramente chi è responsabile della manutenzione dei sistemi sottostanti, è anche responsabile di garantire continuità di servizio anche in caso di guasto che ha impatto di breve durata (5 minuti, 1 h, 3h) o di lunga durata (>24h). In questo caso, utilizzare sistemi vmware costituisce un punto chiave importante per un service provider, dato che, oltre alla comprovata robustezza del motore di virtualizzazione, possiede features che lo contraddistinguono dai suoi competitor (pensiamo a vmotion e metro-vmotion, storage vmotion e la suiti site recovery manager) (metti link)
3. Tracciabilità del dato: è vero che nel cloud i dati sono “spalmati” in giro per il mondo, ma è altresì vero che è importante conoscere la posizione del dato e costituisce plus, poter delimitare l’ambito territoriale di giacenza dello stesso. In un contesto IaaS è quasi sempre possibile avere la certezza di movimento del dato, in virtù del fatto che un cloud provider medio-piccolo nonn possiede più di 5 datacenter da dove poter erogare il servizio stesso. Chiaramente utilizzare vcloud director facilita le operazioni di conoscere e delimitiare, dato che il primo utilizzatore della risorsa, cioè l’amministratore dell’organizzazione conosce sempre la posizione della macchina virtuale, dato che, in fase di creazione o movimentazione, è sempre conscio della posiazione della propria macchina all’interno dei virtual datacenter (chiaramente è buona norma per un provider identificare i virtual datacenter aggiungendo una naming coerente tipo vDC_<tier>_<location>_<features or environment>_<1..n>
4. Sicurezza: Un sistema cloud deve essere innanzitutto sicuro e privo di falle a livello infrastrutturale, per questo motivo uno dei maggiori investimenti che dovrebbe fare un buon cloud porvider è proprio sui sistemi di protezione perimetrali (firewall e sistemi di intrusion prevention) e sui sistemi di piattaforma, cioè quelli legati al virtual datacenter (firewall, antimalware e eventuali ulteriori sistemi raffinati di intrusion prevention). Nel primo livello di sicurezza, quello lato virtual datacenter, costituisce valore aggiunto per un cloud provider, la possibilità di demandare la gestione al cliente finale, riservandosi però di intervenire in caso di problemi o di ri-gestire in caso di incapacità da parte del cliente stesso.
5. Governabilità e integrazione: il governo della risorsa  fondamentale per un cliente, dato che costituisce il vero e proprio elemento che contraddistingue il cloud dall’hosting. Se siete un cloud provider, ricordate che un cliente che controlla la propria infrastruttura anche mediante strumenti terzi, è un cliente che può utilizzare il vostro virtual datacenter come primo elemento di un sistema cloud vero e proprio.
6. Pricing e Billing: non voglio fare i cosiddetti conti in tasca a nessuno, ma il mercato in ambito cloud è spietato e necessita di flessibilità anche in fase di trattativa, aggiungendo una miriade di pacchetti ma facilitando l’ingresso in fase di acqusizione. In questo ambito ci sono 2 cose fondamentali da tenere presente: il software utilizzato per la configurazione, chargeback e billing, il cost model. Ovvio esiste anche uno staff commerciale ben preparato sull’argomento, ma questo mercato spesso lo si vende online, ed è difficile che un potenziale cliente americano chieda un appuntamento con un provider italiano per un preventivo.  E’ la perdita definitiva dei contatti umani? no, ma il cloud IaaS è un argomento all’interno di una trattativa ma non dovrebbe mai essere l’oggetto della trattativa. Per quanto riguarda il cost model, occorre essere molto flessibili e seguendo questi modelli suggeriti da vcloud director: paga quando utilizzi la risorsa, paga la risorsa prenotata, paga un fisso sulla risorsa prenotata più eventuali eccedenze. Altrettando importante è valorizzare SLA, parametri di pregio dell’infrastruttura fisica e livelli di assistenza; questi ultimi sono elementi che aumentano il valore dell’offerta, ma non dovrebbero essere mai elementi inclusi nell’offerta.

 

 

vcloud director

VMWware qualche anno fa è uscito con una soluzione veramente interessante in ambito infrastrutturale: vCloud Director.

Grazie alla sua flessibilità di utilizzo in poco tempo stessi clienti che utilizzavano vSphere lo adottarono proprio in virtù del notevole valore aggiunto che restituiva agli IT manager in fase di Time to market, controllo di utilizzo delle risorse computazionali, di networking e di storage, controllo dei costi. Ma esistevano caratteristiche importanti che costituivano un punto importante per l’erogazione di un servizio cloud: multitenancy, federazione e integrazione.

Dal punto di vista  architetturale vcloud director è un sistema che orchestra, separa e controlla svariate risorse vsphere ripartite in cluster che costituiscono i virtual datacenter dei provider. Grazie poi alle componenti come vCloud Network Security (ex vShield), vcenter operations e vcloud chargeback è possibile controllare e gestire al meglio tutte le risorse computazionali, di storage e di networking al livello più alto, cioè a livello di organizzazioni. Di fatto ogni organizzazione può usare 1 o più virtual datacenter con SLA, profili computazionali, di network e di storage differenti a seconda della qualità scelta dal cliente stesso.

Ma cosa ha determinato la svolta di vcloud director rispetto ai suoi competitor? La formazione di cloud ibridi, cioè la possibilità di federare il proprio virtual datacenter privato (quello costituito da installazione presso CED o presso branch office) con il proprio vcloud. Questo processo è favorito da 2 oggetti fondamentali: il cloud connector e le API di integrazione; di fatto, secondo vmware, un buon cloud provider deve dare la possibilità di federare e di integrare per restituire quella flessibilità richiesta dal paradigma del cloud stesso.

Seguendo il diagramma, in ambito “public” e in ambito “hybrid” troviamo use-case di sicura e facile implementazione come:

1. Disaster Recovery as a Service (DRaaS): tramite sistemi di replica detti VM-based (cioè che possiedono come elemento minimo del dato da proteggere, la macchina virtuale) è possibile realizzare strategie di disaster recovery a costi contenuti e con rese molto alte. Si pensi ai costi realizzativi di sistemi asincroni replicabili solo mediante storage, con tolleranze alla perdita del dato che che vanno da 5 a 30minuti; i risparmi di una piattaforma as-a-service, dinamica e flessibile, sono notevoli, passando da cifre come 600.000€ in 5 anni a 30.000€ /anno.
2. Servizi Platform as a service (PaaS): è possibile costruire sistemi di Platform as a Service partendo dall’infrastructure as a service e “federati” con altri IaaS provider che adottano gli stessi standard.
3. Sistemi in self provisioning: Tramite le api di integrazione anche un amministratore della propria organizzazione è in grado di integrare workflow di creazione e gestione dei workload con portali e software di terze parti, compatibili con le api esposte da vcloud stesso.

Però proviamo a vedere, a conti fatti, quali sono le spese a cui un cloud provider deve far fronte per erogare un servizio cloud:

1. Costo dell’hardware: acquistare tutto o mediante locazione operativa? Il mio consiglio è quello di cominciare la vostra avventura con la classica configurazione 2n+1 (cioè 3 nodi minimo) e con hardware ad alta densità. Chiaramente alla domanda acquistare o mettere in locazione operativa, dovrete verificare sempre il vostro piano di sviluppo. In molti casi acqusitare implica utilizzare per 3 anni la risorsa come preziosa e al quarto anno (ad ammortamento completo) sfruttare il costo 0 per fare delle offerte molto aggressive (Il cloud è come il maiale: non si butta via niente!!!)
2. Costo del licensing vmware. Per avere vcloud, occorre fare investimenti a livello di licensing talmente alti da superare anche il costo dell’hardware. VMware, mediante il programma Partner Service Provider, ha costruito un’opportunità davvero interessanti per tutti coloro che volessero vendere risorse virtuali: il VSPP. Con questa modalità il costo del licensing è erogato nella modalità as-a-service, cioè pagato mensilmente e subordinato all’utilizzo di RAM e features del virtual datacenter.
3. Licensing Sistemi operativi. Come per il costo licensing vmware anche Microsoft e altri concorrenti sono in grado di erogare il licensing con la modalità simile a quella as-a-service, riducendo all’utilizzo effettivo il costo e facilitando, a livello di spesa, l’utilizzo di sistemi operativi e applicativi come Windows Server 2012 e SLQ server.
4. Licensing accessori. Al momento altri sistemi sono in grado di erograre licenze basandosi sul paradigma as-a-service: Veeam e Trend Micro sono tra i prodotti che a mio avviso meritino più considerazione, dato che, oltre all’utilità che svolgono in ambito datacenter, forniscono strumenti potentissimi che possono essere messi a disposizione sia al cloud provider e sia all’utente che acquista un virtual datacenter.

Termina qui la mia breve panoramica sul cloud declinato nel solo ambito infrastructure as a service. Nei prossimi articoli cercherò di fornirvi ulteriori use-case in ambito IaaS e di declinare anche la parte platform e la parte software.