WASI

[Laurent Caillette]

Il y a un certain temps j'avançais l'idée qu'une JVM était, en tant que conteneur de code, un concurrent naturel de Docker :

https://groups.google.com/d/msg/techos/4AZfasdArpc/18Q2MTEZBAAJ

https://groups.google.com/d/msg/techos/4AZfasdArpc/Ald28DBJBAAJ

<<

[GraalVM] donne encore quelques longueurs d'avance à la JVM d'Oracle, alors que des alternatives commençaient à montrer le bout du nez, comme  PNaCl puis Wasm. Ce qui est complètement fou c'est que la JVM, qui est sur le papier le truc le plus approprié pour confiner du code, se soit fait sortir par d'autres trucs moins pertinents comme la VM de JavaScript (dans les navigateurs) ou [Docker]. 

[...]

Le rapport entre Docker et la JVM ? 

--- Docker est un outil pour confiner un environnement d'exécution avec ses dépendances. Si les dépendances à l'exécution n'avaient pas débouché sur un bordel colossal, on se passerait probablement de Docker. Docker c'est la meta-distro Linux qui trivialise la notion de distro. 

--- La JVM enferme toutes les dépendances dans un seul processus. Tu mets tout ce que tu veux dans ton classpath et tu as la paix. La JVM se débrouille avec le système sous-jacent.

Donc cette histoire de dépendances constitue un point commun assez frappant. 

>>

Depuis le début il est clair que Docker fournit un niveau d'indirection assez redondant si on fait tourner dedans juste une JVM, qui a ses propres fonctionnalités d'isolation. La grande nouvelle c'était la capacité de GraalVM d'exécuter du code LLVM, sachant que LLVM est le standard multiarchitecture et multilangage du code exécutable. Ce qui donnait à GraalVM le potentiel pour trivialiser Docker. Il s'en est suivi une passionnante discussion abordant diverses facettes du déploiement et de la compilation anticipée (AOT).

Le sujet vient de rebondir avec l'annonce de WASI (WebAssembly System Interface) par Mozilla. Je recommande la lecture de l'article [Mozilla tries to do Java as it should have been -- with a WASI spec for all devices, computers, operating systems-_]

https://www.theregister.co.uk/2019/03/29/mozilla_wasi_spec

En bref, avec WASI tu ton code Java ou LLVM est compilé en Wasm, qui accède aux primitives de WASI. Tu obtiens alors du code exécutable prêt à être déployé dans le nuage, sur une machine de bureau, dans un navigateur Web ou un bidule embarqué. Les grandes différences avec du C standard, c'est que le code autorise un niveau de vérification et de confinement correct, ainsi que de l'instrumentation. 

L'article de The Registe cite un [tweet hallucinant]

https://twitter.com/solomonstre/status/1111004913222324225

de Solomon Hykes, co-fondateur de Docker :

<<

If `Wasm+WASI` existed in 2008, we wouldn't have needed to created Docker. That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!

>>

Du code multiarchitecture et multiplateforme comme concurrent de Docker : c'est pas que moi, c'est un des inventeurs de Docker qui le dit ! Et sérieux, la différence entre `Wasm+WASI` et GraalVM, elle est assez mince.

En arrière-plan il est clair que chez Mozilla ils ont bien pris note des difficultés de Rust à s'imposer comme langage généraliste multiplateforme (notamment face à Kotlin), de la menace que pourrait faire peser GraalVM, du succès des conteneurs légers côté serveur, et de l'étonnant succès de NodeJS (étonnant parce que techniquement inepte à de nombreux égards). Ils n'ont pas pu ignorer OSv, qui fusionne la JVM, le conteneur de microservice et l'unikernel. 

À ce jour, `Wasm+WASI` constitue la synthèse la plus brillante de toutes ces idées. Elle retient les points suivants :

- Compilation anticipée, produisant un exécutable avec :

  - Un temps de démarrage très court.

  - Une faible empreinte mémoire à l'exécution.

- Multilangage, multiarchitecture avec LLVM comme code intermédiaire.

- Code vérifiable avant l'exécution, façon PNaCl ou JVM.

- Fusion de la notion de conteneur léger et de la JVM (qu'on peut décidément appeler conteneur méconnu).

- Donc fusion les étapes de compilation et de conteneurisation, avec des larmes de bonheur dans les yeux des devops.

- Différentes modalités d'exécution (y compris du JIT et de l'interprété).

- Interface programmatique standardisée pour accéder aux ressources système.

Dans cette liste il n'y a que le dernier point qui soit spécifique à WASI, le reste est déjà fourni par Wasm. Mais c'est bien la standardisation de ces interfaces qui concrétise la promesse du multiplateforme.

Après la grande question c'est la gueule qu'elles auront. D'après l'annonce officielle [Standardizing WASI: A system interface to run WebAssembly outside the web]

https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

on sera très près de POSIX. Genre tu retrouves un bon vieux [``sbrk``]

https://github.com/WebAssembly/reference-sysroot/blob/master/dlmalloc/include/unistd.h 

pour l'allocation mémoire. (Hé hé, les auteurs de WebAssembly ont compris : le ramasse-miettes obligatoire il y a des cas où ça ne passe pas !) Si WASI est un POSIX allégé il n'y aura rien à inventer, c'est mieux. Bien sûr on s'attend à voir un jour des Sockets, de l'OpenGL et du DOM W3C.

C'est marrant, Sun et Oracle n'ont jamais brillé par leur capacité à imposer Java côté client (il a fallu attendre que Google s'y mette avec Android). Cette grosse bouse de JavaScript a presque eu plus de succès en "remontant" du client vers le serveur avec NodeJS. Mozilla, qu'on a toujours tendance à enterrer un peu vite, est bien parti pour refaire le même coup avec `Wasm+WASI`. Deux ans après l'annonce, c'est assez clair qu'Oracle n'a pas vu, ou n'a pas envie d'exploiter, le potentiel de GraalVM comme concurrent de Docker.

On prend les paris ? Dans 2 ans jour pour jour : 

- Oracle continue de présenter la JVM dans Docker comme une saine pratique de déploiement.

- Amazon et Google hébergent du code WASI qui s'exécute directement dans leur infrastructure nuage. 

- En plus du format natif, une version de NGINX est livrée compilée pour WASI.

- Docker annonce la sortie d'un conteneur WASI pour dans pas longtemps.

Pour une fois personne ne meurt. Si, le JavaScript, mais ça va prendre du temps.

Vu le manque de moyens de Mozilla pour pousser les bons produits (Rust est demeuré assez confidentiel) tout ça peut sembler très optimiste. D'un autre côté le couple `Wasm+WASI` résoud tellement de problèmes qu'on peut compter sur un puissant relai de la part d'autres acteurs.

[Henri Tremblay]

C'est une grosse semaine.

Tu peux aussi aller faire un tour du côté de Quarkus https://quarkus.io/. Tu as aussi JIB https://github.com/GoogleContainerTools/jib mais c'est déjà vieux :-)

GraalVM n'est pas du tout un concurrent de Docker. Du tout. Par contre GraalVM est un gros concurrent des VM ruby, V8, runtime python et patata.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+un...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Laurent Caillette]

Salut Henri,

Chouettes liens, à regarder de près pour qui veut déployer du code dans une JVM qui tourne dans Docker. L'étape suivante c'est se poser la question "Mais quelle est la valeur ajoutée de Docker là-dedans ?" Les diagrammes de la prez de JIB sont assez éloquents.

Alors toi tu dis : "GraalVM n'est pas du tout un concurrent de Docker." C'est vrai, mais juste dans la mesure où Oracle ne veut pas que ça le soit. 

Je reformule. Un programme (au hasard, une JVM) qui constitue l'environnement d'exécution d'un autre programme natif (ou presque, genre du code LLVM) c'est un concurrent de Docker, parce que ça définit des modalités de déploiement. Ce qui m'a bien fait rigoler, c'est que ça soit un des créateurs de Docker qui le dise. Certes il le dit à propos de Wasm+WASI, qui sont une spec du bytecode plus une API système, ce qui ressemble bien à GraalVM. 

Pour aider : imagine que ton application soit déployée en un seul jar. Le déploiement est régi par la JVM, les éventuelles couches de Docker et d'hyperviseur en-dessous tu t'en tapes un peu.

[Julien Kirch]

Hello,

Quelques éléments pas structurés

De ma fenêtre la partie conteneur de Docker pourrait être à moyen terme absorbé par les évolutions dans le noyau Linux élargi (je vois bien une combo d’évolution des API du noyau + systemd), d’où le repositionnement des vendeurs (comme Docker) sur l’orchestration des déploiements et le monitoring (ce qu’on pense plus pérenne et qu’on peut vendre aux grosses boites).

Docker gère l’accès aux ressources systèmes (droits et quotas), les accès réseaux … je ne dis pas qu’une VM ne peut pas le faire mais que ça sort du modèle VM classique.

J’ai l’impression qu’on a deux paradigmes qui avancent en parallèle :

- d’un côté des choses comme WASI qui augmentent la capacité à s’abstraire du système cible

- d’un autre des outils qui permettent de faire du build / déploiements natif plus facilement

Et pour les deux une capacité meilleure ou mieux exploitée de la couche en dessous (Docker ou équivalent) et au dessus (service discovery …) pour faire de l’isolation et de la configuration

Je ne sais pas si un va gagner ou si les deux approches seront complémentaires

Je ne sais si Mozilla pense que Rust est un échec : il a l’air de se développer de manière positive, et je n’avais pas compris qu’ils pensaient en faire un hit qui aurait été manqué. Pour moi un langage peut être un succès sans être une licorne.

Côté GraalVM il faut aussi prendre en compte la volonté des clients : avec les tensions ces derniers temps autour des briques open source d’entreprise, et la réputation d’Oracle telle que je la perçois dans mes missions, je ne sais pas à quelle part de marché pourrait prétendre ce type d’offre.

PS : j’ai lu récemment https://archiloque.net/blog/nix/ qui m’a fait pas mal réfléchir à ce genre de choses.

Julien

[Laurent BEDE]

Hello,

quand je vous lis et que je contemple tout le buz sur Docker, Kubernetes, je me dis que l'on pas loin d'une rupture avec un modèle qui arrive au bout de sa course comme les disquettes qui ont été éradiquées de la surface du globe par l'usb, le CD par le streaming et le cloud etc.

Bref, le principe est "si c'est trop compliqué" alors c'est une impasse.

Je crois beaucoup dans des modèles serverless ou l'on oublie une fois pour toute, la notion de serveurs, os, hyperviseurs, VM, conteneurs ...

On a besoin de RAM, de CPU et de réseau et on se fout pas mal de savoir comment on nous la met à dispo.

Je déploie du code, il tourne; le reste c'est une affreuse tuyauterie qui ne devrait être réservée qu'aux fournisseurs de Cloud.

J'ai tout faux ?

[Loïc Lefèvre]

Hello Laurent B.

100% d'accord avec toi sur ce sujet.

Souscris et consomme !

[Laurent Caillette]

Salut Julien, Laurent, Loïc,

C'est vrai que la JVM brut de fonderie ne fournit pas le dispositif de quotas. Mais autant que je sache c'est une fonctionnalité du noyau (cgroups), Docker n'en fournit que l'habillage. Pareil pour le réseau, derrière c'est du Netfilter. Avant Docker toutes ces fonctionnalités étaient disponibles, Docker (comme conteneur) c'est la sauce pour dire aux gens comment tout ça marche ensemble. Systemd pour généraliser l'emploi des cgroups : là je dis super idée -- si c'est pas déjà fait ! Et avec un peu de jus de cervelle on doit pouvoir convaincre Kubernetes d'utiliser une JVM comme conteneur.

Concernant Rust je n'ai pas parlé d'échec. Mais bon l'important c'est que LLVM est là pour au moins 30 ans.

Au milieu de tout ça la construction et le déploiement ça reste le bordel, c'est sûr, d'autant plus que les deux sont considérés comme des activités distinctes. Des fois je me prends à rêver d'un tuyau pour balancer le résultat d'une compilation différentielle dans Kubernetes en mode dev. Et puis je me dis : à quoi bon, j'ai ma JVM en local, et de toutes façons il faut faire des versions pour des livraisons étagées.

Concernant les disquettes d'antan, certes elles ont disparu, mais depuis l'informatique est devenue beaucoup plus compliquée. Des fois aussi on perd en fonctionnalités. Ainsi le CD non-réinscriptible, résistant à la démagnétisation et à l'humidité, n'a toujours pas d'équivalent pour les sauvegardes. 

Avec tous les engins comme Docker, Kubernetes, OSv, JIB et patin couffin, certes il y a une complexité croissante, mais ils mettent aussi des simplifications en valeur. Genre les mecs de Docker ont identifié une utilisation de Linux où on n'avait plus peur de s'affranchir des utilisateurs et des droits, et où on arrêtait de se faire pourrir la vie par des versions de bibliothèques système. Grâce à Kubernetes nous avons vu comment automatiser l'administration de milliers de serveurs, alors qu'avant c'était un grand mystère. Mais avant de virer toutes les étapes superflues introduites par l'assemblage de produits qui n'étaient pas prévus pour être intégrés, il faudra encore pas mal d'itérations, sans parler de tout l'existant qu'on est obligé de se traîner. Et au passage on ajoutera encore de la complexité entre temps, avec du push, de plus gros volumes, de plus faibles latences, etc. Et des noms débiles comme "serverless" pour dire qu'on ne sait pas combien il y a de serveurs.

Bien sûr il faut que ça mature, mais j'ai la nette impression que Wasm+WASI apportent les bonnes simplifications aux bons endroits, sans essayer de faire de la magie.

[Dominique Jocal]

Salut camarades,

Serverless ouais ouais mais ça tord pas mal le bras de tout penser 'fonction' (seul grain supporté si j'ai bien compris) et ça force à dépendre de services de haut niveau pour le (moindre) stockage (même un peu de mémoire) et les tarifs des saas de stockage tapent ouillouille..

M'enfin je vois ça de loin pour l'instant, je débute ds le cloud public, je ne connais pas l'effet compétition sur les saas de stockage (les prix baissent ils), alors qu'on le voit bien à l'oeuvre sur la ressource brute vm + block storage, en hosting classique comme cloud.

A vous lire

Le ven. 29 mars 2019 à 17:33, Laurent BEDE <priva...@gmail.com> a écrit :