Windows Azure – Outils et bonnes pratiques

Note: ceci est un résumé d’une session des Microsoft Days, pas mon point de vue.

Par Pierre Couzy, Microsoft France.

Un tour d’horizon d’Azure

Le principe est de prendre un DataCenter de Microsoft et d’y poser nos applications. C’est du Platform as a Service (PaaS), là où d’autres (comme Amazon) proposent de l’Infrastructure as a Service (IaaS).

Avantages

• gérer les pics de charge immédiatement, là où en PaaS la montée en charge peut prendre plusieurs jours.
• traditionnellement, une application n’est pas conçue pour permettre les fermes de serveur frontaux/UI/base de données; sous Azure, le mode de développement rend au contraire cela obligatoire.
• l’identification de l’utilisateur se fait avec des moyens divers (Active Directory, OpenId, base de données, …) de manière transparente pour l’application (c’est intégré à l’identification traditionnelle .NET)
• on peut uploader dans le Cloud public les données publiques de l’entreprise à publier, voire la logique l’accompagnant. On cloisonne ainsi bien les données privées, qui restent chez moi, et celles publiques, mises à disposition des autres dans Azure (JSON, AtomPub).

Comment se préparer

Si l’application est du type serveur web + base de données, il n’y a pratiquement pas de travail pour la porter sur Azure.

Par contre, si on utilise d’autres sources de données, comme des fichiers, c’est plus compliqué. Pour les fichiers, mieux vaut utiliser:

SorageHelper.GetContainer()
RoleEnvironment.GetLocalStorageResource()

Inconvénient: cela ne marche que pour du stockage temporaire: c’est perdu en cas de plantage, et ça peut subir de la répartition de charge.

Sinon, il y a le cloud storage pour stocker:

• Blobs (données)
• Queues (messages): adapté pour des logs, par exemple, là où un Blob prend trop de ressources si on fait des ajouts
• Tables

Inconvénient: il faut utiliser des API spécifiques pour y accéder, notamment parce que c’est du HTTP.

Gérer un déploiement

Dans une démo, on peut déployer via le portail en uploadant le package réalisé par Visual Studio. Mais en pratique c’est lourd en manips et ça prend environ 15 minutes.

En pratique, pour éviter ça:

• Grâce à l’identifiant unique Azure on peu automatiser le déploiement. Pour cela il faut un certificat dont on fournit juste la clé publique (même un certificat généré personnellement fonctionne).
• CloudBerry Explorer permet une vue à la Norton Commander

Quand on fait F5 dans Visual Studio, on a un environnement Azure local pour simuler un DataCenter. Mais un vrai DataCenter est un peut différent. Le programme “Azure Diagnostic Manager” permet d’en savoir plus sur ce qui s’est passé dans Azure.

Autre façon d’avoir des informations: activer IntelliTrace, qui recueille énormément d’informations.

Instrumenter l’application est une bonne idée, car avec le Cloud on n’a pas assez d’informations. L’instrumentation permet de comparer ce qui se passe côté Cloud et côté serveur.

Comme on n’a pas de garantie sur l’odre de déploiement, il va falloir ajouter du code d’initialisation qui déploie le bouts d’infrastructure nécessaires s’ils n’y sont pas déjà.

Spécificités Sql Azure

Il est pratiquement comme Sql Server, mais:

• il est “loin” du code: si on enchaîne 80 petites requêtes, ça ne fonctionne pas bien.
• une surveillance constante de notre serveur SqlAzure est effectuée contre les attaques, qui coupe l’accès au serveur: si on ne respecte pas des bonnes pratiques de développement, on aura des surprises.