L’équipe MSDN/Partenaires vient de publier un article très complet sur les raisons qui pourraient pousser (ou non) à utiliser Azure, à lire absolument si vous réfléchissez à faire le grand saut :

http://blogs.msdn.com/b/editeurs_de_logiciels/archive/2011/04/08/les-bonnes-questions-224-se-poser-avant-de-se-lancer-sur-windows-azure-partie-1.aspx?utm_source=twitterfeed&utm_medium=twitter

Ce billet est fait partie de la série “Migrer un application vers Windows Azure”.

L’une des plus grosses différences entre Azure et les modèles classiques d’hébergements, ou même d’autres hébergements “Cloud” tels qu’Amazon EC2, tient en peu de chose : il s’agit tout simplement de l’orientation application de Windows Azure. Fidèle à sa réputation de developper-friendliness, Microsoft ne propose pas un environnement où vous louez des serveurs et où vous devez vous débrouiller pour y faire tourner vos programmes : vous louez en fait un environne-ment pour votre application et la puissance de calcul qui lui est nécessaire.Si le résultat est finalement le même : avoir votre application qui tourne sur des serveurs, la façon de procéder sera quelque peu différente.

Architecture d’une application

Une application pour Azure est composée, comme toutes les autres applications, d’un  ou plusieurs module(s) – le terme Azuréen est “rôle” – qui s’occupe(nt) d’effectuer un service. On peut prendre l’exemple d’un site de réservation de chambres d’hôtels, composé d’un front-office permettant au client de chercher un hôtel et de passer sa commande et d’un ensemble de traitements batch qui traitent les réservations, envoient les mails de confirmation, etc.

Si vous réalisez ce site en architecture classique, vous obtiendrez probablement le schéma d’architecture suivant :

Nous avons, volontairement, mis de coté l’option « tout sur le même serveur » : si votre service est suffisamment petit pour correspondre à ce type d’architecture, vous ne serez probablement pas intéressé par Azure.

Sur Azure, pas de révolution, on retrouve quasiment la même chose :

Les choses deviennent plus intéressantes si votre site devient important en terme de fréquentation ou de volume d’information. Vous serez alors amené à mettre en place plusieurs serveurs avec des systèmes de répartition de charge et des copies de sauvegardes synchronisées pour fournir la tolérance aux pannes. Le schéma se complexifie pas mal en mode « classique » :

Du cote Azure, par contre, ces services sont fournis par la plateforme, vous n’aurez donc pas les gérer. Mettre en place plus de puissance de calcul se résume à demander plus d’instances du rôle concerné (via le portail d’administration ou un fichier de configuration) à la plateforme : Azure se charge automatiquement du LoadBalancing et du FailOver. Le schéma reste donc le même :

Les différents rôles disponibles

Lorsque vous développez une application Azure, vous pouvez utiliser une combinaison de trois types de rôle :

• Les web-roles correspondent aux applications web, tournant sous IIS. Il peut aussi bien s’agir de véritables sites que d’applications proposant des web services.
• Les worker-roles sont simplement un environnement dans lequel est exécuté votre code, sans l’intervention d’IIS ou de tout autre serveur externe. On pourrait résumer en disant qu’il s’agit d’un environnement faisant tourner un exécutable.
• Et finalement les VM-roles permettent de faire tourner votre propre machine virtuel dans Azure.

Pour chacun de ces rôles, vous pourrez déterminer (et modifier dynamiquement) la puissance de calcul disponible mais il est important de noter que chaque rôle correspond à au moins une instance, et donc à une facturation du temps d’exécution. Si vous avez plusieurs sites (par exemple un site “front-office” pour le public et un “back-office” pour les administrateurs) ou plusieurs “services applicatifs”, il vous faudra déterminer s’il vaut mieux séparer ces derniers en rôles distincts pour améliorer la flexibilité ou au contraire les regrouper pour minimiser les couts.

Cet article est (principalement) un résumé d’un billet de Ryan Dunn, datant d’il y a quelques mois.

Si vous développez sur Azure, et que vous y faites tourner des WebRoles, vous avez dû vous lamenter sur la longueur des déploiements. Si cela ne pose pas vraiment de problème lors de la phase de production, il arrive toujours un moment où “l’émulateur” fourni dans le SDK n’est plus suffisant et où l’on a besoin de pouvoir tester ses déve-loppements sur un véritable environnement Azure. Patienter entre 15 et 30 minutes après chaque modification pour en voir le résultat n’est pas particulièrement une bonne idée, surtout quand on est en train de finaliser une version.

Depuis la version 1.3, et l’ajout du support complet de IIS, il existe une autre solution : en utilisant le protocole WebDeploy que vous utilisez – peut-être  – déjà pour vos déploiements Web habituels. Avant de vous expliquer comment faire, précisons tout de même que cela n’est prévu que pour des environnements de test, et que ce n’est absolument pas prévu pour votre version de production et que vous devrez respecter certaines conditions pour que cela fonctionne :

• votre rôle devra être déployé sur une seule et unique instance
• vous devrez avoir activé l’accès à distance pour ce rôle (les identifiants du compte RemoteAccess seront utilisés par WebDeploy)

Une fois ces quelques limites connues, le principe est extrêmement simple, grâce à un petit add-in réalisé par Ryan Dunn :

• Téléchargez le fichier ZIP qu’il met à disposition sur Skydrive
• Décompressez le dans le dossier %ProgramFiles%\Windows Azure SDK\v1.3\bin\plugins\. Vous devriez déjà trouver dans ce dossier des plugins pour RemoteAccess et Diagnostics
• Editez ensuite le fichier ServiceDefinition.csdef de votre projet Azure pour ajouter une nouvelle ligne dans la section Imports, afin qu’elle ressemble à ceci :

  <Imports>
    <Import moduleName="RemoteAccess" />
    <Import moduleName="RemoteForwarder" />
    <Import moduleName="WebDeploy" />
  </Imports>

   

• Déployez votre rôle comme d’habitude.

Une fois ces quelques étapes faites, vous devriez avoir une instance active de votre rôle et le service d’administration à distance activé sur celui-ci. Il ne reste plus qu’à s’en servir :

• Cliquez sur “Publier” pour le projet web concerné. Attention, ne faites pas “Publier” sur le projet Azure, mais bien sur le projet Web, sinon vous êtes repartis pour un tour de déploiement complet.
• Dans l’écran de publication, choisissez la méthode WebDeploy, saisissez le nom DNS de votre service dans l’Url du service
• les informations de connexion sont celles de votre utilisateur RemoteAccess
• Cochez la case “Autoriser des certificats non approuvés”
• pour le champ “site/application”, c’est un tout petit peu plus compliqué : il vous faudra le nom de l’instance, que vous trouverez dans le portail d’administration Azure :

  ainsi que le nom de votre site dans cette instance, que vous trouverez dans le ServiceDefinition.csdef :

  <Sites>
    <Site name="Web">
      <Bindings>
        <Binding name="HttpIn" endpointName="HttpIn" />
      </Bindings>
    </Site>
  </Sites>

   

  Il ne vous reste plus qu’a combiner les deux avec un “_” pour obtenir le nom de votre application, dans l’exemple ci-dessus nous aurions donc le nom de site/application “ECommerceSite_IN_0_Web”

Voila ! Avec ces quelques manipulations, vous pourrez effectuer des déploiements BEAUCOUP plus rapidement. Pour terminer, sachez aussi qu’en cas de déplacement de votre instance (par exemple en cas de maintenance du serveur physique sur lequel vous êtes hébergé), votre rôle sera, bien entendu, redéployé à partir de l’archive d’origine et que tous vos déploiements par WebDeploy seront perdus.

Puisque les vitrines interactives et le digital signage sont de plus en plus un sujet à la mode (à ce propos, ne manquez pas le blog connected-store des excellentissimes membres d’Improveeze), voici une mini-video sur une vitrine interactive piloté par Kinect :

Depuis quelques temps, et en marge des développements principaux, nous procédons à la migration de notre application principale vers Windows Azure. S’il s’agit pour nos clients hébergés d’une opération transparente, le fait de ne plus avoir à gérer tout la couche système devrait être une vraie avancée pour nous !

Pour ceux d’entre vous qui ne connaitraient pas encore Azure, commençons par un petit tour d’horizon de l’un des derniers ajouts à la panoplie des produits Microsoft. Windows Azure (et ses services complémentaires comme SqlAzure, AzureConnect, etc.) est un système de Platform As A Service, c’est à dire qu’il s’agit d’un environnement, hébergé dans les datacenters de Microsoft, où vous pouvez déployer des applications sans avoir à vous soucier d’administrer le ou les serveurs sur lesquels elles tourneront. Ce qui différentie Azure des solutions hébergées classiques, c’est qu’il est vraiment orienté "hébergement d’applications" et qu’il intègre donc, de façon totalement transparente – ou presque – des services tels que LoadBalancing, FailOver (sous conditions), ou encore un CDN.

Mettre le focus sur l’application, et non sur les ressources physiques a quelque chose d’assez magique : votre service connait des périodes d’utilisation intense de façon périodique ? Aucun problème : provisionnez plus de serveurs pendant ces pointes de consommation et rendez-les quand ils ne vous servent pas ! De part son architecture totalement virtualisée et sa configuration gérée par application, les serveurs deviennent une ressource comme une autre, librement allouables ou desallouables. De la même façon, si votre "petite application" connait d’un seul coup un essor exceptionnel, vous pourrez facilement ajouter de nouvelles ressources pour gérer cette augmentation de trafic.

En omettant volontairement Azure Marketplace, l’AppStore Azure (j’y reviendrai peut être d’ici quelques temps, lorsque nous y serons éventuellement présents), Azure se découpe en trois grandes partie :

- d’abord, bien évidemment, Windows Azure, dont le rôle est de vous proposer un service d’exécution de votre application dans les nuages : instances "matérielles", OS et plateforme applicative et environnement de stockage. le tout est bien entendu fourni une architecture vous permettant la montée en charge

- SQL Azure, est le système de base de données relationnelle pour la plateforme. il est bien entendu tolérant au pannes et est de plus équipé d’un firewall qui peut le rendre accessible aussi bien à une application azure qu’à vos applications on-permise.

- Azure AppFabric est un ensemble de services applicatifs que vous pouvez utiliser dans vos applications et qui vous permettent, par exemple, d’établir un canal de communication vers une application se trouvant dans votre environnement privé, ou de gérer un cache de données.

Parlons un peu technique maintenant : Azure est un environnement Microsoft. Vous y trouverez donc les technologies habituelles : le système d’exploitation est une version probablement quelque peu personnalisée de Windows Server 2008, IIS et les technologies .net sont donc à votre disposition immédiate. Si vous êtes plutôt orientés Java ou PHP, ne partez pas tout de suite : Microsoft propose des "accélérateurs" vous permettant aussi de déployer vos applications.

Pour la partie base de données, Sql Azure est assez proche de celle de son parent on-permise, SqlServer. A l’exception de quelques spécificités, et d’un certain nombre de fonctions non disponibles, la très grande majorité des commandes T-SQL que vous auriez pu utiliser dans vos applications sera supportées. Il est par contre à notre que les modules complémentaires tels que SSIS, Reporting Services ou encore Analysis Services ne sont pour l’instant pas disponibles.

Je ne m’hasarderai pas à vous parler de la partie financière, si ce n’est pour vous dire que vous paierez véritablement que ce que vous consommerez (sans engagement, sauf offres promotionnelles), justement parce que votre facturation dépendra vraiment de vos besoins. Par contre, ne nous voilons pas la face : si le prix du service est à priori raisonnable pour y faire tourner une véritable application, il n’est pas vraiment adapté à, par exemple, l’hébergement d’un blog ou d’un site vitrine d’entreprise, à moins d’être extrêmement populaire. D’ailleurs, à quoi pourrait bien vous servir toutes les fonctionnalités de la plateforme pour ce genre de sites ?

Pour en savoir plus sur la plateforme Azure, je ne peux que vous conseiller d’aller faire un petit tour sur www.windowsazure.fr.

Petite démo assez sympa d’une interface intelligente en provenance des labos de Microsoft Research :

On y retrouve une idée assez sensationnelle pour une maison intelligente : détecter ce qui devrait vous intéresser le plus et s’adapter en fonction de vos gouts / activités / rendez-vous etc. Cela devrait me donner pas mal d’idées pour continuer ma solution domotique.

Bien que cela date déjà de quelques mois, les Templates Illustrator de Clarity consulting sont d’une telle utilité qu’il est impossible de ne pas en reparler !

Vous y trouverez, en plus des polices Segoe UI WP, tous les outils pour vous permettre de prototyper rapidement votre application dans Illustrator : des kits pour préparer vos Pivots et Panoramas, des exemples de textes formatés selon les principaux styles de la plateforme et même les icônes principaux pour vos barres.