Voici une synthèse des principaux éléments de l’épisode 120 du Cloud Cover Show que je vous engage à regarder.

 

Dans cet épisode, Nick Harris et James Baker parlent d’un nouveau service en cours de développement (en open source) appelé “Service Gateway”.

NB: je ne traduis volontairement pas ici “service gateway” par passerelle de service.

 

James Baker a rejoint récemment l’équipe Corp. d’évangélisation Windows Azure. Avant cela, il a développé pendant plusieurs années au sein de Microsoft, en particulier sur SQL Server Integration Services (SSIS ), HDInsight, et Windows Azure Active Directory.

A quoi répond Service Gateway ? Lorsqu’on développe une application et qu’on ajoute de plus en plus de choses dedans, elle deivent de plus en plus grosse et de moins en moins agile. Les développeurs Web ont plusieurs approches pour résoudre cela. Avec Service Gateway, une de ces approches est utilisée: la décomposition de l’application; les différentes parties de l’application sont séparées de façon à ce qu’elles puissent être gérées avec des technologies différentes, par des équipes différentes, ce qui facilite par exemple les mises en production et redonne de l’agilité. Cependant, une fois qu’on a la recherche d’un côté, la gestion des commandes d’un autre côté etc., il est nécessaire d’avoir une façade qui unifie l’ensemble sous un même espace de nom, un même look, un même mécanisme d’authentification. C’est ce que doivent faire des services comme bing, Facebook ou Office365. Pour des applications telles que des application d’éditeurs de logiciels ou d’entreprises, on veut proposer la service gateway pour aider à résoudre ce problème. L’idée ici est de mutualiser tout un tas de services, et de le faire en hébergeant en frontal un service commun qui gère le début de la requête (ex: authentification)  et aussi la fin (ex: ré-écriture d’URL). La service gateway peut également prendre en charge - autre exemple de service commun - la télémétrie, et présenter l’analyse des logs web.

La service gateway est encore en cours de développement, en open source, à http://sg.codeplex.com/, et on peut l’utiliser sous forme binaire (IT ops) ou sous forme de code source (dev). Elle joue le rôle de reverse proxy, mais les notions telles que ARR, ou l’URL rewriting d’IIS (qui est utilisée par la service gateway) n’ont pas besoin d’être connues par ses utilisateurs. Il y a une configuration en JSON qui simplifie la ré-écriture d’URL par rapport à des expressions régulières par exemple.

Pour les IT ops, il y a une console qui permet de configurer les rôles, la sécurité, les analyses de logs, ou encore déployer la gateway.

La première chose à faire est de configurer les rôles. Les rôles sont les différents composants de l’application. Pour prendre un exemple très simple, si l’on crée un rôle “Search” qui a comme url de base http://search.myapp.com, cela signifie que si l’on arrive sur la service gateway avec /search, cela sera en fait servi par ce qui est à http://search.myapp.com. Un point important ici est que le rôle qui rend le service n’a pas besoin de savoir qu’il est derrière la service gateway. En utilisant la configuration en JSON, on peut aussi configurer assez simplement de l’A/B testing ou un pourcentage du trafic va vers un service, le reste allant vers un autre service, et ce de façon à savoir lequel des deux services A ou B plaît le plus aux utilisateurs. Cela peut servir aussi dans des environnements mutualisés (multi locataires, “multitenant”) où l’on envoie une partie des clients sur un rôle et une autre partie des clients sur un autre rôle. Aujourd’hui cette notion de “flights” est basée sur les utilisateurs, les locataires, l’adresse IP source ou une séparation en pourcentage de trafic (ex: 20% sur rôle 1, 80% sur rôle 2).

Une autre chose possible est de configurer la sécurité. On peut simplement ajouter à l’application une authentification Windows Azure Active Directory. Même si les outils de Visual Studio 2013 simplifient cette tâche, avoir cette authentification au niveau de la service gateway permet de le faire une fois pour tous les composants.

Ensuite, il faut déployer la service gateway sous la forme d’un role dans un cloud service Azure. Il est à noter qu’une fois que la service gateway est déployée elle peut prendre en compte des nouvelles configurations sans être redéployée. Nick et James montrent alors une service gateway déjà déployée, à laquelle on commence par s’authentifier avec Windows Azure Active Directory. Ensuite, par défaut on arrive sur la console de la service gateway elle-même. Ici, ils ont fait en sorte que /iptest pointe sur le blog de Nick Harris. Bien que le blog ne sache pas qu’il est dans ce cas derrière la service gateway, cette dernière ré-écrit les URL des liens internes au blog.

On voit ensuite comment configurer la télémétrie et les “application analytics”. Comme toutes les requêtes de l’application passent par la service gateway, cela permet d’avoir une vue d’ensemble. Via Azure diagnostics, les logs de toutes les instances de la service gateway (c’est elle-même une ferme web) sont récupérées et envoyées vers des blobs du stockage Windows Azure. Ensuite, ces logs peuvent être analysés via le nouveau service Hadoop de Windows Azure: HDInsight, qui peut traiter de gros volumes de logs. Lorsque Yahoo! a commencé à implémenter Hadoop, c’est exactement ce qu’ils voulaient faire, à savoir analyser les clics sur leur application. Depuis la console de la service gateway, on peut configurer le cluster HDInsight que l’on veut utiliser pour analyser les données, voir les résultats, avoir une connectivité vers Excel pour utiliser Power Query et Power View. HDinsight aura réduit le volume des données collectés par la service gateway et fourni un volume facile à manipuler dans Excel.

Parmi les choses envisagées pour le futur, il y a la géodistribution, en s’appuyant sur Traffic Manager.

Le code est disponible sur http://sg.codeplex.com. La solution Visual Studio contient un projet “CloudProject” pour le déploiement (clic droit, publish), un certain nombre d’assemblys pour la configuration dynamique, la console, le site web lui-même (Router), … On peut aussi déployer en dehors de Windows Azure, cela doit fonctionner et servir de reverse proxy. Même si la service gateway est faite pour bien fonctionner avec Windows Azure, son fonctionnement hors Windows Azure est aussi un des buts.

Dans le projet de déploiement Windows Azure “CloudProject”, on peut changer deux paramètres:

  • l’endroit où se trouve la configuration qui peut typiquement être un blob Windows Azure en json
  • l’endroit où les logs et les traces vont (un compte de stockage Windows Azure)

Un bon endroit pour discuter de la service gateway est sur le site codeplex du projet.

 

Voici quelques copies d’écrans de l’épisode avec les time code:

image_thumb

 

image_thumb[1]

 

image_thumb[2]

 

image_thumb[3]

 

image_thumb[5]

image_thumb[6]

 

image_thumb[7]

image_thumb[8]

image_thumb[9]

image_thumb[10]

 

image_thumb[11]

image_thumb[12]

image_thumb[13]

image_thumb[14]

image_thumb[15]

image_thumb[16]

image_thumb[17]

image_thumb[18]

image_thumb[19]

image_thumb[20]

image_thumb[21]

image_thumb[22]

image_thumb[23]

 

Smile

Benjamin (@benjguin)