Un modello architetturale permette di gestire le proprie soluzioni attribuendo ruoli e competenze a ogni layer, che si tradurranno poi in componenti o soluzioni tecnologiche realizzati sempre dai principali esponenti nel mercato in quel settore.
Introduzione
Come in altre situazioni, anche per il cloud, i principali provider si sono adoperati per realizzare il proprio modello architetturale di riferimento per le soluzioni cloud che metteranno a disposizione dei propri clienti. Il modello architetturale deve fornire non solo le linee guida di definizione dei loro servizi, ma anche la gestione dei progetti applicativi da parte degli sviluppatori, la modalità di offerta, richiesta e pricing dei serivzi, la modalità di fruizione degli stessi con un determinato SLA, e così via.
Dal momento che non esiste un modello architetturale standard, vedremo alcuni di quelli forniti dai principali competitor di mercato, con l’obiettivo di valutare cosa i loro prodotti possono realizzare, ma soprattutto per capire in che modo un’azienda di settore, ma non di prodotto, si può inserire nelle fasi di consulenza cloud.
Modelli architetturali cloud di riferimento
Quando si parla di Modello Architetturale di riferimento per il cloud si fa riferimento a un insieme di concetti di cloud computing e delle relazioni che possono essere usate per guidare le organizzazioni ad applicare tali concetti. Gruppi come la Distributed Management Task Force e grandi fornitori come la IBM e la Oracle stanno realizzando dei modelli di riferimento cloud per definire delle linee guida di gestione interna nella realizzazione del servizio e nella modalità di fruizione e supporto allo stesso.
La definizione di un modello dà opportunità business ai fornitori del servizio stesso e a tutti coloro che, non disponendo di un modello di riferimento proprio, si approcciano a questo nuovo paradigma. Agli utenti finali il modello è trasparente ma, grazie a questo però, ne trae vantaggio la fruizione dei servizi che vengono messi loro a disposizione, e migliora anche la possibilità che viene data agli utenti di richiedere servizi, e alle aziende di raggiungere clienti, con costi d’ingresso vantaggiosi e competitivi rispetto agli approcci classici.
Anche agli sviluppatori di servizi cloud vengono forniti dei vantaggi in quanto il modello architetturale permette di ridurre gli investimenti, di rimuovere i vincoli di calcolo e spazio, assicura uno sviluppo più veloce e promette di semplificare (almeno in buona parte) la gestione di ambienti complessi.
In questo articolo vedremo proprio quali sono i modelli di riferimento proposti dalle organizzazioni e dai principali competitor. Tratteremo in particolare le seguenti architetture:
- Distributed Management Task Force (DMTF)
- IBM Cloud Reference Architecture
- Cisco Cloud Reference Architecture Framework
- Oracle Cloud Reference Architecture
Modello architetturale della Distributed Management Task Force (DMTF)
La Distributed Management Task Force (DMTF) è un’organizzazione leader nel settore per lo sviluppo, l’adozione e l’unificazione di standard di gestione e iniziative per ambienti desktop, aziendali e Internet. Grazie alla collaborazione con fornitori di tecnologia di primaria importanza e gruppi di standard affiliati, la DMTF è in grado di offrire un approccio per la gestione più integrato, contenuto nei costi e meno soggetto a crisi, avvalendosi di soluzioni che si caratterizzano per loro l’interoperabilità.
Figura 1 – Modello architetturale cloud della Distributed Management Task Force.
Attori
In questo modello di riferimento, gli attori principali sono:
- il Cloud Service Provider, che mette a disposizione i servizi al Cloud Service Consumer, offerti, come spiegato di seguito, tramite opportune interfacce funzionali;
- il Cloud Service Consumer rappresenta un’organizzazione o un singolo che contratta col Provider del servizio e lo utilizza; il Cloud Service Consumer potrebbe anche essere un altro Cloud Service Provider che è provider di un ulteriore consumer;
- il Cloud Service Developer modella e realizza i componenti di un servizio e interagisce col Cloud Service Provider per poterne distribuire i componenti.
Interfacce funzionali e Data Artifact
L’interfaccia del provider dichiara come lo sviluppatore e il consumer interagiscono con lo stesso. In particolare, le interfacce funzionali sono interfacce di programmazione (p.e.: le API). Tramite queste interfacce funzionali, sviluppatori e consumatori interagiscono con il provider per richiedere, distriburire e usare i servizi. Esempi di questo tipo di interfacce sono:
- il catalogo servizi (Service Catalogs), tramite il quale i servizi possono essere offerti, ricercati e gestiti;
- il gestore della sicurezza (Security Manager), tramite il quale sono gestiti gli aspetti inerenti la sicurezza di un cloud;
- il gestore del servizio (Service Manager), tramite il quale le istanze di servizi distribuiti possono essere gestite e modificate.
Gli artefatti di dati (auto definizione del formato dei dati previsti ) sono scambiati tramite le interfacce funzionali. In questo contesto, la definizione di un Data Artifact descrive il contenuto semantico e lo specifico formato (p.e.: lo schema XML descrive il paylod). Esempi di artefatti di dati sono le richieste di servizio, i service level agreements (SLA) e i template dei dati.
Profili DMTF
I profili DMTF sono specializzazioni o estensioni delle interfacce e degli artefatti, le quali risultano utili per indirizzare alcuni contesti, come quelli di interesse di un gestore della sicurezza. Sono quindi una delle possibili viste di un provider.
Modello architetturale della IBM
Vediamo adesso il modello proposto dalla IBM. I principali attori coinvolti nel modello sono quelli illustrati nella figura 2:
- il Cloud Service Consumer;
- il Cloud Service Provider;
- il Cloud Service Developer.
Figura 2 – Modello architetturale cloud della IBM.
Dal momento che gli attori coinvolti sono gli stessi rispetto al modello DMTF, vediamo in che cosa si distinguono quelli della IBM.
Cloud Service Consumer
Il Cloud Service Consumer comprende ogni tipo di utente e sistema che utilizza o consuma risorse del cloud. Le funzioni e i servizi sono messi a disposizione mediante un portale. Quindi il concetto e la modalità di utilizzo è analoga a quanto visto per la DMTF.
Cloud Service Provider
Il Cloud Service Provider fornisce e mette a disposizione l’infrastruttura e una piattaforma comune di gestione cloud (CCMP). Come illustra la figura 2, partendo dal basso si hanno le seguenti sezioni:
- la Common Cloud Management Platform;
- la Virtualized Infrastructure
- i Cloud Services.
Vediamo nel dettaglio a cosa si riferiscono queste singole sezioni.
Common Cloud Management Platform (CCMP)
Questa è la piattaforma principale e consta delle seguenti sezioni:
- i servizi di supporto business (BSS) che sono servizi di piattaforma di significato business;
- i servizi di supporto alle operazioni (OSS) che rappresentano gli aspetti infrastrutturali e operazionali della piattaforma.
Il BSS rappresenta un set di servizi esposti dalla CCMP verso gli utenti finali come per esempio richiedere gli ordini, elaborare le fatture, riscuotere i pagamenti. Comprende quindi tutti i componenti che sono coinvolti per eseguire operazioni business lato client.
Gli Operational Support System o Operations Support System (acronimo OSS) sono tutti quei sistemi che vengono utilizzati dalle aziende fornitrici di servizi di comunicazione, per il funzionamento delle reti.
Nei tempi passati, le attività OSS erano svolte principalmente da operatori che si scambiavano materiale cartaceo. Dopo il 1985 si introdussero sistemi informatici (o applicazioni software) che automatizzarono gran parte di queste attività. Ad ogni modo questi sistemi erano isolati tra di loro (si parla spesso di silos applicativi, ossia di applicazioni verticali che non hanno modo di comunicare tra di esse).
Ad esempio, si consideri il caso di un cliente che richiede l’attivazione di una nuova linea telefonica. Il sistema di ordinazione raccoglie i dati dell’utente e della sua richiesta, ma non è in grado di configurare la rete per la realizzazione del servizio. Questa operazione veniva svolta manualmente da un operatore umano che trascriveva le informazioni da un sistema all’altro, con l’inefficienza che ne conseguiva. Negli ultimi anni ci si è dunque focalizzati sulla creazione di interfacce automatizzate tra le applicazioni OSS.
I servizi offerti riguardano la gestione del ciclo di vita dei servizi stessi che possono essere realizzati mediante la piattaforma, come la gestione di richiesta di un servizio, la gestione della configurazione, degli incidenti e dei problemi, la gestione dei livelli di servizio IT, la gestione delle licenze, delle performance e della virtualizzazione.
Virtualized Infrastructure
L’infrastruttura virtualizzata include tutti gli elementi infrastrutturali necessari alla realizzazione di un cloud e che il cloud provider non può fare a meno di mettere a disposizione.
Gli elementi infrastrutturali intesi sono i server, gli storage, le risorse di rete e come queste risorse sono interconnesse tra loro, collocate all’interno di un data center e così via. Nei casi di virtualizzazione, ci si riferisce anche agli hypervisor; non rientrano invece i software di gestione della virtualizzazione poich� questi fanno parte dei componenti di tipo OSS.
Figura 3 – Infrastruttura virtualizzata del modello IBM.
Cloud Services
In cima allo stack dei servizi messi a disposizione dal Cloud Provider troviamo i Cloud Services. Questa categoria racchiude tutti i servizi messi a disposizione al Cloud Consumer e sono i SaaS, i PaaS e gli IaaS, illustrati ampiamente nel primo articolo di questa serie.
Figura 4 – Layer dei servizi cloud del modello IBM.
Come illustra la figura 4, un’ulteriore generalizzazione dei servizi forniti può essere il Business Process as Service, che consiste nel fornire Processi Business a partire dai Servizi già esistenti. Per esempio, se esiste un processo caratterizzato da step conosciuti, questo processo può essere fornito come servizio all’interno del catalogo. Ciò consente ai provider di servizio sia di automatizzare gli step, sia di renderlo trasparente al cliente che ne fa uso.
Cloud Service Developer
Un Cloud Service Developer utilizza i Service Development Tools per realizzare nuovi servizi cloud, il che include sia lo sviluppo di artefatti runtime (p.e.:la persistenza, la gestione transazionale, e così via) sia per aspetti legati alla gestione (p.e.: monitoring). In questo contesto, i tool di sviluppo supportano gli sviluppatori per la realizzazione dei template e dell’offerta dei servizi; mentre il template del servizio definisce come la funzionalità OSS è usata nel contesto del rispettivo servizio cloud; l’offerta di servizio specifica come invece viene usata la funzionalità BSS.
In generale, ci sono due categorie di tool di sviluppo: uno per sviluppare gli stessi servizi cloud, e un secondo per realizzare gli artefatti che sono specifici al servizio stesso.
CISCO Cloud Reference Architecture Framework
Anche CISCO ha realizzato un modello di riferimento per l’architettura cloud (figura 5), nei layer previsti, connessi mediante API.
Figura 5 – Modello Architetturale cloud della Cisco.
Partendo dal basso troviamo:
- Technology Architecture: consta delle tre sezioni di network, storage e calcolo. Questo layer ospita tutti i servizi che sono messi a disposizione dei consumatori cloud o dei sottoscrittori al servizio.
- Security Layer: la differenza del modello CISCO consiste proprio nel posizionamento di questo layer che è trasversale ai framework. Dal momento che la sicurezza è uno dei punti chiave in un’architettura di sicurezza, in questo modello gli è stato riservato un ruolo predominante.
- Service Orchestration: attivato mediante configurazioni. Vengono usati dei repository di configurazioni che salvano informazioni come il catalogo dei servizi, l’inventario degli asset e il mapping risorsa-servizio. È un layer chiave in quanto mappa la tecnologia del componente nel servizio stesso ed è il “collante” tra gli strati più bassi e quelli più alti per fornire un servizio da poter esporre.
- Service Delivery and Management: è il layer dedicato alla gestione del servizio offerto.
- Cloud Services Consumers: è il layer finale destinato all’utente finale, il che generalmente si traduce in un portale. È qui che il servizio viene visionato, richiesto e gestito dagli utenti.
Vediamo adesso un tipico scenario in cui viene fatto uso di questo framework.
- il consumer effettua la login presso il portale e verifica e/o aggiorna il proprio profilo;
- in base al profilo utente viene offerto e mostrato un determinato set di servizi;
- l’utente sceglie e seleziona il servizio che vorrà utilizzare e inoltra una richiesta;
- le risorse sono destinate e ritenute riservate per quel servizio, legato a quella specifica richiesta;
- viene realizzato e configurato il dominio di storage, di rete e destinato al calcolo, con il livello di servizio e di sicurezza richiesto dall’utente.
Modello architetturale della Oracle
Vediamo ora la Oracle come si è preparata rispetto agli altri competitor per fornire il servizio di cloud.
Figura 6 – Modello Architetturale cloud della Oracle.
Come in un modello architetturale n-tier, ciascuno di questi layer è inteso allo scopo di indirizzare i requisiti chiave ma anche i requisiti non funzionali come la scalabilità e la disponibilità.
Per comprendere a fondo quest’architettura, è utile distinguere tra “il Cloud che esegue le applicazioni” e tra “le applicazioni che vivono nel Cloud” (come i servizi Cloud, le entità di cui è stato fatto il deploy o i data center virtuali).
Questo tipo di architettura è prettamente centrata sul Cloud, col quale ci si riferisce a tutte le risorse e ai servizi che lavorano insieme per fornire gli IaaS, i PaaS e il SaaS; in questa ottica, l’infrastruttura è a supporto delle “applicazioni che vivono nel Cloud”. Vediamo adesso nello specifico i singoli layer architetturali.
Access Layer
Questo layer è quello che abilita gli utenti finali, gli sviluppatori e i responsabili di applicativi ad accedere ai servizi cloud (e a tutte le applicazioni in esso ospitate) mediante una interfaccia di gestione. Questo layer è paragonabile al presentation layer di un qualsiasi modello tradizionale n-tier, con la differenza però che questo modello prevede che mediante il presentation si mettano a disposizione anche dei servizi di gestione, tramite l’interfaccia apposita Cloud Management Interface.
Management Layer
Il layer di Cloud Management espone la logica necessaria al design, alla fornitura e alla gestione dei servizi nel cloud, utile agli sviluppatori e ai responsabili applicativi ai quali viene messo a disposizione un pannello di controllo. Le attività che concernono questo layer sono:
- gestione business e delle attività runtime dell’infrastruttura cloud;
- gestione delle policy e degli aspetti di sicurezza;
- orchestrazione delle attività di gestione all’interno dell’infrastruttura.
Questo layer è posto tra quello di Access e di Resource al fine di mediare tutte le comunicazioni; quindi queste ultime non possono interagire direttamente con le risorse senza passare da questo layer.
Service Layer
Questo layer contiene tutte le entità distribuibili, che sono di tipo infrastrutturale, di piattaforma e/o servizi software.
Resource
Questo layer ha due obiettivi:
- aggregare e gestire risorse fisiche o virtuali;
- esporre i pool di risorse al layer di gestione di modo da poter essere orchestrate come servizi Cloud.
Esempi di risorse possono essere i server virtualizzati o i file system, così come i container Java EE in cluster o le code di messaggi. Questo layer rappresenta inoltre un importante punto d’integrazione tra i cloud ibridi e le risorse legacy.
Cloud Brokers
L’infrastruttura dei broker del cloud è un mix sia di quella dei cloud provider sia di quella dei cloud consumer, quindi forniscono un valore aggiunto ai servizi offerti. Pertanto, il broker richiede capacità aggiuntive come per esempio l’infrastruttura di Access e di Consumption, dal momento che deve incarnare le funzioni di provider e di consumer. In accordo a Gartner, una delle caratteristiche del broker potrebbe essere quella dell’aggregazione, dell’arbitraggio e dell’intermediazione; comunque sia, le prospettive future su questo layer non rientrano negli scopi di questa trattazione.
Vista logica
I layer sopra descritti sono illustrati in figura 7 dal punto di vista logico: è anche più semplice immaginare come gli stessi abbiano un rispettivo mapping tecnologico, ideato e realizzato dalla stessa Oracle.
Figura 7 – Vista logica del modello cloud Oracle.
Conclusioni
Questo articolo ha l’obiettivo di individuare come i principali provider si stanno organizzando dal punto di vista metodologico, il che, dal loro punto di vista, si traduce nel mettere a disposizione i rispettivi prodotti software in modo che riescano a mappare le funzionalità descritte e individuate nei loro modelli.
Ma una società non di prodotto come può inserirsi in questo settore dal punto di vista consulenziale? È una domanda su cui ciascuna azienda può iniziare a riflettere per darsi delle risposte utili a migliorare la propria strategia business.
Nel prossimo articolo vedremo un esempio di realizzazione SaaS, ottenuta come migrazione di applicazioni già esistenti. La metodologia e le tecniche di integrazione si realizzano solo col buon senso e non con i vincoli tecnologici.
Riferimenti
[1] La voce di Wikipedia sugli OSS
http://it.wikipedia.org/wiki/Operational_Support_Systems
[2] Oracle® Reference Architecture “Cloud Foundation”
[3] Oracle® Reference Architecture “Cloud Infrastructure”