I Quaderni del Cloud : Windows Azure Platform : Cosa Cambia per il programmatore

Nei precedenti quaderni del cloud ho sottolineato più volte che lo sviluppo di applicazioni per Windows Azure può essere fatto offline, dallo sviluppo al debugging fino al testing.
Alla fine del processo di sviluppo e test (che tendenzialmente è lo stesso che già già implementiamo in azienda) invece di deployare l’applicazione sui server on-premises - come abbiamo fatto per decenni - potremo installarla sulla piattaforma di Windows Azure risparmiandoci molti aspetti tecnici (dette anche seccature) come la configurazione dei load-balancer, configurazioni di IIS o di un web server, permission sulle folders, regole di routing, ecc...

Ma che impatto ha un programmatore per lo sviluppo su Windows Azure?

NOTA : In questo post ci concentreremo sull’esperienza del .NET Developer mentre nel successivo vedremo l’esperienza per un JAVA e PHP Developer!

Esperienza di sviluppo per Windows Azure

Da un punto di vista puramente tecnico i cambiamenti richiesti sono veramente limitati perchè gli strumenti utilizzati per lo sviluppo di applicazioni ”Azure aware” sono esattamente gli stesso usati per lo sviluppo on-premises più alcune estensioni e un SDK. Nel caso dello sviluppatore .NET useremo lo stesso Visual Studio che utilizza durante lo sviluppo di altre tipologie di applicazioni con l’aggiunta di un SDK di Windows Azure e i tool per Visual Studio. L’ SDK, come tutti gli SDK, aggiunge le librerie,assembly, esempi e tool di supporto mentre i tool di Visual Studio (dalla versione Express alla Ultimate) permettono di estendere l’interfaccia di Visual Studio tramite wizard e menù aiutando quindi lo sviluppatore in tutti quegli aspetti più a basso livello.

Tra i vari tool del SDK di Windows Azure troviamo anche il Development Fabric, ovvero una simulazione in piccolo dell’ambiente di Windows Azure, storage compreso. Questo aspetto è molto importante perchè significa che lo sviluppo per Windows Azure può essere fatto anche da postazioni senza la connessione in rete, in offline !!! Sarà solo alla fine, quando il package sarà pronto che disponendo di una connessione ad Internet potremo installare l’ applicazione su Windows Azure Platform!!

Anche se i post dei Quaderni del Cloud non sono rivolti a programmatori voglio dare un piccolo assaggio di quali sono i principali passi per lo sviluppo.

Creiamo un nuovo progetto di tipo Cloud:

Una volta selezionato la tipologia Cloud potremo scegliere il tipo di progetto : Web Role/Worker Role (ed altri) – maggiori informazioni sui Role nel post precedente I Quaderni del Cloud : Cosa è la piattaforma Windows Azure

Selezionando un ASP.NET Web Role creeremo una semplice applicazione ASP.NET pronta per essere ospitata in un Web Role.

A questo punto si presenta Visual Studio all’interno del quale potremo sviluppare la nostra applicazione Web complessa e vasta a piacere!!! Nell’esempio, per mantenere le cose più semplici possibili, ho tolto un po’ di codice superfluo alla demo e ho scritto la stringa “Ciao Windows Azure” !

A questo punto, se lanciamo l’applicazione (es: F5 o Ctrl-F5) potremo notare due cose importanti:

1) Nella TNA (Try Notification Area) compare un logo Azzurro (guarda caso) con scritto Windows Azure Simulation Environment! Questo è l’ambiente di Windows Azure simulato in locale che ci permette di sviluppare applicazioni per Azure anche offline.

2) La nostra applicazione Cloud (che Cloud non è... ancora) sta girando effettivamente su 127.0.0.1 ovvero in locale!!!

Infatti l’ambiente di simulazione locale fa credere all’applicazione di essere su Windows Azure.

Vogliamo provare? :-)

Se ricordiamo dal primo post della serie : I Quaderni del Cloud : Cosa è il Cloud Computing si è parlato di scalabilità on demand e di elasticità , ovvero la capacità della piattaforma Cloud (reale o simulata che sia) di creare n istanze automaticamente a fronte di una semplice configurazione da parte dell’utente o, in questo caso, del programmatore...

Proviamola!

All’interno di Visual Studio troviamo il file XML based chiamato : ServiceConfiguration.cscfg. Tale file rappresenta gli aspetti di configurazione della piattaforma. All’interno del Role “WebRole1” troviamo la voce “Instance count = 1” ovvero richiediamo alla piattaforma una sola istanza dell’applicazione.

Infatti, lanciando nuovamente la nostra applicazione e andando a curiosare nell’ambiente simulato nella TNA (se non compare la GUI selezionate la voce Show Development Fabric UI ) notiamo che effettivamente è attiva una sola istanza.

Ritornando in Visual Studio e modificando nuovamente il file ServiceConfiguration.cscfg impostandolo ad esempio a 5 avremo :

avremo 5 istanze contemporaneamente attive sullo stesso end-point :

Proprio come il famoso detto : "Non c'e' problema, tu mi dici cosa devo fare e io lo faccio" :-)

Dimentichiamoci la configurazione dei Web Server, la configurazione dei load balancer, la configurazione delle regole di routing, ecc...

Una volta testato completamente le funzionalità on-premises potremo installare la nostra applicazione direttamente in staging su Windows Azure. Windows Azure ha il concetto di Staging e Production. Come primo deployment installiamo la nostra applicazione in staging per effettuare gli ultimi test. Una volta terminati andremo in produzione!

Piccolo consiglio : anche se tutti i test sono andati bene on-premises è buona norma rilanciare tutti i test una volta che l’applicazione è sul Cloud perchè AppFabric simulato, come dice la parola, è una copia in piccolo del vero appFabric...
I test di carico significativi invece ovviamente verranno fatti sulla piattaforma Cloud in Staging.

Quindi è venuto il momento di installare la nostra applicazioni in staging su Windows Azure.

In Visual Studio selezioniamo il nostro progetto e clickiamo su Publish, un’ esensione di Visual Studio che permette di creare il package della soluzione e relativi file di configurazione.

e finalmente possiamo andare all’interno del portale (dovremo avere un account precedentemente attivato) in Windows Azure e selezionare il progetto :

e carichiamo i file precedentemente creati per noi da Visual Studio :

Dopo pochi istanti di creazione dell’ hosted service (l’applicazione) su una nuova macchina virtuale (che non vediamo) avremo il nostro servizio/applicativo funzionante su Windows Azure in ambiente di staging.

Infatti, se lanciamo l’applicazione avremo

Dove il prefisso dell’ URL è un GUID che identifica in modo univoco il progetto in Staging.
In questo modo possiamo condividere l’applicazione anche con beta tester esterni alla nostra azienda per completare i test.

Una volta terminati tutti i test anche con l’ambiente di Staging in Windows Azure potremo finalmente installare la nostra applicazione in produzione. Per questa attività non dobbiamo fare altro che premere il tasto centrale che copia l’intero ambiente di staging in produzione !!!

il quale andrà online nella versione definitiva (in produzione)

Ecco, ora abbiamo la nostra applicazione perfettamente funzionante su Windows Azure in ambiente di production (notiamo l’URL )...

Cosa cambia?

Ovviamente non tutto è esattamente come l’on-premises anche se orami spero sia chiaro che la curva di apprendimento è molto bassa!

Esistono delle best-practices architetturali per lo sviluppo con Windows Azure che vanno da aspetti molto semplici come ad esempio non usare mai il disco locale per salvare informazioni dell’applicazione fino ad arrivare ai message patterns asincroni per la comunicazione distribuita tra Web e Worker Roles… Altro aspetto importante è legato al debugging in locale e al tracing in the Cloud perchè una applicazione in produzione potrebbe anche dare qualche problemino nel tempo :-) con relativo persisting dei dati di diagnostica e integrazione con gli strumenti di analisi on-premises.

Ci sono quindi alcuni aspetti architetturali e metodologici e di sviluppo (pochi) che è meglio conoscere prima di affrontare un progetto reale e che affronteremo durante i prossimi appuntamenti dei quaderni .

Un ultimo aspetto importantissimo!

Come abbiamo visto gli aspetti di sviluppo e di testing sono quasi identici a quelli tradizionali mentre di fatto cambia radicalmente l’aspetto del deployment! Consideriamo però un aspetto molto importante! Le risorse Cloud Based, indipendentemente dal tipo di vendor, sono  risorse che in qualche modo si pagano. Questo deve cambiare in modo radicale l’approccio che abbiamo verso questo tipo di risorse (soprattutto quelle di staging). Oggi siamo abituati ad avere macchine di test , spesso non molto performanti, ma sempre e comunque disponibili alla bisogna e non ci preoccupiamo del fatto di usare o meno tali risorse.

Il modello economico del Cloud cambia radicalmente questa abitudine!

Dovremo sempre e comunque avere il nostro ambiente di sviluppo e di test funzionali on-premises e provare la piattaforma Windows Azure solo quando necessario perchè tali risorse hanno sempre un costo (anche quando si hanno dei contratti ad uso gratuito fino ad un certo limite). Ad ogni modo  dedicherò un post ad-hoc sulla software factory per progetti Cloud e i modelli di utilizzo di Windows Azure per sfruttarli al meglio !!

--Mario