du Web 2.0 au Web 34.x ? - Big Things 2016

Posted on 21 May, 2016 by Administrator

Trop souvent dans l'univers IT, les fausses révolutions font le buzz en se marchant les unes sur les autres, à coup de déclinaisons quantiques d'un concept initial qu'elles seraient bien en peine de détrôner. Ainsi en est-il, par exemple, de l'irremplaçable JQuery sur le registre des UX web et mobile. Qui ira raisonnablement lui préférer un framework javascript plus en vue mais moins rapide, extensible et fiable quand il faudra mettre la dernière main à un projet sensible traité pour un client exigeant dans un contexte qui ne l'est pas moins ?

Côté serveur, pour l'architecte fonctionnel ou le DevOps en quête d'économie de moyens et de contrôle des coûts, les deux dernières décennies ont surtout été affaire de petits pas méthodologiques - très discrète montée en puissance de la programmation fonctionnelle asynchrone à la "Church-Turing" -> Node.js, Scala - et, parfois, de conformisme frileux - persistance des approches synchrones "objet"; faible taux de pénétration de PostgreSQL sur le segment des SGBDR de très haute disponibilité.

Beaucoup d'intégration et fort peu de raw-développement direct. Un mix incertain entre vrai et faux "open-source" où, tandis que Java et PHP semblent devoir se partager le meilleur de ce qui se rapportera jamais au secteur du développement serveur, lourd pour Java et, léger pour PHP, une vraie révolution silencieuse s'est engagée, au tournant des années 2010, de Moscou à Beijing, d'abord et de San-Jose à Seattle ensuite.

Tout est parti de trois conjectures simples : comment industrialiser des CDN et applications Saas de grande envergure fiables, économiques et parfaitement sécurisées sans avoir à les reconstruire "from scratch" quasiment tous les cinq ans ? Par-delà le conflit d'intérêt qui pourra ici opposer, au sein même des grandes ESN/SSII, les commerciaux en charge de tirer les prix vers le haut, d'une part, et les architectes fonctionnels et DevOps déterminés à produire les solutions garantissant les TCO les plus bas, d'autre part, ce sont, comme toujours quand l'innovation technique fait son chemin, les mathématiciens qui se sont saisis de l'affaire :

a.- à Moscou, Igor Sysoev conçoit entre 2002 et 2004, Nginx, un serveur httpd et proxy multi-services destiné à répondre aux besoins de montée en charge d'un site russe à très fort trafic (Rambler). Nginx est, aujourd'hui (avril 2016), le deuxième serveur httpd le plus utilisé (17%) après Apache (45%) et sa position passe à 25% si l'on ne ne prend en compte que le premier million de sites les plus fréquentés de la planète. Netfix.com, Expedia.com, Fastmail.com ou Wordpress.com constituent quelques uns des portails qui le mettent en oeuvre.

b.- à Beijing, Yichun Zhang, successivement ingénieur système chez Taoboa et Yahoo Chine, contribue au développement de Tengine (fork Nginx) et à deux implémentions du framework MVC OpenResty, sous Perl d'abord et sous Lua ensuite, ce langage de script proposant une architecture et des caractéristiques sémantiques et fonctionnelles (pile asynchrone, co-routines, API C/C++ native) très favorables à l'intégration avancée d'OpenResty avec Nginx et LuaJIT, la machine virtuelle C/C++ propre à Lua, un lointain équivalent de la JVM propre à l'univers Java, les problèmes de heap memory en moins, l'économie de moyens, la stabilité et la vélocité de la compilation à la volée sous C/C++ en plus.

c.- à San Francisco, Matthew Prince, Lee Holloway, and Michelle Zatlyn créent, en 2009, Cloudflare qui devient en quatre ans l'un des premiers opérateurs de CDN, de serveurs de noms de domaine et de services de sécurité des portails web. Le modèle économique de l'entreprise repose sur l'industrialisation à grande échelle d'un système distribué de reverse-proxies Nginx sécurisant et accélérant l'accès aux sites web utilisant les serveurs de noms de domaine Cloudflare. Le concept consistant à lier serveurs de noms et reverse-proxies Nginx opérant des web application's firewall et des serveurs de cache passif, modélisé quelques années auparavant à Moscou (Mail.ru) et à Beijing (Taoboa) fera bientôt la fortune de l'opérateur mais pas avant que l'entreprise ne recrute Yichun Zhang à qui elle confie la mission d'intégrer, via OpenResty, deux modèles de données Lua indispensables à la sécurisation de ses reverse-proxies Nginx : les sockets asynchrones bi-directionnels, d'une part, l'usage étendu des co-routines, elles aussi asynchrones, d'autre-part.

d.- à Seattle, Expedia.com (Microsoft) choisit à son tour d'intégrer Nginx et OpenResty à son CDN (reverse-proxies, web application's firewalls, serveurs de cache passif, DNS).

En Europe, nous en restons encore à quelques bons "steps behind". Si Nginx impressionne, il reste, dans l'hexagone, au Royaume-Uni ou en Allemagne, prioritairement valorisé comme serveur proxy et nous sommes encore très loin de bien mesurer qu'il est d'autant plus performant quand il est simultanément exploité comme serveur httpd.

Pour rester très synthétique, l'espace mémoire de Nginx est conçu pour opérer quatre types de traitements, ailleurs distribués entre autant de serveurs distincts : filtrer les requêtes entrantes à l'effet de rejeter les demandes illégales, servir les pages web statiques, réceptionner en contrôleur applicatif natif (se substituant aux contrôleurs des frameworks habituels propres aux univers Java, PHP,...) les requêtes dynamiques en les redirigeant vers les passerelles applicatives adéquates, répartir la charge des requêtes entrantes entre plusieurs serveurs esclaves s'il est configuré à cet effet.

A ces caractéristiques de référence s'en ajoutent deux, tout aussi essentielles à bien des égards :

- son aptitude à distribuer les traitements qu'il opère en autant de "workers" que la machine hôte permet d'en supporter, ceci à raison d'un processus par core de processeur dédié en mode n-2, les derniers étant à réserver aux taches de service du système d'exploitation;

- son aptitude à interagir avec LuaJIT, la machine virtuelle Lua, et les serveurs de cache passifs adéquats (memCached, Redis ou Tarantool) permettant de déployer des plate-formes applicatives capables d'atteindre un indice de performance moyen de 34, l'indice de référence 1 représentant les traitements dynamiques gérés en mode CGI, les principales plate-formes opérant dans cette configuration (Perl, PHP, RoR,...) se tenant dans un mouchoir.

OpenResty est conçu pour tirer parti de la combinaison Nginx-LuaJIT-serveur de cache passif-SGBD en l'organisant en une pile de calcul asynchrone (routines, co-routines, sockets) permettant de factoriser l'indice de performance moyenne (HTTP GET et POST) de 34 de manière extrêmement efficace dans une logique formelle d'algorithmie de flot, là où les modèles orientés objet plafonnent en mode synchrone dans une logique formelle d'arbre de décision.

Nginx est, par ailleurs, une excellente plate-forme d'accueil des serveurs d'application tournant sous HHVM (Machine Virtuelle JIT PHP asynchrone de Facebook) et Python3 avec des performances très respectables en HTTP POST, tant en lecture qu'en écriture.

Tandis que l'indice 34 devient la base de référence des fournisseurs de CDN les plus performants de la planète, de Moscou à à Beijing et de San Francisco à Seattle, on se demandera, peut-être à juste titre, pourquoi, dans l'Union Européenne, le nombre d'entreprises curieuses de comprendre la révolution OpenResty semble encore pouvoir se compter, en mai 2016, sur les doigts d'une main ?