Windows Azure

Windows Azure [14] est l’offre de cloud proposée par Microsoft. Cette offre est constituée d’un ensemble de services correspondant tant à la fourniture de VMs qu’à la fourniture d’intergiciels. Ces services se répartissent de la façon suivante :

• Les sites web Windows Azure. Il s’agit d’environnements de déploiement d’applica-tions web Node.js, Java, PHP, ASP.NET, Python et Ruby. De façon globale, toute application acceptée par le serveur Microsoft Internet Information Services (IIS). Ce service vise avant tout le déploiement rapide d’applications en cours de déve-loppement. Windows Azure Web Sites s’interface effectivement avec des logiciels de gestion de version ou d’hébergement de code tels que Git, Mercurial, bitbucket ou encore CodePlex.

• Les rôles applicatifs sont des environnements de déploiement permettant un contrôle plus fin à l’utilisateur que les sites web Windows Azure. Ils en existent deux sortes :

– Les Web Roles sont des VMs appelées instances dont le système d’exploitation est Windows Server 2012. Ces VMs embarquent un serveur IIS actif. Les Web Roles permettent à une application d’exposer une interface web.

– Les Worker Roles sont des VMs dont le but est d’effectuer des traitements pour les applications. Leur usage convient notamment au tiers métier d’une application web multi-tiers. Il ne diffèrent des Web Roles que par l’inactivation par défaut de IIS (qui peut malgré tout être réactivé par l’utilisateur). Ces rôles applicatifs offrent l’avantage d’être redémarrés aussitôt que la plateforme Azure détecte leur panne. En revanche, il s’agit de VMs sans état : à chaque démar-rage, l’image virtuelle est vierge de toute donnée issue d’un démarrage précédent. La persistance doit être assurée par le recours à des services de stockage de la pla-teforme Azure. Enfin, l’image de ces VMs est maintenue par Microsoft qui ajoute régulièrement des mises à jour.

• Les Virtual Machines sont des VMs avec état laissant un contrôle total à l’uti-lisateur. Elles peuvent aussi bien embarquer un système d’exploitation Microsoft qu’un Linux. Le maintien des images est à la charge de l’utilisateur.

L’ensemble de ces services peut avoir accès à des services de stockage fournis par Win-dows Azure pour assurer la persistance des données. Les services de stockage com-prennent :

• Un service de base de données relationnelle nommé SQL Database.

• Un service de base de données non-relationnelle NoSQL. Il s’agit de tables asso-ciatives clé-valeur.

• Un service de stockage sous forme de blobs. Ce sont des blocs de stockage d’in-formations binaires qui peuvent permettre de créer des périphériques de stockage embarquant un système de fichier pour les VMs.

3.3. SOLUTIONS DE GESTION COMPLÈTE DE L’ÉLASTICITÉ 57 Enfin, d’autres services ciblent des besoins plus spécifiques tels que Windows Azure Service Bus, un intergiciel de communication par messages ; HDInsight un service de calcul distribué basé sur Hadoop ; ou encore Windows Azure CDN qui est un service de livraison de contenu.

Modèle d’application

Une application s’exécutant dans le cloud Microsoft Azure est issue de la composition des services offerts par la plateforme.

Microsoft offre un large catalogue de gabarits d’environnements au niveau de son services Web Sites. Ce catalogue contient des gabarits pour des environnements de sys-tème de gestion de contenus très populaires tels que WordPress ou Drupal. Ce catalogue contient également des gabarits pour des canevas de prototypage rapide tels que Node.js ou Django.

Opérations d’élasticité couvertes

La gestion de l’élasticité est opérée en trois points distincts. Le premier est intégré à la plateforme (Autoscale) tandis qu’un deuxième est un outil additionnel que l’utilisateur doit déployer et configurer lui-même (WASABi). Par ailleurs, à l’instar de la base de donnée relationnelle, Windows Azure offre des services élastiques. Toutefois, le contrôle sur ces services est faible puisque géré automatiquement par la plateforme.

Autoscale permet l’élasticité automatique des services Azure. Il offre la possibilité de définir les cardinalités minimales et maximales du nombre de VMs. il permet éga-lement de définir des politiques de prises de décision s’appuyant soit sur des métriques de surveillance, soit sur des planifications temporelles. L’équilibrage de charge se fait au niveau des flux réseau.

WASABi est un outil plus ancien qui permet toutefois une plus large gamme d’opéra-tions. Il ne permet cependant de gérer que des rôles applicatifs. De façon globale, il peut être considéré comme un canevas de développement servant à l’élasticité dans Windows Azure. WASABi permet de définir des politiques de décision similaires à celles admises par Autoscale mais permet également à l’utilisateur d’en définir de nouvelles. WASABi permet de définir des priorités à appliquer entre les règles de sorte à pouvoir opérer une conciliation lors de l’exécution. En fonction de la règle à appliquer, des opérations sont planifiées. Ces opérations permettent notamment d’ajouter ou de retirer des VMs mais également de modifier des paramètres applicatifs. Un cas d’usage du dernier point est la mise en place d’un mode dégradé d’une application web lorsque la charge des serveurs est trop importante. Ce scénario est particulièrement adapté pour continuer à offrir un service dans l’attente du démarrage de nouvelles instances.

Architecture applicative

Windows Azure n’offre pas d’architecture applicative à proprement parler, tant durant l’exécution que lors de la spécification de l’application élastique. L’architecture est

ef-fectivement implicite et restreinte aux applications multi-tiers. Une pseudo-vision des liaisons applicatives est proposée au niveau de la spécifications des ports réseau d’entrée et de sortie des rôles applicatifs.

Gestion du placement

Concernant Autoscale, l’utilisateur peut uniquement définir une région d’exécution. L’utilisateur peut également définir les profils des VMs sous-jacentes. Ce profil est fixe, hormis pour les Windows Azure Web Sites qui permettent un redimensionnement dyna-mique des conteneurs d’exécution à chaud.

Avec WASABi, les mêmes paramètres peuvent être gérés. WASABi ajoute cependant la possibilité d’effectuer des opérations élastiques réparties dans différentes régions. Il se pose alors pour l’utilisateur la problématique de définir et réaliser le déploiement de WASABi au sein de ces régions.

Positionnement par rapports aux critères

• Indépendance applicative. Windows Azure permet l’élasticité de plusieurs types d’applications ainsi que de les composer. Ce critère a une évaluation à Bonne. • L’Indépendance architecturale de Windows Azure est évaluée à Bonne puisque la

solution gère plusieurs types d’architectures et permet de les composer.

• L’Indépendance vis-à-vis de l’environnement est évaluée à Faible car Autoscale et WASABi ne permettent d’accéder qu’au cloud Azure.

• Gestion des applications patrimoniales. La gestion des applications patrimoniales est Bonne puisqu’en fonction de l’application, il peut être nécessaire de modifier une partie de l’architecture de l’application de sorte à permettre l’utilisation des services de la plateforme. Il est par exemple nécessaire pour l’application d’être adaptée à l’équilibrage de charge offert par la plateforme (équilibrage matériel sur des ports réseau) ce qui implique le remplacement des éléments de répartition de charge déjà présents dans l’application.

• Granularité des opérations. La granularité des opérations se situe au niveau de la VM tant pour Autoscale que pour WASABi. Le critère de granularité est donc évalué à Faible.

• Concernant la Modélisation à l’exécution, Windows Azure permet de connaitre la consommation en nombre de VMs instanciées pour chaque application. Il n’est fait mention ni de composant, ni de liaison. Ce critère est donc évalué à Moyen. • La Modélisation de l’élasticité est évaluée à Moyenne en raison du fait que le

comportement élastique de l’application est implicitement décrit par la mention de groupes de VMs et de services consommés.

3.3. SOLUTIONS DE GESTION COMPLÈTE DE L’ÉLASTICITÉ 59 • Expression de contraintes. Autoscale et WASABi permettent l’expression de contraintes

à base de cardinalités sur le nombre d’instances par type de VMs composant l’appli-cation. WASABi se différencie sur ce point d’Autoscale puisqu’il permet d’exprimer des contraintes de placement. Il est possible de répartir des opérations élastiques au sein de différentes régions. Ces contraintes ne sont pas extensibles. L’évaluation de ce critère est Moyenne pour Autoscale, et Bonne pour WASABi.

Le tracé en Orange donne l’évaluation d’Autoscale. Celle de WASABi est illustrée par le tracé de couleur verte. Il est utile de rappeler que WASABi n’est pas directement accessible à l’utilisateur et que celui-ci doit opérer son déploiement.