Introduction



Débordement d’une application d’entreprise vers Windows AzureAuteur?: Benjamin Guinebertière, Architecte en système d’informationMicrosoft FranceContributeurs : Xavier Warzee, Architecte en système d’informationStéphane Goudeau, Architecte Microsoft Technology Center (MTC)Microsoft FranceVersion?: 1.0Publication?: Juillet 2010Copyright? 2010 Microsoft Corporation. Tous droits réservés.? 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-UnisTable des matières TOC \o "1-3" \h \z \u I.Introduction PAGEREF _Toc266430082 \h 4II.Scénario PAGEREF _Toc266430083 \h 5III.Conception de la solution PAGEREF _Toc266430084 \h 61.Dimensionnement et opportunité PAGEREF _Toc266430085 \h 72.Mécanisme de débordement PAGEREF _Toc266430086 \h 83.Lien avec le système d’information interne de l’entreprise PAGEREF _Toc266430087 \h 10a)Authentification et autorisation PAGEREF _Toc266430088 \h 10b)Lien avec l’ERP PAGEREF _Toc266430089 \h 154.Déploiement PAGEREF _Toc266430090 \h 215.Modifications à apporter à l’application existante PAGEREF _Toc266430091 \h 226.Considérations complémentaires PAGEREF _Toc266430092 \h 26c)Saisie depuis l’extérieur de l’entreprise PAGEREF _Toc266430093 \h 26d)Utilisation d’un Worker Role pour soumettre les feuilles de temps validées à l’ERP PAGEREF _Toc266430094 \h 26e)Si l’application avait été développée dans d’autres technologies PAGEREF _Toc266430095 \h 26IV.Conclusion PAGEREF _Toc266430096 \h 27IntroductionUne 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. 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 SOAP qui permettent deRécupérer pour un utilisateur la liste des codes et libellés de projets sur lesquels il peut saisir pour la périodeRécupérer la liste des temps déjà saisis sur une périodeSoumettre une saisie de tempsL’application de saisie des temps est une application Web écrite en , 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 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 , 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?? 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 16?000 pers. ×30 req.=480?000 requêtes à servir pendant la période de 4 heures du vendredi après-midi, à savoir 480?000 req.4 h×60 min ×60 sec ?33,3 requêtes par seconde en moyenne, à répartir sur deux 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 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 . En entrant dans le détail () 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 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.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 à 16?000 pers. ×400 Ko1?0242?6,1 Go sortant et16?000 pers. ×100 Ko1?0242?1,5 Go entrant. Un extrait de 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,1 Go ×0,15 $+1,5 Go ×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.Mécanisme de débordementOn prévoit d’avoir deux applications différentes?: timesheet. pour les saisies hors période de pointe et cloudtimesheet. 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. ne serve qu’à rediriger vers cloudtimesheet. 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.. 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..Ainsi, on aetLien avec le système d’information interne de l’entrepriseAuthentification et autorisationLes utilisateurs de timesheet. 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 , 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. Le principe est le suivant?: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 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 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 a besoin pour autoriser l’utilisateur à accéder aux bonnes fonctions de l’application et l’identifier si nécessaire.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). 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?: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. (un jeton peut durer plusieurs heures, ce qui permet d’avoir une sollicitation assez faible du STS). Dans ce cadre, le STS 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 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 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é.Dans les deux cas, on sera donc capable d’authentifier depuis l’application Azure des utilisateurs venant du domaine Active Directory interne . Dans les deux cas, l’expérience utilisateur sera la même que lors de l’utilisation de l’application à demeure timesheet., si ce n’est quelques redirections de navigateur.L’application existante s’appuie sur la notion de r?les 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 à partir des noms de groupes Active Directory. On trouvera des informations complémentaires sur le sujet par exemple à . 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é. Cela se traduira par une revendication de type à partir de l’attribut sAMAccountName d’Active Directory.Ainsi, le code de l’application 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 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’ 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’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?: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 de l’application. A demeure, la session 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. 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 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?16?000 pers. ×200 Ko10242 ×0,15 $*4 h24 h×365 j12 mois+30 req. ×2 ×0,01 $10?000 trans.? 0,00006016?$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 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) à fa?on à ne pas modifier les services Web qui exposent l’ERP, mais également parce qu’on ne peut pas 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 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 à . 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 à 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 $ × 6 h24 h ×365 j12 mois = 0,032794521 $Pour chaque personne qui saisit ses temps, on aura besoin de 2 transactions de contr?le d’accès, ce qui donne16?000 pers. ×2 trans. ×1,99 $100?000 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.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) à et le déploiement est terminé, il est nécessaire de configurer l’application timesheet. de rediriger vers azuretimesheet.. On décide de le faire par configuration des serveurs IIS de la ferme Web interne, comme indiqué à de la création du service Azure, on obtient une URL de type <nom de service>.. Le nom de service contosotimesheet a été configuré. Cependant, on préfère présenter aux utilisateurs l’URL azuretimesheet. plut?t que contosotimesheet.. Pour cela, on ajoute dans le DNS qui gère le nom de domaine le sous domaine azuretimesheet. sous la forme d’un enregistrement de type CNAME qui pointe vers le nom contosotimesheet.. 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. 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. 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 existanteL’application existante timesheet. 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.(à demeure)azuretimesheet.(en nuage)Modification à apporterType de projet Visual StudioApplication Web Role et projet de type ??Windows Azure Cloud Service??Un Web role et une application sont similaires. Voir plus bas.Session Configurée pour être stockée dans SQL ServerConfigurée pour être stockée dans le stockage Windows Azure (non relationnel)Incorporer le???provider?? de session pour les tables Azure et changer la configuration . Il n’y a pas de changement de code de l’application.Moindre sollicitation de l’ERPModification des appels pour ne solliciter l’ERP qu’en tout début et en toute fin de saisieRéutilisation de ces modificationsModification 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’ERPDirecte (via le réseau local)A travers Windows Azure Platform AppFabric Service Bus & Access ControlLa 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, AutorisationUtilisation de la notion de r?le Configuration IIS pour avoir une authentification intégrée où les groupes Active Directory deviennent des r?lesUtilisation de Windows Identity Foundation pour récupérer les claims de type r?le sous forme de r?les 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 AzureInexistantApplication complémentaire déployée sous la forme de services WindowsS’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 comme par exemple l’initialisation de l’appel aux services Web exposant l’ERP. Pour ces parties, on s’appuie sur MEF 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 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 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 classique. Le code de démarrage du Web Role, contenu par défaut dans un fichier WebRole.cs est ignoré par l’application . Pour l’application timesheet., 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 ?: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. et non contosotimesheet.. 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). 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.Considérations complémentairesSaisie 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 . 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 à (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 . 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 .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.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 à 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. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download