Annuncio : Ruoli in Windows Azure

 

Ieri il team di Windows Azure ha annunciato la possibilità di attivare 25 ruoli per ogni deployment a differenza dei 5 attuali. Questo permette di avere a disposizione un mix di 25 ruoli differenti (Web Role, Worker Role, VM Role) come parte di un singolo deployment. In questo modo chi sviluppa applicazioni può avere maggior controllo sulla scalabilità della propria applicazione. Perchè è importante ?

Immaginiamo per esempio di avere un applicazione web così composta.

1. Un interfaccia web realizzata con ASP.NET MVC
2. Servizi di business dell’applicazione esposti tramite WCF
3. Servizi di integrazione dell’applicazione esposti tramite WCF
4. Un interfaccia web di amministrazione scritta in ASP.NET
5. Servizi di comunicazione per un applicazione Windows Phone 7 esposti tramite REST API
6. Servizio di import/export dei dati basato su code
7. Database SQL Server

Senza entrare troppo nel dettaglio delle mille architetture possibile per realizzare questa applicazione, possiamo facilmente identificare dei ruoli ben precisi che dovremmo trattare come unità isolate. Per poter avere un minimo di scalabilità ovviamente dobbiamo pensare che ogni ruolo venga esposto con più istanze (più frontend) a seconda ovviamente del numero di utenti che ci aspettiamo.

Il database fa storia a se ovviamente, chiediamo ad Azure di costruire un database della dimensione che ci interessa e avremo la stringa di connessione per fare tutto quello che ci pare.

In Windows Azure esiste il concetto di Hosted Service. Un hosted service è un qualcosa che risponde ad un URL definito. La forma dell’URL è tipicamente mycomplexapp.cloudapp.net. La domanda a questo punto è : quanti hosted services ci servono per la nostra applicazione ?

Potremmo per esempio avere un hosted services per la parte web che includa due ruoli, l’interffaccia principale MVC a l’interfaccia di amministrazione (mycomplexappui.cloudapp.net), un hosted service che contenga i servizi esposti (tre ruoli in totale –mycomplexappsvc.cloudapp.net) e un hosted service che contenga un solo ruolo per l’importazione dei dati (mycomplexappwrk.cloudapp.net) . Quindi riassumendo avremo un totale di 11 istanze:

Hosted service	Numero di ruoli	Numero totale di istanze	Totale istanze
mycomplexappui.cloudapp.net	2	3 istanze per MVC, 1 per l’admin	4
mycomplexappsvc.cloudapp.net	3	2 istanze per i servizi applicativi, 2 istanze per i servizi di comunicazione e 2 per i servizi WP7	6
mycomplexappwrk.cloudapp.net	1	1 istanza per import/export	1

Uno dei vantaggi che abbiamo usando questa architettura è quello di poter dividere l’applicazione in deployment differenti (per esempio potremmo mettere la parte web su un datacenter e i servizi su un altro) o anche di poter addirittura dividere i servizi in sottoscrizioni diverse (una a consumo e una a risorse definite). Insomma abbiamo la possibilità di distribuire le unità come ci pare rendendo la nostra applicazione più semplice da mantenere (per esempio se devo aggiornare solo il servizio di import/export non devo aggiornare tutti i ruoli ma solo quello che mi serve). Uno degli svantaggi di questa architettura è il fatto che le comunicazioni tra i servizi avvengono sempre passando attraverso il LB. Vuol dire che se l’istanza 1 dell’hosted service mycomplexappui (A1)deve chiamare l’istanza 1 del servizio mycomplexappsvc (B1) la comunicazione partirà dalla macchina virtuale A1 verso l’esterno di internet fino al DNS e poi sarà ridirezionata all’interno di Windows Azure verso la macchina virtuale (B1) tramite il load balancer. In Windows Azure non è possibile eseguire comunicazioni dirette tramite hosted services diversi.

Per rendere tutta l’applicazione più veloce e per permettere per esempio di attivare dei canali di comunicazioni diretti (TCP/IP – Named Pipe) tra macchine virtuali diversi e ruoli diversi il  mio deployment dovrà essere fatto su un unico hosted service. A quel punto la mia applicazione sarà esposta nel sequende modo:

Hosted service	Numero di ruoli	Numero totale di istanze	Totale istanze
mycomplexappui.cloudapp.net	1	3 istanze per MVC	3
mycomplexappui.cloudapp.net:8080	1	1 istanza di admin	1
mycomplexappsvc.cloudapp.net:9090	1	2 istanze per i servizi applicativi	2
mycomplexappsvc.cloudapp.net:9091	1	2 istanze per i servizi di comunicazione	2
mycomplexappsvc.cloudapp.net:9092	1	2 per i servizi WP7	2
mycomplexappwrk.cloudapp.net:7070	1	1 istanza per import/export	1

Il numero totale di istanze rimane invariato ma come vedete l’applicazione risponderà ad un unico URL utilizzando diverse porte per poter connettere le varie unità. In realtà se volessimo potremmo non esporre le due istanze sulla porta 9090 (utilizzate solo per la comunicazione interna) ma semplicemente dichiarare degli InternalPoint di comunicazione diretta tra il frontend ed il middleware.

Quanti sono i ruoli all’interno del nostro hosted services adesso ??? Sono 6 e prima di oggi non era possibile averli mentre oggi possiamo arrivare fino a 25 che ci permette di avere architetture molto complesse e benificare del fatto che la comunicazione interna (tramite VIP – Virtual IP Addess) sia permessa.

Ps. Uno dei motivi per i quali non è permessa in questo momento una comunicazione diretta tramite hosted service diversi è quello di impedire che la piattaforma venga usata per fare DOS tra servizi differenti. Potrei caricare per esempio 5 VM e mettere un servizio che faccia chiamate interne a tutti gli altri servizi esposti dalla server farm ed è stato deciso quindi di limitare questa possibilità.