Accostare il cloud computing alla SOA (Service Oriented Architecture) viene piuttosto naturale: entrambe le architetture sono basate sul concetto di Servizio (in effetti, il cloud è un modello di consumo dei servizi più che un’architettura). Per essere precisi, per offrire e per consumare servizi è necessario costruire una SOA.
Tanto per iniziare, il consumatore di un servizio vuole delegare la costruzione, la proprietà e la gestione a una terza parte che si assume la responsabilità dello SLA (accordo contrattuale sul livello di servizio).
Il servizio è considerato una funzione che l’altro fornisce, mentre il consumatore è interessato solamente all’interfaccia con la quale può accedere a essa (oltre che alla qualità e al prezzo).
Definizioni
La più nota definizione del cloud computing è quella del NIST mentre SOA è stata definita, quando ero in BEA Systems (uno dei pionieri di SOA), in questo modo:
Potete trovare una discussione dell’architettura di riferimento per SOA nel mio vecchio blog. Anche IBM fornisce una buona definizione della SOA qui.
Concetti della SOA che valgono anche per il Cloud
Alcuni concetti si ritrovano in entrambi i modelli: ciascuno meriterebbe un post tutto per se, forse anche un intero libro. In questo post cerco di darne una descrizione essenziale.
- Il concetto di Servizio: le responsabilità del Consumer e del Provider
- Sistemi Distribuiti, in cui API remote sono invocate su protocolli standard
- Separazione di responsabilità: interfaccia vs implementazione
- Interfaccia e Contratto
- Riuso e Loose Coupling
- Service Repository e Service Catalog
- Service Lifecycle
- Service Assurance
- Strategia e Governance
Sistemi Distribuiti
Un sistema distribuito è costituito da componenti deployate separatamente, nella maggior parte dei casi remotamente. Ciascuna di esse fornisce funzionalità di livello base che possono essere usate come mattoncini da costruzione per la soluzione di un requisito di business.
Per rendere più facile la costruzione di un sistema così complesso, l’industria del software ha separato il concetto di interfaccia dalla implementazione.
L’interfaccia di un componente software specifica le funzioni che implementa, i parametri che riceve e restituisce, lo stile di conversazione (sync/async) e i vincoli di sicurezza. È un artefatto che può essere prodotto – e deployato – prima che la reale implementazione sia pronta: si può generare un componente stub che restituisce sempre dati fittizi, ma almeno risponde alle chiamate dei client consentendo un test end-to-end dell’intera architettura.
In questo modo differenti sviluppatori possono dividersi l’implementazione del sistema lavorando in parallelo, basandosi sulla definizione dell’interfaccia che ciascun componente presenta agli altri. I primi test di integrazione possono essere eseguiti usando gli stub, per assicurare che la conversazione funzioni. Questo aiuta anche la prototipazione rapida e lo sviluppo agile.
L’insieme dei tre concetti identifica un servizio.
L’interfaccia è l’unica parte visibile del servizio, perché il consumatore userà sempre quella. In base al tipo di servizio, potrebbe essere una GUI o le API offerte a un programma client.
La parte più importante è il Contratto: l’accordo (generalmente definito in un documento) che definisce chi ha il diritto di consumare il servizio, le credenziali, il prezzo, lo SLA, i vincoli (per es. il tempo di risposta è garantito fino a 1000 transazioni al secondo), e altro.
Una certa interfaccia potrebbe essere offerta con due contratti differenti, per es. con requisiti di security differenti. Oppure con prezzi differenti, o SLA differenti, ecc. L’offerta di un nuovo contratto genera un nuovo servizio (una differente tripla contratto + interfaccia + implementazione):
Anche l’aggiunta di una nuova interfaccia (per es. sincrona o asincrona) genera un nuovo servizio.
Riuso e Loose Coupling
Costruire un servizio in modo che sia riusabile richiede uno sforzo maggiore. I consumatori potenziali del servizio lo useranno se è abbastanza robusto, se scala, se è sicuro, etc. Bisogna fornire informazioni su quello che il servizio fa, come usarlo, come viene supportato. Una giustificazione di business è quindi necessaria per lo sforzo aggiuntivo, che si tratti di un servizio per uso interno (SOA) o di un servizio cloud.
L’integrazione tra i consumatori e i fornitori del servizio non dovrebbe creare dipendenze strette, per consentire innovazione e manutenzione. L’accoppiamento si riferisce al grado di integrazione diretta che lega un elemento all’altro. La separazione tra interfaccia e implementazione gioca un ruolo importante, perché consente di modificare l’implementazione senza effetti sull’interfaccia pubblicata. Buone definizioni del loose coupling si trovano su Wikipedia e Techtarget.
Service Repository e Service Catalog
Come abbiamo detto, bisogna fornire informazioni sul servizio e, eventualmente, commercializzarlo. Se i possibili consumatori non sanno che esiste, non lo useranno. Hanno anche bisogno di informazioni descrittive e di dettagli tecnici: questo vale sia per costruire un’architettura enterprise che per vendere servizi cloud.
Un elemento importante della SOA è il Service Repository. Un punto centrale in cui tutti gli artefatti prodotti dai progetti sono esposti per il riuso, completato dal Registry che espone gli end point del servizio.
Successivamente è stato definito il Service Catalog, che gestisce l’intero ciclo di vita di un servizio cloud: da quando viene ideato (inception) fino al suo ritiro (decommissioning), passando per i modelli di costo e la gestione dei tenant. Un’ottima definizione di Service Catalog e del suo utilizzo si trova in questo eccellente ebook gratuito: Defining IT Success Through the Service Catalog
Service Lifecycle
Quando si crea un nuovo servizio, si deve progettare il suo processo di provisioning – che potrebbe comprendere azioni completamente automatizzate o anche manuali, comprese le autorizzazioni – il suo modello di costo, la gestione delle risorse allocate per un tenant, l’assicurazione della qualità del servizio, la fatturazione e il reporting per gli end user, il decommissioning e la restituzione delle risorse al pool condiviso al termine del servizio.
Una buona soluzione per la gestione di servizi cloud è stata appena rilasciata: Cisco ONE Enterprise Cloud suite, un ambiente flessibile in cui si possono creare nuovi servizi con un minimo sforzo, in un approccio bottom-up (dalla gestione dell’infrastruttura su fino al catalogo dei servizi). Offre strumenti potenti per la creazione di servizi IaaS e PaaS.
Strategia e Governance
La governance IT fornisce il quadro che collega le risorse IT agli obiettivi e alle strategie aziendali. Inoltre, l’IT governance istituzionalizza le best practice per la pianificazione, l’acquisizione, implementazione e monitoraggio delle prestazioni dell’IT, al fine di garantire che le risorse dell’azienda sostengono i propri obiettivi di business.
Gli organismi di regolamentazione di tutto il mondo chiedono un sempre più rigoroso controllo sulle informazioni, viste le ricorrenti notizie di disastri nei sistemi informativi e di frodi elettroniche. La gestione del rischio correlato all’IT è ora ampiamente accettata come una parte fondamentale della governance aziendale.
Questo argomento, con riferimento a un’architettura di riferimento per SOA è discusso in SOA è solo tecnologia? e in 6 errori da non fare in un progetto SOA. La stessa discussione, secondo me, può essere applicata ai servizi cloud.
Allora SOA e il Cloud sono identici?
Naturalmente no. Hanno molti concetti in comune ma, mentre SOA è nata per risolvere le necessità del business e dell’IT nel contesto di una singola azienda, il cloud è un modello più ampio che offre servizi sul mercato.
C’è sempre il modello della private cloud, in cui i servizi sono offerti internamente. Abbiamo ancora lo stesso modello di consumo dei servizi, e anche qui l’automazione del provisioning è critica quanto la qualità dei servizi offerti dal catalogo.
La lezione più importante che abbiamo imparato dalla SOA è che il fattore umano è fondamentale, avendo spesso un impatto superiore alla scelta della tecnologia migliore.
Il change management è una delle iniziative chiave che aiutano a vincere la resistenza (sia dentro l’organizzazione IT, quando si adotta un nuovo modello operativo, sia tra i consumatori dei servizi a cui si offre un modo nuovo di usare le applicazioni o di realizzare i progetti).
La corretta documentazione dei servizi è critica, così come la definizione corretta di una strategia per il go-to-market: la tecnologia non dovrebbe essere adottata solo perché è di moda o perché dimostra che si hanno le competenze. Dovrebbe essere sempre funzionale alla realizzazione di requisiti di business ed essere allineata alla strategia aziendale.
Link
http://en.wikipedia.org/wiki/Service-oriented_architecture
http://www.alleywatch.com/2013/03/people-as-a-service/
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
http://www-01.ibm.com/software/solutions/soa/what-is-soa.html
http://www.mulesoft.com/platform/soa/mule-esb-open-source-esb
Authors
