Esaminiamo il nuovo modello di delivery che l’”ecosistema cloud” introduce per business e It aziendale. Partendo dalle aspettative di benefici e rischi e dalla separazione dei compiti tra fornitori e fruitori di servizi cloud, guardiamo al nuovo modello di delivery da tre punti di vista: il ventaglio di opzioni di delivery fra pubblico e privato; dove il cloud eroga valore al consumo (persone o applicazioni che invocano servizi cloud); la catena del valore che si viene così a stabilire. Dal nuovo modello di delivery derivano poi impatti al business come la fruizione diretta di Software as a Service da parte delle linee di business, il valore che l’It deve comunque garantire, l’impatto finanziario di un diminuito rapporto Capex su Opex, i diritti e le responsabilità dei fruitori, la trasformazione (a rischio) per molti vendor in fornitori cloud. Li approfondiremo tutti nel corso dell’articolo.
Che il cloud computing e i servizi cloud siano destinati ad avere un profondo impatto sulle modalità di sourcing delle aziende nei prossimi anni è intuibile: per i servizi It aziendali sta maturando un processo di industrializzazione in cui al modello di delivery “uno a uno” (dall’It o da un suo outsourcer alla singola azienda) si affianca il modello “condiviso uno a molti”, in grado di soddisfare una molteplicità di fruizioni diverse. È già successo con i servizi elettrici, telefonici o postali, erogati nelle loro forme originali entro le mura aziendali: oggi stupirebbe che non fossero offerti da fornitori esterni a un’utenza molteplice, in modalità pubblica o privata e su scala industriale.
Dopo un 2010 che è stato “di scoperta e di prime iniziative (soprattutto Usa) per un 30% di aziende con oltre 1000 dipendenti”, il modello di delivery cloud di servizi It, ha raggiunto un sufficiente livello di maturità perché se ne possa offrire una descrizione magari non esaustiva, ma con una certa pretesa di rigore. Ci facciamo guidare in questa analisi da David Cearley e David Mitchell Smith, Vp e Fellow di Gartner.
Benefici attesi, rischi da controllare
Gartner giudica corrette tre aspettative dal cloud. La prima è ridurre i costi Capex prima e Opex poi, ma senza aspettarsi che i risparmi, in molti casi sostanziali, siano garantiti: far girare un’applicazione legacy su piattaforma cloud senza adattarla allo “stile cloud” può addirittura far crescere gli Opex relativi. Più importante dei risparmi, sottolinea Smith, è la “imprenditorialità It” abilitata dal cloud. A una Web startup, per esempio, oltre che l’idea giusta, prima del cloud serviva investire su un’installazione che alle spalle del sito assorbisse ogni picco di domanda; ora non più: provisioning automatico e gestione dinamica delle risorse garantiscono, con costi “a consumo”, un servizio agile ed elasticamente scalabile. La seconda aspettativa è dunque che la “capacity on demand” (acquisizione di risorsa informatica passiva) diventi “capability on demand” di servizio subito operativo che coinvolge in modo elastico tutte e sole le risorse utili a performare. La terza è un cambio di paradigma, dall’”uso di tecnologia” al “consumo di valore” con risultati misurabili (un pricing sulla base del costo per ottenere un risultato richiesto è più trasparente di un costo per una tecnologia, attribuito magari pro quota tra utenze business).
Cearly ricorda i rischi da controllare: la sicurezza anzitutto e la carenza di reporting e auditing per la compliance: “Alla sicurezza servono una difesa perimetrale logica (a livello virtual machine o più in profondità), e misure di identity access management e data loss prevention adeguate a un ambiente multitenant. Ciò rallenterà il cloud computing pubblico per un paio d’anni, ma – aggiunge Cearly – con il lancio dei ‘cloud infrastructure service’ di vendor aziendali come Ibm o Hp, è legittimo attendersi livelli di sicurezza cloud di classe enterprise”. Serve inoltre maggior granularità nello specificare come i servizi cloud devono rispondere alle diverse esigenze di business e di compliance: per esempio garantire che certi tipi di dati in cloud non escano da una specifica giurisdizione politica.
Attributi critici dei servizi Cloud
Alla base del modello di delivery c’è ovviamente la definizione stessa di cloud computing. Gartner lo definisce come uno “stile” elaborativo, in cui le capacità funzionali scalabili ed elastiche sono fornite “as a service” alla controparte consumatrice, che ne fruisce attraverso tecnologie Internet. Uno stile nuovo, come lo è stato il client server, e, come questo, con impatti sul disegno delle applicazioni, sull’organizzazione del data centre, sulle modalità di consumo di applicazione e servizi. Le novità dei servizi cloud rispetto a servizi di outsourcing sono riassunte da Gartner nei cinque attributi in figura 1.
Figura 1 – Le caratteristiche dei servizi cloud
(cliccare sull'immagine per visualizzarla correttamente)
L’idea base è un modello di delivery fondato su servizi (punto 1), “condiviso uno a molti” e con l’utilizzo dei servizi tracciato ai fini del loro pricing al consumo (punto 4): ciò significa separazione dei compiti fra consumatore del servizio e fornitore: il primo vede solo l’astrazione della capability e il suo consumo come servizio attraverso l’interfaccia per lui definita (un portale se è un utente o un consumatore, un’Api se è un’applicazione); tutta la complessità delle tecnologie sottostanti è gestita dal secondo, che distribuisce le risorse in pool (punto 3), cura il livello di servizio, pensa al disaster recovery. Tale separazione dei compiti è poi la vera discriminante fra il cloud computing e forme anche avanzate di semplice hosting o outsourcing (nei quali le risorse sono tipicamente dedicate, non condivise; e manca capacità di deprovisioning, cioè di restituire al pool le risorse che non servono più, per uso altrui, punto 2).
Le opzioni di Delivery di Servizi cloud
Nel cloud pubblico, il servizio cloud ha come fornitore una terza parte (Amazon, Google, Ibm, ecc.) e l’azienda ha solo il ruolo di consumatore. Il servizio è tipicamente aperto al pubblico, individui singoli compresi; basta registrarsi e pagare il servizio a consumo. All’altro estremo c’è il cloud privato, in cui l’azienda non ha solo il ruolo del consumatore ma una sua parte (il dipartimento It o un outsourcer) è anche il cloud service provider: si occupa di hardware, software, architetture, gestisce il data center customizzato che eroga i servizi cloud (vedi figura 2).
Figura 2 – Quando scegliere tra cloud pubblico e privato
(cliccare sull'immagine per visualizzarla correttamente)
Cearley suggerisce di esaminare se per un dato servizio cloud la delivery pubblica oltre a ridurre i costi soddisfi i vari requirement indicati nella figura 2. E nei casi negativi (previsti prevalere a tutto il 2012) consiglia di ripiegare sul privato per beneficiare almeno di agilità ed elasticità infrastrutturale, in attesa che vengano rimossi gli inibitori percepiti sul pubblico (per esempio sicurezza, livelli di servizio, licenze). Il “community cloud” (governativo o specifico per industry o di un gruppo) può essere la scelta vincente, sottolinea l’analista, perché mitiga due rischi del cloud pubblico: l’accesso aperto a chiunque, e il modello di condivisione che genera colli di bottiglia su risorse o processi. Un compromesso è offerto da vendor che propongono cloud pubblici con risorse “esclusive”: il modello resta di servizi shared ma un’azienda può approvvigionarsi di risorse fisiche (anziché di macchine virtuali che insistono su hardware comune), sicché le risorse sono dinamicamente scalabili. Alla resa dei conti il modello di delivery più probabile sarà un cloud ibrido, con risorse interne attorno a un cloud privato e risorse esterne in una comunità cloud o in cloud pubblici magari con risorse esclusive.
Gli strati dell’ecosistema Cloud che offrono Valore “as a Service”
C’è ormai consenso sulla terminologia proposta dal National Institute of Standards and Technology (Nist) americano che definisce tre strati da cui l’ecosistema cloud eroga valore “as a service”, vedi figura 3 di Gartner. È corretto parlare di layer e non di stack, dice David Smith, perché l’interazione col consumo umano e programmatico avviene da ogni livello e da livelli multipli.
Figura 3 – I livelli dell'ecosistema del cloud computing
(cliccare sull'immagine per visualizzarla correttamente)
Infrastructure as a service (Iaas) è il layer cloud che eroga hardware (server e Vm, storage, network) come servizio a un consumatore che risparmia sul proprio: tipico consumatore di Iaas è il dipartimento delle It operation. Platform as a service (Paas) è meglio definito come “middleware in the cloud” perché eroga come servizio il middleware per sviluppare o far girare applicazioni cloud: consumatore di Paas è tipicamente uno sviluppatore cui Paas offre un Software Development Kit per i nuovi servizi cloud o il redevelopment cloud del legacy. Software as a service (Saas) eroga applicazioni business: consumatore di Saas è tipicamente la business unit. Tre strati – anzi quattro, perché c’è anche il layer del Business and Information Services: qui Google offre il suo Information Service finanziandosi con la pubblicità, ma è anche il luogo dell’outsourcing di processi nel cloud, con applicazioni di Bpo.
La catena del valore dei servizi Cloud
Nell’ecosistema cloud un vendor può posizionarsi come abilitatore (enabler) o fornitore (provider) di servizi cloud. Per chiarire come queste due figure collaborino, è utile il costrutto della catena del valore che rappresenta come tra i componenti costitutivi di servizi cloud possano esserci altri servizi, il cui valore viene integrato. Ne nasce una cascata concettualmente illimitata, vedi figura 4.
Figura 4 – La catena del valore dei servizi
(cliccare sull'immagine per visualizzarla correttamente)
L’“equazione base del cloud” esprime la relazione tra un enabler che gestisce hardware e software (non necessariamente dedicati al cloud) e un provider che a richiesta assembla e “consuma” una “capability” rendendola come servizio cloud. Colui che genera la richiesta può essere una persona o un processo/programma (tramite Api). In questo caso il servizio cloud reso può diventare un brokerage per un secondo enabler che lo può includere come componente di una propria “capability”, consumata da un secondo provider, a creare un servizio cloud che ingloba il primo. Possono esservi brokerage in cascata finché la catena del valore derivato o reso risale a un consumatore finale. Per inciso, Gartner prevede entro il 2014 un “sorpasso” tra le richieste di servizi cloud: le richieste da processi/programmi supereranno gli accessi da persone fisiche.
