Débordement d’une application d’entreprise

vers Windows Azure

Auteur : Benjamin Guinebertière, Architecte en système d’informationMicrosoft France

Contributeurs : Xavier Warzee, Architecte en système d’informationStéphane Goudeau, Architecte Microsoft Technology Center (MTC)Microsoft France

Version : 1.0Publication : Juillet 2010

Copyright

© 2010 Microsoft Corporation. Tous droits réservés.

Page 1

© 2010 Microsoft Corporation. Tous droits réservés.

Les informations contenues dans ce document représentent le point de vue actuel de Microsoft Corporation sur les sujets traités à la date de publication. Etant donné que Microsoft doit s’adapter aux conditions changeantes du marché, ces informations ne doivent pas être interprétées comme un engagement de la part de Microsoft, et Microsoft n’est pas en mesure de garantir l’exactitude de toute information présentée après la date de publication.

MICROSOFT NE DONNE AUCUNE GARANTIE EXPRESSE OU IMPLICITE DANS CE DOCUMENT.

Les autres noms de produits ou de sociétés cités dans ce document peuvent être des marques de leurs propriétaires respectifs.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • Etats-Unis

Page 2

Table des matières

I. Introduction..........................................................................................................................................4

II. Scénario................................................................................................................................................5

III. Conception de la solution.................................................................................................................6

1. Dimensionnement et opportunité....................................................................................................7

2. Mécanisme de débordement...........................................................................................................8

3. Lien avec le système d’information interne de l’entreprise...........................................................10

a) Authentification et autorisation.................................................................................................10

b) Lien avec l’ERP............................................................................................................................15

4. Déploiement...................................................................................................................................21

5. Modifications à apporter à l’application existante.........................................................................22

6. Considérations complémentaires...................................................................................................26

c) Saisie depuis l’extérieur de l’entreprise......................................................................................26

d) Utilisation d’un Worker Role pour soumettre les feuilles de temps validées à l’ERP..................26

e) Si l’application avait été développée dans d’autres technologies..............................................26

IV. Conclusion......................................................................................................................................27

Page 3

I. IntroductionUne 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étails d’un document de spécifications générales.

Page 4

II. ScénarioLa 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 performance 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 services Web SOAP1 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.

Page 5

III. Conception de la solutionDe 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 :

A 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 ?

Page 6

Comment l’application pourra-t-elle être modifiée de façon à pouvoir s’exécuter à la fois à demeure et dans Azure ?

1. 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 (16000 pers.×30 req . )=480000requêtes à servir pendant la période de 4 heures du

vendredi après-midi, à savoir 480000 req.

4h×60min×60 sec≅ 33,3 requêtes par seconde en moyenne, à répartir

sur deux instances de rôle Web Azure (pour former une ferme Web2).

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 :

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 dans le détail (http://bit.ly/bcNpwO) on trouve que le prix d’une heure de petite instance est de 0,12 $3. Sachant que la facturation est à l’heure et qu’on démarrera l’application un peu avant 14h pour l’arrêter un peu après 18h, on vise une consommation de 6 heures pour les calculs. Cela correspond donc à 0,12$×2 (car instance moyenne )×2 instances×6 h=2,88 $ par vendredi après-midi.2 Les SLA de Windows Azure sont valables à partir de deux instances uniquement3 Tous les prix indiqué 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.

Page 7

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 à 16000 pers.×400Ko10242

≅ 6,1Go sortant et

16000 pers.× 100Ko10242

≅ 1,5Go 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 6,1Go×0,15$+1,5Go×0,10 $≅ 1,07$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.

2. Mécanisme de débordementOn 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.

Page 8

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 4 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

Page 9

3. Lien avec le système d’information interne de l’entreprise

a) Authentification et autorisationLes 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 scénarios de Web SSO4. Le principe est le suivant :

L’utilisateur, via son navigateur, va vers l’application (1) ou RP5. 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 ou STS6. 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 Windows par exemple. Le STS, s’appuie sur le fournisseur d’identité ou IP7 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.

4 SSO = Single Sign-On5 RP = Relying Party6 STS = Security Token Service7 IP = Identity Provider

Page 10

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 a besoin pour autoriser l’utilisateur à accéder aux bonnes fonctions de l’application et l’identifier si nécessaire8.

Sur la plateforme Microsoft, les technologies de base permettant d’implémenter cela sont Active Directory Federation Services 2.0 (ADFS V2) et Windows Identity Foundation (WIF)9. ADFS V2 est un STS qui s’appuie sur l’IP Active Directory. WIF quand à 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 :

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 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.

Page 11

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çu avec cette authentification Windows (une application ASP.NET traduit les appartenances à des groupes en des rôles10). Dans le cadre du développement d’une application simple, avoir un STS spécifique peut permettre un déploiement plus rapide. C’est cependant moins pérenne que la mise en place d’ADFS V2 qui permettra plus facilement de mettre en place de la fédération d’identité entre forêts, ou même avec d’autres implémentations du marché11.

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.

10 Voir par exemple http://msdn.microsoft.com/en-us/library/system.security.principal.windowsprincipal.isinrole.aspx 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

Page 12

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 concernent cet utilisateur précis. Dans l’application à demeure, c’est le compte Active Directory qui est utilisé12. 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.

Ainsi, le code de l’application ASP.NET existante qui effectue des appels de type User.Name ou User.IsInRole13 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 sont les modules HTTP de WIF14 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.

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

Page 13

b) Lien avec l’ERPL’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 :

Page 14

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. A demeure, la session ASP.NET peut être stockée dans SQL Server par exemple. Sur Azure, elle peut être stockée dans des tables de Windows Azure Storage par exemple15. 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 4 heures (on peut supprimer toutes les valeurs de session en fin de vendredi après-midi) et qu’on a 2 transactions de stockage par requête HTTP (1 lecture, 1 mise à jour). Cela donne une estimation de coût de l’ordre de

16000 pers.×(200Ko10242×0,15 $∗4 h

24h×365 j12mois

+30req .×2× 0,01$10000 trans. )≅ 0,00006016$

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

15 Cf http://blogs.msdn.com/b/jnak/archive/2009/11/19/using-the-sample-windows-azure-asp-net-providers.aspx

Page 15

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 NAT16 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 :

16 NAT = Network Address Translation

Page 16

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.

Page 17

De façon à ne pas modifier les services Web qui exposent l’ERP, mais également parce qu’on ne peut pas17 exposer des services vers Azure Service Bus quand ils sont hébergés dans IIS18 ou WAS19, 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 binding fourni par le SDK20 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

17 Voir http://vasters.com/clemensv/PermaLink,guid,3cc2bb9c-9a43-4c4c-9fdb-1f7bbfcaec43.aspx 18 IIS = Internet Information Services19 WAS = Windows Process Activation Service20 SDK = Software Development Kit

Page 18

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 (6 heures car on compte la mise en place avant et après, comme vu plus haut) :

3,99$× 6h24h×365 j12mois

=0,032794521$

Pour chaque personne qui saisit ses temps, on aura besoin de 2 transactions de contrôle d’accès, ce qui donne

16000 pers .×2 trans .× 1,99 $100000 trans

=0,6368 $

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.

Page 19

4. DéploiementLe 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 azuretimesheet.contoso.com plutôt que contosotimesheet.cloudapp.net. Pour cela, on ajoute dans le DNS21 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.

21 DNS = Domain Name System

Page 20

5. Modifications à apporter à l’application existanteL’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(à demeure)

azuretimesheet.contoso.com(en nuage)

Modification à apporter

Type de projet Visual Studio

Application ASP.NET Web Role et projet de type « Windows Azure Cloud Service »

Un Web role et une application ASP.NET sont similaires. Voir plus bas.

Session ASP.NET Configurée pour être stockée dans SQL Server

Configurée pour être stockée dans le stockage Windows Azure (non relationnel)

Incorporer le « provider » de session ASP.NET pour les tables Azure et changer la configuration ASP.NET. Il n’y a pas de changement de code de l’application.

Moindre sollicitation de l’ERP

Modification des appels pour ne solliciter l’ERP qu’en tout début et en toute fin de saisie

Réutilisation de ces modifications

Modification de la logique applicative pour mieux séparer la logique métier de la cinématique de l’interface utilisateur (UI Process)

Connexion aux services Web de l’ERP

Directe (via le réseau local)

A travers Windows Azure Platform AppFabric Service Bus & Access Control

La logique d’appel des Web Services reste la même. Comme pour tout code WCF, certaines parties spécifiques aux bindings peuvent être dans du code ou de la configuration.

Authentification, Autorisation

Utilisation de la notion de rôle ASP.NETConfiguration IIS pour avoir une authentification intégrée où les groupes Active Directory deviennent des rôles

Utilisation de Windows Identity Foundation pour récupérer les claims de type rôle sous forme de rôles ASP.NET

Vérification qu’il n’y a pas de dépendance directe à un WindowsPrincipal, mais uniquement à IPrincipal, changement de la configuration web.config.

Service de lien Azure

Inexistant Application complémentaire déployée sous la forme de services Windows

S’appuie essentiellement sur le RoutingService de 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

Page 21

code peuvent ne pas être communes comme par exemple l’initialisation de l’appel aux services Web exposant l’ERP. Pour ces parties, on s’appuie sur MEF22 qui permet de gérer des composants enfichables. Il est à noter que l’on pourrait également préférer d’autres approches comme l’utilisation d’un conteneur de type IoC23 tel que Unity Application Block24. 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.

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 23 IoC = Inversion Of Control24 Cf http://msdn.microsoft.com/en-us/library/ff647202.aspx

Page 22

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 contostesttimesheet.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.

Page 23

En aval du processus de build, on aura donc :

Lors du développement, des tests sont effectués dans un environnement d’intégration spécifique (1). A 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.

NB : 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.

Page 24

6. Considérations complémentaires

c) Saisie depuis l’extérieur de l’entrepriseSachant 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 leurs 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.

d) Utilisation d’un Worker Role pour soumettre les feuilles de temps validées à l’ERPOn 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éponses 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.

e) Si l’application avait été développée dans d’autres technologiesLe 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/.

Page 25

IV. ConclusionLe 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.

Page 26