A l'analyse de l'
architecture ouverte de Google Buzz, on découvre que celui-ci s'appuie entre autres sur le
protocole Pubsubhubbub pour signaler les nouveaux "buzzes" à des tierces parties intéressées par ces nouveaux éléments de contenus juste publiés.
En effet, il serait impensable et insoutenable pour qui que ce soit d'envisager de crawler et re-crawler en permanence les 174 millions de flux Atom potentiellement issus des utilisateurs Gmail (les
"Gmailers" sont en effet estimés 174 millions) pour tenter d'y découvrir ces nouveaux éléments juste publiés.
En effet, à moins d'une
infrastructure de crawling colossale à la Google (2 millions de machines), il est impossible de "visiter" une telle quantité de flux Atom pour détecter les changements. Le rendement d'une telle activité serait catastrophique alors que son coût serait exhorbitant.
Il fallait trouver un chemin plus efficace: c'est la raison d'être de Pubsubhubub. Son architecture est basée sur 3 types d'acteurs :
- les éditeurs de contenu ("publishers") : leurs utilisateurs publient des nouveaux éléments de contenus (articles, micro-blogs, etc...) au gré de leurs activités
- les concentrateurs ("hubs"): les éditeurs signalent à ces concentrateurs les nouveaux éléments de contenus dès leur parution. L'intérêt: l'éditeur signale une seule fois et il peut atteindre en cascade via le concentrateur des milliers de services à l'écoute de son activité...
- les abonnés: ce sont tous les services Internet qui ont annoncé - par échange de messages idoines - au(x) concentrateur(s) leur intérêt pour 1 ou N (N pouvant être des millions) flux d'information issus des éditeurs. Dès qu'il est notifié par un éditeur, le concentrateur répercute instantanément (en tout cas, il essaie...) les abonnés de la présence d'un nouveau contenu sur le flux Atom ou RSS d'intérêt. Le concentrateur pousse même l'efficacité jusqu'à livrer le nouvel élément de contenu lui-même avec la notification de sa naissance.
Selon ce schéma, on voit qu'une efficacité globale émerge au niveau de l'infrastructure de l'Internet émerge:
- les nouveaux contenus se propagent en temps réel vers tous ceux qui ont manifesté de l'intérêt
- l'infrastructure des abonnés peut rester très faible: ils ne sont pas obligés de déployer comme Google, 2 millions ou plus de serveurs pour suivre en temps réel un publication de contenus dont le rythme global est élevé mais dont le rythme individuel de chaque producteur (buzzeur, blogueur, etc.) est très faible. Il suffit de savoir discriminer finement les flux d'intérêt et alors ils peuvent faire beaucoup avec une infrastructure très faible puisque chaque analyse est stimulée par l'émergence certaine d'un nouveau contenu.
- l'infrastructure des éditeurs peut aussi rester plus faible car ils ne sont plus massivement visités par des robots d'analyse de contenus "juste pour voir"....
C'est cette forte réactivité associée à une dépense énergétique très faible qui me fait comparer l'infrastructure Pubsubhubbub au système nerveux (par analogie au corps humain) du
Web Temps Réel en train de naître. Le côté très distribué de cette architecture ne fait que renforcer la pertinence de l'analogie avec le système nerveux.
Les éditeurs au sens Pubsubhubbub sont très sensibles aux infrastructures plus réduites rendues possibles par cette architecture: la plate-forme leader Wordpress.com annonce aujourd'hui que
ses 10.5 millions de blogs sont sous Pubsubhubbub et motive tous les agrégateurs / distillateurs de son contenu à l'utiliser dans les meilleurs délais pour faire "baisser son stress". Google communique activement sur l'
état d'avancement de ses travaux en la matière en tant qu'éditeur (100% pour Buzz, 95% pour Feedburner, 95% pour Blogger, etc..) mais
également en tant qu'abonné potentiel à tous les sites du monde.
Pourquoi je parle de ce sujet Pubsubhubbub qui peut paraître tellement abscons à l'utilisateur standard de l'internet ?
Eh bien que je suis convaincu que la mise en place maintenant très rapide de ce service va permettre à une nouvelle génération de services d'émerger: ceux qui ne sont intéressés que par une fraction des contenus publiés - ou des méta-données induites par ses publications - en continu sur le web (de manière distribuée) mais pour qui la taille de cette fraction reste malgré tout trop importante pour le financement d'une infrastructure classique de crawling à faible rendement (ratio découvertes / visites très faible).
C'est exactement pour cela que Google a choisi pour Buzz une architecture ouverte aussi capillarisée : pour
permettre à de toutes petites équipes d'innover à l'échelle du web en "montant sur ses larges et solides épaules"!Très faible barrière à l'entrée et efficacité maximale au niveau global sont les 2 atouts que Google et les autres plates-formes ouvertes veulent mettre dans les mains des développeurs tiers pour
mettre à mal la stratégie de silos propriétaires des Twitter et autres Facebook.
Les prochains rounds de ce combat de titans s'annoncent passionnants! N'est-ce pas ?....
PS: c'est bien sûr encore une émanation (à la Android) de la stratégie de l
'hégémonie patiente opposée à coup d'éclat instantané sans pérennité.
Source: blog
Media & Tech (par didier durand)