Node.js côté Ops : un chantier à part entière

Mon premier figure dans le top 10 des technologies préférées des développeurs depuis 10 ans. Mon second est privilégié pour les applications web temps réel et conversationnelles. Mon tout est un environnement d’exécution. Voilà comment nous pourrions dresser un rapide portrait de Node.js. Un environnement d’exécution car, de fait, Node.js n’est ni un langage (il exécute du Javascript), ni un framework (en revanche, il existe quantité de frameworks conçus pour lui). Et c’est sans doute cette nature particulière de Node.js qui explique l’engouement qu’il suscite, mais aussi une partie de ses limites lorsqu’on le soumet aux exigences des Ops.

Node.js un engouement intimement lié à Javascript

Node.js a la cote. Et pas qu’un peu. Aujourd’hui encore, à travers le monde, Google enregistre environ 1 million de requêtes par mois sur ce sujet – sans comptabiliser tous les noms de frameworks associés. Cet attrait pour Node.js, qui ne s’est pas démenti au fil des ans, est intimement lié à l’histoire même de Javascript. Présenté à la JSConf de 2009, l’environnement emporte de suite une forte adhésion et l’apparition de NPM en 2011 accélère la constitution d’un véritable écosystème. Une dynamique qui s’appuie sur des qualités propres à Node.js – en tous cas, à l’époque.

Node.js a émergé d’un souhait : disposer d’un serveur web non-bloquant en environnement persistant. Voilà pourquoi il prend en charge directement les connexions réseaux. Voilà pourquoi aussi il s’agit d’un moteur persistant à thread unique capable de gérer des événements et des méthodes de rappel. Cette architecture basée sur les événements et sa vélocité naturelle en font un bon candidat pour les applications en quête de temps réel (ou assimilé). Node.js a ici comblé un véritable manque.

Si l’environnement connaît encore un tel succès dans le temps, c’est aussi parce qu’il permet d’exploiter côté serveur un langage – Javascript – connu côté client et pour lequel l’apprentissage peut être rapide.  Dans la pratique, Node.js a permis à de nombreux développeurs frontend de migrer peu à peu vers le backend, donc d’étendre leur champ d’action et de compétences. En clair, Node.js est arrivé à point nommé pour soutenir les évolutions de compétences par ailleurs requises pour produire des applications web plus « dynamiques ».

Scalabilité, packaging, sécurité : les faiblesses de Node.js

Si les développeurs ont de bonnes raisons de s’intéresser à Node.js, côté Ops le bilan est toutefois plus… mitigé. Et cela pour au moins 3 raisons.

La première concerne la scalabilité de l’environnement : il n’y a tout simplement pas de parallélisation possible. Même si le multi-thread est apparu dans des versions récentes, il s’avère pour l’heure quasiment inexploité – chez Oxeva, nous n’avons pas encore vu un seul de nos clients y recourir. Ajoutons à cela que Node.js est très sensible aux petites erreurs : en cas de crash, là où PHP renvoie vers une nouvelle instance, pour Node.js, le moteur entier doit être redémarré.

Seconde raison qui modère l’enthousiasme des Ops : le packaging. C’est une évidence toujours bonne à rappeler : le code développé avec Node.js ne tourne pas tout seul, mais utilise un grand nombre de modules. Ce grand nombre de dépendances, combiné avec les incompatibilités d’une version à l’autre du moteur, peut rapidement déboucher sur un joli chaos.

Enfin, troisième raison, la sécurité. Beaucoup de modules, cela signifie, mécaniquement, de nombreuses potentielles failles de sécurité. Et à l’échelle de centaines (voire des milliers) de modules, l’inspection du code s’avère impossible. Et pourtant, nous avons déjà eu l’occasion d’identifier dans des modules de quoi orchestrer un vol de données ou du minage de crypto-monnaies… Les limites (ou facilités, question de point de vue) de NPM sont ici en cause. D’une part, s’il est très facile de publier du code de manière publique, il est tout aussi simple via une petite erreur de basculer du code privé en public. Problématique pour protéger du code. Par ailleurs, là où Github demande une authentification, NPM permet la publication de code de manière anonyme…

Des principes et des outils pour bien « entourer » les apps Node.js

Question légitime : peut-on contourner ces limites et rendre les applications Node.js plus scalables et plus sécurisées ? Bonne nouvelle : oui. Mais à condition d’investir et d’outiller une véritable démarche Ops autour de Node.js. Pour y parvenir, nous avons adopté quelques principes et développé des outils.

Côté principes, nous jugeons la conteneurisation incontournable pour assurer la conformité de l’environnement, du développement à la production. Faire fonctionner côte à côte des apps qui exploitent des versions différentes de Node.js posent bien trop de problèmes de compatibilité. La conteneurisation permet à la fois d’isoler les apps et de gérer les dépendances avec les modules.

Et si un client n’a pas conteneurisé ses apps ? Nous lui proposons de prendre la main sur le sujet afin de l’accompagner au mieux – les Ops viennent ainsi à la rencontre des dev.

Pour la sécurité, la seule solution sûre consiste à restreindre l’accès internet – oui, c’est assez radical – ou à limiter l’accès pour n’autoriser que certaines ressources. Dans des contextes sensibles – bancaires par exemple –, nous recommandons fortement d’en passer par ces restrictions/autorisations au cas par cas des ressources.

Et la scalabilité ?

Reste la question de la scalabilité. Ici, nous nous appuyons sur deux composants développés par nos soins : l’un pour gérer la répartition sur des instances et automatiser les relances en cas de crash ; l’autre pour assurer la supervision (surveillance de l’empreinte mémoire, du statut du process, de la haute disponibilité).

Avec ces outils et ces principes, nous avons standardisé – à notre échelle bien sûr – une démarche pour accompagner les apps Node.js jusqu’en production. Objectif : les rendre compatibles avec ce que nous estimons être des exigences de base côté Ops.

Si l’approche vise à compenser les faiblesses de Node.js du point de vue Ops, elle suppose aussi que des fondamentaux du développement soient respectés. Gardons notamment à l’esprit que Node.js est de nature à traiter la donnée mais n’est pas conçu pour la stocker. Si l’on s’y risque, la désynchronisation entre des instances devient un sujet. Pour éviter ces malentendus, relisons ensemble le manifeste « The Twelve-Factor App ». Tout y est pour s’assurer que développeurs et ingénieurs Ops travaillent dans le même sens afin que les apps Node.js soient un succès… jusqu’au bout.