Azure Web Burst Architectes

Tutoriel : Débordement d'une application
d'entreprise vers Windows Azure
Par Benjamin Guinebertière (Microsoft) -

Stéphane Goudeau (Microsoft) - Xavier Warzee
Date de publication : 8 novembre 2013
Dernière mise à jour : 11 novembre 2013
L'équipe de Windows Azure, la plateforme Cloud de Microsoft, a préparé beaucoup

de contenu intéressant, en exclusivité pour les lecteurs de Developpez.com. Chaque
semaine, on va partager ce contenu avec vous. Regardez les vidéos, rejoignez des Web
Events, étudiez les tutoriels. À la fin de chaque semaine, il y aura des questions, et chaque
personne qui répondra correctement à 80 % de ces questions recevra un t-shirt sympa.
Le 23 décembre, un tirage au sort sera effectué entre tous les gagnants, et le vainqueur
recevra un Nokia Lumia - un cadeau sympa de Noël ! Tous ceux qui auront au moins une
fois trouvé 80 % de bonnes réponses à une série de questions - et donc, gagné un t-shirt -
seront sélectionnés pour participer à ce tirage. En d'autres mots, un seul challenge réussi
suffira pour participer au tirage.
Une des promesses de l'informatique en nuage ou « cloud computing » est l'élasticité qui
permet d'allouer des ressources informatiques pour des besoins ponctuels.
Dans ce tutoriel nous allons voir comment on peut utiliser cette élasticité pour permettre
à l'informatique interne de l'entreprise de déborder sur le nuage pendant les périodes de
plus forte charge. Pour illustrer cela, on s'appuie sur l'exemple de la saisie des feuilles de
temps dans laquelle les employés de l'entreprise affectent leur temps à des projets, pour
le suivi budgétaire de ces derniers.
L'équipe Windows Azure de Developpez.com tient à remercier « L'équipe Azure de

Microsoft » pour la mise à disposition de ce tutoriel aux membres de Developpez.com.
Vous pouvez essayer gratuitement Windows Azure pendant une période d'un mois et
obtenir une réduction de 150 euros.
Pour réagir au contenu de ce tutoriel, un espace de dialogue vous est proposé sur le forum :
Commentez.
Tutoriel : Débordement d'une application d'entreprise vers Windows Azure par Benjamin Guinebertière (Microsoft) - Stéphane Goudeau (Microsoft) - Xavier Warzee
Introduction...................................................................................................................................................................4
Scénario....................................................................................................................................................................... 4
Conception de la solution............................................................................................................................................ 5
Dimensionnement et opportunité........................................................................................................................... 6
Mécanisme de débordement..................................................................................................................................7
Lien avec le système d'information interne de l'entreprise....................................................................................9
Authentification et autorisation..........................................................................................................................9
Lien avec l'ERP...............................................................................................................................................11
Déploiement.......................................................................................................................................................... 15
Modifications à apporter à l'application existante................................................................................................ 15
Considérations complémentaires......................................................................................................................... 18
Saisie depuis l'extérieur de l'entreprise.......................................................................................................... 18
Utilisation d'un Worker Role pour soumettre les feuilles de temps validées à l'ERP..................................... 18
Si l'application avait été développée dans d'autres technologies...................................................................19
Conclusion..................................................................................................................................................................19
-3-
Copyright ® 2013 Microsoft. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse
de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.
https://windows-azure.developpez.com/tutoriels/azure/debordement-application-entreprise-vers-windows-azure/
Introduction
Cet article, publié en janvier 2010, a inspiré la rédaction d'un article complémentaire et plus
récent que l'on propose ici.
Une des promesses de l'informatique en nuage ou « cloud computing » est l'élasticité qui permet d'allouer des
ressources informatiques pour des besoins ponctuels.
Ce document montre comment on peut utiliser cette élasticité pour permettre à l'informatique interne de l'entreprise
de déborder sur le nuage pendant les périodes de plus forte charge. Pour illustrer cela, on s'appuie sur l'exemple
de la saisie des feuilles de temps dans laquelle les employés de l'entreprise affectent leur temps à des projets, pour
le suivi budgétaire de ces derniers.
Le présent document décrit la solution envisagée avec le niveau de détail d'un document de spécifications générales.
Scénario
La société CONTOSO demande aux employés européens qui travaillent sur ses projets de saisir de façon
hebdomadaire le temps qu'ils ont passé sur chaque projet, de façon à pouvoir suivre budgétairement ces projets.
Les saisies peuvent avoir lieu par anticipation, mais la plupart de ces saisies ont lieu le vendredi après-midi (plus de
80 % de la population concernée). Il y a à peu près 20 000 personnes concernées par cette saisie dans l'entreprise.
Cela donne donc une population de 16 000 personnes pour la saisie le vendredi après-midi.
Le vendredi après-midi, l'application de saisie des temps rencontre des dégradations des performances aboutissant
à des abandons de saisie, et une baisse de productivité des employés. Les prestataires externes peuvent saisir leurs
temps directement dans l'application quand ils sont dans les murs de l'entreprise, mais ils ne peuvent pas le faire
depuis Internet, l'application de saisie des temps n'étant pas exposée à l'extérieur.
L'affectation des temps aux différents projets est gérée au niveau de l'ERP de CONTOSO. Ce dernier expose des
(1)
services Web SOAP qui permettent de
• récupérer pour un utilisateur la liste des codes et libellés de projets sur lesquels il peut saisir pour la période ;
• récupérer la liste des temps déjà saisis sur une période ;
• soumettre une saisie de temps.
L'application de saisie des temps est une application Web écrite en ASP.NET, qui fait appel à ces services Web et
utilise l'authentification intégrée Windows (les utilisateurs arrivent avec leur compte défini dans un domaine Active
Directory de l'entreprise).
(1) Il est à noter que l'ERP peut exposer ces services Web directement, ou via une couche d'intégration telle que
BizTalk.
-4-
Conception de la solution
De façon à bénéficier de ressources uniquement une demi-journée par semaine, CONTOSO décide de rendre
l'application Web de saisie disponible également en nuage. L'application étant écrite en ASP.NET, et CONTOSO
souhaitant se concentrer sur l'application sans avoir à gérer l'infrastructure (architecture technique, mises à jour du
système d'exploitation, etc.), elle se tourne naturellement vers l'offre PaaS de Microsoft : Windows Azure Platform.
L'idée peut se résumer avec le schéma suivant :
-5-
À ce stade, on peut lister un certain nombre de questions qui restent à traiter :
• combien de rôles faudra-t-il déployer pour répondre à la charge attendue ? ;

• est-ce économiquement intéressant ? ;
• comment les utilisateurs pourront-ils aller sur la bonne application Web ? ;
• comment s'authentifieront-ils à l'application Azure ? ;
• comment l'application Azure pourra-t-elle se connecter à l'ERP ? ;
• l'ERP ne va-t-il pas être trop chargé ? ;
• comment déploiera-t-on l'application Azure ? ;
• comment l'application pourra-t-elle être modifiée de façon à pouvoir s'exécuter à la fois à demeure et dans
Azure ?
Dimensionnement et opportunité
Sachant qu'on prévoit une charge de 16 000 personnes (80 % de 20 000) qui saisissent leur temps en à peu
près 30 requêtes HTTP (lecture de page, mise à jour de formulaire, appels Ajax…)cela donne une charge de
requêtes à servir pendant la période de quatre heures du vendredi
après-midi, à savoir requêtes par seconde en moyenne, à répartir sur deux

(2)
instances de rôle Web Azure (pour former une ferme Web ).
Les machines virtuelles Azure existent sous différentes formes, comme le montre ce tableau issu de http://bit.ly/
aOfKyb :
Dans la même page, on voit que chaque type d'instance est deux fois plus puissante que la précédente et coûte
deux fois plus cher :
(2) Les SLA de Windows Azure sont valables à partir de deux instances uniquement.
-6-
En première approche, les instances de calcul moyennes sont suffisantes pour assurer la charge au niveau
CPU et permettent de bénéficier de performances d'entrées sorties élevées (seules les petites instances ont des
performances moins bonnes au niveau réseau). Des petites instances seront peut-être suffisantes, mais l'on préfère
ici partir sur un calcul pessimiste.
Les tarifs sont disponibles à l'adresse suivante http://www.microsoft.com/windowsazure/offers/. En entrant

(3)
dans le détail (http://bit.ly/bcNpwO), on trouve que le prix d'une heure de petite instance est de 0,12 $
. Sachant que la facturation est à l'heure et qu'on démarrera l'application un peu avant 14 h pour l'arrêter
un peu après 18 h, on vise une consommation de six heures pour les calculs. Cela correspond donc à
par vendredi après-midi.
Il faut ajouter à cela d'autres coûts pour la connexion à l'ERP (voir plus bas dans le document), le stockage des
données intermédiaires de saisie (voir plus bas) et la bande passante.
Pour le calcul de la bande passante, si l'on suppose que chaque saisie de temps génère 400 Ko sortant d'Azure et
100 Ko entrant, cela correspond à sortant et
entrant. Un extrait de http://bit.ly/bcNpwO indique les tarifs

suivants pour l'Europe : 0,15 $ par gigaoctet sortant et 0,10 $ par gigaoctet entrant. Ceci nous donne une estimation de
consommation par vendredi après-midi de pour la bande

passante.
On voit donc que la consommation de ressources dans Azure par vendredi après-midi est de l'ordre de quelques
dollars en tout, même en tenant compte des coûts complémentaires que l'on détaillera plus bas dans le document.
Le coût de la consommation Azure semble donc tout à fait acceptable.
Mécanisme de débordement
On prévoit d'avoir deux applications différentes : timesheet.contoso.com pour les saisies hors période de pointe et
cloudtimesheet.contoso.com en renfort le vendredi après-midi. On cherche ici à déterminer une façon efficace de
gérer le débordement uniquement le vendredi après-midi.
(3) Tous les prix indiqués dans ce document sont ceux disponibles au moment de l'écriture de ce document.
Il est nécessaire de se reporter aux dernières informations en ligne pour avoir les tarifs en vigueur. Il faut
essentiellement retenir ici les ordres de grandeur.
-7-
Pour des raisons de simplicité, on choisit de faire en sorte que l'application principale timesheet.contoso.com ne serve
qu'à rediriger vers cloudtimesheet.contoso.com le vendredi après- midi. En effet, cela représente 16 000 (80 % de
20 000) requêtes en quatre heures soit à peu près 1,11 requête par seconde. De plus, cette redirection peut être gérée
par une page statique qui est très peu consommatrice de ressources sur le serveur Web timesheet.contoso.com.
Cela permet également de n'avoir qu'une même ferme Web qui gère les saisies à un moment donné, tout en laissant
les utilisateurs se connecter toujours à la même URL : timesheet.contoso.com.
Ainsi, on a
et
-8-
Lien avec le système d'information interne de l'entreprise
Authentification et autorisation
Les utilisateurs de timesheet.contoso.com bénéficient d'une authentification intégrée en Kerberos ou NTLM, ce qui
n'est pas utilisable de la même façon dans le cas d'Azure, car les serveurs Azure ne peuvent faire partie du domaine
contoso.com, ne serait-ce que parce qu'ils n'ont pas accès à un contrôleur de ce domaine.
On décide donc de s'appuyer sur des mécanismes d'identité fédérée, à base de revendications (« claims » en anglais).
Ces mécanismes, décrits dans des spécifications telles que WS-Federation, WS-Trust ou SAML 2.0 simplifient les
(4)
scénarios de Web SSO . Le principe est le suivant :
(5)
L'utilisateur, via son navigateur, va vers l'application (1) ou RP . Cette dernière vérifie si la demande arrive avec un
jeton. Comme ce n'est pas le cas dans un premier temps, elle redirige le navigateur vers son fournisseur de jetons
(6)
ou STS . Le navigateur demande alors au STS (2) un jeton pour l'application. Cette demande de jeton est réalisée
avec une authentification qui permet au STS de savoir qui est l'utilisateur. Cette authentification lors de l'appel (2) peut
elle-même utiliser des mécanismes d'authentification fédérée, mais également plus simplement une authentification
(7)
Windows par exemple. Le STS s'appuie sur le fournisseur d'identité ou IP pour construire le jeton et le renvoie
au navigateur (2 bis) tout en le redirigeant vers l'application (RP). Le navigateur peut alors se présenter auprès de
l'application avec le jeton (3). Le RP peut vérifier que le jeton est signé par un STS auquel il fait confiance (cette
confiance s'établit par des échanges de métadonnées) et lire le jeton qui lui fournira des informations sur l'identité
de l'utilisateur.
Les informations contenues dans le jeton sont appelées des revendications (claims en anglais). Elles correspondent à
un ensemble de clefs/valeurs qui permettent d'identifier l'utilisateur auprès du RP avec les informations dont ce dernier
(8)
a besoin pour autoriser l'utilisateur à accéder aux bonnes fonctions de l'application et l'identifier si nécessaire .
(4) SSO = Single Sign-On.

(5) RP = Relying Party.
(6) STS = Security Token Service.
(7) IP = Identity Provider.
(8) Il peut exister des scénarios où le RP n'a pas besoin d'identifier l'utilisateur ; il peut uniquement avoir besoin de
caractéristiques telles que son âge pour de la vente d'alcool par exemple.
-9-
Sur la plateforme Microsoft, les technologies de base permettant d'implémenter cela sont Active Directory Federation
(9)
Services 2.0 (ADFS V2) et Windows Identity Foundation (WIF) . ADFS V2 est un STS qui s'appuie sur l'IP Active
Directory. WIF quant à lui est un framework de développement que l'on utilise typiquement dans une application ou
des services WCF qui ont le rôle de RP. WIF permet également de développer son propre STS.
On prévoit donc l'architecture suivante :
Cependant, mettre en place ADFS V2 au niveau du domaine peut prendre un certain temps (il est souvent plus
long dans une grande entreprise de toucher à des éléments aussi centraux qu'Active Directory, que de déployer une
application), et l'équipe projet prévoit donc une solution alternative et intermédiaire qui peut permettre une mise en
production plus rapide. Il s'agit de développer son propre STS avec WIF.
Cette solution intermédiaire suppose de développer un peu de code, mais elle doit pouvoir être hébergée sur
l'infrastructure de l'application timesheet.contoso.com (un jeton peut durer plusieurs heures, ce qui permet d'avoir une
sollicitation assez faible du STS). Dans ce cadre, le STS ASP.NET reçoit la demande de jeton venant du navigateur de
l'utilisateur avec une authentification Windows intégrée, et il peut produire le jeton, il peut traduire des rôles reçus avec
(10)
cette authentification Windows (une application ASP.NET traduit les appartenances à des groupes en des rôles
). Dans le cadre du développement d'une application simple, avoir un STS spécifique peut permettre un déploiement
(9) Ces deux technologies ont été développées sous le nom de code Geneva. Geneva Server est devenu ADFS V2
et Geneva Framework est devenu WIF.
(10)Voir par exemple http://msdn.microsoft.com/en-us/library/
system.security.principal.windowsprincipal.isinrole.aspx
- 10 -
plus rapide. C'est cependant moins pérenne que la mise en place d'ADFS V2 qui permettra plus facilement de mettre
(11)
en place de la fédération d'identité entre forêts, ou même avec d'autres implémentations du marché .
Dans les deux cas, on sera donc capable d'authentifier depuis l'application Azure des utilisateurs venant du domaine
Active Directory interne contoso.com. Dans les deux cas, l'expérience utilisateur sera la même que lors de l'utilisation
de l'application à demeure timesheet.contoso.com, si ce n'est quelques redirections de navigateur.
L'application existante s'appuie sur la notion de rôles ASP.NET qui viennent directement de l'appartenance à des
groupes Active Directory. Cela peut se traduire facilement avec une règle ADFS V2 qui génèrera des revendications
de type http://schemas.microsoft.com/ws/2008/06/identity/claims/role à partir des noms de groupes Active
Directory. On trouvera des informations complémentaires sur le sujet par exemple à http://msdn.microsoft.com/
en-us/library/ee748475.aspx.
Il est également nécessaire d'authentifier l'utilisateur de façon à pouvoir demander à l'ERP la liste des projets
ou renvoyer à l'ERP la feuille de temps saisie qui concerne cet utilisateur précis. Dans l'application à demeure,
(12)
c'est le compte Active Directory qui est utilisé . Cela se traduira par une revendication de type http://
schemas.xmlsoap.org/ws/2005/05/identity/claims.name à partir de l'attribut sAMAccountName d'Active Directory.
(13)
Ainsi, le code de l'application ASP.NET existante qui effectue des appels de type User.Name ou User.IsInRole
sera le même pour les deux types de déploiement. Dans le déploiement en nuage utilisant la fédération d'identité, ce
(14)
sont les modules HTTP de WIF qui s'occupent de faire le lien entre l'implémentation très différente et la syntaxe
qui est la même. Les modules WIF effectuent les demandes de redirection du navigateur vers le STS et la vérification
du jeton SAML, puis son interprétation avant de remplir les objets IIdentity et IPrincipal qu'ASP.NET utilise.
Il restera à vérifier que le code utilise uniquement les interfaces IIdentity et IPrincipal, et non les classes
WindowsIdentity et WindowsPrincipal. Après ces éventuels ajustements assez simples, le code pourra être le même
dans les deux modes de déploiement.
Lien avec l'ERP
L'application dans les nuages n'est utile que si elle est liée à l'ERP qui contient les données des feuilles de temps,
et les liens entre les utilisateurs et les projets sur lesquels ils travaillent.
L'application existante a tendance à solliciter beaucoup l'ERP puisque la plupart des interactions entre le navigateur
et l'application Web aboutissent à des interactions entre l'application Web et l'ERP, comme le montre le diagramme
de séquence suivant :
(11)Voir le livre blanc téléchargeable à http://bit.ly/dxBZJZ: AD FS 2.0, une plateforme ouverte et interopérable pour
l'authentification unique Web et la fédération des identités.
(12)Il est à noter que si l'attribut à envoyer dans les revendications avait été dans un autre entrepôt de
données qu'Active Directory, ADFS V2 aurait également pu s'appuyer sur ce dernier. Voir par exemple http://
technet.microsoft.com/en-us/library/dd807093(WS.10).aspx sur le sujet.
(13)Pour savoir si l'utilisateur a le droit de valider des temps, d'en saisir, etc.
(14)WIF = Windows Identity Foundation.
- 11 -
De façon à ce que l'application en nuage allège effectivement l'ERP, il faut tendre vers le type d'interaction suivant
où l'ERP n'est sollicité que pour la récupération des données de contexte et pour la mise à jour de la feuille de temps
complète :
Cela peut être fait par exemple en stockant les données intermédiaires dans la session ASP.NET de l'application. À
demeure, la session ASP.NET peut être stockée dans SQL Server par exemple. Sur Azure, elle peut être stockée
(15)
dans des tables de Windows Azure Storage par exemple . L'avantage de cela est que la différence entre les deux
modes est uniquement de la configuration ; la syntaxe est la même dans les deux cas.
Dans le cas de Windows Azure, le stockage fait l'objet d'une facturation. La page http://bit.ly/bcNpwO nous donne
un coût de stockage de 0,15 $ par gigaoctet et par mois et de 0,01 $ pour 10 000 transactions de stockage. On part
de l'hypothèse qu'on stockera à peu près 200 Ko/utilisateur pendant quatre heures (on peut supprimer toutes les
(15)Cf http://blogs.msdn.com/b/jnak/archive/2009/11/19/using-the-sample-windows-azure-asp-net-
providers.aspx
- 12 -
valeurs de session en fin de vendredi après-midi) et qu'on a deux transactions de stockage par requête HTTP (une
lecture, une mise à jour). Cela donne une estimation de coût de l'ordre de
Le coût par vendredi après-midi au niveau stockage est donc négligeable.
Il reste à voir comment l'application peut se connecter à l'ERP sans avoir directement accès au système d'information
de CONTOSO, et en ayant une bonne protection du lien contre des menaces telles que le vol ou la modification
d'informations.
Pour cela, on s'appuie sur Windows Azure Platform AppFabric Service Bus & Access Control (Azure Service Bus).
Ce composant de la plateforme Windows Azure permet à des applications qui restent derrière des pare-feu et NAT
(16)
d'exposer des Web Services SOAP ou REST à travers une connexion sortante sur Internet, tout en fournissant
une sécurité d'accès.
Schématiquement, Azure Service Bus permet ce type de scénario :
On vise donc son utilisation de la façon suivante :
On trouvera des informations complémentaires sur le lien entre Azure et un ERP (SAP en l'occurrence) à http://
bit.ly/b9vZF6.
(16)NAT = Network Address Translation.
- 13 -
(17)
De façon à ne pas modifier les services Web qui exposent l'ERP, mais également parce qu'on ne peut pas
(18) (19)
exposer des services vers Azure Service Bus quand ils sont hébergés dans IIS ou WAS , on met en frontal
des services Web existants un service Windows (qu'on appelle Service de lien Azure) ; il effectuera le lien entre les
services Web et Azure Service Bus. Cela est schématisé ci-dessous :
Le service de lien Azure, effectue une transition de protocole entre sa connexion (1 bis) et sa connexion (2). La
connexion (1 bis) utilise le binding WCF natif du service Web d'exposition de l'ERP. La connexion (2) utilise un
(20)
binding fourni par le SDK d'Azure Service Bus tel que ws2007HttpRelayBinding. Le service de lien Azure
n'ayant aucune fonction métier, on peut s'appuyer sur le nouveau service de routage du .NET Framework 4.0
(System.ServiceModel.Routing) dont on trouvera une vue d'ensemble à http://msdn.microsoft.com/en-us/library/
ee517423.aspx. Ainsi, on aura essentiellement de la configuration (vs du code) dans le service de lien Azure.
Enfin, et parce que le service Web d'exposition de l'ERP est installé sur une ferme de deux serveurs pour la
redondance, on prendra en compte les recommandations du SDK d'Azure Service Bus fournies dans une installation
par défaut à « C:\Program Files\Windows Azure Platform AppFabric SDK\V1.0\Samples\ServiceBus\Scenarios
\LoadBalance ». Cela permet de gérer de façon transparente un mécanisme de round robin dans la ferme.
La connexion via Azure Service Bus doit être prise en compte dans les coûts de consommation.
Les tarifs tels que disponibles à http://bit.ly/bcNpwO indiquent 1,99 $ pour 100 000 transactions au service de
contrôle d'accès (Windows Azure Platform AppFabric Access Control) et 3,99 $ par connexion et par mois. On part
du principe que deux connexions seront nécessaires, car la ferme de services Web de l'ERP est composée de deux
serveurs, ce qui permet d'assurer la redondance. Le calcul se fait au prorata temporis. On obtient donc pour un
vendredi après-midi (six heures, car on compte la mise en place avant et après, comme vu plus haut) :
Pour chaque personne qui saisit ses temps, on aura besoin de deux transactions de contrôle d'accès, ce qui donne
(17)Voir http://vasters.com/clemensv/PermaLink,guid,3cc2bb9c-9a43-4c4c-9fdb-1f7bbfcaec43.aspx
(18)IIS = Internet Information Services.
(19)WAS = Windows Process Activation Service.
(20)SDK = Software Development Kit.
- 14 -
On voit donc que l'ordre de grandeur reste le même que ce qu'on a vu plus haut à savoir quelques dollars par vendredi
après-midi.
Déploiement
Le déploiement de l'application peut avoir lieu de façon manuelle ou de façon automatisée. De façon manuelle, il est
possible de déployer directement depuis Visual Studio ou depuis le portail de Windows Azure où l'on peut déployer
les deux fichiers issus de Visual Studio ou du processus de build.
De façon automatisée, il est possible d'écrire du code qui effectue ce déploiement ou de s'appuyer sur des outils en
ligne de commande qui ont eux-mêmes été développés au-dessus des API de gestion d'Azure.
On prévoit de s'appuyer sur les outils en ligne de commande pour écrire des scripts de déploiement. Ces outils sont
téléchargeables (sous forme de code source et d'exécutables) à http://code.msdn.microsoft.com/wazt et http://
code.msdn.microsoft.com/azurecmdlets.
Quand le déploiement est terminé, il est nécessaire de configurer l'application timesheet.contoso.com de rediriger
vers azuretimesheet.contoso.com. On décide de le faire par configuration des serveurs IIS de la ferme Web interne,
comme indiqué à http://www.iis.net/ConfigReference/system.webServer/httpRedirect.
Lors de la création du service Azure, on obtient une URL de type <nom de service>.cloudapp.net. Le
nom de service contosotimesheet a été configuré. Cependant, on préfère présenter aux utilisateurs l'URL
(21)
azuretimesheet.contoso.com plutôt que contosotimesheet.cloudapp.net. Pour cela, on ajoute dans le DNS
qui gère le nom de domaine contoso.com le sous-domaine azuretimesheet.contoso.com sous la forme d'un
enregistrement de type CNAME qui pointe vers le nom contosotimesheet.cloudapp.net. On ne peut entrer un
enregistrement de type A, car l'adresse IP assignée au service change chaque vendredi après-midi. En revanche,
un enregistrement de type CNAME est approprié, car le nom contosotimesheet.cloudapp.net reste constant d'un
vendredi après-midi à l'autre et Azure s'occupe d'associer la bonne adresse IP (variable) à ce nom (constant).
De façon à ce que les informations saisies ne circulent pas sur Internet en clair, on veut accéder à
cloudtimesheet.contoso.com en HTTPS. Il faut donc prévoir un certificat associé à ce nom de domaine que l'on pourra
charger vers Azure sous la forme d'un fichier PFX.
Modifications à apporter à l'application existante
L'application existante timesheet.contoso.com doit être modifiée de façon à pouvoir s'exécuter à la fois à demeure
et dans les nuages. On souhaite effectivement n'avoir à maintenir qu'une version du code. On liste dans le tableau
ci-après les différences entre les deux formes de l'application :
timesheet.contoso.com
azuretimesheet.contoso.com
Modification à
(à demeure) (en nuage) apporter
Type de projet Application Web Role et projet Un Web role et
Visual Studio ASP.NET de type « Windows une application
Azure Cloud ASP.NET sont
Service »
(21)DNS = Domain Name System
- 15 -
similaires. Voir plus

bas.
Session ASP.NET Configurée pour Configurée pour Incorporer
être stockée dans être stockée le « provider » de
SQL Server dans le stockage session ASP.NET
Windows Azure pour les tables
(non relationnel) Azure et changer
la configuration
ASP.NET. Il
n'y a pas de
changement
de code de
l'application.
Moindre Modification des Réutilisation de Modification
sollicitation de appels pour ne ces modifications de la logique
l'ERP solliciter l'ERP applicative pour
qu'en tout début mieux séparer la
et en toute fin de logique métier de
saisie la cinématique
de l'interface
utilisateur (UI
Process).
Connexion aux Directe (via le Á travers Windows La logique d'appel
services Web de réseau local) Azure Platform des Web Services
l'ERP AppFabric Service reste la même.
Bus & Access Comme pour
Control tout code WCF,
certaines parties
spécifiques aux
bindings peuvent
être dans du
code ou de la
configuration.
Authentification, Utilisation de la Utilisation de Vérification qu'il
Autorisation notion de rôle Windows Identity n'y a pas de
ASP.NET Foundation pour dépendance
Configuration IIS récupérer les directe à un
pour avoir une claims de type WindowsPrincipal,
authentification rôle sous forme de mais uniquement
intégrée où rôles ASP.NET à IPrincipal,
les groupes changement de
Active Directory la configuration
deviennent des web.config.
rôles
Service de lien Inexistant Application S'appuie
Azure complémentaire essentiellement
déployée sous la sur le
forme de services RoutingService de
Windows WCF 4.0.
On voit donc que code existant doit essentiellement subir des modifications pour qu'il puisse fonctionner tel quel dans
les deux modes de déploiement (à demeure, en nuage). Cependant, certaines parties de code peuvent ne pas être
communes par exemple l'initialisation de l'appel aux services Web exposant l'ERP. Pour ces parties, on s'appuie sur
(22)
MEF qui permet de gérer des composants enfichables. Il est à noter que l'on pourrait également préférer d'autres
(22)MEF = Managed Extensibility Framework, voir http://msdn.microsoft.com/en-us/library/dd460648.aspx et

http://msdn.microsoft.com/en-us/library/system.componentmodel.composition.aspx
- 16 -
(23) (24)
approches comme l'utilisation d'un conteneur de type IoC tel que Unity Application Block . On s'oriente vers
MEF qui est un peu plus simple à utiliser et qui fait partie du .NET Framework 4.0, contrairement à Unity Application
Block qui est fourni sous forme de code source pour lequel on hérite de la maintenance.
Une application ASP.NET et un Web Role Azure sont très similaires, tant et si bien qu'au niveau du poste de
développement, on peut exécuter le Web Role comme une application ASP.NET classique. Le code de démarrage
du Web Role, contenu par défaut dans un fichier WebRole.cs est ignoré par l'application ASP.NET. Pour l'application
timesheet.contoso.com, on ne déploiera pas ce fichier.
La sélection des fichiers à compiler et à déployer sera faite dans le processus de build automatisé. Par exemple,
dans le package à destination du déploiement à demeure, on retrouvera un composant MEF qui permet d'initialiser
les appels directs aux services Web de l'ERP alors que dans celui à destination d'Azure, on trouvera le composant
qui initialise les appels de services Web de l'ERP via Azure Service Bus. De même, le composant d'initialisation du
rôle ne sera utile que dans le cas du déploiement en nuage.
On vise donc schématiquement de procéder comme suit pour l'application ASP.NET :
Les fichiers de configuration issus du processus de build sont des fichiers avec des valeurs de développement.
Le compte Azure utilisé pour le déploiement lors de tests n'est pas le même que pour la production. Par exemple,
il déploie l'application contosotesttimesheet.cloudapp.net et non contosotimesheet.cloudapp.net. C'est l'équipe de
production qui se charge de mettre à jour les fichiers de configuration avant le déploiement en production. Cela
n'empêche pas d'automatiser le déploiement du vendredi puisque les fichiers de configuration de production ne
changent pas nécessairement d'un vendredi à l'autre.
En aval du processus de build, on aura donc :
(23)IoC = Inversion Of Control.

(24)Cf http://msdn.microsoft.com/en-us/library/ff647202.aspx
- 17 -
Lors du développement, des tests sont effectués dans un environnement d'intégration spécifique (1). À chaque
nouvelle version, les packages sont pris en charge par les équipes de production (2) de façon à rendre les fichiers
de configuration compatibles avec l'environnement de production.
N.B. On ne montre ici qu'un environnement de test et un environnement de production pour simplifier, mais il peut
évidemment y avoir beaucoup plus d'environnements intermédiaires tels que ceux pour les tests unitaires automatisés
(dans le cadre du processus de build), des tests de recette, d'homologation, de charge, de préproduction, etc. Pour
chacun de ces environnements, on peut avoir un environnement Azure différent. En effet, la nature très homogène, et
à la demande de l'informatique en nuage permet de disposer facilement d'environnements similaires. Bien sûr, il faut
faire correspondre ces environnements Azure à des environnements à demeure, par exemple pour les appels à l'ERP.
Considérations complémentaires
Saisie depuis l'extérieur de l'entreprise
Sachant que l'application est exposée sur Internet, on peut faire évoluer l'authentification via ADFS V2 de façon à ce
qu'elle soit également possible depuis Internet pour des postes qui n'ont pas accès directement aux contrôleurs de
domaine de contoso.com. Cette évolution est en dehors du champ de ce document. L'évolution consisterait à avoir
des serveurs ADFS V2 de type proxy. On trouvera des informations sur le sujet à http://technet.microsoft.com/en-
us/library/dd807130(WS.10).aspx.
On peut également dans un deuxième temps fédérer l'identité d'autres partenaires, de façon à ce que les prestataires
puissent saisir leur temps en s'authentifiant avec les crédentités de leur propre employeur, et non de celles fournies
par contoso.com. Dans le cas de l'application de saisie des temps, cela peut supposer des adaptations au niveau
de l'ERP pour qu'il accepte des saisies de temps pour des utilisateurs dont l'identifiant n'est plus un compte Active
Directory de contoso.com.
Utilisation d'un Worker Role pour soumettre les feuilles de temps validées à l'ERP
On peut imaginer, en fonction des temps de réponse de l'ERP que les feuilles de temps sont soumises de façon
asynchrone à un Worker Role Azure qui les soumet à son tour à l'ERP via Azure Service Bus. Cela risque cependant
de complexifier l'application, ne serait-ce que pour gérer les cas d'erreurs alors que la personne qui a saisi ses temps
n'est plus connectée à l'application. De plus, si les temps de réponse se dégradent parce que l'ERP répond plus
lentement, il peut être plus simple et moins onéreux d'ajouter des web roles plutôt que de modifier plus profondément
l'application.
- 18 -
Si l'application avait été développée dans d'autres technologies
Le raisonnement qui est tenu dans ce document est largement transposable à une application écrite en Java ou PHP.
En effet, Windows Azure permet d'héberger divers types d'applications qui ne sont pas écrites en .NET. On trouvera
plus d'informations sur le sujet à http://www.microsoft.com/windowsazure/interop/.
Conclusion
Le présent document permet d'avoir une vue d'ensemble des éléments que l'on peut retrouver dans des spécifications
générales pour une application à demeure que l'on veut faire déborder en nuage pendant les pics de charges
prévisibles.
Les principales considérations étudiées ici sont le coût d'exécution en nuage (quelques euros par vendredi après-midi
dans le cas étudié), la connexion avec le système d'information (authentification/autorisation, connexion aux services
Web via Azure Service Bus dans le cas étudié), faire en sorte que le déploiement sur Azure prenne effectivement
l'essentiel de la charge pendant le pic (sollicitation de l'ERP uniquement en tout début et en toute fin de saisie), les
tests, et le déploiement.
On voit donc que l'on peut, en a priori quelques dizaines de jours de développement et de tests, faire déborder une
application telle que la saisie des temps sur Windows Azure pendant les pics de charge, tout en conservant une base
de code commune entre les deux versions de l'application, et en ayant des coûts d'exécution faibles.
- 19 -

Azure Web Burst Architectes

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Azure Web Burst Architectes

Transféré par

Droits d'auteur :

Formats disponibles

Tutoriel : Débordement d'une application

d'entreprise vers Windows Azure

Par Benjamin Guinebertière (Microsoft) -

Date de publication : 8 novembre 2013

Dernière mise à jour : 11 novembre 2013

L'équipe de Windows Azure, la plateforme Cloud de Microsoft, a préparé beaucoup

L'équipe Windows Azure de Developpez.com tient à remercier « L'équipe Azure de

L'idée peut se résumer avec le schéma suivant :

À ce stade, on peut lister un certain nombre de questions qui restent à traiter :

• combien de rôles faudra-t-il déployer pour répondre à la charge attendue ? ;

requêtes à servir pendant la période de quatre heures du vendredi

après-midi, à savoir requêtes par seconde en moyenne, à répartir sur deux

Les tarifs sont disponibles à l'adresse suivante http://www.microsoft.com/windowsazure/offers/. En entrant

par vendredi après-midi.

100 Ko entrant, cela correspond à sortant et

entrant. Un extrait de http://bit.ly/bcNpwO indique les tarifs

consommation par vendredi après-midi de pour la bande

Lien avec le système d'information interne de l'entreprise

(4) SSO = Single Sign-On.

On prévoit donc l'architecture suivante :

Lien avec l'ERP

Le coût par vendredi après-midi au niveau stockage est donc négligeable.

Schématiquement, Azure Service Bus permet ce type de scénario :

On vise donc son utilisation de la façon suivante :

(16)NAT = Network Address Translation.

Modifications à apporter à l'application existante

(21)DNS = Domain Name System

similaires. Voir plus

(22)MEF = Managed Extensibility Framework, voir http://msdn.microsoft.com/en-us/library/dd460648.aspx et

On vise donc schématiquement de procéder comme suit pour l'application ASP.NET :

En aval du processus de build, on aura donc :

(23)IoC = Inversion Of Control.

Saisie depuis l'extérieur de l'entreprise

Si l'application avait été développée dans d'autres technologies

Vous aimerez peut-être aussi