Au cas où vous ne savez pas ce que c’est, voici un petit résumé (vous pouvez en savoir plus sur Wikipedia et dans sa FAQ):
« La plate-forme de services Azure est une plate-forme d’application dans le nuage (cloud) qui permet aux applications d’être hébergé et géré par les serveurs de Microsoft. Il fournit un système d’exploitation dans le nuage appelé Windows Azure, qui est un environnement pour les applications et fournit un ensemble de services qui permet le développement, gestion et hébergement d’applications gérées en ligne. »
Pratiquement parlant, on l’utilise par la construction et l’emballage d’un site Web, puis l’uploader par le biais du portail d’Azure et après ça, le site est disponible à une adresse du genre: http://MonSiteWeb.cloudapp.net/
Notez qu’il peut être utilisé non seulement pour les applications .NET, mais aussi PHP, Java, Ruby, etc.

En plus de l’hébergement lui-même, la plate-forme Azure comprend également de nombreux services. Je ne citerai que le stockage (pour stocker des fichiers et données non-structurés) et SQL Azure (SQL Server fonctionnant en ligne). Ils ont tous été conçus pour être extrêmement évolutif (gardez cela à l’esprit lorsque vous observer d’étranges limitations).
Microsoft fournit des SDKs pour émuler la plupart de ces services sur votre machine (la « Fabrique de Développement » ou FabDev). Cela rend le débogage plus facile. En théorie, si votre application fonctionne correctement sur votre ordinateur, elle fonctionnera également en ligne (même si, ce n’est pas exactement le cas, pour le moment).

Maintenant, parlons de ce que c’est que de développer pour cette plate-forme.

1. En ligne, Azure vous permet de stocker des données dans des tables Azure. Elles ne sont pas relationnelles. Elles se comportent comme des « sets non typés« , de sorte que vous pouvez mettre n’importe quel objet (de différents types) de la même « table », il n’y a pas de schéma et les tables peuvent être créées à la volée.
La « fabrique de développement » (FabDev) est livrée avec un outil de stockage qui s’appuie sur SQL Server pour émuler le stockage de données. Contrairement à la version en ligne, il possède de nombreuses ennuyeuses restrictions (en raison de sa mise en œuvre basée sur SQL Server): Vous devez exécuter un outil (Devgentable.exe) pour générer les tables où sont stockées vos données. Le plus ennuyeux est que les chaînes de caractères ont une longueur maximale de 1000. Ceci est très petit pour tout travail sérieux. Globalement, cela signifie que profiter des tables Azure comme sets non typés est difficile, car cela rend l’application in-testable localement.
Malheureusement, je ne vois pas comment contourner ce problème. Au mieux, on peut augmenter la taille des chaînes de caractères. Espérons qu’une meilleure mise en œuvre sera disponible bientôt.

2. Comme je l’ai expliqué précédemment, vous devez emballer votre site web pour l’uploader. Cela signifie que, chaque déploiement doit contenir l’ensemble du projet. Cela est compréhensible pour les fichiers binaires, mais cela signifie aussi que vous ne pouvez pas faire un changement rapide de web.config ou une page HTML par exemple. Et je ne veux pas être parmi les gens qui doivent uploader l’ensemble de l’environnement PHP/Java à chaque fois (requis parce qu’ils ne sont pas préinstallés comme .NET).
Ce problème est soluble. Après tout, le stockage d’Azure donne accès aux fichiers individuels, afin de les ajouter/modifier/supprimer. Tout ce dont nous avons besoin, c’est d’avoir accès à la racine Web de la même manière. Notez que, dans les deux cas, la montée en charge est abstraite (il existe de nombreuses copies de des fichiers sur des ordinateurs différents et ils sont gardés en synchronisation).

3. Nous avons vraiment besoin d’une solution pour accéder aux services de stockage d’Azure. Pour le moment, j’utilise AzureStorageExplorer, il est assez bon, mais a de nombreuses lacunes. Il existe des sociétés offrant des solutions plus complètes, mais ils ne sont pas gratuits.

4. Windows Azure a une API pour enregistrer des événements. Cela est vraiment utile pour surveiller un site web. Le problème est l’accès à ces logs. Actuellement, on doit: transférer dans un stockage, attendre, télécharger et, enfin, lire. Nous avons besoin d’une interface web pour accéder aux logs en temps réel!
Ma solution actuelle (mise en œuvre dans mon BlogEngine.NET sur Azure): Tous les journaux sont envoyés par la même API (classe ApplicationEnvironment). J’ai ajouté un StringBuilder statique où je les enregistre et à la fin de chaque demande, je l’enregistre dans un blob Azure (nom du fichier basé sur la date). Ensuite, j’utilise AzureStorageExplorer pour le lire. Je pourrais aussi créer une page Web pour le lire en ligne. Cette solution est primitive, mais elle fonctionne. N’oubliez pas de désactiver ça en production (afin de réduire les coûts).

5. Enfin, le plus irritant problème s’est produit lorsque je débutais. L’application ne démarrais pas du tout. Dans .NET, le débogueur est attaché avant que tout le code soit exécuté, de sorte que toute erreur peut être interceptée et débuggée. Ce n’est pas le cas pour la FabDev. En plus, je ne pouvais même pas lire les logs dans sa console. J’ai donc utilisé le StringBuilder introduit en 4. Je l’enregistre dans un fichier après chaque log:
File.WriteAllText(Path.Combine(HttpRuntime.AppDomainAppPath, "logs.txt"), Logs.ToString());
De cette façon, je pouvais au moins ajouter assez de logs pour finalement savoir où sont les bugs.
Au fait, dans Silverlight, il ya l’évènement Application.UnhandledException qui peut être utilisé pour détecter toute exception non gérée. Ceci est très utile car, avec lui, je n’ai plus à mettre des try/catch/log partout. AppDomain.UnhandledException semble faire le même travail, mais je ne l’ai pas encore testé.

Globalement, j’aime vraiment Azure, considérant les contraintes dues au support de la montée en charge, c’est une bonne plate-forme. Et je comprends qu’il est encore en version bêta/CTP (la version finale est prévue pour Novembre). J’espère que ces commentaires contribueront à l’améliorer.

Au cas où vous n’avez pas jamais entendu parlé de Windows Azure, il s’agit, en gros, d’un service d’hébergement offert par Microsoft. Il diffère des solutions classiques ASP.NET parce qu’il est fait pour supporter une grand montée en charge. Il est donc comparable à Google AppEngine et à Amazon EC2 (avec un support natif pour ASP.NET).

Il existait déjà deux portages de BlogEngine.NET vers Azure: Azure Blog Engine and ZeCloud. Après les avoir testé, j’ai décidé d’en faire un autre pour deux raisons:

– Faire un portage plus facile à maintenir: Les versions actuelles n’ont pas gardé la structure originelle de BlogEngine.NET, ce qui signifie qu’il serait difficile d’incorporer ces nouvelles fonctions.
– Me familiariser avec Azure: Rien de tel qu’un projet compliqué pour approfondir ces connaissances

Processus de portage de BlogEngine.NET vers Azure

ZeCloud as un article détaillé et j’ai suivi un chemin assez similaire. J’ai aussi fait beaucoup d’efforts pour changer la structure au minimum. Il devrait donc être assez facile de la maintenir à jour.

Vous pouvez télécharger le résultat final sur CodePlex: http://kleartouch.codeplex.com/
J’ai inclu un court lisez-moi qui explique comment l’installer.