Upload
dodat
View
218
Download
0
Embed Size (px)
Citation preview
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.
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.
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