Wasmer : un runtime open source pour l'exécution de WebAssembly sur un serveur

Wasmer : un runtime open source pour l'exécution de WebAssembly sur un serveur,
tout en prenant en charge l'API Wasm-C

Syrus Akbary, un développeur open source, et son équipe ont publié ce mois la version 1.0 de Wasmer, un runtime WebAssembly (Wasm) côté serveur capable d'exécuter Nginx. Cette version de l'outil, en développement depuis 2018, comprend de nouvelles fonctionnalités, notamment : une meilleure gestion des erreurs, une API plus puissante, la compilation croisée, et bien plus encore. Akbary et son équipe sont réunis au sein d'une entreprise du même nom, Wasmer, et estiment que la raison d'être de leur outil Wasmer est que WebAssembly est en passe de devenir un outil incontournable dans le développement.

Qu'est-ce que Wasmer et quel est son utilité pour les développeurs ?

WebAssembly (Wasm) est un format d'instruction binaire pour une machine virtuelle basée sur une pile. Wasm est conçu comme une cible de compilation portable pour les langages de programmation, permettant le déploiement sur le Web pour des applications client et serveur. Wasmer quant à lui est un runtime open source permettant d'exécuter WebAssembly sur le serveur. Selon les explications d'Akbary, il permet d'utiliser des conteneurs super-légers basés sur WebAssembly qui peuvent fonctionner n'importe où : du bureau au cloud et aux périphériques IoT, et également intégrés dans n'importe quel langage de programmation.

« Nous pensons que WebAssembly sera un élément crucial pour l'avenir de l'exécution et de la conteneurisation des logiciels (non seulement à l'intérieur du navigateur, mais aussi à l'extérieur) », a expliqué Akbary pour justifier l'utilité de son outil. Selon lui, en exploitant Wasm pour la conteneurisation de logiciels, il crée avec son équipe des binaires universels capables de fonctionner partout sans aucune modification, y compris dans des systèmes d'exploitation comme Linux, macOS, Windows, et aussi dans les navigateurs Web.

Pièce jointe 588350

Il poursuit en disant que Wasm met automatiquement les applications en bac à sable par défaut pour une exécution sécurisée, protégeant ainsi l'environnement hôte contre les codes malveillants, les bogues et les vulnérabilités des logiciels qu'il exécute. Wasm fournit également un environnement d'exécution allégé permettant aux conteneurs Wasmer de fonctionner dans des endroits où les conteneurs Docker sont trop lourds pour fonctionner. Après deux ans de développement, la première version stable de l'outil est disponible, Wasmer 1.0, avec en vedette les améliorations, changements et apports suivants :

• une performance prête à la production ;
• une infrastructure enfichable ;
• Native Object Engine ;
• Headless Wasmer (idéal pour l'IdO) ;
• la compilation croisée ;
• une API super facile à utiliser et extensible ;
• la prise en charge de Wasm-C-API ;
• le traitement des erreurs et débogage.

Benchmark de performance

Selon Akbary, le benchmark de performance de Wasmer 1.0 nécessite un poste autonome. Une analyse complète de Wasmer par rapport aux autres exécutions de Wasm est en cours pour vous permettre de comparer et de choisir ce qui convient le mieux à votre projet. Néanmoins, pour vous donner un aperçu, Akbary a partagé certains chiffres recensés lors de son analyse. Il estime que Wasmer 1.0 propose des vitesses de compilation jusqu'à 9x plus rapide que les versions précédentes. « Tous nos compilateurs compilent maintenant les fonctions en parallèle », a-t-il déclaré.

« Grâce à cette nouvelle stratégie, nous avons réussi à accélérer jusqu'à 9 fois les temps de compilation de tous nos compilateurs ». Ces chiffres sont beaucoup plus faciles à comprendre si l'on compare avec des exemples réels. Voici les temps de compilation de clang.wasm dans Wasmer 0.17.1 par rapport à Wasmer 1.0 :

• Singlepass : de 18 à 2s (9x plus rapide) ;
• Cranelift : de 27 à 9s (3x plus rapide) ;
• LLVM : de 1140 à 117s (9x plus rapide).

Akbary note que, lorsque l'on utilise la CLI de Wasmer, la compilation ne se fait qu'une seule fois et le résultat est ensuite mis en cache pour des exécutions futures optimales.

Infrastructure enfichable

Selon l'équipe de Wasmer, l'extensibilité est l'une des caractéristiques les plus critiques de tout produit d'infrastructure. Akbary estime que l'une des capacités les plus vitales pour son équipe est la prise en charge de plusieurs compilateurs. La possibilité de sélectionner et de brancher le compilateur qui répond le mieux aux cas d'utilisation des clients est incroyablement puissante. Wasmer 1.0 est livré avec un support prêt à l'emploi pour :

• Singlepass : pour des temps de compilation ultrarapides insensibles aux bombes JIT (idéal pour les blockchains) ;
• Cranelift : pour des temps de compilation rapides où des optimisations minimales sont nécessaires (idéal pour le développement) ;
• LLVM : pour un code machine généré optimal lorsque des performances de pointe sont nécessaires (idéal pour la production).

En plus des compilateurs, l'équipe a introduit le support pour les moteurs enfichables. Un moteur WebAssembly est une abstraction qui décide de la manière dont le compilateur doit gérer le code assembleur généré, y compris la manière de le charger et de le sérialiser. Wasmer 1.0 prend en charge les moteurs de compilation suivants :

• le moteur JIT : il pousse le code généré directement en mémoire ;
• le moteur natif : il génère du code natif qui peut être chargé comme un objet partagé. En bonus, les objets et modules partagés du moteur natif sont incroyablement performants et démarrent en quelques microsecondes.

Native Object Engine

Wasmer 1.0 introduit "wasmer compile", une nouvelle commande pour la précompilation des fichiers Wasm. Selon l'équipe, ses clients et développeurs utilisent "wasmer compile --native" pour précompiler les modules WebAssembly en fichiers objets natifs comme .so, .dylib et .dll. Les objets et modules précompilés sont compatibles avec la CLI de Wasmer ou utilisés avec les Wasmer Embeddings (Rust, Python, Go, etc.). Abkary a déclaré que l'un des principaux avantages des objets natifs précompilés est qu'ils ne nécessitent qu'un temps d'exécution minimal pour exécuter les modules compilés, tout en offrant un environnement entièrement "sandboxed". Le temps de compilation éliminé permet l'exécution directe de l'artefact à des temps de démarrage ultrarapides.

Headless Wasmer

« Ce n'est un secret pour personne que les dispositifs IdO fonctionnant à la périphérie sont les moteurs de l'avenir de l'informatique », a déclaré Akbary. Cependant, il estime que de nombreux appareils ne disposent pas d'un matériel informatique optimal ou d'autres ressources telles que l'alimentation, le réseau et le stockage. Dans le passé, les utilisateurs expédiaient leur application Wasm avec Wasmer et tous les compilateurs joints. Cette pratique était sous-optimale, en particulier pour les cas d'utilisation de l'IdO et de l'informatique en périphérie.

Avec Wasmer 1.0, l'équipe voit Wasm et Wasmer mener la charge en fournissant l'environnement d'exécution le plus léger possible, essentiel pour faire fonctionner efficacement Wasm sur les périphériques IoT en périphérie. « Grâce à notre nouvelle prise en charge de la compilation AOT (Ahead Of Time - compilation anticipée ou compilation hors ligne), vous pouvez exécuter une version "headless" de Wasmer qui ne pèse que quelques centaines de kilo-octets et exécute n'importe quel binaire Wasm précompilé sur n'importe quel appareil », a déclaré Akbary.

Compilation croisée

Wasmer 1.0 propose désormais une compilation croisée. Dans les versions précédentes de Wasmer, les applications Wasm compilées en natif visaient et fonctionnaient sur la même architecture. Avec Wasmer 1.0, vous pouvez précompiler Wasm pour une architecture aarch64 à partir d'une machine x86_64 et vice-versa.

API très facile à utiliser

Un des principaux objectifs de Wasmer 1.0 est de rendre les API très faciles à utiliser pour les développeurs qui ont une connaissance limitée des concepts avancés de WebAssembly ou de l'écosystème WebAssembly. Wasmer 1.0 améliore encore l'API fournie par l'outil, en la rendant résistante à l'avenir en la modelant sur des structures similaires à celles de la norme Wasm-C-API.

Prise en charge de l'API Wasm-C

Selon Akbary, au fur et à mesure que l'écosystème de WebAssembly se développe, l'industrie va légitimement pousser et unir les API qui interagissent avec le WebAssembly. Il a déclaré qu'au début de leur parcours, l'API Wasm-C était encore très jeune, son équipe et lui ont donc décidé de construire une API qui correspondait étroitement à leurs structures internes. Cependant, comme l'industrie s'oriente vers une API universelle, ils ont décidé de l'adopter dans le cadre de Wasmer 1.0 et d'y contribuer afin que tout le monde puisse en bénéficier.

Sources : Syrus Akbary, Wasmer

Et vous ?

:fleche: Que pensez-vous de Wasmer ?

Voir aussi

:fleche: La spécification WebAssembly Core est désormais un standard web officiel ! Après HTML, CSS et JS, WebAssembly devient le 4e langage pour le Web permettant au code de s'exécuter dans le navigateur

:fleche: Mozilla, Fastly, Intel et Red Hat lancent l'Alliance Bytecode, une initiative construite autour de WebAssembly qui propose d'apporter plus de sécurité, d'ubiquité et d'interopérabilité sur le Web

:fleche: 50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig

:fleche: Mozilla finance un portage de Julia en WebAssembly afin d'effectuer des calculs lourds au sein du navigateur

Ce serait quand même ironique qu'une technologie du Web devienne le langage de référence de l'embarqué !

Que pensez-vous de Wasmer ?

La description qu'en fait un de ses concepteurs, me fait quand même penser à des relents marketing de SUN avec Java :aie:, mais à part ça, la création d'une VM Open Source et Libre, basé sur des standards eux aussi Libre ne peut que me réjouir.
Après pour cette implémentation spécifique, j'attend de voire des retours d'expérience du runtime pour me faire un avis plus précis.