. 
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 services Web SOAP(1) 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).
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 :
À 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 instances de rôle Web Azure (pour former une ferme Web(2)).
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 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.
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
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 scénarios de Web SSO(4). Le principe est le suivant :
L'utilisateur, via son navigateur, va vers l'application (1) ou RP(5). 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 STS(6). 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 IP(7) 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 a besoin pour autoriser l'utilisateur à accéder aux bonnes fonctions de l'application et l'identifier si nécessaire(8).
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 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 cette authentification Windows (une application ASP.NET traduit les appartenances à des groupes en des rôles(10)). 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.
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, 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.IsInRole(13) 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 WIF(14) 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 :
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 dans des tables de Windows Azure Storage par exemple(15). 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 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.
De façon à ne pas modifier les services Web qui exposent l'ERP, mais également parce qu'on ne peut pas(17) exposer des services vers Azure Service Bus quand ils sont hébergés dans IIS(18) ou WAS(19), 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 SDK(20) 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
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 azuretimesheet.contoso.com plutôt que contosotimesheet.cloudapp.net. Pour cela, on ajoute dans le DNS(21) 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
(à 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) | Á 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.NET Configuration 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 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 MEF(22) 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 IoC(23) tel que Unity Application Block(24). 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 :
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.
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.