Techdays'09 : Microsoft explique Azure en détail

C'est l'inconvénient avec les concepts à la mode : lorsqu'une technologie s'en réclame, tout ou presque peut être dit pour la définir, les notions de 'cloud' et de 'Saas' (Software as a service) se mélangeant allègrement. C'est ce qui est arrivé avec Azure, le « Windows dans les nuages » de Microsoft, dévoilé en octobre dernier et actuellement dans sa phase 'preview'. Si bien que les développeurs, mais aussi des décideurs IT et des administrateurs systèmes se sont pressés dans les sessions consacrées à Azure lors des Techdays, 3 jours de conférences gratuites organisées par Microsoft France, et auxquelles se sont inscrites près de 16 000 personnes, indique l'éditeur. L'une des sessions sur Azure, animée par deux architectes de Microsoft France, Stève Sfartz et Régis Mauger, reprenait ainsi tranquillement les fondamentaux de ce qu'est, ou n'est pas, Azure. Un distinguo à opérer entre les services Azure et la plateforme Azure D'abord, il faut distinguer la plateforme Azure des services de la plateforme Azure. La première est « un système d'exploitation dans le nuage », qu'il convient de voir comme « une troisième plateforme de déploiement, après la plateforme client (desktop/mobile) et la plateforme serveur ». Stève Sfartz a d'ailleurs insisté sur cette continuité: « C'est un continuum, vous restez dans un environnement de développement connu. » A côté de ce Windows Azure - l'offre de 'cloud computing en tant que telle -, figurent des services complémentaires, apportés des applicatifs Microsoft hébergés : la manipulation de données avec des services SQL Server, par exemple, ou le transactionnel avec des services Biztalk. Le fait d'avoir proposé en même temps ces services applicatifs en ligne - qui s'apparentent au Saas - a largement contribué à la confusion initiale. Le déploiement dans Azure repose sur le téléchargement de deux fichiers La plateforme Azure - sans ces services - est donc un environnement de déploiement d'applications créées avec Visual Studio, l'atelier de développement de Microsoft, dûment secondé du SDK (kit de développement) Azure. Une fois que le développeur a créé son compte dans Azure, la publication des programmes dans ce Windows hébergé est simplissime : l'outil crée deux fichiers, un package de l'application et un fichier de configuration XML, qu'il suffit de télécharger depuis la page d'accueil de son compte Azure. Nul besoin de se préoccuper, lors de la création du programme, du fait que cela tournera sur une machine virtuelle, ou des capacités de montée en charge. « La gestion des ressources est transparente pour vous », explique Régis Mauger. Tout est géré par ce que Microsoft appelle « la fabrique ». C'est elle qui alloue les capacités (en fonction du nombre d'instances déterminé dans le fichier de configuration), gère l'équilibrage de charge, la récupération en cas d'incident, la réplication de données... « Votre code sera capable de supporter la charge, quelle qu'elle soit » La version de prévisualisation d'Azure permet aujourd'hui de monter jusqu'à deux instances ; dans la version finale, l'éditeur du logiciel déterminera librement le nombre d'instances dont il pensera avoir besoin - sachant que cela pourra évoluer à la hausse ou à la baisse. « Votre code sera capable de supporter la charge, quelle qu'elle soit », assure-t-on chez Microsoft. La seule contrainte sera la tarification. Celle-ci n'est pas encore finalisée, mais on sait déjà que comme toute offre de cloud, le coût grimpera en fonction des ressources utilisées. D'où l'intérêt, soulignent les architectes, de tout de même bien optimiser le code, pour qu'il consomme le moins de ressources possibles. L'application tournant dans Azure dispose de sa propre URL (avec une terminaison en cloudapp.net, qui peut être masquée à l'aide d'une redirection), et peut communiquer avec d'autres services accessibles en ligne, grâce aux protocoles Soap ou Rest. Des tables, des queues et des Blobs dans le « cloud storage » d'Azure Les données que l'application doit manipuler sont stockées dans le « cloud storage » d'Azure, qui peut prendre trois formes : des tables, des files d'attente de messages et des blobs (Binary large objects, containers pour stocker de gros fichiers binaires, comme des photos ou des vidéos). Chacun de ces formats dispose d'une URL distincte, permettant au développeur d'y accéder librement. Quelques outils, dont un est fourni en guise d'exemple dans le SDK d'Azure, donnent la possibilité de manipuler plus facilement ces données (dont le total est limité à 50 Go dans la 'preview'). Des traitements sur ces données peuvent être effectués de façon asynchrone, dans le nuage, « l'équivalent d'un traitement batch », précise Stève Sfartz. La grosse difficulté aujourd'hui concerne le débogage des applications. Certes, Azure dispose d'un mode 'préproduction', pour y faire tourner une application avant de la mettre en production, mais on ne peut y déboguer un programme. Il faut donc faire le maximum de tests en local, sachant que le SDK reproduit en local la « fabrique ». Dans ce cas, les données sont stockées dans une base SQL Express, mais il est possible de les charger dans Azure, et d'utiliser un outil tiers comme Fiddler pour examiner les flux, afin d'identifier les points de l'application posant problème. Autre limitation imposée aux développeurs : dans la mesure où Azure s'appuie sur la version 7 du serveur Web IIS de Microsoft, le travail de conception doit s'effectuer sur Vista ou Seven, XP n'étant pas compatible avec IIS 7. Au final, les choses sont donc plutôt claires, mais cela pourrait se complexifier à l'avenir, avec le support de langages natifs, et la possibilité de déployer dans Azure ses propres machines virtuelles.
>>Toutes les actualités de la rubrique Services<<