[cloud PaaS] Microsoft Azure : quels usages pour les Web Role et Worker Role

L’arrivée du PaaS (Plateforme as a Service) Azure de Microsoft, dans le paysage du développement .Net ne peut passer sans l’apparition d’un nouveau jargon technique.

Cet article met l’accent sur l’un de ses nouveaux termes techniques : la notion de Role.

Pourquoi c’est important de comprendre la signification réelle de la notion de « Role »,

Tout simplement pour savoir utiliser le bon Role pour le bon usage

Le développeur Windows Azure doit choisir un ou plusieurs types de rôles à implémenter lors de la mise en ouvre de sa solution (sous forme de service), en phase d’architecture. Une fois déployée au sein de Microsoft Azure, l’application pourra exécuter plusieurs instances de rôles différents.

Le plus simple est de distinguer les rôles en deux catégories

• Web role: pour traiter des requêtes HTTP/HTTPS. Un Web Role est un rôle adapté pour le développement d’application web supporté par IIS 7 et ASP.NET (3.5 pour le moment). Exemples de Web  rôles disponibles : ASP.NET Web Role, ASP.NET MVC2 Web Role,  CGI Web Role et WCF Service Web Role : 

• Worker role: pour traiter des tâches en arrière plan : il s’agit de processus de tache de fond (aucune requête HTTP entrante, ni exposition à un protocole). Il s’agit d’application de type s’exécutant comme une sans nécessiter d’être exposée sur un quelconque protocole. : un worker role peut servir de tâche de fond à une application web basé sur un Web Role.

Typiquement, pour un site ou une application web en ASP.NET il suffit de créer un Web Role. En créer plusieurs permet d’augmenter la disponibilité de l’application et de prétendre aux bénéfices d’un niveau de service d’au moins 99.95%.

Le niveau de service assuré par Azure exige au moins deux roles pour bénéficier du Windows Azure Service Level Agreement “Windows Azure has separate SLA’s for compute and storage. For compute, we guarantee that when you deploy two or more role instances in different fault and upgrade domains, your internet facing roles will have external connectivity at least 99.95% of the time.”

Le Worker role est utilisé typiquement pour des activités de traitement de fond :

• Création de fichier pdf,

• Traitement d’images

• Préparation des fiches de paye, en fin du mois

• Datamining

• calcul statistique

• etc.

Faire fonctionner 10 Worker Role durant une heure offre la même capacité de calcul que celle réalisée par 1 seul Worker role durant 10 heures, et ça coûte le même prix.

Un web role peut définir un point de contact (Endpoint) HTTP unique et un autre point unique HTTPS pour les clients externes.

La configuration d’un worker role est plus flexible : il peut définir jusqu'à cinq points de contact (Endpoint) externe en utilisant HTTP, HTTPS ou TCP. La principale contrainte est que chaque point de contact externe défini pour un rôle doit rester à l’écoute sur un port unique.

De plus, tous les rôles peuvent accéder aux services Windows Azure de stockage (Windows Azure storage services ) via les API de Windows Azure Managed Library ou le protocole REST via Windows Azure Storage Services REST API..

Avant de lancer votre application sur Azure (en mode SaaS ou non), pensez à prendre le temps de bien choisir les rôles adéquats : faire de l’architecture applicatif, devient plus important dans le cloud que dans le cas « on premise ».

Mais ceci est un autre sujet …