Présentation

Cloudflare OS, annoncé le 12 mai 2024, étend la gamme de services d’exécution côté réseau de Cloudflare. Le produit se décrit comme « une plateforme ouverte pour agents, applications et flux de travail », permettant d’exécuter du code à la périphérie sans passer par les Workers classiques. La plateforme s’appuie sur l’infrastructure globale de Cloudflare, qui compte plus de 300 points de présence (PoP) répartis sur cinq continents, garantissant une latence inférieure à 10 ms pour la plupart des requêtes européennes.

Le lancement inclut un SDK multi‑langage (JavaScript, Rust, Go) et un catalogue d’agents pré‑packagés (cache‑purge, DNS‑monitor, etc.). Chaque agent fonctionne dans un environnement sandbox isolé, similaire à un conteneur léger, avec un accès limité aux API réseau de Cloudflare.

Architecture

Cloudflare OS repose sur le même moteur d’exécution V8 utilisé par les Workers, mais ajoute une couche d’orchestration appelée OS Runtime. Cette couche gère le cycle de vie des agents : création, mise à jour, mise à l’échelle et destruction. Le Runtime expose un manifest YAML qui décrit les ressources requises (CPU, mémoire, stockage temporaire) et les permissions (accès aux KV, aux logs, aux API tierces).

name: hello-agent
runtime: javascript
cpu: 0.1
memory: 128Mi
permissions:
  - kv:my_namespace
  - logs
entrypoint: index.js

Le manifeste est analysé à la compilation ; le Runtime alloue les ressources dans un pool de micro‑VMs (Firecracker) d’une taille fixe de 256 MiB, limitant ainsi le risque d’escalade de privilèges. Les micro‑VMs partagent le même réseau de bord, ce qui évite les coûts de routage supplémentaires.

Fonctionnement des agents

Un agent se déclenche soit par un événement HTTP, soit par un déclencheur interne (ex. : expiration d’une clé KV). Lorsqu’un événement survient, le Runtime charge le code depuis le stockage Cloudflare R2, initialise le sandbox et transmet le contexte d’exécution. Le temps moyen de démarrage d’une micro‑VM est de 30 ms, ce qui, combiné à la proximité du PoP, maintient la latence totale sous 50 ms pour les flux critiques.

Les agents peuvent appeler les API Cloudflare (Workers KV, Durable Objects, Images) via des bibliothèques standardisées. Par exemple, un agent de purge de cache utilise l’API POST /client/v4/zones/:zone_id/purge_cache avec un token d’accès limité à la portée cache_purge. Cette granularité de permission réduit l’exposition en cas de compromission du code.

Analyse des performances et limites

Les premiers benchmarks publiés par Cloudflare montrent un débit moyen de 1 200 req/s par micro‑VM pour du JavaScript simple, et 800 req/s pour du Rust compilé en WebAssembly. Le facteur limitant reste la capacité de stockage temporaire : chaque micro‑VM ne dispose que de 64 MiB de disque éphémère, insuffisant pour des traitements de données massives. De plus, le modèle de facturation repose sur le nombre d’exécutions et la durée d’allocation (0,001 $ par seconde de CPU), ce qui peut rendre les charges très fréquentes coûteuses.

Sur le plan sécurité, la sandbox V8 + Firecracker offre une isolation robuste, mais la dépendance à un manifeste YAML expose le système à des erreurs de configuration. Un champ mal renseigné (ex. : cpu: 2 au lieu de 0.2) peut entraîner une surcharge de ressources dans un PoP, affectant la stabilité des autres services. Cloudflare recommande donc l’usage d’outils de validation automatisée avant le déploiement.

En résumé, Cloudflare OS fournit une couche d’abstraction qui simplifie le déploiement d’applications edge, tout en conservant les contraintes de latence et de sécurité inhérentes à l’infrastructure de bord. Son adoption dépendra de la capacité des équipes à optimiser le manifeste et à gérer les coûts d’exécution à grande échelle.