Évolution des normes Wasm : construction du modèle de composants

Plusieurs nouveaux efforts de normalisation sont en cours dans l'espace WebAssembly (Wasm), y compris ce que nous pensons être une nouvelle façon d'écrire des applications logicielles. En décrivant ce nouveau modèle, je voudrais plonger dans une partie de l'histoire de Wasm afin de décrire où nous nous dirigeons.

La conception de WebAssembly (Wasm) a commencé en 2015, des années avant de devenir officiellement la 4e langue du Web en 2019. Alors que de nombreux technologues connaissent Wasm en tant que technologie de navigateur, Wasm lui-même ne dépend pas de JavaScript ou des API Web.

Le précurseur de Wasm, asm.js , a pris de l'importance en 2013. Un sous-ensemble de JavaScript qui est hautement optimisable pour les navigateurs et qui peut servir de cible de compilation pour des langages comme C et C++. L'une de mes conférences préférées de tous les temps, "La naissance et la mort de JavaScript" couvre un futur fictif inspiré par asm.js . Notez les similitudes entre l'avenir que nous avons finalement ouvert avec les prédictions de Wasm et Gary en regardant son discours de PyCon 2014.

J'appelle souvent asm.js le plus grand hack de tous les temps (de la manière la plus affectueuse). Qui aurait cru qu'un langage de script de haut niveau pouvait être A")" une cible de compilation et B")" si incroyablement rapide ? En 2012, j'ai porté plusieurs bibliothèques C++ sur asm.js et j'ai senti que j'avais déverrouillé le code secret vers un univers portable.

La technologie a prouvé plusieurs choses. Tout d'abord, il y a un besoin et un désir d'apporter d'autres langages sur le Web, mais les développeurs ne voulaient pas s'arrêter là. Les types d'applications portées étaient exigeantes en termes de calcul et de graphisme, des outils de visualisation de données (comme les composants sur lesquels j'ai travaillé chez SAS) aux jeux construits avec Unity et Unreal Engine (UE3 a été porté en 4 jours ).

C'est pourquoi, lorsque le groupe communautaire W3C WebAssembly et le référentiel de conception WebAssembly correspondant ont été créés en 2015, les fournisseurs de navigateurs comme Mozilla, Google , Microsoft et Apple ont été parmi les premiers contributeurs à l'effort et les premiers à voir une opportunité tangible. La conception prévoyait un langage au format binaire pouvant être utilisé comme cible de compilation portable, optimisé en taille pour permettre des téléchargements rapides et une prise en charge de la compilation en continu qui permet au module téléchargé d'avoir une instanciation quasi instantanée. Plus important encore, ces modules doivent faciliter les [environnements d'exécution] en bac à sable, comme le doit tout code arbitraire exécuté dans les navigateurs.

Pourquoi Wasm au-delà du navigateur ?

Une grande partie de ce qui a été appris dans les déploiements côté navigateur a donné des indices sur les nombreuses façons dont Wasm pourrait réaliser son potentiel au-delà du navigateur. Le « cloud » constitue un ensemble hétérogène d'architectures de calcul, de systèmes d'exploitation et de contraintes système dans un réseau mondial de machines.

Considérez certaines des propriétés clés de Wasm comme une cible de compilation portable qui est rapide, en bac à sable et facilement distribuée grâce au format binaire compact. Ces propriétés de Wasm en font l'unité de calcul distribuable parfaite pour le cloud. De plus, les entreprises souhaitent créer des applications pour différents environnements, mais ne veulent pas avoir à refactoriser à chaque fois. Wasm supprime ces barrières.

Lorsque j'ai découvert asm.js pour la première fois, j'étais à la recherche d'une solution pour convertir notre application Flash existante en HTML5. Cette application ActionScript/Flex était une version réécrite de son homologue Java qui était un portage de versions antérieures de la même logique métier écrite en C. Cette histoire peut vous sembler folle si vous n'avez pas travaillé dans de grandes entreprises, mais vous pouvez trouver ce type de portage entre chaque époque de l'informatique dans chaque organisation qui a la chance de survivre à l'épreuve du temps.

Wasm permet une portabilité totale à tout environnement d'exécution compatible Wasm, y compris les navigateurs, les environnements d'exécution spécialement conçus pour FaaS ou quelque chose conçu pour fonctionner sur de petites architectures pour l'IoT. Sur le Web, les modules Wasm sont capables d'utiliser le code JavaScript "glue" pour accéder aux API Web telles que WebGL, la mise en réseau et les appareils pour faire des choses au-delà du calcul pur. En fin de compte, un programme Wasm ne fonctionne vraiment que sur des valeurs numériques, ou dit différemment, un module Wasm est un tas d'i32 dans un trench-coat. Pour faire des choses intéressantes, un module Wasm doit pouvoir appeler des fonctions à partir de l'environnement d'exécution de l'hôte.

WASI : la frontière du Wasm côté serveur

À peu près au même moment où WebAssembly 1.0 est devenu une norme Web recommandée, un nouveau sous-groupe au sein du groupe de travail W3C WebAssembly a été créé pour explorer une interface de niveau système pour WebAssembly connue sous le nom de WASI (WebAssembly Systems Interface). Depuis, le groupe travaille à la création d'un ensemble d'interfaces standardisées.

WASI existe pour que WebAssembly fonctionne bien n'importe où, pas seulement dans le navigateur, mais la caractéristique clé de WASI est son modèle de sécurité basé sur les capacités. La sécurité basée sur les capacités existe depuis les années 60 ( Dennis & Van Horn, 1966 ), mais Dan Gohman a conçu une nouvelle approche en s'appuyant sur les idées de Cloud ABI .

Naturellement, cette technologie a rapidement attiré l'attention des entreprises intéressées par l'exécution de Wasm en dehors du Web. Des entreprises comme Fastly, Intel, Red Hat et Mozilla ont vu une opportunité de faire fonctionner Wasm dans le cloud, sur des appareils et à la périphérie. Ces sociétés étaient les membres fondateurs de la Bytecode Alliance (BA), une organisation à but non lucratif chargée de créer des bases logicielles sécurisées pour Wasm en utilisant des normes telles que WASI. De nombreuses autres organisations ont rapidement rejoint la BA, y compris des acteurs majeurs de l'industrie du logiciel et elle compte maintenant plus de 30 membres et ne cesse de croître !

Au cours des deux dernières années, nous avons fait des progrès considérables dans la création des outils nécessaires pour exécuter Wasm dans des applications cloud natives . La communauté a beaucoup appris de ces premières expériences, ce qui nous a incités à créer une nouvelle norme que nous appelons maintenant le modèle de composants. Le modèle de composant est à un niveau inférieur à WASI, il fonctionne bien avec WASI mais ne dépend pas de WASI. C'est le résultat de notre vision d'un écosystème logiciel qui n'est pas seulement basé sur une unité de calcul portable, mais quelque chose d'entièrement nouveau avec des modules WebAssembly composables, interopérables et virtualisables de plate-forme.

Décomposons cela :

• Composabilité : permet la réutilisation du code modulaire d'une manière indépendante du langage.

• Virtualisation de plate-forme : La possibilité de superposer les éléments spécifiques à la plate-forme dont un composant a besoin pour s'exécuter dans un environnement donné. Une proposition antérieure pour la fonctionnalité de virtualisation de plate-forme et de composabilité s'appelait la liaison de modules.

• Interopérabilité : avec des composants composables et virtualisables, nous avons besoin d'un moyen d'échanger des informations entre les composants. Nous avons commencé avec une proposition appelée types d'interface, mais cela aussi est maintenant une caractéristique clé de la proposition de modèle de composant.

  
  

C'est l'histoire de la façon dont le modèle de composants a commencé à prendre forme. Chacune des propositions précédentes a maintenant été affinée dans cette norme globale. Nous nous attendons à voir la prochaine itération stable majeure des normes WASI et du modèle de composants plus tard cette année.

Normes WASI - où en sommes-nous maintenant ?

Ci-dessous, nous vous présentons un historique tracé de Wasm, WASI et du développement du modèle de composants.

2019 : Cible de compilation pure, ajoutant les premières interfaces qui connectent les appels système à l'hôte. À bien des égards, il est apparu que nous nous dirigions vers une version WebAssembly de POSIX. Nous avons pu écrire une CLI très simple et l'exécuter avec Wasmtime sur un ordinateur de bureau ou dans une fonction sans serveur.

2020 : Les API WASI se concentrent sur le genre de choses dont tout programme CLI pourrait avoir besoin, par exemple l'horloge système ou un système de fichiers. Le runtime Lucet Wasm de Fastly a fusionné avec Wasmtime (un projet BA).

2021 : Bien sûr, tous ces éléments continuent d'évoluer et de s'améliorer. En 2021, nous commençons à voir le développement de nouvelles interfaces WASI spécifiques à des cas d'utilisation, par exemple wasi-nn lorsque l'accélération matérielle est nécessaire pour l'inférence. C'est aussi l'année où Luke Wagner a commencé à définir le modèle de composants.

2022 : Nous commençons à voir de nouvelles API de niveau supérieur pour faire fonctionner correctement les modules Wasm dans les environnements cloud où des fonctionnalités telles que l'utilisation d'un magasin clé-valeur ou d'un service de messagerie pub/sub sont nécessaires. Enfin, après beaucoup de travail, les prises WASI ont été introduites. 2023 : Nous travaillons vers des jalons de stabilité pour le modèle de composants et les normes WASI.

En regardant le parcours depuis 2019, vous pouvez commencer à voir comment les normes se sont diversifiées à mesure que les cas d'utilisation se sont multipliés et que les utilisateurs commencent à choisir ce dont ils ont besoin et ce dont ils n'ont pas besoin. D'un bloc omniprésent à une suite croissante de blocs de construction plus petits conçus pour fonctionner les uns avec les autres dans un cadre flexible : le modèle de composants.

Qu'est-ce que le modèle de composant ?

Dans ce modèle, les développeurs peuvent choisir des éléments de leur application, implémentés dans différents langages, en tant que propositions de valeur différentes. Alors que les développeurs commencent à créer des bibliothèques de composants Wasm, d'autres développeurs peuvent les traiter comme la plus grande caisse de "LEGO" au monde.

Dans un moment de boucle complète, nous pensons que de nouvelles innovations viendront lorsque le modèle de composants commencera à influencer la façon dont nous écrivons des applications Web. Cela a du sens si l'on considère que le Web est l'un de ces environnements cool mais contraints, avec des utilisateurs très impatients - un terrain fertile pour de nouvelles expérimentations.

Par exemple, je m'attends à ce que les composants facilitent encore plus la conception d'un système de plug-in indépendant de la langue pour une application Web. S'il y a un élément nécessaire pour un runtime de langage comme Python, plusieurs composants qui exploitent ce runtime de langage pourraient l'utiliser. Comparez cela au monde d'aujourd'hui, où nous n'avons que des modules Wasm (pas des composants) et ceux-ci sont généralement construits avec toutes leurs dépendances au moment de la compilation intégrées dans un seul binaire. Si une grande application devait prendre en charge des plug-ins tiers, il est probable que chaque plug-in Wasm aura des dépendances en double entraînant une augmentation de la taille et de la mémoire et des téléchargements plus lents.

Avec un futur système de composants Wasm pour le Web, où une seule application peut avoir son choix de composants écrits dans n'importe quel langage, une application n'aura qu'à télécharger exactement ce dont elle a besoin et interagir avec les composants comme n'importe quel autre module ES avec une importation. Dans ce monde, le meilleur composant se hissera au sommet. Le meilleur pourrait signifier l'API la plus rapide ou la plus propre, mais le plus important, sa caractéristique déterminante ne sera pas le langage source. Que le meilleur composant gagne !

Construire une base technique stable pour WASI et les composants

Une grande partie de la concrétisation des normes WASI et du modèle de composants est le rôle que joue la BA dans la création d'un cadre technique utilisable : les SDK, les outils et les composants de base ; le tout construit de manière cohérente et sécurisée, et accessible par tous comme exemples de bonnes pratiques.

De même, le rôle du comité de pilotage technique (TSC) de la BA sera essentiel pour assurer la gouvernance technique et le soutien de chaque projet de la BA. Nous travaillons aux côtés des personnes qui conçoivent le meilleur ensemble de normes possible dans les groupes de travail W3C WebAssembly et WASI, ce qui signifie que nous collaborons avec eux pour nous assurer que tout fonctionne dans la pratique. Les groupes W3C WebAssembly et WASI se concentrent sur la finalisation de ces normes, et la BA s'attache à les rendre consommables au sein de la communauté le plus rapidement possible afin d'établir une boucle de rétroaction active.

Une autre partie importante de la charte de la BA est de permettre l'interopérabilité du langage et de l'environnement. La BA fournit des outils pour générer des liaisons linguistiques pour de nombreuses langues différentes, mais un aspect de la façon d'atteindre le nirvana de l'interopérabilité linguistique est que nous avons besoin de registres et de gestionnaires de packages dans divers écosystèmes linguistiques pour interagir avec les composants Wasm. C'est pourquoi nous travaillons à la conception d'un protocole de registre (appelé warg) dans le cadre de SIG-Registries qui permet à tout registre qui implémente le protocole de publier, consommer, stocker et partager des composants Wasm.

L'élément le plus critique de toute pile logicielle Wasm est peut-être le runtime Wasm, et le BA en héberge deux ! Wasmtime est écrit en Rust et est souvent le banc d'essai pour expérimenter de nouvelles propositions WASI et WebAssembly. Le WebAssembly Micro-Runtime ( WAMR ) est écrit en C et prend en charge de nombreuses architectures, y compris de petites architectures comme ESP32. Ces deux runtimes agissent comme d'excellentes implémentations de référence d'un runtime Wasm. Les SDK et les outils de création d'un module Wasm sont conformes aux normes Wasm, de sorte que tout environnement d'exécution Wasm conforme aux normes (y compris ceux qui ne sont pas hébergés par la BA) peut s'appuyer sur ces bases logicielles.

Compte tenu de toutes les nouvelles normes passionnantes évoluant via WASI et le modèle de composants et les implémentations de la Bytecode Alliance, je m'attends à ce que 2023 soit une année passionnante !

Commencez gratuitement avec Cosmonic dès aujourd'hui : lancez-le maintenant !

Par Bailey Hayes | Directeur de la Bytecode Alliance TSC et Cosmonic