le lab

Parfois, on peut avoir des idées brillantes, faire des choses extra, mais que personne ne le sache. Que se passe-t-il dans ce cas? personne ne vient vous les demander ces choses.

C'est le problème que rencontre mon employeur actuel Witbe. J'essaie d'améliorer sa visibilité par tous les moyens, parce que je pense:

1. Que c'est dommage de ne pas mieux vendre les solutions
2. Que plus il y a aura de clients avec des besoins pointus et mieux je pourrai les aider et valoriser mon expérience
3. Qu'on est loin d'être les plus mauvais (c'est un euphémisme) dans les solutions qu'on apporte
4. Un peu comme mon boss (Jean Michel Planche), je pense que la qualité générale et la réciprocité sur internet sont des choses importantes et on a tous un rôle à jouer, et Witbe peut aider.

A savoir tout faire on n'arrive plus à nous rentrer dans une case

Souvent en France, on pense à Witbe comme à un concurrent de Net Vigie, Net Monitor (non pas de lien vers eux, merci). Cela est un peu la faute à M Séguéla, qui a signé la campagne de lancement de la boite en 2000. Mais nous faisons aujourd'hui beaucoup plus de choses, souvent plus vitales pour une entreprise qu'un site web : applications métiers, citrix, serveurs vocaux interacitfs, et (merci Free et Orange) triple play : data, VOIP et vidéo sur ADSL.

Dès lors, les gens qui ont connu le nom Witbe à son lancement pensent qu'on fait du ping sur Internet, et les étrangers qui arrivent avec leurs besoins de monitoring et d'évaluation de la qualité de leur réseau de IPTV ne savent pas qu'on fait aussi de la mesure de site web scénarisée. Ce grand écart est assez dur à maîtriser, je vous assure. Souvent les clients qui nous connaissent pour un besoin restent collés à leur chaise quand on leur dit tout ce qu'on fait et qu'on leur montre.

Disons clair et net : Witbe ne fait pas du ping internet. Witbe fournit des outils de surveillance, d'analyse et de reporting de la qualité d'expérience. Et derrière les mots? Plutôt que de faire un ping www.monentreprise.fr, on a des sondes au japon qui vérifient qu'un internaute sous IE va pouvoir accéder au site, voir les produits normalement accessibles, les mettre dans le panier et les payer. On va vérifier qu'une set top box en bout de chaîne, chez l'utilisateur, va être capable de faire du data et de la vidéo en même temps, en maintenant un temps de zapping raisonnable et une qualité d'image acceptable par les utilisateurs. On va déterminer en combien de temps on obtient un téléconseiller chez Air France ou BNP, en passant par le serveur vocal interactif, depuis une ligne mobile, ou depuis une ligne RTC (fil de cuivre classique).

Ces questions, et la capacité à y répondre, cela dépasse un peu le ping sur internet. Et cela intéresse certainement plus les gens du marketing ou du commercial, voir la direction générale de savoir ces informations que de savoir que vous perdez 1564 paquets et que la latence à l'intérieur de votre réseau est seulement de 25ms : on traduit des données complexes en des services simplement quantifiables. A la fin, on met un soleil ou un nuage.

Mais on est capable de parler aux gens de l'exploitation, aux développeurs, aux gens du réseau. On a des outils uniques, comme le smartping, qu'on entrevoit dans une de ses fonctionnalités les plus spectaculaires sur ce post de Jean Michel. On a bien évidemment la trace des temps de résolution dns, connexion tcp et corps de page, on a la capture d'écran de la page en erreur pour montrer ce qui ne va pas. On a les croisements entre différentes mesures pour montrer si c'est l'appli, le réseau ou internet qui est à la racine sur problème. Bref, on est capable d'analyser. Je passe sur les discussion de MOS, de PESQ et d'autres mots barbares que mon voisin de bureau me fait subir chaque jour.

Comment résoudre le problème?

C'est quoi le problème, d'abord? Il y en a plusieurs :

• on nous compare à NetVigie ou Net Monitor
• on ne voit pas nos solutions applications métiers ou svi : les mesures dans les entreprises
• on a tout bousculé avec nos solutions pour la TV et le triple Play

Pour le 1, cela fait partie de ma mission. Je ne suis pas seul à la tâche, heureusement. De la même façon que je recense les meilleurs trucs du web, je vais mettre en scène les solutions Witbe pour répondre aux problèmes des décideurs d'internet : comment assurer la qualité de mes principales applications critiques sur internet, comment utiliser les solutions witbe pour déterminer les domaines de responsabilité, comment utiliser Witbe pour benchmarker mes développements ou mes déploiements? Le screencast me semble une bonne solution, il faut juste que je trouve des cobayes pour montrer les différents types de problèmes que l'on peut rencontrer. Attention, ce qu'ils font, on peut aussi le faire : vous envoyer un sms quand votre site n'est pus accessible sur internet depuis Paris, c'est dans nos cordes.

2. Nos présentations avant vente elles même ne mettent pas en scène les applications métiers. Faut dire que c'est chiant. Mais bon, les responsables d'application de gestion de stock ressentent un pincement au cœur en voyant leur interface 3270 de consultation. Et pour eux c'est vital qu'en entrepôt ou en magasin, on sache tout de suite le nombre de refs dispo d'un article que le vendeur a l'acheteur qu'il est là en personne devant lui. S'il lui faut 2 minutes pour savoir que l'EOS 40D du monsieur est à la Fnac de Ternes, et pas celle des Champs, le monsieur est parti.

3. Difficile de gérer une solution tellement bien ficelée que tout le monde ou presque s'y intéresse. La croissance dans ce domaine est importante, grâce à l'avance que la France a dans le domaine, et c'est le patron qui le dit. Après tout nous ne sommes qu'une petite boite française. La solution : être mille fois meilleurs dans la formation et le support aux partenaires pour s'appuyer sur des clients maîtrisant nos solutions, et des partenaires qui les vendent bien.

Tout cela n'est que de la mise en scène et de la mise en œuvre d'un savoir faire dont nous disposons déjà mais que nous ne répandons pas assez. Cela rejoint un peu le triste constat que j'avais fait sur Velocity, la conférence tenue aux US, mais sans équivalent en Europe. Pour noptre part, et par rapport aux opérateurs et aux relations que nous avons dans le domaine de la qualité, nous avons déjà soutenu des travaux de mise en commun des ressources, avec nos journées opérateurs ou nos journée de la qualité. Faut il qu enous étendions cette ouverture à d'autres domaines? Oui, certainement, mais pas seuls. Or j'ai du mal à identifier les acteurs qui veulent nous accompagner dans cette démarche.

PS : ces commentaires ne sont que mes commentaires personnels et ne reflètent pas forcément l'opinion de mon employeur.

James Duncan Davidson fait partie des gens que je suis sur Twitter, parce que c'est un excellent photographe et un excellent développeur (avec quelques contributions majeures à son actif, comme tomcat). Il parcourt aujourd'hui les états unis en suivant les conférences, notamment certaines de O'Reilly.

C'est en suivant ses tweets que j'ai découvert Velocity : la conférence sur l'opération des sites Web et la performance (OK mauvaise traduction). Un événement qui a eu lieu il y a quelques semaines déjà, et où on a reparlé de performance, d'outils de mesures, de moyens d'améliorer la rapidité des pages web, d'améliorer la perception des internautes. Comme c'est un sujet qui m'intéresse et sur lequel j'ai écrit un e-book, je regrette un peu d'avoir appris cette conférence un peu tard.

Je regrette aussi beaucoup que ce genre d'événement ne traverse jamais la mare. On parle en effet assez peu de problématiques et des stratégies d'amélioration des performances de ce côté de l'atlantique. Du moins en public. On a l'impression que les sites sont tous super rapides. Et pourtant ce n'est pas le cas.

Les présentations sont pour la plupart disponibles sur le site de O'Reilly dédié à l'événement : http://en.oreilly.com/velocity2008/public/schedule/proceedings et je vous invite chaudement à toutes les lire si le sujet vous paraît plus ou moins intéressant. Notamment les présentations de Steve Souders qui sont toujours aussi intéressantes.

J'ai écrit une petite application en Rails qui s'appelle "D'ici ça marche" et qui regarde si un serveur web fonctionne depuis l'application.

Souvent en effet on se demande si un serveur web est indisponible uniquement de chez soi ou pour tout le monde. L'idée est donc de se mettre ailleurs dans le réseau (en l'occurrence chez Dedibox, mon fournisseur) pour voir si le service fonctionne depuis cet endroit.

Alors j'ai fait simple et court. Je regarde exactement le nom de serveur qui est donné. Par exemple google.fr ça marche pas, mais www.google.fr marche.

Essayez le et dites moi si pour vous aussi ça marche.

Aujourd'hui, j'ai fait quelque chose que j'avais décidé il y a plusieurs semaines : j'ai mis mon deuxième e-book (Maximum performance) en téléchargement et consultation gratuite.

Comme je n'ai pas modifié le texte lui même, je tiens à dire que bien que le contenu de ce site et du livre soient offerts gratuitement, ils ne sont en aucune façon libres : j'accorde le droit de publier, de partager, mais pas de modifier le contenu. Que ce la ne vous empêche pas toutefois d'écrire un livre ou des articles sur le même sujet, ou d'essayer de me convaincre de rendre le livre libre.

J'ai un peu recommencé à faire du dev en Rails et j'ai notamment mis à niveau en Rails 2.0 une appli que j'ai pour un site. Et j'ai lu ensuite le mode d'emploi, c'est à dire la liste des changements. Elle est disponible ici.

Ce que j'ai particulièrement apprécié, ce sont ces deux paragraphes :

We’ve also made it much easier to structure your JavaScript and stylesheet files in logical units without getting clobbered by the HTTP overhead of requesting a bazillion files. Using javascript_include_tag(:all, :cache => true) will turn public/javascripts/.js into a single public/javascripts/all.js file in production, while still keeping the files separate in development, so you can work iteratively without clearing the cache.

Along the same lines, we’ve added the option to cheat browsers who don’t feel like pipelining requests on their own. If you set ActionController::Base.asset_host = “assets%d.example.com”, we’ll automatically distribute your asset calls (like image_tag) to asset1 through asset4. That allows the browser to open many more connections at a time and increases the perceived speed of your application.

Ce que cela signifie : une concaténation des fichiers javascripts en un seul entre le développement et la production, une excellente idée que je pousse à fond dès que je vois un site avec 5 js qui ralentissent son affichage. Rails prouve encore une fois à quel point c'est un framework agile en prenant en compte ce besoin.

L'autre partie, c'est l'usage de la parallélisation des fichiers de ressources pour essayer d'exploiter un maximum de connexions pour un navigateur donné ( et surtout IE).

Wow! Je ne pensais pas que des recommandations de performance pouvaient ainsi traverser l'ether et revenir directement dans un framework. Il faut croire qu'il y a des gens intelligents et qui écoutent.

J'aimerais que la notion de cache Http et de compression des ressources texte soient aussi bien intégrés, mais je pense qu'il faudrait que je m'y colle, ce qui n'est pas de mon niveau vraiment. On laissera ces problématiques aux serveurs web (qui sont certainement plus adaptés pour cett question).

Cet article est le troisième d'une série de quatre articles sur les réseaux de distribution de contenus, ou Content Delivery Network (CDN).

Je ne vais pas rentrer dans le détail du fonctionnement des CDN, mais juste effleurer les principes, éventuellement citer un ou deux exemples de fonctionnement dans des cas réels.

Tout d'abord, les différents fournisseurs n'expliquent pas tout le fonctionnement de leurs infrastructures (il y a une question d'avantage compétitif) et de leurs serveurs. Ce n'est pas encore un marché où l'offre est apparemment mature, et la technologie préside beaucoup à l'intérêt et à l'efficacité d'un CDN.

Ensuite, les différences vont souvent dans des niveaux techniques qui ne sont pas intéressants à mon propos : le but est de vous faire comprendre les concepts de base, nécessaires à l'évaluation de l'impact sur votre travail.

Plusieurs principes et gros mots sont utilisés dans le travail des CDN :

• redirection
• serveur surrogate
• routage des requêtes
• réplication
• synchronisation

Les besoins des fournisseurs de contenu

On l'a vu dans le post précédent, le CDN est là pour rendre le contenu plus accessible. Ce contenu a en effet une valeur (commerciale) car d'une manière ou d'une autre il est vendu aux visiteurs des sites, à travers de la publicité, de l'abonnement à un service, parce qu'il s'agit d'un besoin marketing de promotion d'un produit...

Ces fournisseurs de contenu veulent aussi garder le contrôle de leur contenu, être capables de comptabiliser le trafic, être capables de le mettre à jour de manière à ce qu'il soit bien frais. Des parties de sites sont personnalisées, avec gestion d'identification et de compte, d'autres sont sécurisées au niveau du protocole (https) , avec à la fois cryptage des données et identification confiante du fournisseur de l'information.

Les CDN vont répondre à ces différents besoins en mettant l'accent sur l'accessibilité.

Les serveurs surrogates

Ce qui fait l'extensibilité d'un réseau de CDN est le nombre de serveurs surrogate. Pardonnez l'anglicisme : un serveur surrogate est un serveur 'qui prend la place', qui se substitue. Il se substitue au serveur d'origine, celui qui détient véritablement l'information, fraîche.

Le nombre et la position des serveurs qui peuvent se substituer au serveur d'origine est un des éléments qui sont commercialisés par les CDN : plus leurs serveurs de substitution sont proches de tous vos visiteurs, plus vous avez de chance de servir vite les ressources.

Comment se fait la substitution?

Il y a un élément central dans le fonctionnement qui va contrôler la manière dont se fait la substitution des ressources à l'origine par celles qui sont dans les serveurs surrogate. Cet élément, l'algorithme sur lequel il repose va conditionner l'efficacité des serveurs de substitution.

La substitution d'un serveur d'origine par un serveur de CDN peut se faire par redirection ou par routage différent. La redirection implique qu'un serveur renvoie une réponse de type 307 temporary redirection et fournisse une nouvelle url pour une ressource. Cette redirection peut aussi être plus discrète, et ne pas comprendre de modification de l'adresse de la ressource (ce qui n'estjamais terrible pour le cache).

Le routage peut faire pointer la requête directement vers un serveur qui va la servir en se faisant passer pour le serveur d'origine.

J'ai essayé d'illustrer le fonctionnement des deux techniques dans les deux diagrammes illustrés et animés suivant. Le premier décrit une redirection, le deuxième un routage vers un serveur de substitution.

Ne vous laissez pas leurrer par la durée des représentations : il n'y a pas d'avantage chronomètre entre les deux techniques de manière systématique. La performance est le résultat d'un tel nombre de paramètres, tous fluctuants, que la performance réseau de ces deux techniques est comparable.

Comment ces mécanismes de redirection fonctionnent, c'est le problème des CDN. Ce qui est important pour vous c'est l'impact sur votre architecture et votre service. En l'occurrence, rien n'est à faire pour vous, tout se passant en amont de votre serveur d'origine.

La réplication

Ce qui peut avoir plus d'impact direct pour vous, c'est l'usage et le fonctionnement de la réplication. En effet, pour que les serveurs de substitution soient efficaces, il leur faut des données. Ces données peuvent être soit déposées soit cherchées. C'est soit du pull, soit du push.

Le push, c'est le fait d'aller déposer dans le CDN vos ressources. Vous les poussez dedans. Dans les cas concrets, cela correspond souvent à l'utilisation d'une zone de stockage externalisée : le coût de développement d'un système de duplication des ressources sur toute l'infrastructure de distribution est mutualisé chez le CDN. Celui traite dont les problèmes inhérents à ce mode de réplication : fiabilité, taille du stockage, surconsommation de la bande passante.

Le pull est généralement préféré par les CDN, car il implique un transfert des ressources en fonction du besoin, et donc pas de surconsommation de la bande passante ou du stockage. C'est totalement compatible avec une zone de stockage externalisée. Dans ce cas, les serveurs surrogates remplissent leur office de cache : ils vérifient qu'ils ont la ressource et qu'elle est fraîche, et sinon, il vont la tirer du serveur d'origine (pull).

Dans le cas où le système est en push, cela implique pour vous de publier les ressources soit directement dans le réseau de contenu, soit dans la zone de stockage tampon. Vous avez un travail important à faire.

Si le système est en pull, l'action se situe au niveau des serveurs surrogate. L'impact pour vous est nul, ou presque : vous n'avez pas besoinde déposer les fichiers dans une zone de stockage tampon, de changer leur url etc. Bien sûr il existe un ensemble de meilleures pratiques valables pour les services des CDN comme pour les web classiques.

Contrôle

Il est important pour les fournisseurs de contenu de pouvoir garder le contrôle des ressources qui sont servies. Par contrôle, j'entends d'abord contrôle pour dire si les ressources doivent être servies ou pas par le CDN, ensuite contrôle de la fraîcheur (un vieux problème avec les caches) et enfin contrôle de l'utilisation des ressources (statistiques etc).

Le contrôle de quels éléments sont servis ou pas par le CDN se fait souvent en choisissant un nom de domaine différent pour ces ressources. Cela va en général de pair avec une bonne gestion des noms de domaines pour les cookies, les directives de cache etc. Si on ne veut pas avoir le choix, on peut aussi mettre toutes les ressources dans le CDN, en lui confiant son nom de domaine. L'idée est que le CDN devient proxy pour toutes les requêtes qui sont adressées au serveur d'origine, et qu'il sert les ressources uniquement quand il les a en cache et qu'elles sont cachables, qu'il transmet la requête au serveur d'origine quand il n'est pas capable de le faire.

Le contrôle de la fraîcheur est un problème aussi vieux que le cache : en donnant l'autorisation à un cache de cacher une ressource, on lui délègue le pouvoir d'invalider la ressource. Il faudrait pour conserver le contrôle être capable de recenser tous les serveurs de cache qui ont enregistré une ressource, et quelle ressource. Un travail colossal, entraînant un trafic colossal quand on désire invalider... D'autres solutions sont en cours de définition, notamment grâce au travail de Mark Nottingham, mais elles doivent encore se répandre et prouver leur efficacité.

Dans le cas des serveurs des CDN, les fournisseurs de contenu, on un périmètre connu, recensé et simple à valider pour valider ou invalider la fraîcheur de certaines ressources. Il est alors possible de dire qu'une ressource ou un ensemble de ressources ne sont plus frais, et d'accéder à une interface de gestion qui permet de les invalider. Des API sont souvent disponibles pour invalider directement à partir de votre infrastructure les ressources que vous désirez.

Le monitoring et les statistiques font partie des questions que les CDN vont savoir gérer rapidement : il leur faut aussi être capable de stocker le volume et le type de requêtes et de ressources demandées pour pouvoir vous adresser une facture. Leurs outils pour faire ce calcul de facture sont disponibles aussi pour les clients. Ils servent aussi à mettre en exergue les problèmes qui peuvent exister (requêtes vers des ressources inexistantes, problèmes de connexions etc). Pour pouvoir récupérer des logs de trafic HTTP consolidés, il faut le demander. Vous urez intérêt à avoir un outil de statistiques de trafic extérieur en javascript pour continuer à observer votre trafic sans couture (un google analytics, un mint hébergé sur un domaine non CDN ou un Omniture).

Bien évidemment, chaque CDN a ses spécificités, ses avantages compétitifs, son réseau de serveurs et de caches, mais tous fontionneront aujourd'hui en mettant en œuvre le meilleur mix entre réplication, redirection, routage et contrôle. Une étude un peu datée a esayé de faire un suivi et une taxonomie des CDN. Cette taxonomie est très américanophile (ils ont plus de CDN que la France car la latence est un problème plus important dans leur pays).

Dans le dernier article, j'aborderai les meilleures règles à mettre en œuvre pour profiter pleinement d'un CDN, celles qui permettent de s'en passer le plus longtemps possible, et j'essaierai de mettre en avant les critères permettant de faire une taxonomie permanente des CDN disponibles pour la France.

A partir de lundi, j'ai la chance de travailler pour Witbe, un des pionniers de la supervision vision client sur internet, et le leader français.

Je vais travailler en tant que consultant au sein du groupe 'business solutions' qui a vocation à fournir des solutions orientées métier, prototypes ou non, à réaliser des audits complets et à faire des pilotes. Des activités qui étaient un peu dispersées au sein de l'entreprise, et qui s'appuient sur la structure existante, notamment l'entité professional services.

Comme le métier de Witbe est très proche du sujet de cette catégorie de blog, je ferai particulièrement attention au mélange des genres. Je tiens ainsi à préciser systématiquement que mes positions ne reflètent pas forcément celles de mon employeur, et qui est celui ci dans chacun des posts. Ce blog ne deviendra pas toutefois un moyen de communication de Witbe : le site de l'entreprise est là pour ça, et peut être les évolutions de ce site seront elles le moyen de développer ce blog avec plus d'études de cas, de livres blancs etc.

Vous voilà prévenus ;-)