WebAssembly au-delà du navigateur : la couche d'exécution universelle manquante

La première fois que la plupart des développeurs entendent parler de WebAssembly, l'explication est présentée de manière réductionniste : elle est utilisée pour exécuter du code C ou Rust dans le navigateur avec des performances proches du natif. C'est exact, et ce n'est que la pointe de l'iceberg.

Ce qui s'est passé ces dernières années était plus intéressant que le jeu sur Internet intensif. WebAssembly, ou Wasm, est devenu un format de bytecode portable qui s'exécute en dehors du navigateur, sur des serveurs, en périphérie, à l'intérieur de bases de données, en tant que système de plug-in et en tant que couche d'isolation pour le code tiers.

Lorsque vous cessez de voir Wasm comme une fonctionnalité frontale et commencez à le voir comme une cible de compilation universelle, la conversation change. Cela cesse d’être un détail de mise en œuvre et devient une décision architecturale.

Qu'est-ce que WebAssembly ?

Wasm est un format d'instruction binaire pour une machine virtuelle à pile. Vous compilez le code d'un langage de haut niveau (Rust, C, C++, Go et de plus en plus d'autres) dans ce format, et tout environnement d'exécution compatible peut l'exécuter.

La propriété qui rend cela précieux n’est pas seulement la vitesse. C'est la combinaison de trois choses : une réelle portabilité entre environnements, une isolation par défaut et une taille compacte des artefacts.

La portabilité signifie que le même binaire s'exécute dans le navigateur, sur un serveur Linux, dans un conteneur minimaliste et sur un périphérique Edge, sans recompilation pour chaque cible. Le runtime fait abstraction de la plateforme.

L'isolement signifie que le module Wasm fonctionne dans un boîtier fermé. Il n'a pas accès au système de fichiers, au réseau ou à la mémoire du processus hôte à moins que l'hôte n'accorde explicitement cet accès. Le modèle est refusé par défaut, à l'opposé d'une bibliothèque native qui hérite de tous les privilèges des processus.

La taille compacte est importante car un module Wasm est petit et démarre rapidement. Il n'y a pas d'image de conteneur de plusieurs centaines de mégaoctets ni de long processus de démarrage.

Pourquoi cela a cessé d'être une affaire de navigateur

Le tournant conceptuel est venu avec une interface appelée WASI, l'interface système pour WebAssembly. Il définit comment un module Wasm communique avec le monde extérieur (fichiers, horloge, réseau, variables d'environnement) de manière standardisée et en dehors du navigateur.

Avant WASI, Wasm dépendait des API du navigateur pour tout. Cela s’accompagne d’un contrat neutre en termes de plate-forme. Un moteur d'exécution sur le serveur implémente WASI et tout à coup, le même binaire qui s'exécuterait dans le navigateur s'exécute sur un hôte serveur avec un accès contrôlé aux ressources.

Cela ouvre l’idée de Wasm en tant que cible universelle. Le navigateur devient l’un des environnements possibles, et non le seul.

Les runtimes matures apparus dans cet espace (Wasmtime, WasmEdge, Wasmer, entre autres) traitent Wasm comme une unité d'exécution de premier ordre sur le serveur. Ils chargent le module, appliquent des limites de ressources, accordent des capacités spécifiques et s'exécutent, le tout avec une surcharge bien inférieure à celle du téléchargement d'un conteneur ou d'une machine virtuelle traditionnelle.

Où cela change-t-il l'architecture

Pensez au problème de l’exécution de code que vous n’avez pas écrit et auquel vous n’avez pas entièrement confiance. Plugins tiers, fonctions soumises par le client, extensions d'une plateforme, règles personnalisées définies par un utilisateur.

La réponse traditionnelle à ce problème est coûteuse : conteneurs, sandbox du système d’exploitation, processus isolés, machines virtuelles légères. Tout cela fonctionne, mais cela a des conséquences néfastes sur le temps de démarrage, la consommation de mémoire et la complexité opérationnelle.

Wasm offre une alternative beaucoup plus fine. Vous exécutez du code non fiable dans un module isolé, dans le même processus, en commençant en quelques microsecondes et avec une limite de sécurité définie par le modèle de machine virtuelle lui-même.

Cela ouvre trois fronts qui méritent l’attention de ceux qui conçoivent des systèmes. Le premier est l'avantage : les fonctions qui doivent démarrer instantanément et s'adapter à de nombreux emplacements géographiques bénéficient de la taille et de la vitesse de démarrage de Wasm. Le deuxième est l’extensibilité du produit : vous pouvez laisser les clients écrire une logique personnalisée et l’exécuter en toute sécurité au sein de votre plateforme. Le troisième est l'exécution multi-exécution : le même composant s'exécute dans différents environnements sans réécriture.

Chacun de ces fronts mérite sa propre analyse approfondie, et j'explore le cas du Edge en détail et le cas des plugins et du bac à sable dans d'autres textes.

Ce que Wasm n'est pas

Cela vaut la peine de calibrer les attentes, car l’enthousiasme a tendance à prendre le pas sur la réalité technique.

Wasm ne remplace pas l'intégralité de votre backend. Il s'agit d'une unité d'exécution, pas d'un framework d'application. Il faut encore de l'orchestration, de la persistance, de l'observabilité et tout le reste de l'appareil.

Wasm n'est pas comme par magie plus rapide que le code natif. Dans de nombreux cas, il fonctionne presque comme natif, mais il existe une surcharge de traduction et des limites du modèle de machine à pile. Le véritable avantage en termes de performances, par rapport aux conteneurs, réside davantage dans le temps de démarrage et la densité que dans le débit brut.

Wasm a encore des aspérités en matière d’intégration. Accès aux ressources système, threading, support complet de chaque langage pour la cible Wasm, outils de débogage : tout cela a évolué, mais n'est pas au même niveau de maturité qu'un écosystème natif consolidé. Il vaut la peine de connaître les limites du modèle de composant avant de parier gros.

Et Wasm ne renonce pas au travail de sécurité. L'isolement par défaut est une base solide, mais la manière dont vous accordez des capacités, limitez les ressources et auditez ce que fait le module reste de la responsabilité de l'architecte.

Comment penser l'adoption

La manière productive d’évaluer Wasm n’est pas de se demander si elle est meilleure qu’une autre technologie dans l’abstrait. Il s'agit d'identifier où la combinaison spécifique de portabilité, d'isolement et de démarrage rapide résout un problème que vos alternatives résolvent mal.

Si vous devez exécuter du code non fiable avec une granularité fine, Wasm est un candidat sérieux. Si vous avez besoin que le même artefact s'exécute dans des environnements hétérogènes sans recompilation, Wasm est à votre disposition. Si vous avez besoin de fonctions évolutives avec une latence de démarrage minimale, Wasm brille.

Si aucune de ces pressions n’existe dans votre système, il n’y a probablement aucune urgence. Adopter Wasm parce qu’il est intéressant, sans douleur concrète qu’il atténue, est le type de décision qui génère une dette sans retour.

La lecture stratégique est simple : Wasm est une couche d’exécution portable et sécurisée, et des couches comme celle-ci sont rarement protagonistes. Ce sont des infrastructures qui débloquent des cas d’utilisation. La valeur vient lorsque vous avez le bon cas d’utilisation qui l’attend.

Pour les équipes techniques, le meilleur investissement consiste désormais à comprendre le modèle de capacités, à expérimenter un runtime de serveur sur un problème réel et à mesurer. La technologie a suffisamment mûri pour quitter le laboratoire, et suffisamment tôt pour que bien la connaître constitue un avantage concurrentiel.