Cold start WASM vs conteneurs : ce que disent Wasmtime, Wasmer et WasmEdge

Le cold start désigne la latence supplémentaire payée par une requête quand l’environnement d’exécution doit s’initialiser avant que le code applicatif ne tourne. Sur une fonction edge ou serverless classique, c’est loin d’être un cas marginal : une plateforme qui descend à zéro instance entre deux pics de trafic, ou qui distribue son exécution sur des dizaines de nœuds edge géographiquement dispersés, paie ce coût en permanence, pas seulement au premier déploiement.

Le sujet a pris une ampleur presque symbolique dans l’écosystème WASM depuis une phrase de Solomon Hykes, cofondateur de Docker, publiée sur Twitter en mars 2019 : « If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is. WebAssembly on the server is the future of computing. » C’est une opinion de praticien reconnu, pas une mesure. Elle explique pourquoi le sujet fascine, elle ne remplace pas un chiffre sourcé.

Aurabase propose deux chemins pour ses fonctions edge : l’éditeur Studio, qui exécute du code en runtime Deno comme documenté dans notre guide de migration Supabase, et la CLI aura functions deploy, qui vise un chemin distinct pour des fonctions écrites en Rust et compilées en WASM sur Wasmtime. C’est ce second chemin que cet article éclaire, sans lui attribuer un chiffre de cold start qui n’existe pas encore.

Démarrer un conteneur mobilise le noyau de l’hôte : création d’un nouveau processus, mise en place des cgroups et des namespaces qui l’isolent, montage des couches de l’image, puis démarrage du runtime applicatif à l’intérieur (Node.js et son moteur V8, par exemple, ont eux-mêmes un coût d’initialisation). Chaque étape ajoute des appels système et, pour une image jamais vue localement, un téléchargement réseau avant même de commencer.

Un module WebAssembly, lui, est isolé au niveau du langage machine virtuel, pas au niveau du système d’exploitation. Instancier un module signifie allouer sa mémoire linéaire, lier ses imports, puis sauter à son point d’entrée, le tout dans le processus déjà démarré du runtime hôte. Aucun nouveau processus, aucune couche d’image, aucun montage de système de fichiers par défaut.

Le choix du mode de compilation ajoute une variable supplémentaire. Wasmtime compile en JIT via son backend Cranelift au chargement du module, ou peut le précompiler à l’avance avec wasmtime compile, ce qui produit un fichier .cwasm déjà transformé en code machine natif. La compilation anticipée (AOT) retire l’étape de compilation du chemin critique de la requête : c’est exactement le levier qu’une architecture edge sensible au cold start doit activer.

# Extrait réel du dépôt Aurabase
# WASM Runtime
wasmtime = { version = "43", features = ["async", "cranelift"] }

C’est une dépendance de production, pas de développement : elle confirme que Wasmtime tourne réellement sur le chemin CLI des fonctions edge Aurabase. Elle ne confirme, en revanche, aucun chiffre de latence, ce qui reste vrai tant qu’aucun benchmark daté n’est publié.

Sur ce terrain, la source la plus solide est un papier de recherche industriel, pas un billet de blog marketing. Firecracker, la technologie de microVM légère développée par AWS et utilisée notamment pour Lambda et Fargate, a été présentée à la conférence USENIX NSDI 2020 par Agache et al. dans l’article « Firecracker: Lightweight Virtualization for Serverless Applications ».

Ce papier documente un temps de démarrage inférieur à 125 ms et une surcharge mémoire inférieure à 5 MiB par microVM, avec la possibilité de faire tourner des milliers de microVM sur une même machine physique. C’est un chiffre daté (2020), sourcé à une publication académique évaluée par des pairs, et abondamment cité depuis dans la littérature sur l’isolation serverless.

Un conteneur Docker standard se situe généralement plus haut : de quelques centaines de millisecondes à plusieurs secondes selon la taille de l’image, la nécessité de la télécharger, et le temps d’amorçage du runtime applicatif embarqué. Il n’existe pas ici de chiffre unique universellement cité, contrairement à Firecracker : le résultat dépend trop de l’image testée pour qu’une seule valeur fasse consensus.

Fastly a lancé Compute@Edge en 2019 sur Lucet, son propre compilateur et runtime WASM en compilation anticipée. À ce lancement, l’entreprise a documenté des temps d’instanciation WASM sous la milliseconde, un ordre de grandeur qui a marqué durablement le discours sur le cold start WASM dans l’industrie. En 2021, Fastly a cessé le développement autonome de Lucet et a réorienté ses efforts vers Wasmtime, dont le backend de compilation Cranelift a hérité d’une partie de ces optimisations : c’est une des raisons pour lesquelles Wasmtime reste aujourd’hui une référence pour ce type de charge.

WasmEdge, un runtime WASM passé sous gouvernance de la CNCF (à l’origine SSVM, porté par Second State), revendique dans sa documentation officielle un démarrage et une empreinte mémoire nettement inférieurs à un conteneur Docker équivalent, avec un positionnement explicite sur les charges edge et IoT. C’est un chiffre publié par l’éditeur du projet lui-même, à lire comme tel : une revendication produit, pas un audit indépendant.

Côté recherche académique, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, également disponible en prépublication) construit une plateforme serverless à état en s’appuyant sur l’isolation WebAssembly (via WAVM, pas Wasmtime) précisément parce qu’elle permet d’instancier une fonction à un coût largement inférieur à l’isolation par conteneur ou par VM. Le papier ne porte pas spécifiquement sur Wasmtime, mais il apporte une validation académique indépendante à l’argument structurel de la section précédente.

Comparer ces trois runtimes uniquement par leur nom masque la vraie variable : le backend de compilation choisi, qui change radicalement l’équilibre entre vitesse de démarrage et performance d’exécution.

Singlepass, le backend de compilation le plus rapide de Wasmer, existe précisément parce que son équipe a identifié le cold start comme un axe distinct de la performance d’exécution en régime établi : un module compilé en Singlepass démarre plus vite, mais tourne moins vite en pic de charge qu’un même module compilé en LLVM. C’est un compromis assumé, pas un défaut caché.

Ces cinq lignes ne se lisent pas comme un classement unique : elles viennent de méthodologies, de dates et de générations de runtime différentes. Pour une critique méthodologique plus poussée de la fiabilité de ce type de benchmark WASM, notre article sur les limites des benchmarks WebAssembly va plus loin que le présent comparatif, qui reste centré sur ce que chaque source affirme concrètement.

Il pèse particulièrement sur un trafic edge très irrégulier (rafales suivies de silences), sur une isolation par requête plutôt que par conteneur partagé entre plusieurs requêtes, et sur une infrastructure qui redescend réellement à zéro instance entre deux pics plutôt que de garder un pool chaud en permanence. Sur une charge stable et prévisible, où les instances restent chaudes de toute façon, l’écart de cold start compte structurellement moins.

WebAssembly garde par ailleurs des contraintes distinctes du cold start : l’accès au système de fichiers ou au réseau passe par WASI, une interface encore en évolution selon les runtimes et leurs versions, et un module compilé pour démarrer vite (Singlepass côté Wasmer, par exemple) n’est pas nécessairement le plus rapide une fois en régime établi sous forte charge. Cold start et performance d’exécution en pic restent deux axes distincts, rarement optimaux simultanément sur le même profil de compilation.

Pour évaluer un choix d’architecture edge sur ce critère, trois questions concrètes à poser à n’importe quel fournisseur, Aurabase inclus : quel runtime exact est utilisé, quel backend de compilation (JIT ou AOT), et le chiffre de cold start avancé a-t-il été mesuré par un tiers indépendant ou uniquement par l’éditeur du runtime lui-même.

Pour la couche base de données de ce même problème, voir notre article sur le cold start Postgres serverless.