Discussion :

[Bill Fassinou]

Les conteneurs JavaScript surpasseront-ils les conteneurs Linux ?
Le créateur de Node.js pense que les conteneurs JavaScript pourraient simplifier l'écriture des services Web

Ryan Dahl, créateur de Node.js et de Deno (comme 'Node', mais à l'envers), a déclaré récemment qu'il pensait que la majorité des services Web pourraient être simplifiés en utilisant des conteneurs JavaScript, plutôt que des conteneurs Linux. Précisément, les développeurs de Deno, le nouvel environnement d'exécution pour JavaScript et TypeScript, explorent la possibilité d'utiliser des conteneurs JavaScript comme une alternative de plus haut niveau aux conteneurs Linux. Dahl estime que le concept est prometteur, mais certains craignent que cela n'introduise d'autres problèmes de sécurité dans l'infrastructure des conteneurs.

Dans un billet de blogue publié début mai, Ryan Dahl, qui a dirigé le développement des moteurs d'exécution JavaScript Deno (2018) et Node.js (2009), a expliqué pourquoi il pensait que les conteneurs JavaScript pourraient être une meilleure alternative aux conteneurs Linux. En effet, la majorité des programmes de serveur sont des programmes Linux. Ils consistent en un système de fichiers, quelques fichiers exécutables, peut-être quelques bibliothèques partagées, qui s'interfacent avec des logiciels système comme systemd ou nsswitch. Pour Dahl, l'utilisation des conteneurs Linux a surtout été popularisée par Docker.

Docker propose une virtualisation au niveau du système d'exploitation qui fournit un merveilleux mécanisme de distribution des logiciels de serveur. Chaque image de conteneur est un paquetage logiciel prêt à être exécuté et sans dépendance. Selon Dahl, étant donné que les logiciels de serveur dépendent souvent de nombreuses ressources et configurations système, leur déploiement était difficile par le passé. Les conteneurs Linux ont alors résolu ce problème. Cependant, Dahl estime qu'un environnement hermétique similaire peut être trouvé dans le JavaScript du navigateur, bien qu'à un niveau d'abstraction plus élevé.

« Plus nous pouvons supprimer les abstractions inutiles, plus nous pouvons nous rapprocher du concept de "Le réseau est l'ordinateur". Deno Deploy est une nouvelle implémentation de cette idée (sur le réseau GCP) », a-t-il expliqué. Dans son billet de blogue, Dahl a qualifié JavaScript de "langage de script universel" et a émis des hypothèses sur l'évolution des conteneurs JavaScript au cours des deux prochaines années. Pour lui, les langages de script sont très utiles pour résoudre de nombreux problèmes côté serveur. La majorité du code écrit n'est pas lié au calcul, mais plutôt à la productivité.

C'est-à-dire la vitesse à laquelle il peut être écrit et le coût monétaire des développeurs. « Les langages de script permettent d'écrire la logique métier plus rapidement et à moindre coût. Les langages de script (Python, Ruby, Lua, Shell, Perl, Smalltalk, JavaScript) sont assez similaires. Il existe des différences dans la syntaxe et les API, mais il n'y a pas grand-chose d'autre à leur opposer. Quiconque a passé du temps en Rust ou en C comprend ce que ressentent les langages de script. En résumé, les langages de script sont utiles, mais ils se ressemblent tous, et JavaScript est de loin le plus utilisé et le plus évolutif », a déclaré Dahl.

« Il est donc logique de considérer JavaScript comme le langage de script universel », a-t-il ajouté. Selon le créateur de Node.js, le conteneur JavaScript n'est pas destiné à traiter la même ampleur de problèmes que les conteneurs Linux. Son émergence est le résultat de sa simplicité. Dahl estime qu'il réduit au minimum le texte passe-partout de la logique commerciale des services Web. Il partage des concepts avec le navigateur et réduit les concepts que le programmeur doit connaître. (Exemple : lors de l'écriture d'un service Web, il est très probable que toute configuration systemd ne soit qu'un code passe-partout inutile.)

« Chaque ingénieur Web connaît déjà les API du navigateur JavaScript. Comme l'abstraction du conteneur JavaScript est construite sur les mêmes API de navigateur, la quantité totale d'expérience dont l'ingénieur a besoin est réduite. L'universalité de JavaScript réduit la complexité. Shell est le langage de script interprété utilisé pour invoquer des programmes Unix. Il peut faire des conditionnels, des boucles, il a des variables, mais il est malheureusement limité et difficile à programmer. La vraie fonctionnalité est reléguée aux exécutables », a déclaré Dahl. Dans cette nouvelle couche d'abstraction de serveur, JavaScript prend la place de Shell.

« Il est bien mieux adapté à la création de scripts que Bash ou Zsh. Au lieu d'invoquer des exécutables Linux, comme le fait Shell, le bac à sable de JavaScript peut invoquer Wasm. Si vous devez effectuer des calculs lourds, comme le redimensionnement d'une image, il est probablement plus judicieux d'utiliser Wasm plutôt que de l'écrire en JavaScript. Tout comme vous n'écrirez pas de code de redimensionnement d'image dans Bash, vous ferez apparaître imagemagick », a écrit Dahl. Pour finir, il admet avoir quelques erreurs avec Node.js, chose qu'il essaie désormais de corriger avec Deno.

« L'avenir des langages de script est le JavaScript du navigateur. L'erreur fondamentale de Node.js a été de s'écarter du navigateur au fur et à mesure que de nouvelles API étaient normalisées, en inventant trop de choses. En 2010, nous n'avions pas de modules ES, mais une fois qu'ils ont été normalisés, ils auraient dû être intégrés à Node. La même chose peut être dite pour les promises, async/await, fetch, streams, etc. », a-t-il déclaré. « Des éléments non standardisés comme package.json, node_modules et NPM seront finalement soit standardisés et ajoutés au navigateur, soit supplantés par des remplacements alignés sur le Web », a-t-il déclaré.

En gros, le créateur de Node.js de Deno pense que l'universalité de JavaScript favorise l'émergence d'une nouvelle abstraction de type conteneur. Les conteneurs Linux ne vont pas disparaître, mais penser en matière de conteneurs JavaScript pourrait simplifier de nombreux services Web. Dahl a déclaré qu'il s'attendait à ce que la technologie des conteneurs JavaScript se développe au cours des deux prochaines années. Deno explore cette idée, notamment dans son produit Deno Deploy, et recrute actuellement des ingénieurs pour la développer.

Source : Ryan Dahl

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du concept de conteneur JavaScript ?
Que pensez-vous des projections de Dahl sur l'avenir des conteneurs JavaScript ?
Que pensez-vous de l'utilisation des conteneurs JavaScript à la place des conteneurs Linux ?

Voir aussi

Podman : un moteur de conteneur sans "daemon" open source, conçu pour développer, gérer et exécuter des conteneurs sur Linux, une alternative à Docker ?

L'attrait des développeurs pour les conteneurs et Kubernetes est principalement motivé par l'évolution de leur carrière, selon une étude de Red Hat

51 % des 4 millions d'images Docker analysées présentent des vulnérabilités critiques, et certaines d'entre elles peuvent être considérées comme malveillantes, selon une étude de Prevasio

La sécurité et la conformité des conteneurs restent un défi majeur, tandis que leur adoption s'accélère, 89 % des professionnels de DevOps possédant des déploiements actifs, selon NeuVector

[lingtalfi]

L'idée d'avoir javascript comme language universel me plaît bien, car c'est probablement le language le plus facile à apprendre.
Un peu comme l'anglais est le language universel pour les humains.

[Eric80]

j imagine que l auteur parle surtout des conteneurs stockés sur le cloud, mais il n y a pas que le cloud dans la vie..

dans le projet ds lequel je bosse (on utilise des conteneurs sur des box qui gèrent de l IOT, les box envoient les données sur le cloud), on a fait l'étape inverse pour les conteneurs embarqués: ré-écriture des app javascripts en Go sur Alpine pour des conteneurs plus légers (/5 ou /10) et avec une meilleure maîtrise sur les MAJ que les conteneurs node.js
dans le même mouvement, le conteneur .NET Core que je gérais est aussi passé à la trappe, le passage en Go a divisé par 4 la taille du conteneur (70 à 18 Mo l image, 70 Mo seulement en .NET Core est déjà une belle optimisation)

[TheGuit]

L'idée d'avoir javascript comme language universel me plaît bien, car c'est probablement le language le plus facile à apprendre.
Un peu comme l'anglais est le language universel pour les humains.

Javascript le langage le plus facile à apprendre ? Dans quel monde ? Quand 80% des développeurs n'ont pas compris ce qu'est le prototypage (et que non c'est pas parce que on a un mot clé class que on fait des classes en JS), qu'ils n'ont pas compris l'asynchrone et le mono-threading de JS, qu'ils n'ont pas compris bien souvent comment fonctionne réellement le typage, quand le paradigme fonctionnel est souvent un gros mot, ...

Non javascript est de loin un des langages les plus ardu à apprendre. De loin plus compliqué qu'un langage impératif et statiquement typé.

[myNameIsFlo]

L'idée du Javascript partout me donne mal au ventre. J'aimerai que ce langage de script retourne à sa place d'origine.
M'enfin des conteneurs JS pourquoi pas si ça peut être utile... je préférerais lire que wasm va devenir le conteneur universel 😉

[Fagus]

L'auteur prêche pour sa paroisse (Deno) en voulant résoudre un problème déjà résolu ? Les containers marchent déjà et Go fait déjà le job avec sa compilation multi-plateformes avec des performances meilleures que JS pour un langage très abordable.

Quant à dire que JS est idéal (tellement que Typescript existe) ou ressemble beaucoup à python, smalltalk ... (j'avais commencé un cours de Pharo, c'est un choc culturel)