Windows Azure est la plateforme de Cloud Computing de Microsoft, cela fait maintenant 4 ans qu’elle est officiellement commercialisée, et en ce début d’année les analystes de Gartner l’ont élues en tant que leader sur pour les applications d’entreprise sur une « Platform As A Service ». Ici, nous n’allons pas reprendre entièrement les points énoncés par Gartner, mais nous allons voir pour quelles raisons la plateforme de Microsoft est devenue une référence en tant que « Platform As A Service » entre autre.

Le Cloud Computing a deux PaaS

Bien que Windows Azure soit à la base une plateforme orientées PaaS via ses Cloud Services, elle s’est rapidement diversifiée afin de proposer du IaaS à ces utilisateurs, mais aussi un deuxième système de PaaS qui est présent sous la forme des WebSites. De plus, il existe des briques annexes telles que Windows Azure Mobile Services qui est un Backend As A Service pour la réalisation des applications mobiles avec des SDKs natifs pour iOS, Android, Windows, Windows Phone ou pour des développements multiplateforme avec HTML / JS ou Xamarin.

Revenons aux Cloud Services et aux Windows Azure WebSites, et pourquoi Windows Azure a actuellement deux PaaS. Pour cela, je pense qu’il faut revenir aux bases de la plateforme, c’est-à-dire aux Cloud Services et à leur fonctionnement.

Les Cloud Services sont la fonctionnalité historique de Windows Azure en terme de PaaS, ils sont présents depuis les premières betas, mais cependant ils ont gardés un fonctionnement très similaire depuis ce jour. En effet, si on simplifie la démarche, il suffit de créer un package de son application via les outils Windows Azure puis d’uploader notre package et son fichier de configuration sur la plateforme afin qu’il puisse le déployer. On se retrouve donc avec un déploiement qui prend au minimum 10 minutes entre le temps d’upload du package et la configuration de la machine ainsi que le déploiement de notre package. C’est donc le processus très simplifié d’un déploiement sur le Cloud Services, nous verrons plus en détails comment il est possible de le personnaliser et de l’intégrer dans une usine logicielle d’intégration continue.

Les Windows Azure WebSites quant à eux sont apparus en juin 2012 sur la plateforme, ils offrent un déploiement plus simplifié que les Cloud Services, puisqu’il est possible de déployer simplement notre site web via entre autre un FTP. Il est donc plus facile de déployer notre solution sur un WebSite plus que cela ne met qu’au maximum 5 minutes, puisqu’il s’agit juste d’une copie des fichiers sur le serveur, il est donc possible de faire un différentiel des fichiers et ne déployer que les modifications réalisées entre deux versions. On a donc un système plus souple au niveau du déploiement de nos applications.

Nous verrons par la suite les fonctionnalités de ces deux systèmes de PaaS, quelles sont leurs principales fonctionnalités qui les démarquent à la fois des autres Cloud Computing, et aussi entre-elle.

Une plateforme Microsoft, mais pas que…

Un des aspects qui fait que Windows Azure est une plateforme de Cloud Computing pour tous est bien entendu qu’elle propose différents langages de développement au sein de celle-ci que ce soit en natif avec du PHP, Node.js, Python, du Java, les applications FastCGI et bien entendu du .Net. De plus, si vous voulez utiliser la partie IaaS de la plateforme, il faut savoir qu’elle supporte des OS sous Linux tel qu’Ubuntu, CentOS ou OpenSuse, et de plus un partenariat entre Oracle et Microsoft a été signé pour le support des produits Oracle sur Windows Azure. Microsoft est donc à mon avis en train de faire de Windows Azure son fer de lance pour son ouverture aux technologies qui ne sont pas de chez eux. Bien entendu cette ouverture ne s’arrête pas qu’au support de ces technologies sur leur plateforme, mais aussi une réelle implication dans l’ecosystème. On peut par ailleurs le voir au travers de plusieurs actions de la part du géant américain que ce soit pour sa contribution au noyau Linux, ou de son partenariat dans l’OpenJDK pour Windows Azure. On peut donc dire que Microsoft souhaite que sa plateforme soit utilisée par d’autres personnes que les membres de sa communauté.

Focus sur Windows Azure WebSites

Windows Azure WebSites est le petit nouveau des deux PaaS, en effet il a été annoncé lors de la plénière de la conférence Meet Windows Azure en juin 2012 animée par Scott Guthrie. Par la suite, ce PaaS fut disponible pendant presque 1 année en preview publique afin que chacun puisse l’utiliser et faire ces retours dessus. Et depuis il est disponible de façon globale, mais cela n’empêche pas les nouvelles fonctionnalités d’apparaître très régulièrement afin de toujours améliorer l’expérience sur le Cloud Computing de Microsoft. Nous allons donc voir les principales fonctionnalités de Windows Azure WebSites, ainsi que les dernières nouveautés qui ont grandement enrichie le produit.

Différents niveaux de montée en charge

Lorsqu’on parle de Cloud Computing, on pense très rapidement à la scalabilité de la solution. Pour cela Windows Azure WebSites offre 3 modes qui ont chacun leur intérêt.

Le mode gratuit est un mode qui offre un hébergement sur une seule instance mutualisée avec des quotas d’utilisations restreints. Cependant cette offre est selon moi parfaite pour tout ce qui phase de développement de la solution. Car en effet, il est difficile de laisser un site public en mode gratuit, car outre le fait que les quotas sont limités, il n’est pas possible de mettre un nom de domaine personnalisé sur ce mode ci. On pourrait notamment utiliser ce mode pour héberger une API à condition que ce soit sur un service qui soit très peu sollicité.

Le mode partagé est bien entendu mieux que le précédent puisqu’il offre la possibilité d’avoir plusieurs instances de notre application, jusqu’à 6 maximum.

Le mode standard, et le dernier, offre la possibilité de choisir la taille de sa machine via les 3 propositions possibles sur Windows Azure WebSites actuellement, donc soit une instance de type « Small », « Medium » ou « Large ». De plus, il est possible d’y ajouter un certificat SSL que ce soit un SNI SSL (Server Name Indication) ou un IP SSL. Et bien entendu, on peut atteindre un maximum de 20 instances pour notre site web, ce qui permet en toute logique d’absorber un trafic très important si l’applicatif est conçu dans avec les bonnes pratiques. Fonctionnalité importante de ce dernier mode, il est possible de mutualiser ces différents sites web au sein de nos instances afin d’optimiser le coût et les ressources utilisées. Et bien entendu, avec ce mode, on accède enfin à toute la puissante du Cloud, puisqu’il est possible de mettre en place des règles de montée en charge automatique.

On peut déjà voir qu’il existe donc une flexibilité au niveau de la tarification de son service, et de la montée en charge de celui-ci. Mais une notion importante lors de la mise en place d’un site est surtout comment déployer ce dernier.

Publication sur Windows Azure WebSites

Ici encore, Windows Azure ne s’est pas dépourvu d’outil pour déployer ce que vous souhaitez sur la plateforme. Bien entendu, il existe le moyen classique de se connecter via FTP ou FTPS sur Windows Azure afin de déployer nos fichiers. Mais il existe aussi des moyens plus automatisés en connectant directement notre Windows Azure WebSites a un contrôleur de code source comme Git, GitHub, BitBucket ou Visual Studio Online, le tout afin qu’il publie automatiquement à chaque commit sur la branche souhaitée. Bien que la publication soit extrêmement simplifié par ce système, il est tout de même possible de faire un retour en arrière sur la solution déployée sans pour autant à avoir à annuler ces modifications sur notre branche de notre contrôleur de code source. Ainsi via ce système, nous pouvons placer la plateforme Windows Azure en tant que brique de votre intégration continue afin qu’elle suive un processus Agile.

Gérer les logs dans nos applications

Développer et publier une application web, quelques soit le langage n’est qu’une étape de la vie d’un site Web. En effet, il est aussi important de savoir ce qui se passe sur notre site. Que ce soit selon le nombre de requêtes qui sont appelées sur notre service, ou bien la charge utilisée sur le serveur qui héberge notre application. Et bien entendu, le nombre de requêtes en erreur que nous avons lors de l’utilisation de notre service. La solution que nous utilisons dans la plupart de nos projets est de développer ou d’utiliser des librairies existantes pour effectuer cette tâche. Le bien souvent le développement de cette brique est reporté ultérieurement afin de se concentrer sur les fonctionnalités principales de l’application. Grâce à Windows Azure WebSites, une version allégée d’un système de logs et de monitoring existe. Il est possible de récupérer tout type de logs via un système de fichier, qu’ils soient stockés sur le FTP ou sur le Windows Azure Storage. Quand je dis que c’est un système allégée c’est surtout qu’il n’y a pas de moyen de recherche ou de tri simplifié des erreurs. Néanmoins ce système de log peut être assez fin, car il est activable par type de log à récupérer. On peut donc dissocier facilement les erreurs liées aux serveurs ou à l’application elle-même et avoir grâce à cela un premier niveau de logs qui peut faire gagner du temps de développement, notamment en début de projet. Il y a de plus des courbes très simples d’utilisation qui nous permettent de voir graphiquement l’utilisation de nos services et afin d’avoir une rapide idée concrète des pics de charge du service.

Mais aussi des outils pour améliorer la vie du développeur

Autant une gestion des logs simplifiés, et une facilité de déploiement via différents contrôleurs de codes sources ou usines logicielles apportent des facilités aux équipes produits, mais cela n’aide en aucun cas lors d’un comportement anormal lié à la plateforme Windows Azure. Pour cela, il est possible via Visual Studio et donc des projets en .Net d’activer une option de debugging à distance, ce qui permet de rapidement corriger les erreurs liées à l’environnement. De même, pour des modifications mineures, il existe un Visual Studio Online via le projet « Monaco » qui nous permet d’éditer le code non compilé directement sur le serveur, comme par exemple les fichiers html, css, javascript, php, ou node.js.

Abordable pour tous !

Bien que l’on parle d’un environnement à la base pour un public de développeur, il est fort possible d’utiliser Windows Azure WebSites en tant qu’entrepreneur pour par exemple créer simplement une landing page, ou un site WordPress pour y accueillir un blog parlant d’une startup. A noter que dans l’offre Microsoft Bizspark, un crédit Windows Azure est offert et donc peut être utilisé pour réaliser ceci par défaut. Pour que ce soit le plus simple possible, Windows Azure WebSites se dote d’une galerie de template qui permet de créer par exemple notre WordPress en 3 clics avant de pouvoir le configurer puis de le mettre en ligne très rapidement. C’est donc un gain de temps par rapport au fait de devoir étudier les différentes offres du marché avant de se décider où héberger son blog. Bien entendu il n’y a pas que WordPress, il existe aussi des moteurs Drupal, ou BlogEngine.Net qui sont disponibles.

Windows Azure Cloud Service Deep Dive

Windows Azure Cloud Services est présent depuis les débuts de Windows Azure. En effet, la plateforme s’est avant toute chose construite autour de cette « Platform As A Service ». Mais cette brique de Windows Azure n’est pas en reste en termes de fonctionnalité puisqu’elle en gagne régulièrement. Bien que ce soit une brique historique, celle-ci n’est bien entendu absolument pas destinée uniquement aux projets utilisant uniquement les technologies Microsoft, car il est possible d’y faire tourner aussi bien des applicatifs Java, PHP, ou Node.js depuis des versions de la plateforme en beta. Nous allons donc voir ici, les différents types de rôle qui existe au sein de Windows Azure Cloud Service, et les fonctionnalités qui différencient ce PaaS de Windows Azure WebSites selon moi.

Un PaaS pour deux rôles

Windows Azure Cloud Service offre la possibilité d’avoir deux types de rôle, le premier est le Web Role, comme son nom l’indique permet d’héberger des sites web, il contient donc un IIS qui attends le package contenant notre application. Le deuxième rôle est un Worker Role qui permet d’héberger des applications comparables à des services Windows. Alors pourquoi avoir des rôles et non des instances où l’on peut déployer comme sur Windows Azure WebSites, et bien cela est simple, sur les Cloud Services, on déploie en réalité un package, on met donc un certain temps à déployer notre solution, cependant en contrepartie nous avons un accès plus poussé à la machine, il va donc être possible de réaliser des actions plus en liaison avec les serveurs. Par exemple, il est possible d’ouvrir des ports dans le pare-feu Windows Azure afin de créer des services customisés sur le port 8080 par exemple. De plus, on va pouvoir accéder au disque dur temporaire de la machine de manière pérenne via le SDK Windows Azure afin d’y écrire des documents temporaires comme des images afin de les modifier avant de les renvoyer à l’utilisateur. De plus, il existe une API de diagnostiques qui permet de savoir finement qu’elle est l’état de la machine, que ce soit l’utilisation du CPU, la mémoire disponible, mas aussi des statistiques sur les requêtes http, et aussi bien tous les compteurs de performance de Windows. Ce sont des fonctionnalités comme celles-ci qui permettent au Cloud Service de se différencier de Windows Azure WebSites. De plus, vu que l’on a un accès plus poussé à la machine, il est beaucoup plus simple de mettre en place des certificats pour gérer du SSL sur notre application, et de plus contrairement au Windows Azure WebSites, la mise en place de ce certificat est gratuit, à condition qu’il soit bien entendu correctement signé.

Un cache dédié intégré

De plus, Windows Azure Cloud Service permet d’avoir une fonctionnalité de cache comprise dans son prix. Ce cache peut être soit implémenté avec un Cache In Role, soit via un Cache Dédié. Ainsi il est possible de mettre des données dans un cache distribué entre les différentes machines, on peut par exemple réserver une instance Large, soit 7Go de RAM afin que celle-ci soit responsable du cache dédié pour les différents rôles. Ce cache utilise par la suite le Windows Azure Blob Storage afin de stocker les différentes données qu’il a en mémoire afin de se prévenir lors de l’arrêt soudain de la machine.

Un support de Visual Studio pour les applications .Net

Pour les applications utilisant Visual Studio et le langage .Net, il est possible d’ajouter pleins de fonctionnalités très sympas au déploiement, par exemple on peut ajouter l’intellitrace qui va nous permettre de détecter plus facilement des erreurs sur des instances hébergées dans le Cloud, en rejouant finalement la session en erreur sur une machine de développement. Ou bien même ajouter le profiling afin d’obtenir des compteurs de performances que ce soit pour la gestion de la mémoire au sein de notre application, ou bien la gestion des concurrences. Ces deux indicateurs sont extrêmement importants pour des applications hébergés dans le Cloud, puisqu’une fuite mémoire peut être catastrophique sur la facture finale, puisqu’il faudra avoir plus de machines disponibles pour répondre au même besoin.

Bien entendu, il existe d’autres fonctionnalités qui sont les mêmes que sur Windows Azure WebSites, je ne vais donc pas les répéter ici même.

Outils

Il existe de nombreux outils pour développer sur Windows Azure, le premier auquel on pense lorsqu’on vient du monde Microsoft est bien entendu Visual Studio, mais il existe aussi des outils gratuits comme WebMatrix qui est un IDE de Microsoft qui permet de faire du PHP, du Node.Js ou de l’ASP.Net facilement et simplement, et bien entendu il est fortement connecté à Windows Azure. De plus, il existe des SDK pour des IDE tel qu’Eclipse qui simplifie l’utilisation des Cloud Services avec Java, puisqu’il permet de configurer notre serveur en quelques clics afin de faciliter le déploiement de nos applications sur le PaaS Windows Azure.

Addons / Partenaires

Lorsque Windows Azure ne répond pas aux besoins des utilisateurs avec les briques de bases, il est possible d’utiliser des services partenaires, tel que ClearDb pour MySQL. De plus, récemment Microsoft a annoncé son partenariat avec Oracle qui fournit de ce fait des machines virtuelles avec Web Logic, ou bien Oracle Database. On peut donc en déduire que Microsoft préfère s’entourer de partenaires efficaces dans leurs technologies, plutôt que de développer un truc spécifique autour de la technologie. De plus, ils sont prompts pour fournir des librairies pour répondre aux manques des technologies en termes d’ouverture, par exemple Microsoft publie un package pour Node.Js pour se connecter depuis une application node à une base de données SQL Serveur.

Conclusion

Pour conclure, Windows Azure offre deux systèmes de PaaS qui ont beau être sur la plateforme mais ne sont pour autant pas concurrent mais qui selon moi complémentaire. Pour ma part, j’utilise Windows Azure WebSites pour développer des solutions web qui demandent un accès très restreint à la machine, comme un site web présentant sa société ou des apis mobiles. Les Windows Azure Cloud Services je les utilise plus pour réaliser des sites e-commerce ou pour connecter des machines PaaS a des systèmes IaaS pour réaliser des systèmes complexes.