Architecture d’une application Azure
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.