4 pièce(s) jointe(s)
Bytecode Alliance annonce la version 1.0 de Wasmtime, l’environnement d’exécution web WebAssembly
Bytecode Alliance annonce la version 1.0 de Wasmtime, l’environnement d’exécution web WebAssembly,
serait prêt pour une utilisation en production
Dans une publication sur son site officiel, Bytecode Alliance a annoncé la sortie de la version 1.0 de Wasmtime. « À partir d'aujourd'hui, le runtime Wasmtime WebAssembly est passé à la version 1.0 ! Cela signifie que nous tous, membres de la Bytecode Alliance, sommes d'accord pour dire qu'il est entièrement prêt à être utilisé en production. En vérité, nous aurions pu dire que Wasmtime était prêt à être utilisé en production il y a plus d'un an. Mais nous ne voulions pas sortir n'importe quel moteur WebAssembly. Nous voulions avoir un moteur WebAssembly super rapide et super sûr. Nous voulions nous sentir vraiment en confiance lorsque nous recommandions aux gens de choisir Wasmtime », a déclaré Lin Clark, Ingénieur principal senior travaillant sur WebAssembly chez Fastly
Le rapport sur l'état du développement de WebAssembly (The State of WebAssembly 2022) révèle que Wasmtime est l'environnement d'exécution le plus utilisé. En outre, l'utilisation de WebAssembly en tant que plug-in hôte, pour les applications sans serveur et la conteneurisation a considérablement augmenté.
Voici quelques-unes des expériences avec la nouvelle version améliorée de Wasmtime :
- Shopify est passé d'un autre moteur WebAssembly à Wasmtime en juillet 2021. Avec ce changement, Shopify a vu une amélioration moyenne des performances d'exécution d’environ 50 % ;
- Fastly est passé d'un autre moteur WebAssembly à Wasmtime en mars 2022. Fastly a également vu une amélioration d’environ 50 % du temps d'exécution. De plus, Fastly a vu une augmentation de 72 % à 163 % des demandes par seconde qu'il pouvait servir. Fastly a depuis servi des trillions de demandes en utilisant Wasmtime ;
- DFINITY a lancé la blockchain Internet Computer en utilisant Wasmtime en mai 2021. Depuis lors, l'ordinateur Internet a exécuté 1 quintillion (10^18) d'instructions pour plus de 150 000 contrats intelligents sans aucun problème de production ;
- InfinyOn Cloud utilise Wasmtime en production depuis juillet 2021. Avec Wasmtime, InfinyOn a été en mesure de fournir une amélioration de débit supérieure à 5 fois dans le traitement de flux de bout en bout par rapport aux plateformes basées sur Java comme Kafka ;
- Fermyon's Spin utilise Wasmtime depuis sa sortie en mars 2022. Depuis lors, Fermyon a constaté que des dizaines de milliers de binaires WebAssembly peuvent s'exécuter dans une seule instance de Spin tout en gardant des temps de démarrage inférieurs à une milliseconde ;
- Embark utilise Wasmtime dans son moteur de jeu depuis 2020. Depuis lors, Embark a été impressionné par la stabilité, la sécurité et les performances exceptionnelles de Wasmtime, permettant aux jeux de fonctionner à 60 FPS ;
- SingleStoreDB Cloud utilise Wasmtime depuis juin 2022 pour amener le code des développeurs aux données, en toute sécurité et avec vitesse et échelle ;
- Microsoft a utilisé Wasmtime en Preview pour ses pools de nœuds WebAssembly System Interface (WASI) dans Azure Kubernetes Service depuis octobre 2021.
Avec toute cette expérience de l'exécuter en production, Bytecode Alliance se dit capable de recommander Wasmtime en toute confiance.
À l'origine, WebAssembly a été créé pour accélérer l'exécution du code dans le navigateur. Cela signifiait que les utilisateurs pouvaient exécuter des applications beaucoup plus complexes, comme des applications d'édition d'images ou des jeux vidéo, dans le navigateur. Ainsi, chacun des principaux navigateurs possède son propre moteur d'exécution WebAssembly pour exécuter ce type d'applications.
Toutefois, WebAssembly ouvre également la voie à de nombreux cas d'utilisation en dehors du navigateur. Dans ces cas, il est necessqire d'avoir un runtime WebAssembly autonome comme Wasmtime. Voici quelques-uns des cas d'utilisation de Wasmtime.
Microservices et sans serveur
Un runtime WebAssembly comme Wasmtime est parfaitement adapté aux plateformes Microservices et Serverless, où vous avez des morceaux de code indépendants qui ont besoin de monter et descendre rapidement en charge. C'est parce que WebAssembly a un temps de démarrage beaucoup plus faible que d'autres technologies similaires, comme les isolats JS, les conteneurs ou les VMs.
Par exemple, l'alternative la plus rapide un isolat JS - met environ 5 ms pour démarrer. En revanche, il ne faut que 5 microsecondes à une instance de Wasm pour démarrer. De plus, l'isolation légère de WebAssembly est idéale pour les plateformes multi-tenant car vous pouvez faire tenir beaucoup plus de charges de travail sur la même machine qu'avec des VM, des conteneurs ou d'autres technologies d'isolation à gros grains.
Systèmes de plugins tiers
WebAssembly est idéal pour les plateformes, où l'on souhaite souvent exécuter du code tiers afin de pouvoir prendre en charge de nombreux cas d'utilisation spécifiques différents - par exemple, par le biais de marchés de plug-ins où les développeurs de l'écosystème de la plateforme peuvent partager du code avec les utilisateurs.
Avec WebAssembly, les plates-formes peuvent exécuter du code non fiable tout en bénéficiant de certaines garanties de sécurité. Étant donné que WebAssembly est un bac à sable par défaut et qu'il ne peut accéder à aucune ressource que vous ne lui avez pas explicitement confiée, la plateforme ne court aucun risque. Et la communication entre la plate-forme et le plug-in reste rapide.
Bases de données, analyses et streaming d'événements
Pour les applications reposant sur des bases de données, WebAssembly peut vraiment accélérer les choses. Ces applications perdent souvent beaucoup de temps à interroger une base de données de manière répétée, à effectuer des calculs sur la base des données renvoyées, puis à lancer d'autres requêtes pour obtenir davantage de données. Une façon d'accélérer cette communication est d'amener le code aux données avec les fonctions définies par l'utilisateur (UDF). Ces fonctions permettent d'exécuter le code directement dans la base de données, en éliminant les appels réseau entre les deux.
Avec l'aide d'un moteur d'exécution WebAssembly, les bases de données peuvent utiliser des fonctions définies par l'utilisateur basées sur WebAssembly pour associer le code et les données. Cela permet d'effectuer des calculs rapides sur les données sans exposer la base de données elle-même à des risques de sécurité.
Et comme il s'agit de WebAssembly, ces bases de données peuvent prendre en charge un grand nombre de langages différents dans leurs UDF en toute sécurité, sans risque qu'un UDF se plante et fasse tomber toute la base de données. Cela rend les UDF beaucoup plus faciles à aborder pour les utilisateurs qui ne sont pas très familiers avec une base de données particulière.
Environnements d'exécution de confiance
Les environnements d'exécution de confiance (TEE) sont conçus pour les cas où l'utilisateur ne peut ou ne veut pas faire confiance aux niveaux inférieurs du système, comme l'hyperviseur, le noyau ou d'autres logiciels système. Les TEEs fournissent une zone sécurisée sur l'unité centrale où le code hébergé par les TEEs s'exécute, isolé de tous les autres logiciels.
WebAssembly est idéal pour ces cas d'utilisation car il prend en charge de nombreux langages différents et est indépendant de l'architecture du processeur. Il est donc plus facile d'exécuter un TEE sur différentes plateformes matérielles.
Clients mobiles
Le navigateur est un bon exemple de client mobiles, et de nombreuses applications peuvent être exécutées dans le navigateur. Mais parfois, vous avez besoin d'un client mobiles qui se trouve en dehors du navigateur, que ce soit pour des raisons de performances ou pour offrir une expérience utilisateur plus riche.
Dans ce cas, il est possible de créer son propre client mobile à l'aide d'un runtime WebAssembly, comme l'a fait la BBC pour son iPlayer. Le moteur d'exécution WebAssembly se charge de la portabilité et s'assure que le code invité peut fonctionner sur différentes architectures. Cela signifie qu'il est possible de se concentrer sur les fonctionnalités que vous voulez que votre client fournisse.
Le temps d'exécution d'un code est la vitesse à laquelle il s'exécute réellement une fois qu'il a démarré. Ceci est particulièrement important lorsqu'on a du code qui s'exécute longtemps, comme les clients mobiles. Bytecode Alliance dit avoir améliorer les performances d'exécution grâce à une variété de changements. Certains des gains les plus importants proviennent des changements que nous avons apportés à notre compilateur, Cranelift, qui prend le code WebAssembly et le transforme en code machine.
Source : Bytecode Alliance
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: L'édition 2022 du rapport sur l'état du développement de WebAssembly révèle que Rust est le langage le plus utilisé et le plus recherché et les applications Web sont le cas d'utilisation principal
Voir aussi
:fleche: « Pourquoi j'ai quitté l'équipe WebAssembly de Google, et comment cela m'a rendu malade », un témoignage de Katelyn Gadd, conceptrice de jeux et programmeuse d'outils
:fleche: JavaScript et Python règnent, mais Rust monte en puissance, le nombre d'utilisateurs de Rust dans le monde serait passé à 2,2 millions, selon une enquête de SlashData
:fleche: State of the Developer Nation : JavaScript aurait une communauté composée d'environ 14 millions de développeurs, alors que Python est le langage avec la croissance la plus forte ces dernières années
:fleche: Wasmer : un runtime open source pour l'exécution de WebAssembly sur un serveur, tout en prenant en charge l'API Wasm-C
