Sviluppo di applicazioni Cloud

Quanto detto nella sottosezione precedente riguardo alla documentazione fornita da Google App Engine non deve indurre a pensare che qualunque applicazione sviluppata tramite di esso sia automaticamente un’applicazio- ne Cloud. Il fatto che sia possibile programmare in maniera abbastanza semplice non comporta infatti che un approccio elementare allo sviluppo di applicazioni sia equivalente ad uno ingegneristico.

Vedremo di seguito come alcune indicazioni generali vengano fornite comunque anche dalla documentazione di Google App Engine, nonostante essa si rivolga ad un pubblico con competenze minori rispetto a quello di AWS, e, soprattutto,

Indicazioni generali

La documentazione di Google App Engine, nonostante si rivolga ad un pub- blico con competenze minori rispetto a quello di AWS, riporta comunque alcune indicazioni che `e sempre bene considerare quando si realizza un’ap- plicazione in ambiente Cloud. Queste sono state dedotte in particolare leggendo ed analizzando i tutorial9 che vengono forniti per lo sviluppo di applicazioni tramite la tecnologia JSP e trovano riscontro anche con quan- to gi`a esposto nelle sezioni precedenti. Tali indicazioni infatti consistono in una serie di consigli che vengono rivolti allo sviluppatore e si possono cos`ı riassumere:

• sviluppare applicazioni cercando di suddividerle in componenti, rag- gruppando le funzionalit`a comuni e separando quelle appartenenti a contesti diversi;

• sviluppare i singoli componenti in un’ottica orientata ai servizi. Realizzare applicazioni tenendo in considerazione tali indicazioni porta alla produzione di un software dotato di un buon livello di qualit`a, in grado di sfruttare le caratteristiche di scalabilit`a automatica che vengono fornite dalla piattaforma di Google App Engine.

Applicazione di pattern

Per raggiungere un livello di qualit`a superiore e trarre una maggiore efficacia dai meccanismi e dalle politiche di scalabilit`a `e sufficiente in realt`a applicare i principi ed i pattern architetturali discussi nelle sezioni precedenti di questo capitolo. Mentre con Amazon Web Services infatti la conoscenza di tali pattern poteva da sola non essere sufficiente ed occorreva quindi anche uno studio ulteriore per capire come applicarli concretamente e correttamente, in Google App Engine, proprio per il fatto che esso offre servizi di tipo PaaS e permette agli sviluppatori di occuparsi solamente del software, non esistono barriere ulteriori tra la conoscenza ed una buona pratica nell’applicazione dei pattern e la loro effettiva applicazione.

Concludendo quindi, possiamo osservare come lo sviluppo di applicazioni Cloud, anche dal punto di vista dell’utilizzo di pattern e principi architettu- rali, sia molto pi`u semplice tramite Google App Engine che non con Amazon

Web Services. Questo, coerentemente anche con quanto detto nel capitolo precedente, `e legato al fatto che i servizi di Google App Engine, essendo di tipo PaaS, sono strettamente orientati proprio allo sviluppo di applicazioni. Per quanto riguarda AWS invece, volendo utilizzare i suoi servizi di IaaS sempre per sviluppare applicazioni, si riscontra la presenza di un gap che deve essere colmato da parte del progettista, aumentando la quantit`a e la complessit`a del suo lavoro.

6.6

Conclusioni

Come abbiamo potuto capire da questo capitolo, una questione fondamen- tale degli ambienti Cloud `e la realizzazione di applicazioni Cloud, intese, come definito all’inizio, nel senso di applicazioni in grado di sfruttare ap- pieno le caratteristiche di tali ambienti. Purtroppo spesso non vengono forniti strumenti o supporti tecnologici in grado di aiutare lo sviluppatore a scrivere applicazioni di questo tipo: tutto si basa sulle sue capacit`a e sul- l’uso che egli fa dei principi e dei pattern architetturali esposti in questo capitolo, la cui applicazione talvolta pu`o risultare anche molto complessa. Se infatti il modello che discende da essi `e molto diverso da quello indot- to dalla tecnologia sottostante, mappare il primo sul secondo pu`o risultare molto complicato e dispendioso, in termini di energie e di tempo da parte di progettisti e sviluppatori.

In particolare, il modello che viene indotto dalla tecnologia `e quasi sem- pre quello a oggetti, poich´e nella maggior parte dei casi i linguaggi adottati sono proprio quelli Object-Oriented, al giorno d’oggi decisamente i pi`u diffu- si. Tuttavia essi presentano per`o dei grossi limiti che, se non sono percepiti nel contesto di applicazioni desktop o comunque lievemente distribuite, per applicazioni Cloud diventano molto rilevanti. Il paradigma Object-Oriented infatti, nella versione che oggi viene implementata comunemente dai lin- guaggi e che in realt`a `e leggermente diversa da come era stata originaria- mente pensata, non modella in alcun modo il flusso di controllo associato agli oggetti e realizza la comunicazione tra di essi tramite invocazione di metodi per riferimento diretto. Questo rappresenta una grande limitazione nel contesto di ambienti altamente distribuiti poich´e introduce due livelli di accoppiamento: quello tra la comunicazione ed il flusso di controllo e quello tra qualunque coppia di oggetti che necessitino di comunicare, uno dei quali

deve necessariamente avere un riferimento diretto all’altro. Di conseguenza, i linguaggi ad oggetti ostacolano lo sfruttamento del parallelismo e dell’a- sincronicit`a, poich´e richiedono che vengano impiegate specifiche soluzioni di livello piuttosto basso sia per slegare il flusso di controllo dalla comunica- zione, tipicamente implementando quest’ultima con dei meccanismi diversi da quelli nativi dei linguaggi (ad esempio tramite socket, piuttosto che tra- mite invocazione di metodi), sia per poter usufruire di pi`u flussi di controllo all’interno di una stessa applicazione (ad esempio usando specifiche librerie per il multi-threading). Inoltre rendono anche assai complicato gestire la distribuzione degli oggetti poich´e non possono esistere riferimenti diretti che attraversino i confini della singola macchina, quindi le applicazioni restano comunque sempre coscienti, ad un certo livello, della localizzazione e della mobilit`a dei propri componenti.

Si rende ora quindi necessario abbandonare il paradigma Object-Oriented per passare a qualcosa che si trovi ad uno stato pi`u avanzato nell’evoluzione: questo `e il tema fondamentale che verr`a affrontato nel prossimo capitolo.

Nuovi modelli e paradigmi -

Orleans

Come gi`a detto nel capitolo precedente, il paradigma Object-Oriented non `

e pienamente in grado di dominare la complessit`a degli ambienti altamente distribuiti come quelli Cloud. Per poterlo utilizzare `e quindi necessario dotarsi di librerie ed estensioni dei linguaggi che permettano di risolvere molti dei problemi che tipicamente sorgono in tali ambienti, legati ad aspetti come ad esempio il multi-threading, la concorrenza, la consistenza degli stati, la sincronizzazione e la coordinazione. Cos`ı facendo per`o spesso si perviene ad un software molto complesso, che finisce col porre un accento maggiore sui problemi di cui sopra piuttosto che sul contesto applicativo.

Una soluzione a queste problematiche pu`o essere ottenuta adottando dei diversi paradigmi, i quali si adattano molto meglio agli ambienti distribuiti e concorrenti. Uno di questi paradigmi `e quello ad attori, che verr`a introdotto nella prima sezione di questo capitolo, basandosi sulla descrizione fornita in [6]. Successivamente prenderemo in esame Orleans, un framework tuttora in fase di sviluppo da parte di Microsoft che, adottando un modello molto simile a quello ad attori, permette di scrivere applicazioni affidabili, scala- bili ed elastiche. Esso si basa sulla tecnologia .NET ed `e reso disponibile ai programmatori tramite delle librerie per i linguaggi supportati da tale tecnologia, come C# o F#. Le informazioni riguardanti Orleans presenti in questo capitolo sono state tratte da [1].

7.1

Il modello ad attori