Migrer ses applications sur Windows Azure

Note: ceci est mon résumé de la session des TechDays 2011, pas mon avis.

Par Michel Hubert et Jérémie Devillard, de Logica.

Préparation

Microsoft Assesment Planning Toolkit permet de vérifier techniquement la portabilité des applications existantes vers le cloud. Il trouve notamment les serveurs de bases de données, les applications Web, et les performances des machines. Il produit des rapports et indique notamment les estimations de machines équivalentes sur Windows Azure dont on aura besoin.

Les différents rôles

Chaque rôle est l’équivalent d’une machine virtuelle:

• Web Role: héberge un serveur IIS (NDLR: PaaS)
• Worker role: exécute une tâche de fond (équivalent d’un service Windows) (NDLR: PaaS)
• VM Role: machine virtuelle, dont je dois moi-même configurer et maintenir l’OS (NDLR: plutôt IaaS)

Note: le VM role est récent, et pour l’instant il n’y

a pas de système de snapshot.

La migration

Stockage des données

Choisir la bonne solution entre Tables (non relationnelles), Blobs (conteneurs de documents) et SQL Azure (si besoin de SGBDR).

En cas de migration vers SQL Azure il faut vérifier la compatibilité syntaxique de la base. Puis 2 étapes de migration: d’abord le schéma (SQL Azure Migration Wizard, ou alors SQL Server Migration Wizard si la base était MySQL, Access, Oracle, Sybase), puis les données (BCP ou SSIS mais il y en a d’autres) (NDLR: voir les autres outils sur CodePlex).

Frontal Web

Le déploiement vers Azure est long. On commence donc par un développement local avec l’émulateur. Puis un premier déploiement (environ 15 minutes). Après le premier déploiement, Web Deploy (Publish/Web Deploy depuis Visual Studio) permet de déployer rapidement les modifications de manière itérative. Au final, il faut refaire un déploiement complet car Web Deploy n’est pas fait pour la livraison finale.

Cycle de vie

L’application est publiée dans l’environnement de tests. Après tests par l’équipe locale, l’administrateur est responsable de publier dans l’environnement de production.

D’un point de vue des coûts, on peut dé-commissionner l’environnement de tests une fois la publication effectuée.

Le déploiement peut être automatisé avec MSBuild ou des CMDlets de PowerShell.

Supervision / Exploitation

On utilise:

• compteurs de performance
• logs: spécifiques Azure, IIS 7, Failed requests, … (il suffit de les paramétrer dans Azure)
• System Center Operations Manager, grâce à un Management Pack spécifique pour Azure: on unifie ainsi le S.I. local et Azure

Intégration au S.I.

Plusieurs possibilités:

• AppFabric: Service Bus (intégration des données) et Access Control (fédération d’entités: profils, autorisations)
• SQL Azure Data Sync pour synchroniser avec une base locale
• Windows Azure Connect qui permet d’être en VPN avec le S.I. local

Fin du résumé.

Vous pouvez aussi assister à une formation Windows Azure.