Revenons en détails sur l’application Azure/Mesh du Keynote TechDays 2009 – Partie 1 : Windows Azure

Je vous propose de revenir plus en détails sur l’application que nous avons conçu avec Pierre Lagarde pour la plénière développeurs du jour 1 des TechDays 2009. Vous pouvez dors et déjà retrouver cette session en vidéo ici: Vivez ou revivez la plénière développeurs des TechDays (jour 1) en vidéo !

Nous avons voulu illustrer 3 concepts différents que nous retrouverons ici dans 3 billets séparés : une application Windows Azure, du S+S et un scénario d’application Live Mesh. Nous prévoyons bientôt de réaliser un webcast “Director’s cut” qui vous montra tout ce que nous n’avons pu vous montrer en plénière. J’en parlerais notamment en mode bonus dans un 4ème billet. Nous publierons également bientôt le code source complet de notre solution pour vous permettre de jouer avec et de décortiquer l’ensemble.

Le but de notre application est de proposer un partage de photos en ligne. Voici l’architecture retenue pour cette application ASP.NET hébergée dans le nuage:

Comme vous l’a expliqué Pierre, 2 types de rôles sont hébergeables dans le cadre d’une application Windows Azure : 1 Web Role qui contiendra votre application ASP.NET et 1 Worker Role qui contiendra vos services à faire tourner en tâche de fond.

Dans notre cas, le Web Role propose l’interface suivante:

Cette application Web nous permet d’ajouter une photo avec une interface HTML “classique”:

Ou avec une interface RIA utilisant Silverlight 2 pour nous permettre un upload de plusieurs photos d’un coup:

Pour stocker nos photos, nous avons utilisé 2 services de Windows Azure:

- Blob : permettant de stocker nos fichiers/photos dans le nuage
- Table : permettant d’enrichir nos photos de métadonnées et offrant une expérience plus riche pour le développeur à travers par exemple l’utilisation d’un provider Linq.

Lorsque l’on pousse la photo dans notre stockage Azure, on revient alors sur l’interface principale où l’on découvre qu’une animation se lance le temps que la vignette se génère:

On peut alors se poser la question suivante : comment et à quel moment générer une vignette lors de l’upload d’une grosse photo. 2 choix s’offrent à nous:

- la générer au même moment que l’upload dans le web role: cela aura l’inconvénient de bloquer l’expérience utilisateur ce qui n’est pas souhaitable. Cela entrainera également une surcharge du frontal web qui n’est à priori pas dédié à cette tâche

- la générer en tâche de fond par un service de type “service NT” notifié par un système de queue. C’est clairement la meilleure approche. Cependant, dans le cas d’une solution hébergée “classiquement”, comment gérer le déploiement et l’administration de son service?

Avec Windows Azure, le Worker role va vous permettre justement de créer cette notion de service de manière simple et transparente. Dans notre cas, c’est bien lui qui s’occupe de générer la vignette. Il est notifié par le Web role à travers un système de queue proposé également par Windows Azure. Le déploiement est vraiment très simple. Dans Visual Studio 2008 SP1, on fait bouton droit sur le projet Cloud et on clique “Publish”. Un package est alors automatiquement généré et nous redirige vers le portail d’administration:

Ce portail nous propose alors de mettre en pré-production notre nouvelle application et de basculer la pré-production vers la production en 1 click. A noter qu’aujourd’hui en beta, nous n’avons accès qu’à 2 versions en ligne mais qu’à terme, nous aurons accès à N versions. On voit clairement là un des intérêts de la plateforme Azure. En effet, les coûts d’hébergement de plusieurs versions de notre solution peuvent rapidement devenir exorbitant dans un hébergement classique.

Autre avantage de la plateforme Azure, on peut facilement répondre à la charge en modifiant simplement un fichier de configuration XML où je précise le nombre d’instances que je souhaite associer à l’un des 2 rôles. Comme nous le disait Pascal, imaginons une promo de Noël qui explose le nombre de demandes pendant un temps précis. N’est-ce pas agréable de se dire qu’il suffit de changer une simple valeur dans un fichier de configuration pour répondre à la charge sans toucher à son code ni à s’occuper du déploiement de sa solution?

De manière analogue, une fois le pic de consultation passé, il suffit alors de redescendre la valeur pour s’adapter à la nouvelle fréquentation. C’est tout le but de la plateforme Azure: payez uniquement ce que vous consommez.

Résumons ce que nous a donc apporté Windows Azure dans cette 1ère partie de notre application:

1 – une plateforme d’exécution de notre code .NET Framework 3.5 SP1 que ce soit pour le site Web ou pour nos services de traitement en tâche de fond
2 – des services de stockage et de communication entre nos 2 rôles (Blob, Table, Queue)
3 – un déploiement automatisé et simplifié
4 – la possibilité de gérer une pré-production de manière simple et sans surcout.  
5 – la possibilité de supporter la montée de charge ou la descente par simple fichier de configuration

Passons maintenant à la suite avec l’illustration du concept S+S.

David