Par Marco Fioretti

WebAssembly ou Wasm par souci de brièveté, est un format binaire normalisé qui permet aux logiciels d’écrire quelconque langage à exécuter sans personnalisations sur n’importe quelle plate-forme, à l’intérieur de bacs à sable ou temps d’exécution – c’est-à-dire des machines virtuelles – à une vitesse quasi native. Étant donné que ces environnements d’exécution sont isolés de leur environnement hôte, une interface système WebAssembly (WASI) donne aux développeurs – qui adoptent Wasm exactement pour être libres d’écrire un logiciel une fois, mais en ignorant où il s’exécutera – un moyen standard unique d’appeler le bas niveau fonctions présentes sur n’importe quelle plateforme.

le article précédent de cette série décrit les objectifs, les principes de conception et l’architecture de WASI. Cette fois, nous présentons des projets et des services concrets et utilisables basés sur WASI, qui clarifient également son rôle dans la grande image: faciliter la conteneurisation de pratiquement toutes les applications, beaucoup plus efficacement que les conteneurs plus volumineux comme Docker peuvent le faire.

Le codage avec WASI ne représente que la moitié du travail

Les programmeurs peuvent déjà écrire et compiler du code, par exemple dans C ou alors Rouiller, pour créer des modules .wasm utilisable dans tout environnement compatible WASI. Le problème est, avons-nous déjà des environnements d’exécution qui peuvent réellement exécuter ces modules «en dehors des navigateurs Web»? La réponse est oui, et plus d’un. Une solution à usage général est Wasmtime, du Alliance Bytecode. Ce projet développe un runtime compatible WASI pour les modules Wasm qui peuvent être utilisés autonome, en tant qu’outil de ligne de commande, ou être intégré dans d’autres applications, en tant que bibliothèque: pour le moment, en plus de Bash ordinaire, Wasmtime est utilisable depuis Rust, C, Python, .NET et Go.

D’autres environnements d’exécution WASI sont plus ou moins optimisés pour des cas d’utilisation particuliers ou des communautés de programmation. Les exemples suivants donnent une idée de ce qui est possible, sans prétention à l’exhaustivité.

WASI sur les serveurs, ou REMPLACEMENT de certains serveurs

Wasmer est un runtime Wasm open-source de Rust, dont la version 1.0 était sorti en janvier 2021. Wasmer est spécialement conçu pour exécuter – sur des serveurs génériques – des modules .Wasm qui utilisent des méthodes WASI pour interagir avec les fonctions natives du système d’exploitation hôte.

Outre un runtime autonome pouvant exécuter des binaires Wasm sur n’importe quelle plate-forme et chipset, Wasmer est conçu, comme Wasmtime, pour permettre l’utilisation de modules Wasm à partir de beaucoup d’autres langues, à partir de C / C ++, Rust, Python, Go, PHP et Ruby.

Pour prouver ses capacités, les développeurs de Wasmer ont compilé en tant que module .wasm – puis exécutent en fait – un version non modifiée du serveur Web nGinx, en utilisant évidemment des appels WASI pour interagir avec le système hôte.

Wasmer est également le premier runtime Wasm à soutenir pleinement à la fois WASI et programmation haute performance avec le Instruction unique, technique de données multiples (SIMD): en 2019, les deux technologies ont été utilisées ensemble, avec des résultats très intéressants, pour émuler la physique des particules. Les développeurs Wasmer participent également aux travaux pour exécuter Modules Wasm sur le noyau Linux pour exécuter en toute sécurité, via WASI, des tâches qui nécessiteraient autrement plus de vérifications et plus de changement de contexte; ce sont des succès de performance.

Intelligence artificielle, plus rapide que Docker et plus simple que Node.js

Second State a développé une autre machine virtuelle pour exécuter des applications côté serveur «plus sûres et 10 fois plus rapides que Docker», appelée SSVM. Ce qui est particulièrement intéressant dans le runtime SSVM, c’est pourquoi et comment il a ajouté et optimisé la prise en charge de WebAssembly et WASI: accès direct au matériel pour fournir l’intelligence artificielle et l’apprentissage automatique «en tant que service dans Node.js, écrit en Rust, sur le Web» . Les applications typiques, exécutées jusqu’à 25 fois plus vite que le code Python équivalent, incluent la reconnaissance d’images et d’autres modèles.

La chaîne d’outils SSVM peut également être utilisée pour créer des modules Wasm pour Deno. Il s’agit d’un runtime Rust pour JavaScript et TypeScript créé pour résoudre le problème «10 choses que le créateur de Node.js regrette», et prend en charge WASI pour les modules Wasm qui doivent accéder aux ressources système.

Jeux WASI et plus encore, à la périphérie du cloud

Fastly, un fournisseur de plate-forme cloud de périphérie, a développé puis publié en Open Source son propre compilateur et runtime WebAssembly, appelé Lucet. Créé rapidement cet outil spécifiquement pour prendre en charge une exécution plus rapide et plus sûre du code que ses clients écrivent dans n’importe quel langage, pour plusieurs cas d’utilisation de la plateforme Fastly. Pour montrer les capacités de Wasm et WASI en Edge computing, un ingénieur Fastly récemment annoncé qu’il a porté le jeu de tir à la première personne Doom pour qu’il s’exécute sur le cloud de bord de Fastly.

WebAssembly et conteneurs? Quelle est la différence?

En utilisant WASI et le Wasmtime déjà mentionné, il est possible à la fois de exécuter des modules Wasm à partir d’applications .NET Core, et pour générer des modules dans le même format à partir du compilateur Roslyn de .NET. Encore plus intéressants sont les Krustlets de Microsoft, c’est-à-dire les «Kubernetes Rust kubelets». Il s’agit d’un moyen d’orchestrer et d’exécuter des «charges de travail» WebAssembly aux côtés des conteneurs standards, avec Kubernetes. En d’autres termes, Wasm et WASI peuvent déjà permettre l’orchestration, avec des systèmes standard comme Kubernetes, de milliers d’applications génériques, chacune isolée au moins comme avec les conteneurs traditionnels – et côte à côte avec eux si nécessaire – mais avec beaucoup plus petits frais généraux.

Un Internet des objets piloté par WASI

La possibilité d’exécuter le même le format binaire sur des machines virtuelles extrêmement efficaces qui s’exécutent sur de nombreuses plates-formes différentes signifie encore plus qu’il n’y paraît à première vue, car:

« Un environnement d’exécution JavaScript compatible WASI et un micrologiciel simple peuvent synchroniser le logiciel d’un appareil avec un référentiel hébergé dans le cloud ou hébergé localement ».

Au cas où vous ne l’auriez pas remarqué, des procédures comme celles-ci peuvent rendre les tests et le déploiement automatiques de nouveaux micrologiciels ou logiciels pour l’IoT, ou tout autre appareil distant, vraiment, beaucoup plus faciles et fiables qu’ils ne le sont aujourd’hui. Si un périphérique distant peut exécuter le bytecode WebAssembly, tout développeur peut de manière fiable écrivez et testez un nouveau logiciel pour cela, en utilisant simplement « Simulateurs de base avec jumeaux numériques » de cet appareil, comme indiqué ici. N’est-ce pas WASI… intéressant?

La poste Comment WASI rend la conteneurisation plus efficace est apparu en premier le Linux Foundation – Formation.