Indice. 3 Cloud Platform Independent Model Introduzione CPIM Google App Engine Windows Azure... 38

Transcript

1 Sommario Il Cloud Computing è un paradigma relativamente recente che permette di rivoluzionare la modalità attraverso cui i servizi IT vengono forniti. Nonostante gli indubbi benefici in termini di scalabilità e di risparmio di costi, permangono ancora oggi delle problematiche che ne stanno limitando la massiccia diffusione. Uno dei più grossi impedimenti riguarda la percezione del cosiddetto effetto lock-in da parte del provider di servizi cloud. Relativamente a queste tematiche, in questo elaborato viene dapprima introdotto un progetto volto alla soluzione, o quantomeno alla mitigazione, dei problemi che frenano la crescita della tecnologia del Cloud Computing. Questo progetto, denominato CPIM (Cloud Platform Independent Model), propone una libreria che espone delle API vendor-indipendent che forniscono un intermediazione dei seguenti servizi cloud: servizio Blob, servizio NoSQL, servizio SQL, servizio TaskQueue, servizio MessageQueue, servizio Memcache e di Mailing. Inizialmente, la libreria CPIM supporta la portabilità di applicazioni Java tra le piattaforme di Google App Engine e Windows Azure. L intento di questa tesi, sarà quello di estendere il numero di provider supportati con l aggiunta di Amazon Web Services. Relativamente al provider di Amazon, vengono presentati i servizi di AWS che vengono sfruttati e le modalità di implementazione di essi per le funzionalità che offre la libreria CPIM. In tal senso, è stato anche esteso il plugin che permette la configurazione e la preparazione dell ambiente di sviluppo per il deployment di progetti web che fanno utilizzo del framework CPIM. Infine, è stata effettuata un estesa attività sperimentale con l obiettivo di valutare l overhead della libreria rispetto all uso diretto della piattaforma di Amazon Web Services. I risultati hanno dimostrato come l overhead nell utilizzo delle API della libreria, sia marginale in termini di tempi di latenza e utilizzo della CPU.

2

3 Indice 1 Introduzione Il Cloud Computing Infrastructure as a Service Platform as a Service Software as a Service Interoperabilità e portabilità Lock-in Integrazione tra provider Obiettivo della tesi Struttura della tesi Stato dell arte Soluzioni per la portabilità mosaic CloudFoundry Cloud4SOA CAMP CloudBees SimpleCloud Cloud Platform Independent Model Classificazione e confronto delle soluzioni Cloud Platform Independent Model Introduzione CPIM Google App Engine Windows Azure

4 4 INDICE 3.2 Configurazione in CPIM configuration.xml persistence.xml queue.xml Funzionalità offerte da CPIM Blob Manager Service Entity Manager Service SQL Service Mail Service Memcache Manager Service Queue Service Amazon Web Services Introduzione ad AWS Servizi offerti in AWS AWS Networking AWS Storage e Content Delivery AWS Database Deployment and Management App Services Costi in AWS Estensione di CPIM al caso AWS Configurazione di un progetto AWS per CPIM Blob Manager Service: Amazon S Amazon S AmazonS3Client AmazonBlobManagerFactory AmazonBlobManager Entity Manager Service: Amazon SimpleDB Amazon SimpleDB SimpleJPA AmazonEntityManagerFactory AmazonEntityManager SQL Service: Amazon RDS

5 INDICE Amazon RDS AmazonSqlService Mail Service: Amazon SES Amazon SES AmazonSimple Service e AWSJavaMailTransport AmazonMailManager Memcache Manager Service: Amazon ElastiCache Amazon ElastiCache MemcachedClient AmazonMemcache Queue Message Service: Amazon Simple Queue Service Amazon Simple Queue Service AmazonSQSClient AmazonMessageQueueFactory AmazonMessageQueue Queue Task Service: Amazon Simple Queue Service e l Internal Worker AmazonTaskQueueFactory AmazonTaskQueue Plugin di CPIM: supporto per AWS Modello architetturale CloudWizard Pagine Procedura di deployment Guida all utilizzo Precondizioni e predisposizioni per il deployment Interfacce grafiche Test di valutazione Applicazione MiC: descrizione funzionalità Test setup Test Plan Test Plan Tecnica acquisizione utilizzo CPU

6 6 INDICE 7.4 Risultati Test Plan 1 per Amazon Confronto tempi di latenza Confronto utilizzo medio CPU Risultati Test Plan 2 per Amazon Confronto tempi di latenza Confronto utilizzo medio CPU Conclusioni e sviluppi futuri 153 Bibliografia 157

7 Elenco delle figure 3.1 Architettura Cloud Platform Independent Model Schetizzazione abstract factory Console di Amazon Web Services Project Page Source Page Configuration Page Persistence Page Queue Page Frontend Page Backend Page Javascript Scratchpad for Amazon CloudWatch Test Plan 1: carico di 1 utente Test Plan 1: carico di 10 utenti Test Plan 1: carico di 20 utenti Test Plan 1: carico di 30 utenti Test Plan 1: carico di 50 utenti Confronto tempi medi di latenza per la richiesta REGISTER Confronto tempi medi di latenza per la richiesta SELECT TOPIC Confronto tempi medi di latenza per la richiesta SAVE ANSWER Confronto utilizzo medio CPU Frontend Confronto utilizzo medio CPU Backend Confronto tempi medi di latenza per la richiesta LOGIN Confronto tempi medi di latenza per la richiesta EDIT PROFILE Confronto tempi medi di latenza per la richiesta SELECT PROFILE147

8 8 ELENCO DELLE FIGURE 7.15 Confronto tempi medi di latenza per la richiesta SAVE ANSWER Confronto tempi medi di latenza per la richiesta REFRESH Confronto tempi medi di latenza per la richiesta SEND POST Confronto tempi medi di latenza per la richiesta LOGOUT Confronto utilizzo medio CPU Frontend Confronto utilizzo medio CPU Backend

9 Elenco delle tabelle 2.1 Classificazione delle soluzioni Tabella riassuntiva Test Plan Tabella riassuntiva Test Plan

10

11 Elenco dei sorgenti 3.1 configuration.xml persistence.xml queue.xml CloudMetadata.java QueueInfo.java ModeQueue.java CloudThread.java MF.java CloudBlobManagerFactory.java GoogleBlobManagerFactory.java CloudBlobManager.java CloudDownloadBlob.java Esempio Blob Manager Service CloudEntityManagerFactory.java GoogleEntityManagerFactory.java CloudEntityManager.java Esempio Entity Manager Service CloudSqlService.java GoogleSqlService.java Esempio SQL Service CloudMailManager.java CloudMail.java Esempio Mail Service.java CloudMemcache.java Esempio Memcache Service CloudMessageQueueFactory.java

12 12 ELENCO DEI SORGENTI 3.27 CloudMessageQueue.java CloudMessage.java Esempio di message consumer Esempio Queue Message Service CloudTaskQueueFactory.java CloudTaskQueue.java CloudTask.java Esempio Queue Task Service AwsCredentials.properties S3Sample.Java AmazonBlobManagerFactory.java AmazonBlobManager.Java simplejpa.properties Esempio factory di SimpleJPA Esempio entity di SimpleJPA Esempio query di SimpleJPA AmazonEntityManagerFactory.Java AmazonEntityManager.Java Esempio JDBC Esempio statement AmazonSqlService.Java Esempio connection string AWSJavaMailSample.Java AmazonMailManager.Java MemcachedClient.Java AmazonMemcache.Java Esempio di un indirizzo di un cache cluster elasticache.config SimpleQueueServiceSample.java AmazonMessageQueueFactory.java AmazonMessageQueue.java AmazonTaskQueueFactory.java AmazonTaskQueue.java AmazonTaskQueueMessage.java

13 ELENCO DEI SORGENTI AmazonInternalWorker.java AmazonQueueServlet.java Serlvet nel web.xml Esempio di risposta di una richiesta formulata attraverso lo Scratchpad for Amazon CloudWatch

14

15 Capitolo 1 Introduzione Oggi le aziende possono contare su nuove tecnologie che consentono di utilizzare risorse attraverso Internet: dati, software e risorse hardware non devono necessariamente risiedere presso la sede aziendale, ma possono essere ospitati o memorizzati in remoto. Stiamo parlando del Cloud Computing. Questa nuova tecnologia, o meglio ancora insieme di tecnologie, rappresenta una nuova opportunità, soprattutto per le piccole aziende e startup. Questo primo capitolo ha lo scopo di introdurre il Cloud Computing, presentando le diverse tipologie e citando vantaggi e svantaggi che caratterizzano la soluzione cloud. Successivamente, vengono definiti gli ostacoli principali ai quali farà riferimento la soluzione proposta da questa tesi; si parlerà di interoperabilità e portabilità di applicazioni e dati all interno del cloud. Infine, in merito a tutto ciò che è stato introdotto in precedenza, verrà reso chiaro l obiettivo per il quale questa tesi è stata proposta. 1.1 Il Cloud Computing La tecnologia che sta alla base del Cloud Computing, consiste nell utilizzare Internet per distribuire le applicazioni come se fossero un servizio; pertanto, non serve acquistare computer dedicati, installare software e curarne la manutenzione o gli aggiornamenti. Questo rappresenta un grande vantaggio per le aziende perché non dovranno più preoccuparsi dei problemi legati alla tecnologia, risparmiando tempo e denaro che potranno invece dedicare al loro business. Possiamo, quindi, definire con il termine Cloud Computing un insieme di risorse hardware e software che forniscono servizi su richiesta attraverso la rete

16 16 Introduzione Internet. Il Cloud Computing è sostanzialmente un servizio fornito da un gestore di terze parti con la formula on-demand ; l utente paga soltanto per quello che consuma, in termini di banda, di risorse, tempo di utilizzo, numero di transazioni ecc. Questo modello permette di creare soluzioni scalabili, performanti e affidabili anche con un basso investimento iniziale, senza cioé dover acquistare per lo startup l hardware necessario e i servizi connessi, come il consumo di elettricità, la disponibilità di una connessione veloce e permanente a Internet, e un IP fisso per rendere raggiungibili i propri server. Caratteristica fondamentale e imprescindibile del Cloud Computing è quella di fornire una infrastruttura di servizi assolutamente affidabile e scalabile. È infatti possibile, a seconda delle necessità, aumentare o diminuire i nodi in uso, oppure cambiare le caratteristiche dei server potenziando CPU e memoria. Tutto questo è possibile perché l infrastruttura è basata su un sistema di virtualizzazione delle risorse. La piattaforma viene eseguita su macchine virtuali opportunamente dimensionate e in grado di fornire i servizi richiesti. Ogni volta che viene richiesto di scalare utilizzando un nuovo nodo, la piattaforma si preoccupa di replicare l applicazione sul nuovo nodo e renderlo, quindi, disponibile. Il Cloud Computing può essere suddiviso in tre grandi categorie, dipendentemente dallo scopo per cui viene creato. Abbiamo quindi: Infrastructure as a Service (Iaas), dove l infrastruttura hardware, la rete, lo storage vengono resi disponibili come servizi; Platform as a Service (PaaS), dove è la piattaforma applicativa, il sistema operativo, a essere fruibile come servizio con la possibilità di sviluppare soluzioni software; Software as a Service (SaaS), dove l applicazione diventa un servizio fruibile su richiesta. Alcune piattaforme supportano contemporaneamente anche più di una delle tipologie elencate.

17 1.1 Il Cloud Computing Infrastructure as a Service La differenza tra le diverse tipologie di Cloud Computing appare sottile, ma sostanziale. L Infrastructure as a Service (IaaS) è una tipologia di Cloud Computing basato sul consumo, come servizio, di risorse hardware. Server virtuali, potenza di calcolo, storage, reti vengono messi a disposizione per essere utilizzati senza necessariamente dover affrontare costi di acquisto di tale hardware. In questo modo l utente potrà così avere il totale controllo delle risorse a sua disposizione. Il concetto è simile al noleggio, ma con l importante differenza della manutenzione. Chi utilizza l infrastruttura cloud non si deve preoccupare di fare manutenzione, rinnovare l hardware o sostituire un hard disk; deve semplicemente utilizzare un servizio scalabile e affidabile senza preoccuparsi dei meccanismi di gestione interna. Un esempio di IaaS è Amazon Web Services ed, in particolare, il suo servizio più rappresentativo: EC2. Quest ultimo offre la possibilità all utenza di Amazon di poter disporre e controllare risorse virtuali completamente on-demand Platform as a Service Il Platform as a Service (PaaS) rappresenta una tipologia di servizio fornito del tutto differente, anche se per molti versi simile all IaaS. Ad essere fornito come servizio, questa volta, non c è solo l hardware, ma anche la piattaforma che astrae l hardware stesso e permette di usufruire di un set di funzionalità che consentono di ottenere load balancing, storage, reti, virtual machine, deployment e altro ancora. Il meccanismo di tali funzionalità viene spesso mascherato, a differenza dell IaaS dove si ha pieno controllo di tutto ciò. Il vantaggio per l utente è quello di concentrarsi solo ed esclusivamente sullo sviluppo dell applicazione, e non perdersi nell analisi di problematiche legate all ambiente in cui essa deve essere distribuita; ottenendo, contestualmente dalla piattaforma, la scalabilità e l affidabilità necessaria. Come per l IaaS, l utente non deve preoccuparsi di aggiornare il sistema operativo: viene tutto gestito dinamicamente e in modo del tutto automatico dalla piattaforma. Se in determinati periodi si dovessero verificare carichi di picco, la piattaforma è in grado di adeguare la propria struttura per rispondere alle mutate esigenze, anche se temporanee.

18 18 Introduzione Un esempio di PaaS è Google App Engine, una piattaforma per lo sviluppo e l hosting di applicazioni web nei propri server Software as a Service Mentre l IaaS fornisce l infrastruttura e il PaaS la piattaforma, il Software as a Service (SaaS) rappresenta una completa soluzione software sotto forma di servizio. Un esempio di SaaS è la piattaforma Google Documents: un insieme di applicazioni per l ufficio, gestione di documenti, fogli di calcolo, disegno, presentazioni, interamente disponibile online e accessibili da chiunque ne è abilitato. 1.2 Interoperabilità e portabilità Oltre ai molti aspetti positivi accennati finora, il Cloud Computing presenta anche alcuni aspetti negativi. Il principale punto problematico dell adozione del cloud riguarda quello che viene chiamato effetto lock-in. Esistono anche altri aspetti negativi, come la qualità del servizio ed i relativi rischi economici che ne derivano, la confidenzialità e la sicurezza dei dati, ma il trattamento di essi esula dallo specifico compito per il quale è stata proposta questa tesi; quest ultima, si concentra principalmente sull integrazione, interoperabilità e portabilità di applicazioni e dati nel Cloud Computing Lock-in Il rischio dell effetto del lock-in tecnologico per un fornitore del servizio di cloud, è una delle maggiori preoccupazioni degli utenti che fanno utilizzo del servizio. Tali fornitori (i cloud providers) offrono una soluzione proprietaria che forza l utenza che ne fa uso a scegliere ed adottare una certa tecnologia, e modello di deployment, durante le prime fasi dello sviluppo di un applicazione. Sebbene questo aspetto possa rappresentare un aspetto positivo per il fornitore del servizio, non si può dire lo stesso per quanto riguarda l utilizzatore finale del servizio stesso. La scelta iniziale che l utente è costretto a fare potrebbe generare effetti economici catastrofici, qualora il provider selezionato non dovesse soddisfare a pieno i requisiti e le aspettative che si erano previste in fase di sviluppo. Nonostante la gestione del rischio nei sistemi IT tradizionali sia adeguatamente codificata e

19 1.3 Obiettivo della tesi 19 trattata, non si può dire lo stesso per quando ci si prepara a sviluppare un applicazione in cloud; problemi quali metodi di pagamento, sicurezza, contratti, qualità e questioni legali sono la causa principale degli effetti economici catastrofici accennati in precedenza. Da ciò, dunque, si evince l importanza che riveste la capacità, che l utente desidera, di poter migrare da un cloud all altro; tale capacità deriva sostanzialmente dalla portabilità delle applicazioni e dei dati tra i diversi cloud provider esistenti Integrazione tra provider I disagi creati dall effetto lock-in, fanno nascere l esigenza per gli sviluppatori, oltre che per i fornitori stessi, di poter essere in grado di sviluppare un applicazione indipendentemente da dove essa venga rilasciata. Tramite l integrazione tra diversi cloud provider, allo sviluppatore viene garantita la possibilità di poter strutturare e costruire la propria applicazione in modo tale che possa effettuare il deploy su di un provider a scelta, a seconda di quale gli convenga al momento. Inoltre, qualora volesse cambiare il provider inizialmente scelto, lo sviluppatore non deve essere costretto a riscrivere l intero codice, ma dovrebbe essere in grado di effettuare il deploy della medesima applicazione su di un altro provider senza attuare alcuna modifica sostanziale. 1.3 Obiettivo della tesi L integrazione tra provider contribuisce in maniera decisiva alla risoluzione del problema dell effetto lock-in, consentendo lo sviluppo di un applicazione indipendentemente dal provider, la migrazione tra di essi e l unicità del codice. L integrazione può essere raggiunta solo studiando le varie somiglianze e differenze che esistono tra i vari cloud provider che si vuole integrare; si deve cercare di sfruttare in maniera significativa le sinergie esistenti tra di loro, e di assottigliare quanto più possibile le differenze presenti. Non è un problema banale, in quanto bisogna analizzare accuratamente ogni servizio che il singolo provider offre, e confrontarlo con lo stesso servizio che viene offerto dagli altri provider che si vuole cercare di integrare. Per questo motivo, non è possibile, o quasi, l integrazione di ogni servizio offerto da un provider con

20 20 Introduzione lo stesso servizio offerto da un altro provider, poiché essi potrebbero presentare della differenze incolmabili. Oltre, dunque, a dover scegliere quali provider prendere in considerazione per poterne effettuare un integrazione tra di loro, bisogna anche scegliere quali servizi si intendono offrire all utente finale. Con questo approccio, è possibile mediare ai problemi di integrazione che abbiamo visto finora, cercando di offrire il maggior numero di provider e servizi integrabili. In questo elaborato, viene presa in considerazione la soluzione Cloud Platform Independent Model, un progetto che integra i servizi di due famosi provider: Google App Engine e Windows Azure. L obiettivo di questa tesi è quello di integrare un nuovo provider nel progetto CPIM. Ai due provider già supportati dal framework, viene aggiunto Amazon Web Services. 1.4 Struttura della tesi I restanti capitoli di questa tesi sono organizzati nel seguente modo: Il Capitolo 2 descrive lo stato dell arte: le soluzioni, per quanto riguarda l integrazione tra provider, che fino ad oggi sono state offerte. Il Capitolo 3 introduce il framework Cloud Platform Independent Model e e la configurazione di un progetto che lo supporti, enunciando anche brevi esempi per comprendere l utilizzo pratico del framework. Il Capitolo 4 presenta Amazon Web Services: il provider scelto come estensione di Cloud Platform Independent Model. Il Capitolo 5 descrive la configurazione di un progetto Amazon Web Services per Cloud Platform Independent Model, presentando anche l implementazione necessaria per estendere il framework con il provider di Amazon ed i relativi servizi offerti. Il Capitolo 6 intende affrontare i dettagli riguardanti il plugin che Cloud Platform Independent Model offre per Eclipse, e come esso è stato esteso per poter permettere la configurazione automatica e la preparazione del progetto per il deploy su Amazon Web Services.

21 1.4 Struttura della tesi 21 Il Capitolo 7 ha lo scopo di presentare le prestazioni che si sono sperimentate per un applicazione sviluppata in Amazon Web Services attraverso Cloud Platform Independent Model. Il Capitolo 8, infine, delinea le conclusioni ed il possibile lavoro futuro.

22

23 Capitolo 2 Stato dell arte Finora è stata data una prima presentazione ed un primo accenno sui problemi e sui temi che verranno affrontati, da qui in poi, in modo molto più dettagliato. Questo capitolo ha lo scopo di introdurre quanto è stato fatto fino ad oggi per permettere l integrazione e l interoperabilità tra i cloud vendor. La struttura del capitolo prevede una prima presentazione di alcune soluzioni già esistenti, ritenute interessanti per il loro approccio con il problema dell integrazione. Tra queste, verrà anche introdotta la soluzione che questa tesi intende estendere: Cloud Platform Independent Model. A seguito, verrà stilata una classificazione finale che ha il ruolo di poter comparare e confrontare le varie soluzioni sotto alcuni aspetti significativi. 2.1 Soluzioni per la portabilità Le varie problematiche che derivano dall adozione del Cloud Computing, non sono certo temi che non siano stati affrontati fino ad ora. Anzi, sono numerose le soluzioni e le proposte che sono state effettuate, ciascuna con un approccio diverso. Vengono prese in considerazione, ora, alcune delle soluzioni più interessanti o comunque ritenute tali. Esse possono essere elencate nel seguente modo: 1. mosaic 2. CloudFoundry 3. Cloud4SOA

24 24 Stato dell arte 4. Cloud Application Management for Platforms (CAMP) 5. CloudBees 6. SimpleCloud 7. Cloud Platform Independent Model Per ciascuna di esse, verrà presentato l approccio adottato ed alcuni dettagli che caratterizzano la soluzione, individuandone anche aspetti positivi e negativi mosaic La prima soluzione che viene presentata, ambisce a contribuire alla risoluzione, o almeno alla mitigazione, delle problematiche note come l interoperabilità e portabilità di applicazioni e dati all interno del cloud. Il progetto mosaic [1] ha l obiettivo di sviluppare una API neutrale (Application Programming Interface) che integra e media le funzionalità IaaS offerte dalle API proprietarie, mediante adattatori sviluppati per i diversi providers, creando un livello di astrazione PaaS che permette alle applicazioni di negoziare i servizi offerti in modalità cloud in funzione delle richieste effettuate dall utente. È possibile specificare i propri requisiti e comunicarli alla piattaforma mo- SAIC che, utilizzando meccanismi di intermediazione che comprendono il recupero, l interpretazione e l organizzazione di informazioni e di documenti rivolto ad aziende o a privati, cercherà i servizi che meglio corrispondono alle richieste effettuate ed, eventualmente, ricostruiranno per composizione quei servizi non offerti direttamente. Chi sviluppa e mantiene le applicazioni cloud sarà in grado di posticipare le decisioni riguardanti chi deve offrire i servizi al momento in cui questi verranno eseguiti. Gli utenti finali, saranno in grado di individuare i servizi cloud che meglio corrispondono alle proprie esigenze. La piattaforma mosaic avrà anche l effetto, quindi, di facilitare la competizione tra differenti cloud provider che saranno a loro volta in grado di raggiungere nuovi tipi di utenti. Pro: facile individuazione di servizi e providers tramite le API. Contro: alcuni servizi potrebbero non essere coperti.

25 2.1 Soluzioni per la portabilità CloudFoundry Cloud Foundry [2] è una moderna piattaforma applicativa realizzata appositamente per semplificare lo sviluppo, il deployment e la gestione delle applicazioni cloud. Garantisce l implementazione e l intelligence che servono per riunire applicazioni e servizi applicativi eterogenei creati all interno di framework differenti consentendone il deployment trasparente su infrastrutture cloud di ogni genere. Cloud Foundry estende l impegno di VMware per l Open PaaS permettendo di scegliere tra il più ampio insieme di framework e linguaggi, ambienti per il deployment di cloud e servizi applicativi eterogenei. CloudFoundry garantisce, inoltre, il più alto grado di portabilità e minimizza il rischio di lock-in permettendo agli sviluppatori di migrare le applicazioni tra diversi ambienti, tra cloud provider e all interno dei loro stessi datacenter senza bloccare né modificare le applicazioni stesse. Il progetto di CloudFoundry, trattandosi per l appunto di Open PaaS, va al di là della semplice risoluzione dei problemi di interoperabilità e portabilità esistenti tra le piattaforme cloud, proponendosi essa stessa come una piattaforma cloud. Questa soluzione supporta inizialmente i più diffusi framework per la produttività come Spring for Java, Ruby on Rails, Sinatra for Ruby e Node.js. La sua particolare architettura aperta permetterà di supportare rapidamente in futuro anche ulteriori framework di programmazione. Per i servizi applicativi critici CloudFoundry supporta i database MongoDB, MySQL e Redis e i servizi VMware vfabric per il cloud messaging, la gestione flessibile dei dati, il bilanciamento del carico e la gestione delle prestazioni. L Open PaaS offerto da CloudFoundry non è vincolato ad alcun particolare ambiente cloud né richiede un infrastruttura VMware per funzionare. Viceversa, CloudFoundry fornisce il deployment in qualunque ambiente cloud pubblico e privato, fra cui i servizi basati su VMware vsphere. L architettura aperta consente il trasferimento attraverso ambienti cloud eterogenei e nei datacenter aziendali senza bloccare le applicazioni né imporre modifiche alle stesse. Pro: architettura in grado di supportare molto linguaggi di programmazione. Contro: rischio di lock-in in CloudFoundry stesso e nei suoi providers.

26 26 Stato dell arte Cloud4SOA Il progetto Cloud4SOA [3] adotta una tecnologia in grado di risolvere in modo semantico il problema dell interoperabilità tra i cloud providers. L approccio utilizzato permette agli sviluppati ed ai PaaS providers di interfacciarsi l uno con gli altri tramite un vocabolario standardizzato che riesce a mettere in relazione sviluppatori con provider. In questo modo, Cloud4SOA permette di combinare le offerte dei cloud providers con le richieste degli sviluppatori ed, eventualmente, di aiutare quest ultimi nell identificazione delle risorse e soluzioni complementari che i vari fornitori offrono. L interoperabilità semantica è l abilita di superare le incompatibilità e le eterogeneità, semantiche, tra i cloud PaaS e le soluzioni che i fornitori di tale servizio offrono. Si riferisce, in particolare, all abilità di effettuare ininterrottamente il deploy di applicazioni, e dei loro rispettivi dati, sulle varie offerte dei cloud providers; inoltre, è anche possibile migrare tra i providers che utilizzano la stessa tecnologia di fondo, ma con modelli di dati differenti. Un attenta analisi dell interoperabilità nel Cloud Computing, mostra che i conflitti e le incompatibilità che ci sono tra le varie soluzioni sono principalmente di origine semantica; infatti, i maggiori problemi nascono dalla diversa modellazione ed annotazione degli stessi aspetti sui diversi providers. L utilizzo della tecnologia semantica assicura flessibilità; l utente potrà facilmente utilizzare nuove applicazioni e nuove soluzioni che al momento del depolyment in Cloud4SOA non esistono ancora. Pro: flessibilità per la creazione di nuove applicazioni e soluzioni. Contro: i provider devono avere la stessa tecnologia di fondo per permetterne l interoperabilità semantica CAMP Cloud Application Management for Platforms [4] è un progetto che è stato costruito per facilitare la gestione delle applicazioni, incluse le operazioni di packaging e deployment, nelle piattaforme di Cloud Computing.

27 2.1 Soluzioni per la portabilità 27 In accordo con ogni singola tecnologia di ciascun provider, CAMP offre una base comune per poter sviluppare strumenti di gestione delle applicazioni in ambiente multi-cloud; l approccio per la gestione di tali applicazioni è basato sul protocollo REST (REpresentational State Transfer). La specifica offerta da CAMP offre delle API di sviluppo comuni in grado di poter lavorare su più PaaS provider senza un eccessivo adattamento ad un singolo fornitore, in accordo con la linea multi-cloud seguita dall intero progetto. CAMP non e una piattaforma di per se, ma quindi una specifica che può essere adottata da vari PaaS provider per consentirne l interoperabilità tra di essi. Le API di CAMP offrono vantaggi sia per gli utenti finali, sia per i PaaS providers. Il vantaggio principale per gli utenti è la portabilità garantita tra i clouds; non è più necessaria, quindi, la decisione a priori di quale singolo provider scegliere per sviluppare la propria applicazione. Con la standardizzazione delle operazioni di deployment, start, stop, upload e update delle applicazioni, gli utenti possono valutare la soluzione che meglio si adatta ai servizi e agli aspetti che intendono configurare. CAMP può essere implementato nell ambiente di sviluppo e gestione dell applicazione come plugin che guiderà l intera fase di produzione. Per quanto riguarda i providers, invece, CAMP risolve una della maggiori preoccupazioni di chi si avvicina al mondo del Cloud Computing; in questo modo le API comuni offrono ai providers la capacità di poter investire le proprie risorse in altre aree più profittevoli. Pro: standardizzazione dell intero ciclo di vita dell applicazione. Contro: necessita l adozione della specifica CAMP da parte dei provider CloudBees CloudBees [5] è un framework per gli sviluppatori Java che vogliono creare un applicazione web in ambiente cloud, senza la preoccupazione di doversi occupare di tutte quelle operazioni di amministrazione che il Cloud Computing necessita. CloudBees supporta lo sviluppatore di un applicazione non solo in fase di esecuzione del progetto, ma anche nelle prime fasi di sviluppo e testing. L ambiente Paas di CloudBees supporta Tomcat, Java EE, Jboss e MySQL database; è possibile, dunque, sviluppare un applicazione web in Java in grado di

28 28 Stato dell arte utilizzare questi servizi e migrare la stessa applicazione da un provider PaaS ad un altro in grado di offrire gli stessi servizi citati in precedenza. Con il framework di CloudBees, è possibile testare e validare la propria applicazione in locale servendosi di un qualsiasi ambiente di sviluppo integrato come Eclipse. Inoltre, il progetto CloudBees non richiedere alcun uso di API proprietarie o librerie Java non standard. Così facendo, ci si assicura del fatto che il codice sviluppato inizialmente sia e rimanga portabile nel Cloud Computing, poiché CloudBees è in grado di fare il deployment su qualsiasi piattaforma IaaS. Un problema noto del Cloud Computing è il costo che si deve sostenere per far si che un applicazione sviluppata in cloud sia affidabile ed efficiente. In particolare, alcune applicazioni necessitano di essere eseguite 24 ore su 24, 7 giorni su 7. In questa situazione, il Cloud Computing risulta spesso essere una soluzione molto costosa, al punto che un servizio di hosting dedicato sarebbe più economico. Il free-tier di CloudBees cerca di venire incontro a questo problema offrendo agli sviluppatori un livello di servizio gratis, fino a cinque applicazioni e cinque database condivisi; sebbene questo possa sembrare un grande vantaggio soprattutto per i nuovi sviluppatori, esistono molti limiti concernenti questa offerta. Pro: free-tier messo a disposizione anche se con limiti. Contro: framework ristretto al linguaggio JAVA SimpleCloud E un interfaccia comune, in PHP, per l accesso ai servizi di Cloud Computing. Tale interfaccia è volta alla risoluzione degli ormai comuni problemi di portabilità ed interoperabilità della applicazioni all interno dell ambiente cloud. SimpleCloud [6] utilizza il design pattern factory e adapter. Il factory fornisce un interfaccia per creare famiglie di oggetti connessi o dipendenti tra loro, in modo che non ci sia necessità da parte degli utilizzatori di specificare i nomi delle classi concrete all interno del proprio codice. L adapter converte l interfaccia di una classe in una interfaccia diversa. Le API di SimpleCloud offrono un livello di astrazione in grado di poter supportare molti servizi simili offerti dalle differenti piattaforme cloud. La prima

29 2.1 Soluzioni per la portabilità 29 vera implementazione disponibile delle API di SimpleCloud include 3 tipi di servizi: il servizio di file storage che offre la memorizzazione di qualsiasi tipologia di dati; il servizio di document storage che offre la manipolazione di dati strutturati in forma tabulare; Il servizio di simple queue in grado di memorizzare e trasportare messaggi all interno delle code costruite. Il progetto SimpleCloud incoraggia gli sviluppatori PHP ad esplorare il Cloud Computing, scrivendo codice che sfrutta le caratteristiche comuni tra i diversi cloud providers. Inoltre, una volta che gli sviluppatori cominceranno ad avere una certa dimestichezza con ciascuna piattaforma cloud, saranno inclini a sfruttare tutti gli aspetti specifici di ogni provider in modo da trarne ultieriori vantaggi con funzionalità sempre più ricche. Pro: completo per sviluppatori PHP. Contro: supporto solo del linguaggio PHP Cloud Platform Independent Model La logica di Cloud Platform Independent Model [7] è quella di sviluppare un framework per gli sviluppatori JAVA in grado di astrarre le implementazioni specifiche di ciascun cloud vendor per poter offrire alcuni dei servizi che sono comuni ad certo gruppo di piattaforme scelte ed implementate nel framework. Il principio che sta alla base del progetto, è quello di offrire allo sviluppatore dell applicazione un interfaccia in grado di poter effettuare le operazioni di deploy e run su di uno specifico cloud vendor a scelta tra quelli implementati. Una volta, dunque, scritto e validato il codice necessario per poter eseguire l applicazione, non ci sarà alcun bisogno di attuare alcuna modifica sostanziale qualora si volesse cambiare il cloud vendor scelto inizialmente. Questo tipo di risultato è stato raggiunto grazie ad un implementazione specifica del framework, che rende possibile la portabilità e la interoperabilità delle applicazioni e dei suoi servizi all interno del cloud. L approccio di Cloud Platform Independent Model è, quindi, quello di offrire tramite il proprio framework, alcuni dei servizi più significativi in comune tra un certo numero di cloud vendor. Attualmente, le piattaforme implementate sono quelle di Google App Engine e Microsoft Azure. Pro: completo per gli sviluppatori JAVA.

30 30 Stato dell arte Contro: supporto solo del linguaggio JAVA. 2.2 Classificazione e confronto delle soluzioni Dopo aver citato ed introdotto alcune soluzioni esistenti in grado di risolvere, o quanto meno mitigare, il problema dell integrazione tra più provider, può essere utile cercare di evidenziare le caratteristiche comuni e le differenze che esse presentano tra di loro. A tale proposito, viene stilata una classificazione, che non ha come ruolo quello di valutare se una soluzione sia migliore di un altra, ma cerca semplicemente di mettere a fuoco gli aspetti più significativi per ciascuna soluzione. La Tabella 2.1 mette in evidenza, per ogni soluzione, i seguenti aspetti: una breve descrizione di come essa viene offerta agli sviluppatori finali, i tipi di Cloud Computing supportati, il tipo di soluzione adottato per risolvere il problema dell integrazione tra providers, ed, infine, i cloud vendor implementati. Alcune soluzioni, come si nota in tabella, presentano uno o più aspetti simili tra di loro.

31 2.2 Classificazione e confronto delle soluzioni 31 Nome Descrizione Clouds Tipo di soluzione mosaic Open source IaaS Interoperabilità API e portabilità tramite adattatori CloudFoundry Open PaaS IaaS Piattaforma applicativa Cloud4SOA Widgetize services PaaS Interoperabilità semantica CAMP Common interface PaaS Portabilità con for services standardiz- zazione delle operazioni di deploy, run e update tramite REST API CloudBees Integrated PaaS Portabilità tramite and scalable framework platform JAVA SimpleCloud Common interface PaaS Interoperabilità for services e portabilità tramite API PHP Cloud Platform Common interface PaaS Interoperabilità Independent for services e portabilità tra- Model mite framework JAVA Providers Google, Amazon Zoho, CloudFoundry providers Amazon, Azure, Google, Oracle CAMP providers IaaS providers Amazon, Azure, Nirvanix, Rackspace Azure, Google Tabella 2.1: Tabella che evidenza e confronta i punti principali delle soluzioni presentate

32

33 Capitolo 3 Cloud Platform Independent Model Nel capitolo precedente sono state introdotte alcune soluzioni interessanti per il problema della portabilità delle applicazioni ed interoperabilità dei provider nel mondo del Cloud Compting. Si è anche accennato alla soluzione che il progetto di questa tesi intende estendere: Cloud Platform Independent Model (CPIM). In questo capitolo, verranno descritte in maniera più dettagliata e completa le scelte implementative che sono alla base del funzionamento del framework Cloud Platform Independent Model. Inizialmente, viene stesa un introduzione riguardante Cloud Platform Independent Model ed il paradigma con il quale è stato costruito. In seguito, verranno affrontati gli aspetti che riguardano la composizione e la configurazione di un progetto che utilizza il framework CPIM, e come quest ultimo riesca a rendere portabile l applicazione sviluppata. Infine, verranno elencati i singoli servizi offerti da Cloud Platform Independent Model e come essi possono essere utilizzati durante lo sviluppo di un applicazione. 3.1 Introduzione CPIM Cloud Platform Independent Model [7] è, per alcuni aspetti, simile ad una o più soluzioni elencate nel capitolo precedente. La logica di Cloud Platform Independent Model è quella di sviluppare un framework in grado di astrarre le implementazioni specifiche di ciascun cloud vendor per poter offrire alcuni dei servizi che sono comuni ad certo gruppo di piattaforme. In particolare, il progetto cerca quanto più di sfruttare le sinergie e di assottigliare le differenze che le varie implementazioni dei cloud vendor presentano.

34 34 Cloud Platform Independent Model Il principio che sta alla base del progetto, è quello di offrire allo sviluppatore dell applicazione un interfaccia in grado di poter effettuare le operazioni di deploy e run su di uno specifico provider a scelta tra quelli implementati. Una volta, dunque, scritto e validato il codice necessario per poter eseguire l applicazione, non ci sarà bisogno di attuare alcuna modifica sostanziale qualora si volesse cambiare il vendor scelto inizialmente. Figura 3.1: Figura che riassume il paradigma utilizzato da Cloud Platform Independent Model Questo tipo di risultato è stato raggiunto grazie ad un implementazione specifica del framework (Figura 3.1) che rende possibile la portabilità e la interoperabilità delle applicazioni e dei servizi che essa fa uso. Cloud Platform Independent Model utilizza uno dei fondamentali design pattern creazionali della programmazione orientata agli oggetti: l abstract factory. L abstract factory fornisce un interfaccia per creare famiglie di oggetti connessi o dipendenti tra di loro, in modo che non ci sia necessità di specificare i nomi delle classi concrete all interno del proprio codice. In questo modo si permette che un sistema sia indipendente dall implementazione degli oggetti concreti e che il client, attraverso l interfaccia, utilizzi diverse famiglie di prodotti. Questo pattern è utile quando: si vuole un sistema indipendente da come gli oggetti vengono creati, composti e rappresentati;

35 3.1 Introduzione CPIM 35 si vuole permettere la configurazione del sistema come scelta tra diverse famiglie di prodotti; si vuole che i prodotti che sono organizzati in famiglie siano vincolati ad essere utilizzati con prodotti della stessa famiglia; si vuole fornire una libreria di classi mostrando solo le interfacce e nascondendo le implementazioni. Nel nostro caso, non è importante specificare a priori la piattaforma cloud durante la stesura del codice dell applicazione, poiché tale scelta potrà essere effettuata anche in un secondo momento in uno specifico file di configurazione costruito appositamente. È proprio questo l aspetto fondamentale che garantisce l interoperabilità e la portabilità di un applicazione sviluppata con il framework Cloud Platform Independent Model. Il design pattern dell abstract factory (Figura 3.2) è costituito da 5 componenti: AbstractFactory, che dichiara l interfaccia per le operazioni che creano i prodotti astratti; ConcreteFactory, che implementa le operazioni per creare i prodotti concreti; AbstractProduct, che dichiara l interfaccia per un tipo di oggetto prodotto; ConcreteProduct, che implementa l interfaccia AbstractProduct e definisce l oggetto prodotto che deve essere creato dalla factory concreta corrispondente; Client, che utilizza solo le interfacce dichiarate da AbstractFactory e AbstractProduct. In generale si crea una sola istanza di ConcreteFactory a run-time. Questa istanza gestisce la creazione di una sola famiglia di oggetti con un implementazione specifica. Per creare oggetti di un altra famiglia bisogna istanziare un altra factory. Creando ogni ConcreteFactory come singleton, ci si assicura che esista una sola istanza della classe a run-time accessibile pubblicamente. L AbstractFactory, invece, delega la creazione di oggetti prodotto alle sue sottoclassi ConcreteFactory. Poiché AbstractFactory definisce solo l interfaccia, la creazione

36 36 Cloud Platform Independent Model dei prodotti è responsabilità delle classi ConcreteFactory. Si può utilizzare un factory-method per ogni prodotto, ovvero metodi che saranno sovrascritti dalle factory concrete. Figura 3.2: Diagramma che evidenza le principali componenti di un abstract factory Nel framework Cloud Platform Independent Model, questo tipo di design pattern è stato implementato in modo tale che: una AbstractFactory rappresenti uno dei servizio offerti da Cloud Platform Independent Model; una ConcreteFactory rappresenti uno dei cloud vendor supportati dal framework; un AbstractProduct rappresenti l interfaccia dei metodi implementati per uno dei servizi offerti da CPIM; un ConcreteProduct rappresenti la vera e propria implementazione di ogni metodo specificato nell AbstractProduct per uno dei provider supportati da Cloud Platform Independent Model;

37 3.1 Introduzione CPIM 37 il Client rappresenti lo sviluppatore finale che fa utilizzo dei servizi e provider offerti e supportati da Cloud Platform Independent Model. Vista la natura del design pattern stesso, è necessario, dunque, operare una scelta per quanto riguarda i cloud vendor da supportare ed i servizi che il framwork intende offrire. Per quanto riguarda i vendor, Cloud Platform Independent Model implementa Google App Engine e Windows Azure. I servizi scelti, invece, sono: Blob Manager Service, ovvero il servizio adibito alla gestione degli oggetti BLOB (binary large object) all interno del database; Entity Manager Service, ovvero il servizio che si occupa della gestione dei dati in un database non relazionale; SQL Service, ovvero il servizio che si occupa della gestione dei dati in un database relazionale; Mail Service, ovvero il servizio che gestisce l invio delle ; Memcache Manager Service, ovvero il servizio che si occupa della gestione della tecnologia di caching distribuito; Queue Service, ovvero il servizio che si occupa della gestione delle code. Nel contesto dei possibili provider implementabili in Cloud Platform Independent Model, come già anticipato nel capitolo precedente, si inserisce il progetto di questa tesi; essa andrà, per l appunto, ad estendere il numero di piattaforme disponibili per poter sviluppare ed eseguire la propria applicazione. L estensione verrà raggiunta con l implementazione di Amazon Web Services tra i vendor disponibili ed utilizzabili in Cloud Platform Independent Model. Si cercherà, ora, di dare una breve ma esaustiva introduzione riguardo i due vendor già offerti in Cloud Platform Independent Model Google App Engine

38 38 Cloud Platform Independent Model Google App Engine, in sigla GAE o semplicemente App Engine, [8] è un provider PaaS di Cloud Computing per lo sviluppo e l ospitalità (hosting) di applicazioni web. Il servizio consente di creare applicazioni web a traffico elevato senza la necessità di dover gestire l infrastruttura sottostante. Le applicazioni sono incapsulate, per sicurezza, in sandbox ed eseguite su più server. In generale, una sandbox identifica un ambiente in cui possono essere fatte sperimentazioni che potrebbero non portare neppure ad aprire una fase di sviluppo, il cui scopo è quello di investigare sugli effetti di eventuali modifiche o sviluppi che sono ancora nella fase dello studio della fattibilità o dello studio dei costi e benefici. L utilizzo delle sandbox ed il conseguente accesso limitato al sistema operativo sottostante le applicazioni, consente ad App Engine di distribuire le richieste di accesso all applicazione su di una molteplicità di server; inoltre, consente anche di mandare in esecuzione o stoppare uno o più server in modo da servire in maniera intelligente il traffico in entrata. Google mette a disposizione due sandbox collaudate per sviluppare le proprie applicazioni: una in Java e l altra in Python. Inoltre, per Java, Google mette a disposizione anche un suo framework per aiutare la creazione di applicazioni web: Google Web Toolkit. Esiste, infine, una terza sandbox implementata in via sperimentale che consente di programmare in Go. Go è un linguaggio di programmazione semplice, nuovo, estremamente efficiente e nato proprio per lavorare su ambienti cluster e cloud. La piattaforma di Google, quindi, offre una scalabilità automatica per le applicazioni; a seconda del numero di richieste d uso per quella applicazione, alloca in automatico più risorse per gestire la domanda addizionale. Il servizio offerto da Google App Engine è gratuito fino a un certo numero di risorse consumato; viene richiesto un compenso per spazio addizionale, maggiore banda oppure ore di istanza richieste dall applicazione Windows Azure Windows Azure [9] è una piattaforma cloud in grado di eseguire applicazioni Windows distribuite su di un largo numeri di server localizzati nei data center di Microsoft, e di memorizzare i dati