Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Programmazione I

Bluemix:una PaaS per lo sviluppo di software in

Cloud

Anno Accademico 2014/2015 Candidato: Sava Claudio matr. N46/000248

A mio padre,perchè non c’è gioia più grande di vederlo assistere al coronamento di tanti sacrifici,alla mia famiglia tutta ed alla mia fidanzata,la mia più grande forza

Indice

Bluemix:una PaaS per lo sviluppo di software in Cloud .................................................................................... I Indice ............................................................................................................................................................... III Introduzione ....................................................................................................................................................... 5 Capitolo 1: Il Cloud Computing e la sua adozione nello sviluppo software ..................................................... 8

1.1 Le basi del Cloud Computing………………………………………………………………………...8

1.2 Modelli di distribuzione cloud ............................................................................................................ 9 1.2.1 Public Cloud .............................................................................................................................. 9

1.2.2 Private Cloud ............................................................................................................................. 9

1.2.3 Community Cloud .................................................................................................................... 10

1.2.4 Hybrid Cloud..............................................................................................................................10

1.3 Modelli di servizio ............................................................................................................................ 10 1.4 Pro e contro della soluzione PaaS nello sviluppo software ............................................................... 11

1.5 Il confine tra IaaS e PaaS:DevOps .................................................................................................... 13 1.6Virtualizzazione……………………………………………………………………………………..15

Capitolo 2:Introduzione a Bluemix:architettura e sicurezza ........................................................................... 16 2.1 Panoramica di Bluemix ..................................................................................................................... 16

2.2 Architettura di Bluemix .................................................................................................................... 17

2.2.1 Bluemix pubblico.........................................................................................................................17

2.2.2 Bluemix dedicato.........................................................................................................................19

2.3 Sicurezza in Bluemix ........................................................................................................................ 20

2.3.1 Platform Security ....................................................................................................................... 21

2.3.2 Data Security...............................................................................................................................21

2.3.3 App Security...............................................................................................................................22

2.4 Architettura di distribuzione della sicurezza in Bluemix .................................................................. 22 Capitolo 3 :Bluemix:How it works .................................................................................................................. 24

3.1 Infrastruttura offerta da Bluemix ...................................................................................................... 24

3.1.1 Cloud Foundry............................................................................................................................24

3.1.2 IBM Containers...........................................................................................................................25

3.1.3 Virtual Machine (BETA)............................................................................................................25

3.2 Applicazioni Bluemix:staging e distribuzione .................................................................................. 26 3.3 SoftLayer:le fondamenta di Bluemix ................................................................................................ 29

Capitolo 4:Creazione,gestione e sviluppo di applicazioni in Bluemix ....................................................... 31 4.1 Creare applicazioni con Bluemix ....................................................................................................... 31

4.1.1 Creazione applicazioni mobile.....................................................................................................31

4.1.2 Creazione di applicazioni web .................................................................................................... 32 4.2 Gestione Applicazioni ....................................................................................................................... 32 4.2.1 Interfaccia da riga di comando CF ................................................................................................. 33

4.2.2 Interfaccia utente Bluemix ........................................................................................................... 33 4.2.3 Gestione di applicazioni con Bluemix DevOpsServices ............................................................. 34

4.3 Code Editing in Bluemix ..................................................................................................................... 36 4.3.1 CLI dev_mode Bluemix .............................................................................................................. 36 4.3.2 IBM Eclipse tool for Bluemix ..................................................................................................... 36

4.3.3 Editing Code con BluemixDevOpsServices…………………………………………….............37

Conclusioni ...................................................................................................................................................... 40 Bibliografia ...................................................................................................................................................... 41

5

Introduzione

Negli ultimi anni l’innovazione e la velocità di sviluppo sono divenuti sempre più concetti

cardine nel campo informatico e tecnologico,e questo ha portato alla ricerca sempre più crescente di

attività di sviluppo più snelle, in modo da venire in contro alle esigenze di agilità del business

richieste dal mercato. Lo sviluppo software è spesso,erroneamente, associato alla scrittura di

codice e alla fase di testing finale ad esso correlato, mentre in realtà presenta un vero e proprio

ciclo di vita, con attività ben definite quali analisi , progettazione, sviluppo,test e manutenzione,

necessarie al monitoraggio dell’evoluzione dell’applicazione attraverso le metodologie fornite

dall’ingegneria del software.Ridurre le tempistiche legate all’espletamento delle suddette attività

risulta essere uno degli obiettivi più importanti delle più grandi imprese del settore

tecnologico,come evidenziato da IBM nel suo technical summit della divisione software “Innovate

2014” tenutosi ad Orlando in Florida [1] .Una “conference for practitioners from practitioners ”,

così come è stata definita dal General Manager di IBM Rational, Kristof Kloeckner,il cui slogan è

stato “Innovate@speed”. Ogni attività caratterizzante il summit,oltre 500 tra workshop e sessioni

tecniche,era raggruppata nelle 3 aree di maggiore interesse oggi ,in una visione IBM ampiamente

condivisa,caratterizzante lo sviluppo software:

Continuous engineering,ovvero la capacità di velocizzare il delivery di prodotti complessi

attraverso metodologie di riutilizzo dei componenti,di verifica continua ,di analisi ed

integrazione di conoscenze preesistenti di team di sviluppatori.

DevOps, metodologia basata sulla collaborazione tra aree di sviluppo e delle operazioni al

fine di rendere più efficiente il delivery del prodotto.

Innovazione, il concetto di dominare l’impatto sullo sviluppo e sul rilascio di prodotti

software delle nuove tecnologie,come il Cloud,il mobile e l’IoT(Internet of Things).

Il punto focale del summit è stato evidenziare il freno posto dalla mancata velocità di sviluppo del

software,che impedisce una rapida risposta dell’IT alle esigenze di business,quando sono stati fatti

enormi passi avanti dal lato dei sistemi e delle infrastrutture in termini di velocità di

esecuzione,efficienza operativa e rapidità di risposta ai carichi di lavoro [2].Ed è qui che IBM

suggerisce di intervenire,cambiando le metodologie di sviluppo delle nuove applicazioni facendo

uso della tecnologia Cloud,passando dai precedenti modelli di sviluppo in cascata o quelli basati su

processi RUP,Rational Unified Process,ad un modello Agile/Lean legato alle architetture orientate

al servizio ,SOA, incentrato sugli strumenti anziché sulle regole, con una costante capacità di

apprendimento e in cui la pianificazione adattativa si sostituisce a quella di tipo predittivo. Il

modello di sviluppo deve,dunque, essere di tipo "outside-in", focalizzandosi sui cosiddetti

"stakeholder" del business, ovvero su chi risente direttamente dell'impatto del software, e questa

focalizzazione va mantenuta durante l'intero ciclo di vita, aggiornando gli scenari di business e

utilizzando iterazioni verso il prodotto finale ognuna delle quali sia utilizzabile dagli stakeholder e

dagli end users. I componenti che abilitano l'integrazione e la semplificazione del software devono

essere flessibili e riutilizzabili, e questo richiede necessariamente di basarsi su open standard.

Un altro passo fondamentale è ,sicuramente, l’ aggiornamento delle applicazioni esistenti in

maniera che si bilanci l’ottimizzazione raggiunta per le infrastrutture con una progressiva

6

evoluzione verso una architettura caratterizzata da componenti riusabili e componibili che permetta

di applicare i principi del DevOps.

Figura 1:Modello di sviluppo Agile

La risposta IBM per accellerare il delivery dei prodotti,sopperire alle eventuali mancanze dei team

di sviluppo e favorire l’aggiornamento e l’innovazione architetturale e funzionale delle applicazioni

esistenti è BlueMix,introdotto nel febbraio 2014 come versione open beta e reso disponibile

sull'IBM Cloud Marketplace il 30 giugno 2014 .

BlueMix è la soluzione PaaS,Platform as a Service,di IBM che,attraverso appositi servizi e

strumenti,consente di sviluppare ,testare e rendere operativa una applicazione in ambiente cloud.

Basata su SoftLayer,l’infrastruttura cloud IaaS di IBM,e su Cloud Foundry, la piattaforma PaaS

open source standard internazionale che fornisce servizi cloud,applicativi e framework,BlueMix

consente di azzerare processi onerosi come quelli di scelta,acquisto, installazione e configurazione

hardware e software per lo sviluppo dell’applicazione, venendo in contro alle esigenze aziendali con

vantaggi in termini economici,di flessibilità e di time to market. L’obiettivo della mia tesi ,dunque,è

evidenziare i vantaggi offerti dalla scelta di una soluzione PaaS nello sviluppo software,con

particolare attenzione ai servizi di integrazione e sviluppo forniti da BlueMix,la soluzione IBM alle

problematiche di cui sopra.La tesi sarà dunque così strutturata:

Nel primo capitolo analizzerò i concetti alla base del Cloud Computing,fornendone una

descrizione dettagliata ed evidenziando le motivazioni che portano ad una sua adozione nel

processo di sviluppo software.

Nel secondo capitolo fornirò una panoramica di introduzione a Bluemix,caratterizzandone i

servizi offerti,l’architettura e gli aspetti legati alla sicurezza.

Nel terzo capitolo analizzerò in dettaglio le modalità di funzionamento di Bluemix,sia di alto

livello con l’analisi della distribuzione e dello staging delle applicazioini,sia dettagliando

l’architettura su cui si basa,con approfondimenti su SoftLayer e Cloud Foundry.

Nel quarto ed ultimo capitolo evidenzierò gli aspetti implementativi legati alla

creazione,gestione ed editing delle applicazioni in Bluemix,con una panoramica sulla

maggior parte di tools e servizi offerti.

7

8

Capitolo 1: Il Cloud Computing e la sua adozione nello sviluppo software

1.1 Le basi del Cloud Computing Il Cloud Computing è un insieme di tecnologie che permette,sotto forma di un servizio fornito da un

provider al cliente,di memorizzare,archiviare ed elaborare dati grazie a risorse hardware e o

software distribuite e virtualizzate in Rete.Esso,più che una nuova tecnologia vera e propria,viene

visto come un nuovo approccio,una nuova modellizzazione di tecnologie già esistenti quali

Internet,virtualizzazione,Web ed altre,al fine di creare una piattaforma di elaborazione che astrae le

risorse hardware e software impiegate prescindendo da una localizzazione fisica in senso

stretto.Questa tecnologia tenta di risolvere le problematiche precedentemente introdotte

semplificando gli approcci necessari allo sviluppo e o all’integrazione poichè non richiede al cliente

di gestire l’hardware ed il software in quanto ad occuparsene è un fornitore esperto.L’infrastruttura

condivisa permette all’utente di pagare solo le funzionalità necessarie,gli aggiornamenti sono

automatici, la scalabilità,sia verso l’alto che verso il basso è molto semplice e l’utilizzo di internet e

server remoti centrali per mantenere i dati e le applicazioni consentono di utilizzare il software

senza installazione,accedendo ai propri file personali da qualsiasi computer ,tablet ed altri smart

devices.Il NIST ,National Institute of Standards and Technology, fornisce una definizione di Cloud

Computing che ne evidenzia le caratteristiche principali e la struttura [3]:

Cloud computing is a model for enabling ubiquitous, convenient, on demand network access to

a shared pool of configurable computing resources (e.g., networks, servers, storage,

applications, and services) that can be rapidly provisioned and released with minimal

management effort or service provider interaction. This cloud model is composed of five

essential characteristics, three service models, and four deployment models.

Il Cloud Computing è dunque visto come un modello in grado di consentire ovunque un

accesso on-demand,su richiesta, economicamente conveniente ad un insieme condivisibile di

risorse computazionali configurabili (ad esempio: reti, server, storage, applicazioni e servizi)

che possano essere rapidamente erogati e rilasciabili da parte di un provider con un minimo

sforzo per la gestione o l’interazione. Questo modello di Cloud è composto da cinque

caratteristiche fondamentali, da tre modelli di servizio e da quattro modelli di distribuzione.

I principi fondamentali del Cloud Computing sono:

On-demand self-service. La possibilità di offrire al consumer servizi su richiesta senza

dover interagire con il personale del provider dei servizi stessi.

Broad network access. Un ampio accesso alla rete tramite meccanismi standard che

consentono l’utilizzo dei servizi disponibili in essa da dispositivi-piattaforme client

eterogenee.

Resource pooling. Un pool di risorse raggruppate per poter servire

contemporaneamente, una serie di consumers attraverso il modello multi-tenant, con

diverse risorse fisiche e virtuali dinamicamente assegnate e riassegnate secondo le

richieste di ciascun cliente. Si ha,dunque, indipendenza dalla locazione poichè il cliente

9

può usufruire dei servizi pur non avendo il controllo e la conoscenza dell’esatta

posizione delle risorse.

Rapid elasticity. La cosiddetta rapida elasticità che indica come le richieste di ulteriori

risorse siano gestite automaticamente,in alcuni casi, e dinamicamente in relazione alla

domanda del cliente ,al quale,la capacità delle risorse apparirà illimitata ed acquistabile

in qualsiasi momento nelle quantità desiderate.

Measured service. I servizi “misurati”,ovvero la capacità dei Cloud systems di

controllare e ottimizzare automaticamente l’uso delle risorse facendo leva su capacità di

misurazione.Sono tipicamente basati sul modello pay-per-use,e presentano un livello di

astrazione appropriato per ogni tipo di servizio richiesto.L’utilizzo della risorsa può

essere monitorato e controllato in maniera trasparente sia dal provider che

dall’ultilizzatore del servizio.

1.2 Modelli di distribuzione cloud

Nonostante si consideri il cloud sempre in relazione all’utenza finale ed agli obiettivi da

perseguire,come aumentare la flessibilità liberando le risorse e pagando solo ciò che realmente si

utilizza,le architetture cloud non sono tutte uguali e si differenziano in varie tipologie identificabili

nei modelli di:

Public Cloud

Private Cloud

Hybrid Cloud

Community Cloud In generale,l’utilizzo di una soluzione cloud per le aziende ha un impatto sui costi operativi a

consumo o a sottoscrizione,a seconda della metodolgia di utilizzo, per questo la scelta della

distribuzione cloud da adottare è strettamente legata agli obiettivi da perseguire per l’azienda

stessa[4].

1.2.1 Public Cloud

Il cloud di tipo pubblico si basa su uno standard in cui un service provider rende disponibile in rete

le risorse hardware e software utilizzabili dal consumer,ed i cui servizi si basano,principalmente, sul

modello pay-per-use.Inoltre,le aziende possono disporre di un data center,virtualmente

proprietario,annullando i costi legati alla manutenzione dello hardware al loro interno,alla

formazione del personale per la gestione di reti fisiche e alle licenze software.La flessibilità del

cloud pubblico lo rende una soluzione appetibile per aziende di qualunque dimensione,anche se

viene principalmente adottato da piccole e medie imprese e per startup.D’altro canto lo svantaggio

rappresentato da questa soluzione cloud è legato ,da un lato, dal dover pagare i costi di contratto con

il provider per tutta la durata di vita del prodotto,dall’altro all’impossibilità di avere controllo

sull’infrastruttura e sulle scelte di policy di sicurezza, in quanto i costi legati al mantenimento di un

data center che garantisca le regole di protezione delle proprie sale macchina risultano davvero

elevati, ed un lusso per poche aziende.

1.2.2 Private Cloud Il modello di cloud privato presenta un ambiente informatico interno all’azienda stessa,dedicato

interamente ad essa senza eventuali contratti con terze parti,realizzato attraverso una

virtualizzazione di risorse e servizi,la cui gestione risulta standardizzata .La presenza di una data

center interno, che permette il mantenimento dei dati nella propria struttura operativa,favorisce la

risoluzione delle problematiche legate alla privacy e alla gestione delle policy di sicurezza

10

caratteristiche del modello di cloud pubblico,anche se tutti i costi di gestione e manutenzione

addebitati interamente all’azienda stessa hanno caratterizzato una lenta adozione di questa soluzione

cloud.Pian piano,però,si è iniziato a comprendere che usufruire di un sistema di provisioning

semplificato,configurabile e performante ,consente di servire in base alle loro effettive necessità le

singole parti aziendali,ammortizzandone i costi e rappresentando un effettivo vantaggio.A

prescindere dalle problematiche legate ai costi di manutenzione e gestione addebitate all’azienda,un

altro svantaggio rappresentato da questo modello cloud è relativo alla scalabilità poichè il numero di

risorse risulta limitato , a differenza del Cloud pubblico nel quale il consumer ha la percezione che

queste ultime siano illimitate. Ciò può creare dei problemi ed un modo per risolverli è il private

virtual Cloud, modello in cui si costruisce un Cloud privato basandosi su un Cloud pubblico e non

sulle risorse dell’azienda. Con questa soluzione il problema della scalabilità viene risolto, ma la

sicurezza non risulta essere massima come nel modello privato puro.

1.2.3 Community Cloud

Questa distribuzione cloud è realizzata mediante una porzione isolata di Public o Private Cloud,

oppure come un ambiente computazionale completamente isolato.In pratica può essere definito

come un ambiente cloud pubblico con elementi tipici del cloud privato ,come determinati livelli di

sicurezza e privacy.Essenzialmente,dunque,può essere visto come una piattaforma multiutente nel

quale possono cooperare più compagnie condividendo in questa community le informazioni per

lavorare insieme ,ad esempio, al testing di prodotti di alto profilo per la sicurezza enterprise.

1.2.4 Hybrid Cloud

Il cloud di tipo ibrido mette insieme le tipologie di Cloud viste precedentemente al fine di

presentare maggiori benefici,pur mantenendo le caratteristiche di ognuno di esse ben distinte,

adeguandosi al meglio alle esigenze degli utilizzatori del servizio. L’infrastruttura viene mantenuta

congiuntamente dal provider interno ed esterno, e si attuano sistemi che permettono lo sharing di

dati e risorse fra il data center del cliente e quello della cloud pubblica.Una problematica relativa a

questa tipologia di cloud è la cosiddetta “mancanza di consistenza operativa”,il concetto secondo

cui le risorse cloud potrebbero essere gestite da interfacce differenti nonostante le aziende

dispongano di una piattaforma comune di gestione.Risulta quindi necessario riuscire a garantire

l’interoperabilità dei servizi nella cloud ,con un processo di integrazione dei meccanismi di

pianificazione e delivery dei servizi di supporto alle applicazioni.Nonostante la complessità dettata

dai problemi di integrazione suddetti,tipicamente il cloud ibrido viene utilizzato quando le aziende

vogliono mantenere privati certi tipi di servizi e o risorse, ma al contempo desiderano,per abbattere

i costi e per fornire maggiore dinamicità, condividere parte di essi. Un esempio può essere quello

di un’azienda che conserva dati e applicazioni su un Cloud privato, ma nel momento in cui le

risorse interne terminano vengono utilizzati i servizi offerti da un Cloud pubblico. Quindi si

utilizzano servizi e risorse computazionali interni all’azienda in situazioni normali, mentre si scala

su Cloud pubblico a seconda delle necessità.

1.3 Modelli di servizio

Un ulteriore differenziazione delle soluzioni cloud avviene sui servizi, che sono generalmente

organizzati secondo una architettura a livelli.I servizi di base sono principalmente tre,e sono così

strutturati :

IaaS , Infrastructure as a Service.Viene considerato il livello inferiore, che si occupa di

fornire una visione astratta delle risorse fisiche quali memorie di massa,infrastruttura di rete

11

e server.Essenzialmente, l’utilizzo delle risorse hardware avviene in remoto e su

richiesta,nel momento in cui una piattaforma ne ha bisogno,senza che vengano assegnate a

prescindere dal loro utilizzo effettivo.

PaaS ,Platform as a Service. Livello intermedio,è essenzialmente una piattaforma software

remota ,caratterizzata da diversi servizi,librerie e programmi,che fornisce agli sviluppatori

l’ambiente e gli strumenti necessari per la realizzazione e l’esecuzione delle applicazioni,

basandosi sull’infrastruttura del livello sottostante;

SaaS ,Software as a Service. Livello superiore che fornisce all’utilizzatore le applicazioni

ed i servizi richiesti veri e propri tramite programmi in remoto,come ad esempio un web

server.

Figura 2 :Stack Cloud semplificato

Di fatto,i modelli di servizio sopra elencati si differenziano per il livello di controllo

sull’infrastruttura del provider concessa ai clienti.

1.4 Pro e contro della soluzione PaaS nello sviluppo software La soluzione cloud PaaS è il livello di astrazione intermedio tra le tipologie di cloud SaaS e IaaS,

si appoggia su quest’ultima, ed è spesso considerato middleware [5].Mentre l’utente IaaS è ,molto

spesso, immaginato come un system administrator, l’utente di un servizio PaaS è solitamente uno

sviluppatore, o più genericamente una software house, che si concentra su una particolare

piattaforma di riferimento, a partire dalla quale costruire i propri servizi, caratterizzandone i dettagli

implementativi.Esso non dovrà preoccuparsi di configurare l’infrastruttura, di cui non conosce i

dettagli, in quanto acquista una soluzione hardware/software completa per lo sviluppo ed il

deployment delle proprie applicazioni, ignorandone così gli aspetti legati all’organizzazione dei

server, dello storage, o della rete.Si è detto che lo sviluppo di un’applicazione non è riducibile ad

una semplice azione di copia/incolla di blocchi di codice , plugin e componenti riusabili, limitando

il development alla semplice scrittura di codice e testing finale, ma presenta un vero e proprio ciclo

di vita caratterizzato da diverse fasi.Ognuna di esse si sviluppa in una serie di attività che

necessitano di software specifici per essere messe in atto.In particolare,per ambiente di sviluppo e di

runtime si intende l’insieme di software che vanno dal sistema operativo, ai compilatori, editor,

software di debugging, validation, profilig e testing, fino ad eventuali application server o

12

framework, opportunamente configurati, che supportano lo sviluppo stesso ,permettendo inoltre

l’esecuzione dell’applicazione. Da ciò si evince che la preparazione di un ambiente di sviluppo

risulti essere un’attività tutt’altro che semplice, che può condizionare gli sviluppi,far slittare i tempi

stanziati e soprattutto ha un costo.Per questo, l’idea alla base della soluzione cloud PaaS, è proprio

dare vantaggio a queste attività riducendone costi,le risorse necessarie e minimizzando i tempi di

preparazione, poichè l’intero sviluppo risulta confinato all’interno di questo “strato di cloud”, in cui

il provider mette a disposizione un’infrastruttura completa che va dal sistema operativo,

all’ambiente per eseguire e distribuire le applicazioni .La piattaforma è dunque vista come un

servizio che esporta tool e API per lo sviluppo della propria applicazione,dove il provider del

servizio PaaS si fa carico,ad esempio, di allocare spazio per un servizio o di come bilanciare e

distribuire i carichi di lavoro,mentre rimane all’utente l’unica responsabilità dello sviluppo ed il

rilascio della propria applicazione.Nella figura seguente viene evidenziato ciò di cui si fa carico il

provider del servizio PaaS e cose viene gestito dall’utente finale,confrontandolo,inoltre, con le altre

soluzioni cloud.

Figura 3: Differenze di gestione dei servizi cloud

Dall’analisi fatta risulta quindi evidente come il vantaggio offerto da questa soluzione cloud sia la

semplificazione del processo di sviluppo delle applicazioni esulando dalle problematiche di costo e

complessità legati all’ acquisto ed alla gestione dello strato hardware/software sottostante. Il

provider di una soluzione PaaS fornisce ,inoltre, i tool necessari ad agevolare il supporto al ciclo

di vita del software, dallo sviluppo al rilascio, evidenziando come tale modello risulti essere una

scelta quasi obbligata per gli sviluppatori,dati anche i vantaggi legati all’incremento della

produttività ed alla riduzione dei costi operativi:

Il Time to Market,ovvero il tempo che intercorre tra ideazione ed effettiva

commercializzazione del prodotto,risulta molto più breve rispetto ad altre

soluzioni dando la possibilità di “monetizzare” l’applicazione in tempi più

ristretti.

Riduzione dei costi operativi,in quanto non sono richiesti investimenti

iniziali se non quello legato alla sottoscrizione del contratto di servizio.

13

Aumento della produttività ,agevolata dalla centralizzazione della gestione

di tutto il processo di sviluppo,la quale permette di accedere

modificare,verificare e rilasciare codice in qualsiasi momento,da qualsiasi

luogo,mantenendo gli aspetti di sicurezza e privacy dei dati necessari.

Favorisce il cosiddetto sviluppo “collegiale” di un’applicazione,mettendo a

disposizione strumenti di sviluppo collaborativo,favorendo lo scambio di

informazioni e la condivisione di know how tra gli utenti del

servizio,accellerando così il processo di sviluppo.

Customizzazione e personalizzazione delle proprie applicazioni

praticamente illimitata,grazie alla possibilità di integrazione con servizi web.

Così come ogni soluzione cloud,il PaaS presenta anche degli svantaggi.Fornendo una

infrastruttura managed,l’utente non ha molto controllo,a differenza ad esempio della soluzione

IaaS,nella gestione e configurazione della infrastruttura stessa,caratterizzandone una riduzione

della flessibilità e vincolando l’utilizzatore alle scelte del provider.Uno dei grandi nodi da

sciogliere,dunque, è legato ai problemi di lock-in, che possono impedire alle compagnie di

creare applicazioni portabili. Ogniqualvolta una software house introduce nuovi servizi in un

provider IaaS esistente, c’è il rischio di rimanere bloccati all’interno di tale servizio, rischiando

di non poter spostare altrove le proprie applicazioni. Oltre a questo bisogna considerare che più

una compagnia archivia dati in un’unica piattaforma, più diventerà difficile poi spostarsi, a

causa dei tempi di trasferimento di questi dati,poichè più crescono le moli di dati e di calcolo

necessarie per gestirli, più questi devono affrontare un lock in.Facendo l’ipotesi che un provider

fornisca un servizio PaaS per lo sviluppo ed il rilascio di un servizio web, realizzando la propria

infrastruttura su una soluzione LAMP (Linux, Apache, MySql, Perl/Php),ciò conduce ad

utilizzare tutte le tecnologie supportate solo da quella scelta imposta, e non poter migrare ad una

altra soluzione , o utilizzare un supporto di database o di scripting diverso. È questo il vincolo

principale, anche se aggirabile grazie alla vasta scelta di soluzioni proposte dai provider.Il

problema persiste anche se si avesse la necessità di stravolgere l’applicazione o semplicemente

svilupparla pazialmente per una piattaforma diversa una volta sottoscritto il contratto, proprio

per l’impossibilità di avere il controllo sullo strato sottostante.Nonostante le problematiche

evidenziate,la soluzione PaaS,risulta essere la più congeniale agli sviluppatori.

1.5 Il confine tra IaaS e PaaS:DevOps

La continua evoluzione del Cloud Computing sta modificando, non solo il settore del Information

Tecnology , ma anche la tassonomia dei servizi cloud stessi, oltre ai componenti dello stack

tecnologico che non è più suddivisibile semplicemente nei servizi di IaaS,PaaS e SaaS ma presenta

ulteriori sfumature.Da un lato vediamo molti provider IaaS spostarsi più in alto nello stack, e

dall’altro vediamo la nascita di nuove categorie quali DevOps ,introdotta per soddisfare i nuovi

standard di efficienza e integrazione nello sviluppo di software e che unisce le caratteristiche delle

soluzioni IaaS e Paas [6].

14

Figura 4: Introduzione del DevOps nel Cloud Stack

Il termine DevOps deriva dalla fusione di due termini,development,ovvero sviluppo, e

operations,inteso come “messa in produzione” ,ed è un approccio che riguarda sia la figura

professionale dello sviluppatore che quella del sistemista,e che tenta di creare legami tra essi

mettendo a disposizione metodologie di sviluppo e di collaborazione.Più precisamente, DevOps

cerca di integrare anche tasks di sviluppo ,di assicurazione di qualità,di amministrazione della rete ,

dei database, dei clienti, delle funzioni di marketing e vendite ,dando risposta all'interdipendenza tra

sviluppo software e IT operations per agevolare lo sviluppo rapido ed efficiente di prodotti e

servizi.Grazie alle ultime innovazioni tecnologiche dell’IT ,come il cloud computing e la

virtualizzazione, gli strumenti di social networking in campo enterprise, lo sviluppo di dispositivi

mobile ed altri,risulta possibile far valutare a chi si occupa del deployment ,in tempo reale o quando

vuole, lo svolgimento del lavoro reso da chi si occupa di development,cambiando l’approccio

classico dello sviluppo software e venendo in contro alle esigenze di agilità richieste. I processi

chiave caratterizzanti le metodologie DevOps sono dunque:

Cloud e Virtualizzazione: la necessità di avere a disposizione servizi e strumenti che

offrono una modalità veloce di verifica e gestione della complessità di un’applicazione.

Continuous Delivery :consegna continua intesa come continuo miglioramento,con un

testing ad ogni modifica,verificando il livello di qualità e compatibilità del prodotto

sviluppato ed effettuando attività quali: controllo codice sorgente, versioning configuration,

integrazione continua, testing di unità , testing integrato e deployment automatizzato.

Questa cura dettagliata della fase di testing e dell’organizzazione è dettata dall’idea che sia meglio

affrontare, nella realizzazione di un prodotto, tanti piccoli cambiamenti causati dal dialogo tra

sviluppatori e sistemisti, piuttosto che invalidare un’intera applicazione solo alla fine di un’intero

ciclo di sviluppo. Il caso peggiore si avrebbe nel rilascio al cliente di un prodotto di cui non si

conoscono bug ed imperfezioni,il che porta successivamente a sostenere costi di supporto al cliente

e di assistenza che in passato hanno costituito la causa maggiore del collasso di aziende e business

IT.

15

1.6 Virtualizzazione

Il Cloud Computing ha, nella virtualizzazione, la sua tecnologia chiave.Con il termine

virtualizzazione si intende la creazione di una versione virtuale di una risorsa erogata

fisicamente,come memoria,server,sistemi operativi e reti di comunicazione. In questo contesto, il

processo di virtualizzazione di interesse è la virtualizzazione di piattaforme hardware per la

creazione di risorse hardware simulate utilizzabili come macchine vere e proprie dagli utenti, i quali

ne ignorano gli aspetti di gestione.Di norma vi è distinzione tra macchina host, la macchina sulla

quale si esegue la virtualizzazione, e macchina guest ,la macchina virtuale vera e propria. I

componenti principali su cui si basano le tecnologie di virtualizzazione sono:

• Virtual Machine: crea un ambiente virtuale che ha lo scopo di emulare un’intera macchina fisica,

comportandosi ,quindi, come un computer fisico al quale è possibile associare anche hardware

virtuale. È possibile memorizzarla come immagine dell’hard disk del computer, con alcune meta-

informazioni, come le risorse disponibili e le loro caratteristiche.

• Hypervisor: o Virtual Machine Manager, atto alla gestione di sistemi operativi ospiti su server

fisico e alla presentazione, a tali OS, di una vista virtualizzata delle risorse hardware fisiche.

Le modalità di virtualizzazione sono molteplici, e tra esse ricordo la virtualizzazione completa,caso

in cui l’Hypervisor provvede a simulare un sistema hardware completo , intercettando e

interpretando tutte le chiamate fatte dalla Virtual Machine in modo da mapparle in opportune

interazioni con l’hardware sottostante,o la Paravirtualizzazione,in cui ci si appoggia direttamente

all’hardware fisico, senza ricorrere alla simulazione dello stesso. L’Hypervisor ,in questo caso, avrà

il compito di controllare e regolamentare l’accesso all’hardware sottostante da parte delle Virtual

Machine. In questo ambito le istruzioni vengono eseguite direttamente sul processore senza alcun

tipo di intermediazione.

16

Capitolo 2:Introduzione a Bluemix:architettura e sicurezza

2.1 Panoramica di Bluemix Bluemix permette agli sviluppatori di utilizzare strumenti di IBM, di terze parti o open source

fornendo un ambiente Cloud aperto, flessibile, integrabile e scalabile[7]. La piattaforma fornisce

una serie di servizi per lo sviluppo di applicazioni per mobile computing, web app, integrazione,

DevOps e gestione dati mettendo inoltre a disposizione degli sviluppatori anche la suite di

applicazioni, SaaS, di IBM (ad esempio Watson, commerce, sicurezza) sotto forma di servizi

componibili basati su API. Con questo nuovo ambiente di sviluppo viene reso possibile progettare e

realizzare applicazioni aziendali in modo più rapido ed efficiente,permettendo agli sviluppatori di

evitare il rischio di vendor lock-in, sfruttando nello stesso momento le risorse e le competenze di

sviluppo esistenti, fondamentali per la realizzazione di Cloud ibridi. I servizi DevOps di

Bluemix,adottati per rendere lo sviluppo software più agile ed efficiente, aiutano i software

developer ad accelerare il tempo di immissione del prodotto sul mercato e a migliorarne la qualità,

comprendendo servizi per memorizzare e gestire il codice ,ad esempio utilizzando il diffuso

repository Git, un Web IDE,ovvero un ambiente di sviluppo integrato nel web, ed integrazioni con

tools affermati come Eclipse ,in modo da agevolare l’utilizzo dell’ambiente che più si preferisce.I

servizi DevOps forniscono agilità di pianificazione e tracking,attraverso i servizi di Track & Plan,

consentendo la condivisione del lavoro e la collaborazione con i membri del team, oltre

all’automazione del rilascio delle applicazioni,grazie al Delivery Pipeline Service, per rendere più

snella la distribuzione di nuove funzionalità ed il monitoraggio. L’approccio DevOps aiuta gli

sviluppatori a velocizzare il passaggio dall’ideazione alla realizzazione di un’applicazione, in linea

con le esigenze degli utenti, grazie all’integrazione su tutto il ciclo di vita della distribuzione del

software.

Nel corso del suo sviluppo IBM ha aggiunto nuove funzionalità a Bluemix ,come:

connessioni rapide, immediate e veloci, attraverso il Cloud, tra IoT,Internet of Things, e

dispositivi machine-to-machine per lo storage, l’interrogazione e la visualizzazione dei dati;

servizi di integrazione Cloud per consentire una connessione sicura tra applicazioni

pubbliche e dati privati;

dati ed analytics-as-a-service per consentire una progettazione rapida e la scalabilità delle

applicazioni che trasformano i Big Data in intelligenza competitiva;

servizi DevOps che supportano l’intero ciclo di vita dell’applicazione.

Bluemix ,dunque,astrae e nasconde la complessità legata al fungere da host, o al gestire applicazioni

basate sul Cloud, consentendo allo sviluppatore di concentrarsi sullo sviluppo dell’applicazione

senza preoccuparsi della gestione dell’infrastruttura necessaria ad ospitarla.Per le applicazioni web

è possibile caricare la propria applicazione su Bluemix e indicare quante istanze si desidera

eseguire, mentre per applicazioni mobili si possono utilizzare i servizi pre-costruiti forniti da

Bluemix. Una volta effettuato il loading dell’applicazione, vi è la possibilità di eseguirne il

ridimensionamento, a crescere o a decrescere, quando l’utilizzo o il carico delle applicazioni risulta

variabile. Si possono sviluppare applicazioni nei linguaggi di programmazione più diffusi: Ruby,

PHP e Java per applicazioni web, iOS, Android e HTML con Javascript per applicazioni mobile.

17

Bluemix offre anche servizi middleware e opera per conto dell’applicazione quando esegue il

provisioning di nuove istanze di servizio eseguendo quindi il bind di tali servizi all’applicazione.

L’applicazione,dunque, si occupa solamente di eseguire il suo compito effettivo mentre è

l’infrastruttura ad occuparsi dei servizi.Per quanto concerne questi ultimi,le nuove offerte di

servizio Bluemix sono state pensate per aiutare le aziende a trasformarsi rapidamente utilizzando i

Big Data, le tecnologie mobile e social disponibili in Cloud,mentre agli sviluppatori viene permesso

di ridurre i tempi di attivazione grazie alla capacità di combinare facilmente una serie di servizi e

API per la composizione, il test e la scalabilità di applicazioni personalizzate. Alcuni dei nuovi

servizi comprendono:

I servizi DevOps,che permettono a sviluppatori e ad operatori IT di avere un ambiente di

sviluppo rapido, aperto, integrato e scalabile. Il servizio DevOps Continuous Integration

fornisce funzionalità end-to-end per velocizzare i cambiamenti attraverso il processo di

sviluppo. DevOps Mobile Quality Assurance (MQA) aiuta ad analizzare il sentiment degli

utenti per identificare i problemi prima che si diffondano e il servizio Monitoring and

Analytics identifica i problemi di applicazione durante lo sviluppo attraverso tecniche di

analitica. DevOps comprende inoltre un nuovo servizio RapidApp che, senza richiedere

notifica, fornisce strumenti visuali per ampliare le funzionalità delle applicazioni web.

servizi di Cloud Integration,utilizzati per collegare e integrare le applicazioni e le

informazioni nel Cloud in maniera safety.I software developer possono utilizzare connettori

standard per accelerare l’integrazione o sviluppare API personalizzate in base alle proprie

esigenze. Le capacità di gestione integrata delle API fornisce un facile metodo di

pubblicazione di servizi self-service, condivisibili con una API economy più ampia. Questo

consente agli sviluppatori l’integrazione di soluzioni PaaS, applicazioni di terze parti e

sistemi on-premise, dando luogo ad un ambiente ibrido ed integrato.

I servizi di Data e Analytics consentono di sviluppare applicazioni mobili scalabili,

incentrate su dati e applicazioni web.Grazie a questi servizi, comprendendo anche quelli

geospaziali, temporali, predittivi e di reportistica, gli sviluppatori possono facilmente dar

vita ad applicazioni sofisticate che forniscano informazioni in base alle quali agire,

prevedere eventi e migliorare il processo decisionale.Sono inoltre disponibili funzioni di

data masking che aiutano gli sviluppatori a progettare applicazioni nel rispetto di privacy e

sicurezza.

I servizi IoT permettono di registrare e collegare microprocessori e sensori integrati

machine-to-machine al Cloud ,aggregando i dati e gli eventi in maniera semplice,

reagendo ad essi in tempo reale. Le software house possono creare applicazioni in grado di

gestire, analizzare, visualizzare e interagire in modo efficiente con le enormi quantità di dati

generate da veicoli, dispositivi indossabili, telefoni cellulari, fotocamere, computer, sensori

ed altri smart devices.

Bluemix ha dunque molto da offrire,e risulta essere una risposta davvero concreta alle esigenze di

rapidità ed efficienza richieste dal business del software development.

2.2 Architettura di BlueMix Dal punto di vista architetturale Bluemix da la possibilità di accedere alla piattaforma Bluemix

pubblica, configurare una piattaforma Bluemix dedicata o utilizzarle entrambe.

2.2.1 BlueMix pubblico Bluemix pubblico utilizza SoftLayer per la distribuzione di virtual containers che ospitano ciascuna

applicazione distribuita,e fornisce un ambiente ospitante risorse utente eseguite su server delle

applicazioni come Liberty. L’interazione tra sviluppatore ed ambiente avviene utilizzando

un’interfaccia utente basata su browser oppure con l’interfaccia a riga di comando di Cloud

18

Foundry (cf CLI).Anche per quanto concerne i dettagli strettamente implementativi,Bluemix

fornisce varie possibilità di sviluppo,dall’utilizzo di Eclipse al repository GIT,fornendo descrizioni

dettagliate al fine di agevolare una corretta installazione e utilizzo degli stessi. I client, identificabili

come applicazioni mobile, applicazioni che vengono eseguite esternamente, applicazioni basate su

Bluemix o sviluppatori che stanno utilizzando dei browser, interagiscono con le applicazioni

ospitate da Bluemix, utilizzando API REST o HTTP per instradare le richieste tramite quest’ultimo

ad una delle istanze dell’applicazione o ai servizi compositi

Figura 5: Architettura di Bluemix

La soluzione PaaS di IBM permette di distribuire,tramite un unico WEB ID IBM, le proprie

applicazioni su una singola regione o tra più regioni differenti,il tutto tramite la stessa infrastruttura

Bluemix ,in modo da far fronte ad aspetti legati a sicurezza e latenza ,o per selezionare,ad esempio,

la regione più vicina ai clienti del servizio al fine di ottenere una bassa latenza di applicazione. Una

regione Bluemix è intesa, letteralmente, come il territorio geografico dove distribuire la propria

applicazione,ed è caratterizzato da un prefisso univoco.Bluemix fornisce le seguenti regioni e i

seguenti prefissi di regione:

Nome della regione Prefisso della

regione Endpoint API CF Console IU

Regione Stati Uniti Sud us-south api.ng.bluemix.net console.ng.bluemix.net

Regione Europa Regno

Unito eu-gb

api.eu-

gb.bluemix.net

console.eu-

gb.bluemix.net

La piattaforma IBM presenta l’isolamento “esecutivo” delle regioni stesse,poichè l’inattività di una

di esse non impedisce il running dell’applicazione nelle altre regioni in cui quest’ultima è

distribuita,mentre la disponibilità di risorse è la stessa per ogni regione. Il passaggio da una regione

all’altra, per operare con spazi differenti, avviene sia tramite interfaccia utente,sia tramite riga di

comando cf,utilizzando il comando cf api e specificando l’endpoint API della regione per la

19

connessione a quest’ultima. Ad esempio, immettendo il seguente comando è possibile stabilire una

connessione alla regione Bluemix Europa Regno Unito:

cf api https://api.eu-gb.bluemix.net

Anaolgamente se si è scelto di utilizzare gli strumenti Eclipse, risulta necessaria la connessione

alla regione Bluemix con la quale si intende lavorare creando un server Bluemix e specificando

l'endpoint API della regione stessa.

Figura 6:Distribuzione di applicazioni a più regioni

2.2.2 Bluemix dedicato Bluemix dedicato permette di usufruire di grande potenza combinata con la semplicità di Bluemix

grazie al proprio ambiete SoftLayer dedicato,che è connesso in modo protetto sia a Bluemix

pubblico sia alla rete dello sviluppatore stesso,inserendosi in quest’ultima tramite una connessione

20

rete diretta o una VPN. Bluemix dedicato include un catalogo privato di servizi utilizzabili in

esclusiva e tutti i runtime e gli elementi aggiuntivi che vengono diffusi e messi a disposizione da

Bluemix pubblico. Gli ambienti di Bluemix dedicato presentano gli stessi standard di sicurezza di

Bluemix pubblico in termini di sicurezza fisica, operativa e di infrastruttura, ma tuttavia l'accesso

degli sviluppatori a Bluemix dedicato è controllato da politiche LDAP, configurabili dal team di

Bluemix nel momento in cui l’ambiente dedicato viene configurato. All'interno di quest’ultimo è

possibile gestire ruoli e autorizzazioni utenti per la gestione delle politiche d’accesso.L’hardware

a singolo tenant può essere configurato in qualsiasi data center SoftLayer in tutto il mondo,mentre la

manutenzione per le istanze dedicate viene gestita da IBM durante una finestra di manutenzione

stabilita dallo sviluppatore stesso .Per tutte le distribuzioni dedicate di Bluemix ,risulta possibile

evidenziare i seguenti vantaggi : VPN, VLAN privata, firewall, possibilità di avvalersi dei database

e delle applicazioni installati in loco già esistenti, sicurezza in loco 24 ore al giorno, 7 giorni su 7,

hardware dedicato e supporto standard.

Figura 7:Bluemix Dedicato

2.3 Sicurezza in BlueMix

Così come per ogni piattaforma di sviluppo,ancor di più se basata su ambiente Cloud,la sicurezza di

dati e applicazioni risulta essere una tematica critica.Bluemix fornisce diversi livelli di sicurezza tra

rete ed infrastruttura,fornendo inoltre una suite di servizi di sicurezza per la protezione delle

applicazioni.Bluemix si avvale dell’architettura di sicurezza del servizio cloud IBM SoftLayer IaaS

sul quale si basa,aggiungendo funzionalità di sicurezza a livello PaaS in categorie quali

dati,piattaforma ed applicazione.Per la gestione di tali problemi di sicurezza Bluemix utilizza il

processo IBM PSIRT, Product Security Incident Responce Team, così definito:

21

“ The IBM Product Security Incident Response Team (PSIRT) is a global team that manages the

receipt, investigation and internal coordination of security vulnerability information related to IBM

offerings”.

2.3.1 Platform Security

Per quanto concerne la sicurezza di piattaforma ,Bluemix risulta essere conforme a tutti gli

standard di sicurezza IT IBM, come Rete, crittografia di dati , controllo dell'accesso ed altri,

offrendo quattro livelli di protezione:

Sicurezza funzionale:è offerta per mezzo di diversi servizi quali autenticazione degli

utenti tramite l’identità web IBM o autenticazione tramite LDAP nel caso di Bluemix

dedicato;autorizzazione,tramite la quale lo sviluppatore ha accesso mediante

meccanismi Cloud Foundry e OAuth solo alle istanze di servizio da essi create

limitando l’accesso agli endpoint interni per utenti esterni;log di controllo ,creati ad

ogni tentativo di autenticazione riuscito o fallito; protezione dati tramite IBM

WebSphere DataPower SOA Appliances ,che ,mediante l’utilizzo di metodi HTTP e

macro, permettono di ottenere la sicurezza suddetta.

Sicurezza dell’infrastruttura: Bluemix agevola la separazione degli ambienti di

sviluppo e produzione per migliorare stabilità e sicurezza dell’applicazione,fornendo

inoltre protezione dalle intrusioni le cui politiche sono abilitate su firewall atti a limitare

l’accesso alla rete Bluemix.

Sicurezza fisica: Bluemix utilizza la topologia rete all'interno di una rete caratteristica

di SoftLayer,la quale garantisce che i sistemi siano pienamente accessibili unicamente al

personale autorizzato.Nella rete all'interno di una rete SoftLayer, il livello di rete

pubblico gestisce il traffico pubblico a siti Web su host ,o risorse in linea, mentre Il

livello di rete privato o di gestione consente una effettiva gestione fuori banda mediante

un terzo vettore autonomo e distinto su gateway SSL, PPTP o IPSec VPN. In ultima

analisi. il livello di rete da data center a data center fornisce una connettività gratuita e

protetta tra server ospitati in strutture SoftLayer separate.

Sicurezza operativa: è offerta tramite diversi strumenti che effettuano controlli

specifici, come ad esempio Tenable Network Security, Nessus, per la scansione delle

vulnerabilità, IBM Endpoint Manager per la gestione delle correzioni automatizzate e

IBM QRadar SIEM (security information and event management) per monitorare i

tentativi di accesso riusciti e falliti.

2.3.2 Data Security La sicurezza dei dati è un’altra tematica critica delle politiche di protezione offerte da Bluemix

che,in questo caso,richiede uno sforzo congiunto con lo sviluppatore.I dati caratteristici

dell’applicazione sviluppata vengono categorizzati in tre stati:

Data-in-transit: dati che vengono trasferiti tra nodi su rete

Data-at-rest: i dati memorizzati

Data-in-use: dati non attualmente memorizzati ma a cui verrà applicata una azione

in un endpoint. La piattaforma mette in sicurezza i data-in-transit proteggendo l'accesso dell'utente finale

all'applicazione tramite SSL, questo finché i dati non raggiungono l'IBM DataPower Gateway

,punto limite della rete interna Bluemix,che funge da proxy inverso e che fornisce la terminazione

22

SSL stessa.La responsabilità dei data-in-use e dei data-at-rest è invece demandata allo sviluppatore,

che si deve far carico della loro messa in sicurezza attraverso,comunque,numerosi servizi correlati

ai dati forniti da Bluemix.

2.3.3 App Security

Per quanto riguarda la sicurezza delle applicazioni,essa risulta essere demandata allo sviluppatore

che ,in quanto tale, deve farsi carico dell’ abilitazione e delle configurazioni della stessa ,compresa

la protezione dei dati applicativi.Per farlo,è possibile usufruire di numerose funzionalità di sicurezza

fornite dai diversi servizi Bluemix,tutti conformi allo sviluppo di IBM Secure Engineering.Di

seguito, alcuni di tali servizi:

Servizio SSO: IBM Single Sign On per Bluemix è un servizio di autenticazione che fornisce

una funzionalità single sign-on facilmente incorporabile per applicazioni Node.js o Liberty

for Java™. Per consentire tale incorporazione l'amministratore crea istanze del servizio e

aggiunge origini di identità in cui vengono memorizzate le credenziali utente.Cloud

Directory,il registro utente ospitato in IBM Cloud, è un esempio di tali origini di identità.

AppScan Mobile Analyzer, AppScan Dynamic Analyzer e MobileAnalyzer for iOS

:Sono i tre servizi che fornisco analisi di sicurezza rispettivamente per applicazioni mobile

Android,web e mobile iOS ,con quest’ultima in fase BETA.Per usufruire del primo servizio

si ha la necessità di caricare l’applicazione Android compilata come un file APK,ed una

volta eseguita la scansione di sicurezza si usufruisce di un report.Il secondo invece fornisce

un'analisi della sicurezza delle applicazioni web con uno strumento di analisi dinamica che

opera sull'applicazione web distribuita,e non sul codice sorgente dell'applicazione stessa,

dando la possibilità di scansionare qualsiasi applicazione web Bluemix indipendentemente

dal linguaggio utilizzato o dalla sua tecnologia.Per eseguire tale scansione, si ha la necessità

di configurare l'URL dell'applicazione web e le eventuali credenziali di accesso,ottenendo

alla fine dell’analisi un report.

Static Analyzer (Beta): Il servizio porta la potenza del test di sicurezza di applicazioni

statiche nel Cloud. Ripulisce il codice da gestione di dati e chiamate ad API non sicure e

ricerca le vulnerabilità di sicurezza già nello sviluppo, in modo da poterle correggere prima

della distribuzione.

Secure Gateway : Il servizio consente di connettere in modo sicuro le applicazioni Bluemix

a posizioni remote, siano esse installate in loco o nel cloud. Fornisce una connettività sicura

e stabilisce un tunnel tra l’ organizzazione Bluemix dello sviluppatore e la posizione remota

che si desidera connettere. È possibile configurare e creare un gateway sicuro utilizzando

l'interfaccia utente Bluemix o un pacchetto API.

Cloud Integration: Esso consente di integrare i dati cloud e installarli in loco. Vi è la

possibilità di aggiungere un servizio per interagire con i database di back-end, quali DB2,

Oracle e SAP ,e spostare i dati o creare API REST per l'accesso e l’utilizzo da parte delle

applicazioni Bluemix. Il servizio abilita la comunicazione protetta con i connettori sicuri

installati in loco ed espone i system of record di backend come API REST che verranno

utilizzate dalle applicazioni.

2.4 Architettura di distribuzione della sicurezza in Bluemix

In Bluemix ,software users e software developers,considerati le due maggiori categorie di utenza ,

presentano flussi di informazioni differenti al fine di garatire sicurezza d’accesso.

23

Figura 8:Architettura di distribuzione della sicurezza

Dalla figura precedente è possibile intuire il flusso di informazioni caratteristico di queste due

categorie di utenze.Per quanto riguarda i software users, il flusso di informazioni è legato

semplicemente all’accesso alla risorsa rappresentata dall’applicazione,che avviene inizialmente

tramite firewall con il relativo rilevamento delle intrusioni,successivamente si giunge al IBM

DataPower Gateway,con proxy inverso e terminazione SSL,ed in fine si giunge,tramite router di

rete,al runtime dell’applicazione nel DEA ,Droplet Execution Agent.Per quanto riguarda gli app

developers,invece,in Bluemix sono presenti due flussi di informazioni,uno legato allo sviluppo e

alla distribuzione di app e l’altro d’accesso all’app stessa.Nel primo caso,il flusso di informazioni

relativo agli sviluppatori segue lo stesso percorso precedentemente descritto con la differenza che

tramite router di rete si giunge al meccanismo di autorizzazione fornito dal controller Cloud

Foundry,per garantire l’accesso alle sole istanze del servizio creato.Per il flusso legato all’accesso

dello sviluppatore, invece, c’è distinzione nel caso di utilizzo della piattaforma Bluemix pubblica o

dedicata.Nel primo caso il flusso avviene tramite il servizio IBM Single Sign On e tramite verifica

dell’identità Web IBM,nel caso di utilizzo di Blumix dedicato ,invece, l’accesso avviene tramite il

protocollo LDAP aziendale.

24

Capitolo 3 :Bluemix:How it works

3.1 Infrastruttura offerta da Bluemix

La varietà di possibilità offerte da Bluemix viene messa in evidenza anche dal punto di vista della

scelta dell’infrastruttura.La piattaforma ,infatti,mette a disposizione tre modalità di esecuzione del

codice:

Cloud Foundry

IBM Containers

Macchine Virtuali

Ognuna di esse presenta caratteristiche pecuriali.

3.1.1 Cloud Foundry In tale infrastruttura,le applicazioni eseguite operano con applicazioni Cloud Foundry esistenti,con

la possibilità di associarsi ai numerosi servizi messi a disposizione da Bluemix,al quale è lasciato la

gestione e la manutenzione dell’infrastruttura stessa.Al solito,è lasciato allo sviluppatore il solo

compito di implementare e gestire il codice applicativo.A prescindere dalle possibilità offerte ,

cos’è e come si struttura realmente Cloud Foundry? [8]

Cloud Foundry è un open Platform as a Service,implementata e rilasciata in aprile 2011 da VMware

e successivamente amministrata da Pivotal Software, che offre una scelta di Cloud per la

distribuzione, servizi applicativi per l’esecuzione di applicazioni e strutture per lo sviluppo. È un

progetto open source, ed in quanto tale presenta una community che la supporta,quest’ultima

caratterizzata da clienti, partner ed ex aziende concorrenti che collaborano , accelerando così il

ritmo dell’innovazione. Cloud Foundry fornisce supporto nell’intero ciclo di vita del software

adattandosi molto bene alla strategia Continuous Delivery. Gli utenti hanno accesso ad uno o più

spazi, con differenti permessi di accesso,ed ognuno di essi, generalmente, corrisponde a una fase del

ciclo di vita. Le applicazioni distribuite su Cloud Foundry accedono alle risorse esterne tramite

servizi,che devono essere distribuiti prima sulla piattaforma e poi saranno disponibili per qualsiasi

applicazione che li utilizza.

Cloud Foundry non è vincolato ad alcun ambiente Cloud particolare, supporta i più diffusi

framework di produzione come Node.js e fornisce numerosi servizi di supporto per applicazioni

critiche. Cloud Foundry è caratterizzato da diversi componenti che includono un motore self-service

di esecuzione delle applicazioni, un motore di automazione per lo sviluppo e la gestione del ciclo di

vita di un’applicazione, una CLI, Command Line Interface,e strumenti di sviluppo che facilitano la

distribuzione. La piattaforma presenta un’architettura aperta che include un meccanismo di

buildpack,che consiste in una serie di script di rilevamento e configurazione che forniscono

framework e supporto runtime all’applicazione, un’interfaccia di servizi applicativi e un’interfaccia

Cloud provider. Il Router dirige il traffico in ingresso ai componenti appropriati, che generalmente

sono il Cloud Controller o un’applicazione in esecuzione su un nodo DEA ,Dropler Execution

Agent. Il server OAuth2 (UAA-User Account and Authentication) e il Login Server lavorano

25

congiuntamente alla gestione delle identità. La gestione del ciclo di vita delle applicazioni è invece

affidata al Cloud Controller che,una volta caricata l’applicazione, ne memorizza i dati grezzi , crea

un record per monitorarne i metadata e dirige un nodo DEA per eseguirla. Il Cloud Controller,

inoltre, effettua lo storage di record per le organizzazioni, gli spazi, i servizi, le istanze di servizio, i

ruoli degli utenti e altro. Un’altra componente fondamentale dell’infrastruttura CF è HM9000 che

monitora le applicazioni per la determinazione ed aggiornamento dello stato, la versione e il numero

di istanze. Esso riconcilia lo stato attuale di un’applicazione con quello atteso ,quest’ultimo ottenuto

scaricando il database del Cloud Controller,e se le istanze in esecuzione sono minori del numero

atteso, chiede al Cloud Controller di avviare il numero appropriato di istanze. Dirige,inoltre, il

Cloud Controller affinchè corregga tutte le discrepanze nello stato delle applicazioni. HM9000

risulta fondamentale per garantire che le applicazioni in esecuzione su Cloud Foundry rimangano

disponibili, riavviando le applicazioni ogni volta che il DEA cessa di funzionare improvvisamente o

quando un processo di un’applicazione termina con un codice di uscita diverso da zero. Il Droplet

Execution Agent gestisce le istanze di applicazioni, segue le istanze di partenza e trasmette i

messaggi di stato. Le istanze delle applicazioni vivono nel contenitore Warden, il che assicura

l’esecuzione delle istanze in isolamento e l’ottenimento della giusta quota di risorse condivise . Il

codice dell’applicazione, i buildpacks e i droplets sono contenuti all’interno del Blob Store. I

Service Brokers di un servizio sono responsabili della fornitura delle istanze del servizio che lo

sviluppatore fornisce e collega alla sua applicazione. Il Message Bus: Cloud Foundry utilizza NATS

per la comunicazione interna tra componenti. Logging e Statistica: il metrics collector raccoglie

informazioni su quanto un’applicazione possiede una risorsa. Gli operatori possono usare questa

informazione per monitorare un’istanza di Cloud Foundry. L’applicazione aggregator log

(Loggregator) invia i log delle applicazioni agli sviluppatori.

3.1.2 IBM Containers L'infrastruttura IBM Containers, permette di eseguire una applicazione web ovunque sia supportata

la distribuzione di contenitori,intesi come oggetti che contengono l’occorrente per l'esecuzione di

un'applicazione[7].Un contenitore viene generato da un'immagine, che contiene un'applicazione e

che funge da template di sola lettura. Ciascuna immagine include solo l'applicazione e le relative

dipendenze, in esecuzione come processo isolato sul sistema operativo host. Pertanto, ha i vantaggi

dell'isolamento e dell'assegnazione delle risorse, ma offre una maggiore portabilità ed

efficienza.Questa infrastruttura include un registro privato per immagini fornite dallo sviluppatore e

ritenute attendibili, in modo da poterle caricare,memorizzare e richiamare.C’è la possibilità,inoltre,

di renderle disponibili in Bluemix,di usare tutte le immagini disponibili nel Docker Hub pubblico e

servirsi dell'interfaccia riga di comando e della API docker per gestire i contenitori nella

piattaforma IBM. IBM da la possibilità di utilizzare e ampliare anche alcune immagini pubbliche

all'interno del Containers Registro. IBM Containers viene dunque utilizzato per eseguire contenitori

Docker in un ambiente cloud ospitato,aggiungendo un motore che distribuisce l’applicazione

all'ambiente virtuale che viene utilizzato, per eseguire i contenitori stessi. Docker fornisce anche un

ambiente utilizzabile per eseguire il codice, offrendo strumenti con i quali poter trasferire il codice

dall’ ambiente di sviluppo all’ ambiente di test e, quindi, all’ ambiente di produzione.

3.1.3 Virtual Machines (BETA)

Questa infrastruttura ,ancora in fase BETA,offre la possibilità di creare e gestire gruppi di macchine

virtuali sul cloud pubblico IBM,ma anche gruppi di VM sui cloud IBM privati che si è scelto di

rendere disponibili per gli utenti Bluemix [7]..L'assistenza al monitoraggio e alla registrazione è

integrata in Bluemix,mentra la gestione e la distribuzione di macchine virtuali avviene utilizzando

l'interfaccia utente Bluemix o le API OpenStack del cloud. Le macchine virtuali su Bluemix

supportano la fornitura di gruppi di macchine virtuali con ridimensionamento automatico grazie al

26

quale il numero di istanze può aumentare o diminuire in base al carico della CPU o all'esecuzione

non riuscita di un'istanza. Inoltre, viene supportato il bilanciamento del carico, che consente

l'assegnazione di indirizzi IP virtuali (IP variabili) secondo necessità.

3.2 Applicazioni Bluemix:staging e distribuzione

In Bluemix, il ciclo di vita dell'applicazione è identico a Cloud Foundry, indipendentemente da

come la risorsa viene distribuita alla piattaforma IBM Bluemix [9].

Figura 9: App staging

Dal diagramma precedente risultano evidenti i passi operativi relativi allo staging di una

applicazione Cloud Foundry,con il suo relativo ciclo di vita:

1. Lo sviluppatore inserisce nella command line l’entry della directory contenente

l’applicazione,utilizzando successivamente l’interfaccia da linea di comando cf per il push

dell’app stessa

2. L’interfaccia da linea di commando cf dirige il Cloud Controller per la creazione dei record

dell’applicazione

3. Il Cloud Controller memorizza i metadata dell’applicazione come nome e numero di istanze

4. L’interfaccia da linea di commando effettua l’ upload dei files dell’applicazione.

5. Il Cloud Controller memorizza i dati grezzi dell’applicazione nel BlobStore.

6. L’interfaccia da linea di commando cf fornisce l’ app start command.

7. Poichè l’applicazione non è stata ancora messa in esecuzione, il Cloud Controller sceglie un

istanza DEA dal DEA pool per lo stage dell’applicazione . Lo staging DEA utilizza le

istruzioni presenti nel buildpack per la messa in esecuzione dell’applicazione.

8. Lo staging DEA mostra l’ output del processo di messa in esecuzione in modo da

permettere allo sviluppatore di far fronte ad eventuali problematiche.

27

9. Lo staging DEA impacchetta l’applicazione risultante in un “droplet” e lo memorizza nel

BlobStore.I risultati sono memorizzati ed utilizzabili alla successiva esecuzione

dell’applicazione.

10. Lo staging DEA avverte il Cloud Controller che la messa in esecuzione è avvenuta con

successo.

11. Il Cloud Controller sceglie uno o più DEAs dal pool DEA per eseguire l’applicazione.

12. L’esecuzione dei DEAs riporta lo stato dell’applicazione al Cloud Controller.

Quando un'applicazione viene distribuita a Bluemix, si ha la necessità di configurare la piattaforma

con una quantità sufficiente di informazioni per supportarla ,in particolare:

Per un'applicazione mobile, Bluemix contiene una risorsa utente che rappresenta il back-end

dell'applicazione mobile, come i servizi utilizzati dalla applicazione mobile per comunicare

con un server.

Per un'applicazione web,risulta necessario che le informazioni sul runtime e sul framework

corretti siano fornite a Bluemix per poter configurare l'ambiente di esecuzione in maniera

corretta.

Bluemix garantisce l’isolamento di ogni ambiente di esecuzione,compresi sia quello mobile sia

quello web, anche se tali applicazioni si trovassero sulla stessa macchina fisica.

Figura 10:Distribuzione di un’applicazione

Durante la fase di preparazione dell’applicazione,l'ambiente Bluemix, determina una Virtual

Machine,in particolare un Droplet Execution Agent, a cui vengono inviate l'applicazione o le

risorse utente da essa rappresentate tramite l'interfaccia riga di comando cf o tramite file

manifest.yml. Il DEA seleziona un pacchetto di build appropriato per preparare l'applicazione ed il

risultato del processo di preparazione è un droplet. Per un'applicazione mobile, su Bluemix viene

creata una proiezione di back-end mobile e l’intero codice per l'applicazione in esecuzione nel

cloud viene ,in fine,eseguito nell'ambiente Bluemix. Per un'applicazione web, il codice in

esecuzione nel cloud è l'applicazione stessa che lo sviluppatore distribuisce a Bluemix. La

determinazione della VM è basata su diversi fattori, tra cui il carico già presente sulla macchina ed i

28

runtime o i framework supportati da tale VM. Una volta selezionata una VM, un gestore

dell'applicazione, su ogni VM, installa il framework ed il runtime corretti per l'applicazione

distribuendola in tale framework. Completata la fase di distribuzione e preparazione,avviene lo

staging delle risorse utente dell'applicazione .La seguente figura mostra la struttura di un Droplet

Execution Agent, su cui sono distribuite più applicazioni:

Figura 11:Progettazione di una VM

In ogni VM, un gestore dell'applicazione comunica con il resto dell'infrastruttura Bluemix e gestisce

le applicazioni distribuite a questa VM. Ogni VM è caratterizzato da contenitori,gestiti dal

componente Warden e creato al termine della fase di preparazione dal DEA, atti a separare e

proteggere le applicazioni. In ogni contenitore, Bluemix installa il framework e il runtime

appropriati richiesti per ogni applicazione.Quando l'applicazione viene distribuita, se ha

un'interfaccia web,come una web app Java, o altri servizi basati su REST ,come i servizi mobili

presentati pubblicamente all'applicazione mobile, gli utenti dell'applicazione possono comunicare

con essa utilizzando normali richieste HTTP.

Figura 12:Richiamo di un’ applicazione in Bluemix

Il comando cf files viene utilizzato per visualizzare i file archiviati nel file system del contenitore

Warden, quali ad esempio i log. Se l'avvio dell'applicazione non riesce, il DEA arresta

l'applicazione e tutti i contenuti del contenitore Warden vengono rimossi. Pertanto, se

un'applicazione si arresta o se il processo di preparazione di un'applicazione non riesce, i file di log

non potranno essere utilizzati.In questo caso,per verificare gli errori di preparazione,risulta possibile

utilizzare il comando cf logs. Il comando cf logs utilizza l'aggregatore di log di Cloud Foundry per

raccogliere i dettagli dei log di applicazione e di sistema dando la possibilità di vedere ciò che è

presente nel buffer all'interno dell'aggregatore di log.Ad ogni applicazione può essere associato uno

o più URL, ma tutti devono puntare all'endpoint Bluemix. Quando viene ricevuta una richiesta,

29

Bluemix la esamina, determina qual è l'applicazione a cui è destinata e seleziona quindi una delle

istanze dell'applicazione per la ricezione della richiesta.

3.3 SoftLayer : le fondamenta di Bluemix

Dopo aver evidenziato il funzionamento di alto livello di Bluemix,risulta necessario un

approfondimento relativo all’architettura su cui si poggia la piattaforma IBM:SoftLayer

[10].Softlayer è la soluzione IaaS di IBM che fornisce server, storage, networking e servizi in

maniera semplice ed efficiente nel cloud.Softlayer nasce nel 2005 e,grazie alla sua capacità di

mettere a disposizione infrastrutture complesse in tempi rapidissimi, si è posta subito in evidenza

sul mercato grazie soprattutto ai suoi servizi di rete,tanto da venire acquistata da IBM nel luglio

2013.I suoi Datacenter ,distribuiti in tutto il mondo ed interconnessi tramite rete privata,presentano

uno o più pod, ognuno costruito per supportare fino a 5.000 server .Le metodologie di

costruzione,considerate al vertice del settore,ottimizzano le prestazioni dei data center in termini di

spazio,alimentazione,rete ed infrastruttura interna, e ne garantiscono,inoltre,una standardizzazione

in ogni ubicazione geografica.Tali data center sono caratterizzati da una infrastruttura ridondante,

dotata di molteplici alimentatori, collegamenti a fibre ottiche, generatori dedicati e batterie di

soccorso.L’architettura rack,invece,garantisce larghezza di banda elevata, alimentazione

abbondante, implementazione semplificata del sistema e risoluzione più rapida dei problemi,

disponendo ,inoltre, di 40Gbps di connettività così distribuiti:20Gbps per la rete privata, 20Gbps per

la rete pubblica,in modo da garantire elevate prestazioni.Tali datacenter sono capaci di comunicare

ad elevate performance,con un footprint globale,grazie alla tripla architettura di rete presente in

ognuno di essi che garantisce che ogni workload sia erogato con altissimi livelli di sicurezza .Il

dettaglio di tale tripla architettura di rete fa apprezzare al meglio le altissime prestazioni fornite.

Figura 13:Dettagli dell’architettura di rete SoftLayer

La forza di SoftLayer è da ricercarsi nella sua rete di reti,in quanto il traffico pubblico,privato e di

gestione passa attraverso livelli,o meglio, interfaccia di rete diversificate,garantendo scalabilità e

controllo,ma soprattutto, prestazioni elevatissime con una rete globale che presenta più di 2000Gbps

di connettività tra i data center ed i Pop di rete(points of precence).La prima delle 3 interfacce di

rete costituenti Softlayer è la rete pubblica: ogni singolo data center,così come i PoP di

rete,presentano connessioni da 10Gbps a vettori di transito e peering di altissimo livello,con un

traffico di rete che,da ogni sito geografico,si connetterà al PoP di rete più vicino, attraversando

direttamente la rete fino al suo data center, minimizzando così il numero di hop e handoff di rete tra

provider.Schematizzando in maniera semplificativa,è possibile affermare che la rete pubblica

SoftLayer offre elevata larghezza di banda in entrata,molteplici connesioni backbone

internet,gestione ed instradamento IP automatizzati e DNS geograficamente ridondante.La seconda

interfaccia della rete di reti SoftLayer è la rete privata: essendo separata dalla rete

30

pubblica,consente la connesione praticamente ininterrotta ai servizi presenti nei data center

SoftLayer in tutto il mondo ,i quali,insieme ai PoP,sono connessi tramite la backbone di rete privata

SoftLayer.La rete privata,dunque,non interferisce con il traffico della rete pubblica,offrendo

numerosi vantaggi quali larghezza di banda elevata,VLAN private, sicure, e configurabili

,connessioni incrociate da server a server gratuite,resolver DNS locali, privati,risorse di storage

centralizzate e server disponibili con velocità di porta fino a 10Gbps.L’ultima interfaccia di rete

caratterizzante SoftLayer è la rete di gestione: ai fini della manutenzione e

dell’amministrazione,ogni server SoftLayer è connesso anche ad una rete di gestione fuori

banda,accessibile tramite VPN indipendentemente dalla CPU,dal firmware e dal sistema

operativo.Questa rete ha lo scopo di fornire numerose opportunità,come il ricaricamento del sistema

operativo,eseguire il ciclo di alimentazione del server o controllarne l’avvio tramite connessione

IMPI.Oltre ad una architettura così altamente performante,SoftLayer mette a dispozione anche

risorse condivise ,quindi multi-tenant, dedicate ,ovvero single-tenant, o miste.SoftLayer, tramite

portale web, applicazione mobile e API, mette a disposizione ambienti Virtual Machine sia

condivisi che dedicati, su hypervisor standard come Citrix Xen.I server virtuali SoftLayer sono

disponibili su nodi pubblici o privati del cloud pubblico ,offrendo la possibilità di. distribuire un

server virtuale con nodo pubblico per workload adatti ad un ambiente multi-tenant, oppure

scegliendo un nodo privato per la distribuzione del server virtuale su un server host dedicato. I

server virtuali SoftLayer ,inoltre,possono essere implementati con storage primario basato su disco

locale o SAN (Storage Area Network) e con volumi di storage portatili come storage

secondario.Inoltre, con la stessa semplicità di fruizione, è possibile richiedere dei server fisici Bare

Metal senza nessuno strato di virtualizzazione o con il virtualizzatore più adatto alle proprie

esigenze.I Bare Metal ,infatti,forniscono la potenza richiesta per workload a più intenso utilizzo di

processori ed attività di I/O su disco,essendo dotati di pacchetti di funzioni e servizi davvero

completi e ,soprattutto,personalizzabili.SoftLayer,infatti,offre la possibilità di configurare i server in

base alle esatte specifiche tramite il relativo portale o tramite API,distribuendo poi tale

configurazione in tempo reale a qualsiasi data center SoftLayer.I server Bare Metal offrono una

gamma di scelte davvero imponente,da server a processore singolo entry-level,fino a server quad-

core,esa-core e molto altro ,con una personalizzazione completa che passa attraverso la scelta di

RAM,unità disco fisso SSD e molto altro ancora.Anche per lo spazio disco sono disponibili storage

in modalità virtualizzata o dedicata. Il servizio di Object Storage, implementato su OpenStack,

fornisce uno spazio teoricamente “illimitato” con pagamento a consumo PAYG.I servizi Evault ed i

server Idera consento il backup dei propri ambienti in maniera semplice e veloce, inoltre Softlayer

dà la possibilità di installare il proprio software di backup, continuando a sfruttare le proprie licenze

e le proprie competenze. Firewall e Load Balancer sono disegnati per soddisfare ogni esigenza:

servizi ad-hoc o appliance dedicate fanno di Softlayer uno scrigno, altamente scalabile, costruito su

misura a protezione dei propri dati. Per quanto riguarda la sicurezza,servizi come Intrusion

Detection, Intrusion Prevention, Antivirus, certificati SSL facilitano la protezione degli ambienti.Il

Content Delivery Network permette di replicare in modo intelligente i contenuti in tutto il mondo,

per una accessibilità con massime performance. È possibile creare in Softlayer un ambiente Private

Cloud, richiedendo il proprio virtualizzatore, e ambienti Big Data, sfruttando le potenzialità di

MongoDB, Riak, Cloudera e Cloudant. Tutto questo basato sulla tripla architettura di rete,il cuore

pulsante di SoftLayer, che rende solide le fondamenta di Bluemix.

31

Capitolo 4:Creazione,gestione e sviluppo di applicazioni in Bluemix

4.1 Creare applicazioni con Bluemix

Bluemix è stato introdotto per semplificare la vita di ogni sviluppatore software,agevolando il

development ed il delivery delle applicazioni.Per far ciò,la piattaforma semplifica anche i passi

operativi necessari alla creazione dell’applicazione.Bluemix ,infatti,offre la possibilità di creare

un’applicazione mobile,web,aggiungere funzionalità mobili ad un’applicazione web esistente nel

dashboard IBM® Bluemix,il tutto in maniera semplice e veloce[7].Dopo aver creato l’applicazione,

la piattaforma offre diverse opportunità di sviluppo,permette infatti di continuare ad usare

l'interfaccia utente, fornisce un interfaccia riga di comando cf o permette l’uso di IBM Bluemix

DevOps Services per sviluppare, tracciare, pianificare e distribuire l’applicazione.

4.1.1 Creazione applicazioni mobile

La creazione di una applicazione mobile in Bluemix, inizia scegliendo la piattaforma della stessa

,come iOS, Android o Hybrid,e a seconda di tale scelta, vengono forniti dalla piattaforma un

runtime ,come Node.js, ed un insieme di servizi.In quest’ottica,un servizio è un'estensione cloud che

fornisce funzionalità pronta per l'uso, come messaggistica, software di database e web per

l'esecuzione di codice, oppure un fornitore di funzionalità di monitoraggio e o gestione delle

applicazioni . I servizi di norma non richiedono l'installazione o la manutenzione e possono essere

combinati per creare delle applicazioni. Un runtime,invece, è la serie di risorse utilizzata per

eseguire un'applicazione. Bluemix fornisce ambienti di runtime come contenitori integrati e

pacchetti di build,indicati per diverse tipologie di applicazione.Essi sono,inoltre, configurati

automaticamente per l'utilizzo e richiedono una manutenzione minima, se non nulla.Utilizzando i

servizi e i runtime messi a disposizione ,lo sviluppatore può dunque concentrarsi sullo sviluppo

dell’applicazione invece che sulle complessità di gestione dell'infrastruttura di back-end.I passi

operativi atti alla creazione di un’applicazione mobile sono dunque:

1. Cliccare su Dashboard nell'interfaccia utente Bluemix.

2. Scegliere CREA UN'APPLICAZIONE.

3. Selezionare MOBILE attenendosi poi all'esperienza guidata.

4. Scegliere la piattaforma per l’ applicazione. La piattaforma scelta determina quali servizi

vengono messi a disposizione con l‘applicazione.

iOS 8, con l'applicazione vengono messi a disposizione i servizi Advanced

Mobile Access, Cloudant NoSQL DB e Push-iOS8 e un runtime Node.js.

Android, Hybrid, iOS o JavaScript, con l'applicazione vengono messi a

disposizione i servizi Mobile Data, Mobile Application Security, Mobile Quality

Assurance e Push e un runtime Node.js.

32

5. Scaricare l'SDK per il dispositivo di destinazione.

6. Risulta possibile aggiungere un servizio all’applicazione facendo clic su AGGIUNGI UN

SERVIZIO nell'interfaccia utente Bluemix. In alternativa,si può utilizzare l'interfaccia riga

di comando cf.

7. Nel dashboard, fare clic su Aggiungi Git per salvare l'origine applicazione in un repository

Git e creare un progetto ospitato Git. È possibile anche distribuire l'applicazione da IBM

Bluemix DevOps Services.

4.1.2 Creazione di applicazioni web

Quando viene creata un'applicazione web in Bluemix,si parte da uno starter. Uno starter è un

template che include dei servizi predefiniti e del codice applicativo configurato con uno specifico

pacchetto di build. Ci sono due tipi di starter: contenitori tipo e runtime.Un contenitore tipo è un

contenitore per un'applicazione, il suo ambiente di runtime associato ed i servizi predefiniti per uno

specifico dominio. Ad esempio, il contenitore tipo Mobile Cloud include un runtime Node.js, oltre

che i servizi Mobile Data, Mobile Application Security e Push. Include anche un SDK e delle

applicazioni di esempio per iniziare a sviluppare applicazioni mobili che accedono a tali servizi.Un

pacchetto di build ,invece,è una raccolta di script che preparano il codice per l'esecuzione sul PaaS

di destinazione. Un pacchetto di build raccoglie le dipendenze di runtime e framework di

un'applicazione e li impacchetta quindi con l'applicazione in un droplet che può essere distribuito al

cloud.Se non viene specificato un pacchetto di build ,vengono utilizzati per impostazione

predefinita i pacchetti di build integrati,impedendo quindi la scelta di pacchetti esterni forniti dalla

community di Cloud Foundry.I passi operativi relativi alla creazione dell’applicazione sono,in

questo caso:

1. Cliccare su Dashboard nell'interfaccia utente Bluemix.

2. Selezionare CREA UN'APPLICAZIONE.

3. Fare clic su WEB e attenersi all'esperienza guidata per scegliere uno starter, specificare un

nome e selezionare come si desidera eseguire la codifica.

4. Dopo aver terminato l'esperienza guidata, fare clic su VISUALIZZA PANORAMICA

DELL'APPLICAZIONE. La Panoramica è visualizzata nel Dashboard.

5. Si può aggiungere un servizio all’ applicazione facendo clic su AGGIUNGI UN SERVIZIO

O UNA API nella Panoramica dell'applicazione nell'interfaccia utente Bluemix. In

alternativa, si può utilizzare l'interfaccia riga di comando cf.

6. Nella Panoramica dell'applicazione, fare clic su Aggiungi Git per salvare l’origine

applicazione in un repository Git e creare un progetto ospitato da Git. È possibile anche

distribuire l'applicazione da IBM Bluemix DevOps Services.

Nota a margine:se un servizio associato mediante bind ad un'applicazione viene arrestato in modo

anomalo, l'esecuzione dell'applicazione potrebbe essere arrestata oppure presentare degli errori.

Bluemix non riavvia automaticamente l'applicazione per eseguire il ripristino da tali

problemi,demandando tale gestione allo sviluppatore.

4.2 Gestione Applicazioni

Bluemix,una volta creata l‘applicazione,mette a disposizione più opzioni per l’aggiunta di servizi e

la distribuzione della stessa:

33

Interfaccia riga di comando cf

Opzione che permette,tramite tale interfaccia, di aggiornare l’ applicazione, creare

un'istanza del servizio o eseguire il bind del servizio all’ applicazione stessa.

Interfaccia utente Bluemix L'interfaccia utente Bluemix consente di creare l’ applicazione selezionando, tra l'altro,

quali servizi e runtime combinare per risolvere i problemi di business dello sviluppatore.

IBM Bluemix DevOps Services

IBM Bluemix DevOps Service viene utilizzato per creare un'applicazione nel cloud e

distribuirla a Bluemix. I servizi forniti da IBM Bluemix DevOps Services includono Track

& Plan e Delivery Pipeline, elencati nel catalogo Bluemix in DevOps, oltre che Web IDE e

Git hosting.

4.2.1 Interfaccia riga di comando CF L’app management può essere gestita anche tramite interfaccia da riga di comando CF,del quale è

offerto un apposito manuale per comprenderne in pieno tutte le funzionalità[7].Riporto,dunque,i

comandi più comunemente utilizzati nella gestione delle applicazioni:

cf api:Visualizza o specifica l'URL dell'endpoint API di Bluemix .

cf apps:Elenca tutte le applicazioni distribuite nello spazio corrente. Viene

visualizzato anche lo stato di ciascuna applicazione.

cf bind-service:Esegue il bind di un'istanza del servizio esistente all’

applicazione.

cf create-service:Crea un'istanza del servizio.

cf delete:Elimina un'applicazione esistente.

cf events:Visualizza gli eventi di runtime che sono correlati ad

un'applicazione.

cf help:Visualizza le informazioni di guida per tutti i comandi cf oppure per

uno specifico comando cf se viene utilizzato il parametro nome_comando.

cf login:Permette l’accesso alla piattaforma.

cf logs:Visualizza i flussi di log STDOUT e STDERR di un'applicazione.

cf marketplace:Elenca tutti i servizi disponibili nel marketplace. I servizi

elencati da questo comando sono visualizzati anche nel Catalogo di Bluemix .

cf push: Distribuisce una nuova applicazione oppure aggiorna

un'applicazione esistente in Bluemix .

cf scale:Visualizza o modifica il numero di istanze, il limite di spazio su

disco e il limite di memoria per un'applicazione.

cf services:Elenca tutti i servizi disponibili nello spazio corrente.

cf set-env:Imposta una variabile di ambiente per un'applicazione.

cf stacks: Elenca tutti gli stack. Uno stack è un file system precostruito,

compreso un sistema operativo che può eseguire le applicazioni.

cf stop :Arresta un'applicazione.

4.2.2 Interfaccia utente Bluemix

Bluemix offre l’opportunità di utilizzare il Dashboard nell'interfaccia utente IBM® Bluemix per

visualizzare e gestire le applicazioni ed i servizi ,oltre a monitorare l'utilizzo delle risorse mediante i

misuratori di quota.La sezione relativa alle applicazioni nel Dashboard fornisce delle informazioni

di riepilogo per le applicazioni create,come nome, icona, URL, runtime e stato di esecuzione

dell'applicazione, oltre alle istanze di servizio associate all'applicazione stessa. Per indicare lo stato

di esecuzione di ogni applicazione ,l’interfaccia utente ne semplifica la visualizzazione

caratterizzando ognuno di essi con un colore diverso:

34

Grigio: L'applicazione è stata arrestata.

Verde: L'applicazione è stata avviata e tutte le istanze sono in esecuzione.

Giallo: L'applicazione è stata avviata e sono in esecuzione meno del 100% delle istanze.

Rosso:L'applicazione è stata avviata e nessuna delle istanze è in esecuzione.

Nel Catalogo di Bluemix, è possibile visualizzare i servizi e gli starter disponibili, selezionando

quest’ultimo per creare un'applicazione, eseguire il bind di un servizio e gestire l'applicazione

stessa. Dopo che un servizio è stato associato a un'applicazione, è possibile gestirne le istanze e

crearne di nuove.L’iterfaccia utente,inoltre,permette di eliminare l'associazione mediante bind o

l'istanza di servizio da un'applicazione,oltre che scegliere un piano di servizio diverso.La sezione

Panoramica dell’applicazione,permette di visualizzare ulteriori informazioni sulla stessa,osservando

però che risulta possibile visualizzare risorse di una sola organizzazione alla volta.La

visualizzazione di ulteriori informazioni relative ad applicazioni presenti in altre

organizzazioni,dove quest’ultime sono semplicemente workspace associati alle applicazioni

create,viene concessa cliccando semplicemente sull’icona CAMBIA ORGANIZZAZIONE, accanto

al nome di quella corrente.Quando un'applicazione viene distribuita,risulta possibile avviare,

arrestare, riavviare o ,nel caso di applicazioni Web, modificare il numero di istanze e la quantità di

memoria utilizzata dall'applicazione stessa.Le applicazioni possono essere ridistribuite se viene

eseguito un aggiornamento,ed in questo caso Bluemix arresta tutte le istanze in esecuzione e le

sostituisce con le nuove istanze automaticamente.

4.2.3 Gestione di applicazioni con Bluemix

DevOpsServices

I servizi IBM Bluemix DevOps permettono una gestione più diversificata e completa per

sviluppare, tracciare e pianificare un'applicazione, distribuendola in maniera rapida e semplificata a

Bluemix. DevOps Services fornisce due servizi principali di gestione e distribuzione: Track &

Plan e Delivery Pipeline [7]. Il servizio Track & Plan viene utilizzato per una pianificazione agile

del lavoro e dei compiti assegnati al team, permette di gestire il backlog in maniera efficiente,

pianificare i prossimi sprint di lavoro e molto altro,il tutto attraverso la creazione di work items. I

passi preliminari necessari alla fruizione di tale servizio sono l’associazione dello stesso

all’applicazione da sviluppare tramite i seguenti passi operativi:

1. Nel Dashboard dell'applicazione Bluemix, fare clic su AGGIUNGI UN SERVIZIO

O UNA API selezionando Track & Plan nella categoria DevOps del catalogo.

2. Nella pagina Track & Plan, selezionare un piano e fare clic su CREA.

3. Nell'elenco di applicazioni, nella colonna Stato, modificare lo stato per il servizio

Track & Plan facendo clic sullo stato corrente, che in questo caso è DISATTIVO. La

pagina Impostazioni del progetto viene aperta in IBM Bluemix DevOps Services.

4. Selezionare l'opzione per abilitare il servizio Track & Plan e,se necessario,

aggiornare la regione, l'organizzazione o lo spazio.

5. Fare clic su SALVA.

6. Tornare al Dashboard Bluemix e fare clic sul tile del servizio Track & Plan. Lo stato

del servizio Track & Plan viene modificato in ATTIVO .

7. Nell'elenco delle applicazioni, nella colonna Elemento di lavoro, fare clic su CREA

per iniziare a utilizzare il servizio Track & Plan.

DevOps fornisce più modalità di creazione dei work items necessari alla pianificazione ed al

tracciamento del lavoro,con settaggi diversi a seconda di come tali work items siano creati.Creando

35

un work item all’interno della vista MyWork ad esempio,ne si diventa automaticamente

proprietari,oppure creando un cosidetto Defect è possibile associare la parte di codice soggetta a

bug al banco di lavoro dello sviluppatore proprietario del codice in questione per un debugging

monitorato e ,soprattutto,più efficiente.Gli attributi settabili sono strettamente legati alla tipologia di

work item creati.Tali work items sono associati e gestiti tramite un meccanismo basato su stati:

Open: work item non ancora in esecuzione.

In progress: work item in esecuzione.

Resolved: work item terminato con stato completato o invalido.

Gli elementi di lavoro presentano diverse modalità di visualizzazione,come le modalità List,Table e

Lanes,che presentano caratteristiche di rappresentazione differenti.Anche il filtraggio dei work

items risulta semplice e molto potente,con ricerca basate su keywords ed attributi applicabili in ogni

vista,dal MyWork allo SprintPlanning,che danno vita a vere e proprie query.Queste operazioni di

filtraggio consentono di creare viste personalizzate condivisibili con il proprio team di lavoro,

rendendo più consona la pianificazione alle proprie esigenze ed offrendo più dinamicità rispetto alle

viste di base in cui i work items sono organizzati.Queste ultime,permettono la visualizzazione di

attività,come la MyWork Activity view,e la gestione di work items inizializzati ma non ancora in

esecuzione,raccolti nella InComingWork view,per una gestione comunque organizzata della

pianificazione del lavoro.Tale pianificazione,è gestita ,in particolare, nella SprintPlanning view in

cui è possibile assegnare un work item ad uno sprint associadolo ad una attività tramite la

Planningfor list.In questo modo risulta semplice ed intuitivo assegnare e riassegnare elementi di

lavoro,aggiungerli al Backlog e verificare le statistiche di avanzamento e progresso degli

sprint,come ad esempio analizzare le ore di lavoro rispetto alle ore totali stimate,work items

completati sul totale degli stessi e story point raggiunto rispetto a quello stimato.DevOps fornisce

,inoltre,meccanismi di ranking dei work items,con assegnazioni di story points da raggiungere e

visualizzabili, anche, nella Team’s work view,per un tracciamento totale e ben pianificato del

lavoro.Per automatizzare le build e le distribuzioni,invece,Bluemix,ed in particolare i DevOps

Services,offrono la possibilità di utilizzare Continuous Delivery Pipeline for Bluemix, il servizio

Delivery Pipeline fornito dalla piattaforma IBM.Durante lo sviluppo di una applicazione in cloud,lo

sviluppatore fornisce gli script di build mentre IBM Bluemix DevOps Services li esegue,evitando

quindi di dover attribuire allo sviluppatore stesso l’onere di configurare i sistemi di build.Questo

permette in maniera semplice e veloce di distribuire automaticamente l’applicazione sviluppata ad

uno o più spazi Bluemix, server Cloud Foundry pubblici o contenitori Docker su IBM Containers. I

lavori di build compilano e impacchettano il codice sorgente dell’ applicazione in sviluppo da

repository Git o Jazz SCM ,ovvero source control management,producendo così delle risorse utente

quali file WAR o contenitori Docker per IBM Containers ,distribuibili ai server IBM Containers o

Cloud Foundry come Bluemix.Il servizio Delivery Pipeline offre altre numerose opportunità ,come

poter eseguire degli unit test all'interno di build automaticamente, attivare una build ogni volta che

il codice sorgente cambia,o distribuirlo a una o più regioni.Risulta possibile,ad esempio,configurare

il servizio Delivery Pipeline in modo che le risorse di sviluppo che utilizzano IBM Containers,

siano testate in un'unica regione e siano distribuite in più regioni al momento della produzione. Nel

Dashboard Delivery Pipeline è possibile visualizzare i progetti Bluemix DevOps Services e gli stati

in cui si trovano, controllare lo stato dei build, l'applicazione distribuita e gli sviluppi recenti,senza

dimenticare la possibilità di visualizzare i log e i dettagli di distribuzione più aggiornati.Oltre ai

suddetti servizi di pianificazione e distribuzione DevOps Services fornisce anche Git hosting per il

controllo dell'origine e un Web IDE che offre la possibilità di modificare, gestire e distribuire il

codice applicativo.Dal punto di vista operativo ,si abilita l'hosting Git facendo clic sul link

AGGIUNGI GIT, che si trova nell'angolo superiore destro della pagina Panoramica

36

dell'applicazione,mentre è possibile modificare il codice dell'applicazione in Web IDE facendo clic

su MODIFICA CODICE.

4.3 Code Editing in Bluemix

Bluemix mette a disposizione numerosi tools e metodologie di editing per poter sviluppare le

proprie applicazioni,come un ambiente di sviluppo integrato IDE,un editor di testo,un’interfaccia da

riga di comando, tool esterni come Eclipse o IBM® Bluemix DevOps Services.

4.3.1 CLI dev_mode Bluemix

La CLI dev_mode ,o più semplicemente modalità di sviluppo, è una funzione Bluemix utilizzabile

per gestire le applicazioni mentre sono in esecuzione nel cloud,e presenta come unico prerequisito

l’installazione dell’interfaccia CLI Cloud Foundry[7]. La modalità di sviluppo include l'interfaccia

riga di comando dev_mode. La CLI dev_mode è stata messa a punto come un plug-in CLI cf e

supporta sia applicazioni Node.js IBM sia Liberty.La CLI dev_mode presenta diverse funzioni,quali

la possibilità di alternare modalità di sviluppo e quella normale,aggiornare i file applicazione in

modo incrementale evitando,così,una nuova distribuzione dell’applicazione,ed in fine permette di

avviare,arrestare e riavviare l’applicazione contenitore esistente.Per quanto riguarda l’ installazione

dello strumento riga di comando dev_mode,i passi operativi necessari sono i seguenti:

Installare in locale.

1. Scaricare il plug-in dev_mode per la piattaforma da IBM Bluemix CLI Plugin

Repository.

2. Installare il plug-in dev_mode utilizzando il comando cf install-plugin:

3. cf install-plugin dev_mode-linux_amd64

Oppure alternativamente:

Installare dal repository CLI Bluemix.

1. Aggiungere il repository bluemix-repo nel repository CLI Cloud Foundry utilizzando

il seguente comando:

2. cf add-plugin-repo bluemix-repo http://plugins.ng.bluemix.net

3. Immettere cf repo-plugins. Il plug-in dev_mode viene visualizzato nel repository

bluemix-repo.

4. cf repo-plugins

5. Installare il plug-in dev_mode nei plug-in CLI Cloud Foundry utilizzando il seguente

comando:

6. cf install-plugin dev_mode -r bluemix-repo

Per quanto riguarda l’utilizzo di tale funzione,essendo un plug-in dell’intefaccia da riga di

commando CLI,presenta comandi appropiati ampiamente trattati nei manuali consultabili per

ulteriori approfondimenti.Ricordo brevemente che per visualizzare tutti i comandi CLI

dev_mode,basta utilizzare il seguente comando:

cf plugins

4.3.2 IBM Eclipse Tools for Bluemix

IBM® Eclipse Tools for Bluemix fornisce dei plug-in che possono essere installati in un ambiente

Eclipse esistente come ausilio nell'integrazione dell'IDE (integrated development environment)

dello sviluppatore con Bluemix[7]. Gli strumenti amplificano le possibilità fornite allo

37

sviluppatore,dando la possibilità di distribuire file JavaScript, WAR (web archive) ed EAR

(enterprise archive) e i server in pacchetto Liberty Profile al server Bluemix direttamente da Eclipse

IDE o da WebSphere Application Server Developer Tools (WDT). Gli strumenti agevolano,inoltre,

la creazione ed il collegamento di servizi all’ applicazione e permettono di definire delle variabili di

ambiente come parte della distribuzione.Se l’ applicazione è già in esecuzione in Eclipse utilizzando

Websphere Application Developer Tools con Liberty Profile, è possibile installare questi strumenti

in aggiunta al programma in esecuzione, distribuendo inoltre le applicazioni aggiungendole al

server Bluemix nel workbench. Grazie alle funzioni uniche del pacchetto di build Liberty per il

supporto di server in pacchetto, si dispone anche dell'opzione di distribuire l'intero server Liberty

Profile a Bluemix.Per poter installare gli Eclipse Tools è necessario un ambiente di esecuzione

Java 7.Ci sono più modi per installare IBM Eclipse Tools for Bluemix, uno di essi è il

seguente:installazione dal Marketplace,che richiede Eclipse Luna for Java EE Developers (4.4.1)

o Eclipse Kepler for Java EE Developers (4.3.2).

1. AprireHelp > Eclipse Marketplace. Cercare Bluemix.

2. Selezionare la voce IBM Eclipse Tools for Bluemix e fare clic su Install.

3. Per impostazione predefinita, ci sono delle funzioni selezionate per conto dello sviluppatore.

Fare clic su Confirm.

4. Accettare l'accordo di licenza e fai clic su Finish.

La pubblicazione incrementale ed il debug da remoto,sono altre due funzioni molto utili al lavoro

dello sviluppatore fornite dagli Eclipse Tools.La prima, permette di aggiornare i file

dell'applicazione in modo incrementale senza dover eseguire nuovamente il push dell'intera

applicazione per ogni modifica, con un conseguente risparmio di tempo nell'ambito del processo di

sviluppo.Questa funzione supporta le applicazioni web WAR , EAR ed i server in pacchetto, e per

utilizzarla risulta necessario che che la modalità di sviluppo sia abilitata per l'applicazione o il

server in pacchetto.Per farlo,basta semplicemente fare clic con il tasto destro del mouse

sull'applicazione o sul server in pacchetto selezionando Enable Development Mode.Per eseguire il

debug remoto sulle applicazioni Java in esecuzione su Liberty,invece,bisogna selezionare Enable

Application Debug con il tasto destro del mouse sull’applicazione.A questo punto la vista Progress

mostrerà lo stato Establishing debug session for <nomeApplicazione>.L'applicazione mostrerà

,quindi ,che si sta eseguendo lo sviluppo e il debug dell'applicazione ("Developing, Debugging

<nomeApplicazione>") con il debugger in esecuzione e pronto per l’uso.

4.3.3 Editig code in Bluemix DevOps Services

Il Web IDE è un ambiente di sviluppo browser-based che consente di sviluppare in JavaScript,

HTML, e CSS,in maniera semplificata,con l’ausilio ,cioè, di strumenti quali content assist,per una

scrittura di codice più rapida ed efficiente,code completion,per il completamento automatico della

porzione di codice scritto,e l’error checking per un rilevamento degli errori più efficiente.Il Web

IDE consente inoltre di lavorare con quasi tutti i linguaggi offrendo il cosiddetto syntax highlighting

per la maggior parte delle tipologie di file.Per il source control,il Web IDE da la possibilità di

accedere a tools di source code management integrati come i repository Git o Jazz SCM,garantendo

la possibilità di distribuire codice localmente per il testing ed il debugging delle applicazioni.Il fatto

che l’IDE sia accessibile tramite web,svincola lo sviluppatore dagli oneri di installazione e

manutenzione di componenti atti allo sviluppo,essendo questo possibile tramite una semplice

connesione internet.Oltre ai vantaggi strettamente pratici offerti da questo ambiente di sviluppo,vi è

anche la possibilità di un estrema customizzazione del code editor,sfruttando,ad esempio,funzioni

come lo split editor mode per il lavoro contemporaneo su più file, decidendo quindi quali color

schemes o technical tools risultino più adatti alle proprie esigenze di sviluppo.Questo risulta

possibile sia prima di iniziare a sviluppare il codice,cliccando semplicemente sull’icona Settings

38

dalla barra di navigazione e scegliendo i settaggi più adatti,sia durante l’editing grazie all’icona

Local Editor Settings,che,tra le altre cose, consente di scegliere anche altri editor settings

preconfigurati.Dal punto di vista dell’ editing in senso stretto,il web IDE presenta due sezioni

principali:la prima è presente sul lato sinistro dello schermo ed è rappresentata dal file navigator ,il

quale visualizza i file di progetto in una strutturazione ad albero,consentendo di

creare,eliminare,rinominare e gestire files e cartelle dell’applicazione,con la possibilità,inoltre, di

effettuare l’uploading attraverso un semplice dragging dei documenti necessari dal proprio PC;la

seconda senzione è un editor pane posto sul lato destro che presenta numerose features come

content assist e syntax validation,atte ad agevolare la scrittura di codice.Nonostante i numerosi

vantaggi forniti dal Web IDE,qualora quest’ultimo non risulti essere il code editor più adatto alle

proprie esigenze,Bluemix mette a disposizione degli sviluppatori Bluemix Live Sync. Bluemix

Live Sync è una applicazione command-line che sincronizza i cambiamenti nel proprio file system

locale con il proprio cloud workspace in IBM Bluemix DevOps Services permettendo di lavorare

direttamente con i propri file usando qualsiasi tool. Se si sta creando,ad esempio, un'applicazione

Node.js, utilizzando Bluemix Live Sync si ha la possibilità di aggiornare rapidamente l'istanza

dell'applicazione su Bluemix,con le eventuali modifiche che saranno visibili immediatamente,

sviluppando come sul desktop, senza rieseguire la distribuzione.Bluemix Live Sync si compone di

tre servizi:

Desktop Sync:

Questo servizio da la possibilità di sincronizzare qualsiasi struttura ad albero di directory

desktop con uno spazio di lavoro basato sul cloud ,consentendo al Web IDE di modificare in

maniera diretta lo stesso spazio di progetto ottenendo così una sincronizzazione totale.

Desktop Sync funziona per qualsiasi tipo di applicazione,a patto di scaricare ed installare

l’interfaccia riga di comando BL.

Live Edit:

Da la possibilità di apportare modifiche ad un'applicazione Node.js in esecuzione in

Bluemix verificandola nel browser in maniera immediata,poichè qualsiasi modifica

apportata in una directory desktop sincronizzata, o in Web IDE, viene propagata

immediatamente al file system dell'applicazione.

Debug

Mentre un'applicazione Node.js è in modalità Live Edit, è possibile accedere ad essa

mediante shell ed eseguirne il debug,modificando il codice in modo dinamico, inserendo

punti di interruzione, analizzando in dettaglio il codice, riavviando il runtime o altro ,il tutto

utilizzando il programma di debug Node Inspector.

Bluemix Live Sync,dunque,consente di utilizzare Desktop Sync per sincronizzare lo spazio di

lavoro desktop con lo spazio di lavoro del progetto basato sul cloud, modificarlo direttamente con

Web IDE,o utilizzare Live Edit per estendere le modifiche nello spazio di lavoro del progetto all’

applicazione in esecuzione,eseguendone un eventuale debug,il tutto con l’unico scopo di

semplificare, ancora una volta, il lavoro dello sviluppatore.

39

Figura 14: Bluemix Live Sync

40

Conclusioni

La mia tesi ha avuto lo scopo di analizzare le soluzioni innovative proposte dal mondo IT e dalle

più grandi imprese del settore tecnologico,in particolare da IBM,per cercare di fornire risposte

concrete all’agilità di sviluppo richieste dal mercato.A valle di quanto analizzato l’adozione del

Continuous engineering come punto focale dello sviluppo software,unito a soluzioni innovative

come il DevOps e l’introduzione di concrete architetture orientate al servizio,SOA, sembrano

essere un ottimo punto di partenza per permettere al mondo IT di raggiungere gli obbiettivi già

perseguiti per quanto concerne le infrastrutture anche nel campo dello sviluppo software.Queste

tematiche sono state approfondite analizzando una particolare soluzione,Bluemix, evidenziando da

prima,i vantaggi dell’adozione di una soluzione PaaS nel campo dello sviluppo software,entrando

poi nel dettaglio di come l’architettura stessa e l’enorme gamma di servizi offerti dalla piattaforma

di IBM semplifichino altamente il lavoro dello sviluppatore software,svincolandolo da oneri di

gestione infrastrutturale e permettendogli una completa concentrazione sullo sviluppo di

applicazioni.La strada da percorrere è comunque ancora lunga, con una standardizzazione

dell’adozione cloud che risulta essere ancora lontana dall’essere messa in atto a livello

globale,nonostante problematiche quali vendor lock-in vengano ben agirate con i numerosissimi

servizi ed integrazioni offerti,ma sicuramente il viatico intrapreso risulta essere la direzione giusta

da percorrere.

41

Bibliografia

[1] Giampiero Carli Ballola, sviluppo software:per IBM il motore è nel cloud,

http://www.zerounoweb.it/approfondimenti/software-application-quality/sviluppo-software-per-

ibm-il-motore-nel-cloud.html,2014

[2] Riccardo Florio, IBM porta lo sviluppo nel cloud, http://www.tomshw.it/articoli/ibm-porta-lo-

sviluppo-nel-cloud-59949-p3,2014.

[3] M. Peter and G. Timothy. The nist definition of cloud computing. Special Publication 800-145,

2011

[4] Hostingtalk.it,Distribuzioni Cloud : http://www.hostingtalk.it/lezione-3-tipologie-di-cloud-

cloud-pubblico-privato-e-ibrido_-c000000sp/,25/9/2015

[5] Hostingtalk.it,PaaS,Platform as a Service,il cloud per gli sviluppatori:

http://www.hostingtalk.it/lezione-7-paas-platform-as-a-service-il-cloud-per-gli-sviluppatori_-

c000000sL/,25/9/2015

[6] Cloudtalk.it,DevOps,http://www.cloudtalk.it/devops-la-nuova-buzzword-dellit-cerchiamo-di-

capire-cose/,25/9/2015

[7]Bluemix,DocumentazioneBluemix,https://www.ng.bluemix.net/docs/,sezioni:Panoramica,Sicure

zza,Servizi,Creazione applicazioni web e mobile,Servizi DevOpsBluemix,Gestione delle

applicazioni,CLI e strumenti di sviluppo. 26/9/2015

[8]Cloudfoundry.org,ArchitetturaCloudFoundry,http://docs.cloudfoundry.org/concepts/architecture/

,25/9/2015

[9] Cloudfoundry.org,Distribuzione applicazioni Cloud

Foundry,http://docs.cloudfoundry.org/concepts/how-applications-are-staged.html, 27/9/2015

[10] Softlayer.com,Documentazione SoftLayer,http://www.softlayer.com/it/, sezioni: Rete, Server e

Piattaforma, 27/9/2015