WebAssembly à la périphérie : pourquoi un démarrage rapide et isolé est important

Le principe du sans serveur a toujours été séduisant : écrire une fonction, ne pas gérer de serveur, payer pour l'utilisation réelle. Le problème est que la mise en œuvre n’a jamais été aussi claire que le discours. Les conteneurs doivent s'initialiser. Les processus sont réutilisés entre les demandes de différents clients. Et plus votre système doit être global, plus la latence d'une fonction se réveillant à froid à l'autre bout de la planète devient coûteuse. WebAssembly à la périphérie résout exactement cet ensemble de problèmes — non pas en étant plus rapide en termes de débit brut, mais en ayant un modèle d'exécution fondamentalement différent.

Le problème des démarrages à froid

Lorsqu'une fonction Lambda reçoit sa première requête après une période d'inactivité, le runtime doit initialiser l'environnement. Selon la langue et la taille du paquet, cela coûte entre 100 ms et 500 ms. Conteneur dans Cloud Run ou Kubernetes ? Cela peut prendre entre une et dix secondes avant qu'il soit prêt à desservir le trafic. Pour les API internes pour lesquelles la latence P99 n’est pas un problème critique, vous pouvez l’accepter. Pour la logique qui touche chaque demande utilisateur (routage géographique, validation des jetons, personnalisation des en-têtes, tests A/B), ce temps devient un problème visible.

Cloudflare Workers et Fastly Compute ont fait des choix architecturaux qui éliminent structurellement ce problème. Dans Workers, le code s'exécute dans des isolats V8, des partages légers au sein du même processus. l'isolat existe déjà ; lorsqu'une requête arrive, elle est envoyée en microsecondes. Le démarrage à froid, en pratique, se rapproche de zéro. Dans Fastly Compute, l'approche est encore plus directe : le module Wasm est compilé à l'avance en code natif sur la machine hôte et chargé comme une pure unité d'exécution. Moins d'une milliseconde entre le début et le traitement.

Deno Deploy suit une ligne similaire, avec la prise en charge de TypeScript, JavaScript et Wasm distribuée dans plus de trente emplacements périphériques. Le résultat est le même : l'écart entre « la demande est arrivée » et « la fonction a commencé à s'exécuter » s'effondre en quelque chose qui n'est plus mesurable dans l'expérience utilisateur.

Isolement par demande, pas par processus

Il y a un détail qui apparaît rarement dans les tutoriels serverless mais qui compte beaucoup dans les environnements multi-tenant : que se passe-t-il entre des requêtes consécutives au sein d'un même processus ?

Dans les fonctions Lambda et Cloud Run, le conteneur ou le processus est souvent réutilisé pour gagner en efficacité. C'est bon pour les performances, mais cela crée une fenêtre dans laquelle un état accidentel peut s'échapper entre les invocations. Les variables globales modifiées par une requête peuvent influencer la suivante. Connexions ouvertes, caches en mémoire : tout cela persiste dans le même processus. Pour les applications sans patrimoine par conception avec des équipes disciplinées, ce n'est pas un problème. Mais c’est une surface de risque qui existe.

Le modèle Wasm au bord ferme cette surface d'une autre manière. Chaque module Wasm fonctionne sur sa propre mémoire linéaire : un tableau contigu d'octets privé à ce module. Il n’y a pas de tas partagé entre les requêtes. Il n'y a aucun moyen pour une requête de lire la mémoire d'une autre, même si elles s'exécutent sur le même matériel en même temps. L'isolement ne dépend pas d'un processus distinct ; c'est au niveau du modèle d'exécution de la machine virtuelle.

Pour les plates-formes qui exécutent la logique de milliers de clients sur le même matériel, ce détail n'est pas facultatif. C'est la différence entre un modèle de sécurité sur lequel vous pouvez formellement raisonner et un modèle qui s'appuie sur les meilleures pratiques de chaque équipe.

Où Edge Wasm l'emporte sur Lambda et Cloud Run

La victoire n'est pas universelle. Il existe un ensemble spécifique de cas où la combinaison du démarrage instantané, de la distribution mondiale et de l'isolation des demandes crée une réelle différence de produit.

La logique qui doit être proche géographiquement de l’utilisateur en profite davantage. Routage par localisation, réponses personnalisées par marché, validation de l'authentification avant d'atteindre le serveur d'origine — tout cela a une latence directement impactée par l'endroit où le code s'exécute. Une fonction périphérique fonctionne dans une présence réseau à des dizaines de millisecondes de l'utilisateur, et non dans une région cloud à des centaines de secondes.

La modification des requêtes et des réponses convient également : injection d'en-têtes, réécriture d'URL, application d'une mise en cache personnalisée, redirection basée sur des tests A/B. Il s’agit d’opérations nécessitant peu de CPU et ayant un impact important sur l’expérience. La logique de limitation de débit et la détection des robots gagnent également : contrôlez le trafic avant qu'il n'atteigne l'infrastructure principale, personnalisée par locataire, gérée à l'échelle mondiale.

Là où le modèle ne tient pas

La limite de CPU par requête est stricte : environ cinquante millisecondes sur la plupart des plateformes. Tout traitement plus long est en dehors du modèle.

Les charges de travail avec état constituent l’autre limite structurelle. Wasm à la périphérie n'a pas d'accès natif à base de données, et toute persistance passe par un appel réseau vers la source. Si la logique métier consiste à lire, transformer et écrire des données, la latence de cet appel peut annuler tout gain de pointe. Les lourdes dépendances posent également problème : un module Wasm avec des mégaoctets de bibliothèques perd l'avantage d'une initialisation rapide.

L'échange est explicite : vous bénéficiez d'une distribution mondiale et d'un démarrage instantané, et renoncez aux processus de longue durée, à un accès riche au système d'exploitation et aux charges de travail gourmandes en CPU. Accepter ce commerce pour les bons cas – et le rejeter pour les mauvais – est la décision architecturale qui compte.

Ce que le responsable technique doit évaluer

La question productive n’est pas « devrions-nous utiliser Edge Wasm ? » mais « quelle fraction de la logique de pointe de notre plate-forme gagne grâce à ce modèle ? » Presque toutes les plateformes ont une logique qui touche chaque requête : authentification, routage, indicateurs de fonctionnalité, mise en cache personnalisée. Cette logique est une candidate naturelle.

L’évaluation commence par cartographier la latence actuelle par région géographique. S’il existe une grande divergence entre P50 et P99 selon l’endroit où se trouve l’utilisateur, l’edge computing entre dans la conversation. Si la base d’utilisateurs est géographiquement concentrée, l’avantage diminue.