Un rapide coup d’oeil à  Windows Azure

les informaticiens doivent en savoir un peu plus sur les performances et l’évolutivité offertes par Azure.

Premièrement, il faut développer vos applications dans l’optique de garantir leur compatibilité avec l’infrastructure Windows Azure. Au sein de cette dernière, votre application est segmentée en services, lesquels contiennent à leur tour des rôles. Cette approche s’apparente à l’architecture SOA (Service Oriented Architecture), où une application est subdivisée en services. Azure reprend cette notion de services, mais avec des rôles dans chacun d’eux.

La figure 1 présente une structuration synthétique de l’architecture d’une application compatible avec Windows Azure. Comme illustré, l’application comporte les rôles Web et Worker. Un rôle Web est un composant d’application Web accessible via un point de terminaison HTTP ou HTTPS, autrement dit une application client. Il pourrait s’agir d’un navigateur ou d’une application personnalisée côté client susceptible d’accéder à ce rôle Web via HTTP ou HTTPS.

Un rôle Web peut ensuite dépendre de rôles Worker, lesquels sont des composants applicatifs de traitement arrière-plan, alors que le rôle Web constitue l’interface publique. Un rôle Worker communique avec vos services de stockage ou avec d’autres services Internet. Il n’expose pas de point de terminaison externe. Autrement dit, personne de l’extérieur ne peut appeler un rôle Worker. Il faut appeler un rôle Web, lequel appelle ensuite un rôle Worker.

Votre application est désormais constituée de multiples services et chacun d’eux comporte plusieurs rôles. Ces derniers sont hébergés par le service et le client les appelle ou les exécute avec le rôle Web servant d’interface publique.

Ce faisant, votre application peut s’exécuter sur le nombre maximum de serveurs autorisés par le cloud ou en fonction de vos besoins, car tous les rôles sont sans état et ne conservent donc pas les données des appels précédents. Ces rôles s’appuient sur les services de stockage pour conserver les informations d’état. Ainsi, une instance de rôle peut répondre à une requête traitée précédemment par une autre instance de rôle, le cas échéant sur une machine différente. Ces rôles sont des composants de service exécutables en parallèle et assurant l’évolutivité du point de vue de l’architecture applicative. Mais, au final, le problème vient du maillon le plus faible de la chaîne. Bien que Windows Azure dispose d’une architecture brillante, les services de stockage constituent son point faible.