Migrez votre application ASP .Net sous Windows Azure

La plateforme Windows Azure est l’offre cloud de Microsoft qui permet d’héberger et d’exécuter différents types d’applications et de services. Deux ans après son lancement, cette solution PaaS est, désormais, complète et propose des services de haut niveau. Il est donc temps de s’intéresser à la question de la migration des applications .Net et ASP.Net sur le cloud à la Microsoft.

Planifier la migration

Attrayante et parfois très simple à faire, la migration a néanmoins un coût et il faut bien s’assurer de la rentabilité de ce choix. Toutefois, si ce choix est fait, la migration nécessite une planification qui doit répondre à des questions telles que: Mes applications peuvent elle être migrées vers le cloud? Quel type de machines est nécessaire pour héberger et exécuter mon application?

L’outil Microsoft Assesment Planning Toolkit (MAP Toolkit actuellement en version 5.5) donne des premières réponses à ces questions. En effet, cet outil permet de se connecter à un réseau donné (ou d’en explorer un via Active Directory) et de vérifier la portabilité vers le cloud de chacun des services/applications du réseau. Ensuite, il fournit un rapport avec la liste des machines estimées équivalentes dans le cloud. Toutefois, il faut faire attention puisque cet outil a tendance à sous-évaluer le nombre de coeurs des machines lors de ses estimations.

Stockage dans le nuage

La première étape consiste à migrer vos données. Là encore il faut se poser les bonnes questions.

Y a t-il besoin d’une base de données (“relationnelle”)? Si la migration doit se faire vers un SGBDR, la solution dans le cloud sera SQL Azure.

Si l’aspect relationnel n’est pas requis, des solutions NoSQL existent dans Windows Azure telles que les Tables ou les Bobs. Notons pour certaines applications (comme c’est déjà le cas on-premise), il y a besoin d’opter pour les deux solutions.

En ce qui concerne la migration vers SQL Azure, celle ci se fait en deux étapes:

la première vise à migrer le schéma de la base de données. L’outil SQL Azure Migration Wizard est la solution correspondante si votre base de données est de type SQL Server 2005/2008. Pour les bases de type Oracle, Sybase, Access ou encore MySQL, l’assistant SQL Server Migration Assistant (SSMA) devra être utilisé. Certaines fonctionnalités n’étant pas encore supportées par SQL Azure, la migration du schéma risque d’être partielle.

La seconde étape, une fois le schéma migré, consiste en la migration des données avec des outils ETL classiques en sql server tels que BCP, SSIS ou avec un script et de simples requêtes INSERT (attention alors au coup des transaction). Afin de valider le résultat de cette étape, il est possible de modifier les connectionString des applications, encore installées à demeure, pour les faire pointer sur les bases de données SQL Azure.

Serveurs Web dans le nuage

La partie stockage étant migrée, il faut enchaîner avec vos applications avec l’assistance de Visual Studio. Le SDK Azure (actuellement en version 1.4) doit être installé, il faut utiliser le type de projet VS WebRole qui apporte le template et les assemblies nécessaires pour l’hébergement et l’exécution des applications ASP.NET.

La migration n’est possible que pour les solutions Web Applications et non pas pour les solutions Web Site puisque le WebRole ne supporte pas le Web Site. Néanmoins, la conversion d’une solution de type Web Site vers une Web Application est possible.

Attention: si l’application référence des bibliothèques que vous avez ajoutées ou encore des bibliothèques qui sont enregistrées dans le GAC, il faut tout d’abord ajouter explicitement ces références et toutes leurs dépendances à votre application. Ensuite, pour chaque référence, il faut positionner la propriété “Copy Local” à True. Cette opération copiera les DLLs référencées par le projet dans le répertoire Bin du package nécessaire au déploiement sur Azure.

Une fois le WebRole ajouté à votre solution, il faut le paramétrer pour indiquer le nombre d’instances sur lesquelles sera deployée et executée l’application. Il est aussi possible de choisir la taille de la machine virtuelle entre Extra Small, Small, Large et Extra Large.

Il ne reste plus qu’à envoyer votre application dans les nuages. Le déploiement dure quelques minutes. Cette durée est impactante dans une phase de développement .Pour remedier à cet inconvénient, l’emploi de l’émulateur (non) ou de la solution WebDeploy qui déploie les modifications de manière itérative sont à pribilégier. Cette option (laquelle) n’est cependant pas préconisée pour des livraisons finales.

Si, en plus, votre application nécessite en plus un traitement en batch ou une tâche de de fond comme la génération de fichiers PDF, le traitement d’images ou encore de gros calculs, la solution correspondante avec Azure est le WorkerRole. La communication avec le WorkerRole se fait via des endpoints HTTP, HTTPS ou TCP. De même que pour le WebRole, le paramétrage se fait en indiquant le nombre d’instances d’exécution et la taille de la VM.

D’un environnement à un autre

L’application est maintenant dans les nuages mais qu’en est t-il de son cycle de vie? Après la phase de tests, comment publier l’application sur d’autres environnements?

Le scénario le plus commun est de disposer de deux environnements séparés : un pour les tests et un pour la production. Les environnements n’auront donc pas les mêmes restrictions d’accès et pourront être utilisés simultanément. De plus, ça permettra d’identifier les coûts spécifiques à chaque environnement.

Parallèlement, le service d’hébergement Azure offre, pour un même environnement, deux espaces: staging et production. Et il est donc possible de déployer son application sur l’espace staging, valider la version déployée et enfin la déployer sur l’espace production. Il est même possible de faire un swap entre les versions déployées sur les deux espaces. Cette fonctionnalité est très utile s’il y a besoin de faire un rollback sur une version récemment déployée en production.

Le déploiement sur différents environnements implique, souvent, l’utilisation de configurations différentes. En fonction de l’application, cela peut aussi nécessiter plusieurs opérations qui durent longtemps. D’où le besoin d’automatiser les différentes opérations du déploiement. MSBuid et les CDMlets de PowerShell constituent une réponse à ce besoin.

Exploitation / Supervision

Une application déployée dans les nuages n’échappe pas à la règle et reste concernée par les besoins d’exploitation et de supervision. Dans le contexte d’une application Azure, la supervision est possible pour les deux rôles: WebRole et WorkerRole. Elle se base principalement sur les informations suivantes :

• Des logs : Logs Azure, Windows Events Logs, IIS…
• Des compteurs de performance

Ces informations peuvent être stockées sur Azure ou encore surveillées à distance via des outils comme System Centrer Operations Manager (SCOM) de Micrososft grâce à un pack spécifique Azure.

Dans le nuage mais aussi dans le SI

Certaines entreprises auront le besoin (ou la contrainte) de garder à demeure certains services de leur SI. Pour ces cas particuliers, Azure apporte son lot de solutions:

• Service Bus : brique de Windows Azure AppFabric qui assure la communication entre des services / applications dans le cloud et en entreprise
• Access Control: autre composante de Windows Azure AppFabric qui met en oeuvre la fédération de différents types d’identités tel que Windows Live ID, Google ou Facebook. Active Directory est supporté aussi pour les entreprises.
• Windows Azure Connect: apporte une connectivité au niveau de la couche réseau IP entre les ressources Azure et on-premise.

.Net et ASP.Net, C’est tout ?

L’offre Azure est riche et propose des solutions pour la majorité des scénarios de migration. Pour des besoins plus spécifiques, Microsoft propose dans la version commerciale 2011 d’Azure des nouveautés telles que le VM Role (machine virtuelle personnalisée) ou encore l’activation de l’accès distant (Remote Desktop). D’autres améliorations portent sur l’intégration des langages Java et PHP. En effet, Azure propose d’héberger et d’exécuter ces deux langages en plus de Ruby. Alors qu’en est t-il de la migration des applications basées sur ces langages?