latent-service-fabric

Latent Service Fabric (LSF) est une structure d’exécution expérimentale native des composants, écrite en Rust et construite sur Wasmtime. Son runtime autonome exécute des capsules de service sans état déployables indépendamment sur un seul nœud Linux sans attribuer de processus persistants, sockets, threads, tas invités ni pools de connexions aux services inactifs. Un service déployé est représenté par du code immuable, des contrats, une politique et des métadonnées de déploiement/routage. Les ressources d’exécution ne sont allouées que lorsqu’une invocation devient une activation, et les activations s’exécutent dans un pool fixe de cellules sandbox réutilisables. L’invariant central énoncé est que l’état résident équivaut à un runtime de nœud fixe plus des métadonnées de catalogue bornées, des activations actives et des caches partagés bornés ; les nombres de processus, threads, sockets et cellules sont définis par le nœud et ne doivent pas évoluer avec le nombre de services déployés. Les couches d’interface incluent WIT pour les exports de capsules et les capacités de plateforme, Protobuf pour les API de plan de contrôle, de gestion de nœuds, de gestion de déclencheurs et d’invocation, JSON Schema pour les ressources déclaratives, des traits Rust pour les jointures internes, et des surfaces SDK par langage. Le dépôt est organisé en apps (nœud latentd autonome, CLI opérateur, espace réservé de plan de contrôle), crates, wit, api/proto, schemas, sdk, examples, adr, rfcs, research, docs, tests, benchmarks et tools. Binaires : latentd (nœud Linux autonome via serve --config, plus un harnais fini phase0-spike et une preuve de confinement verify-recovery), latent-control (espace réservé de plan de contrôle en cluster), et latent (construction/inspection/vérification locale de paquets, transfert OCI, cycle de vie des versions, rollout/canari/rollback, audit, invocation et commandes de routage). Les fonctionnalités documentées de la phase 1 incluent des builds verrouillés et des contrats générés, des contrats d’invocation SDK dans six langages, le décodage et la validation de manifestes, la comptabilité des ressources avec échéances et annulation, le stockage local des versions avec vérification par digest, le déploiement et le routage avec des générations de routes immuables, le contrôle d’admission et les quotas, l’ordonnancement équitable, l’exécution générique de composants via Wasmtime, les capacités et le cycle de vie des activations, la télémétrie, les services d’invocation et de gestion, le nœud autonome, la CLI opérateur, des tests de conformité bornés et des rapports de mesure. Le projet documente aussi des exécutions de comparaison Docker et Kubernetes (9 926 offres complètes par plateforme), rapportant une latence de requête à chaud plus faible pour les services natifs et une mémoire applicative plus faible pour LSF à 8 et 32 services, tout en notant les limites de démarrage à froid, les différences de limites de ressources et l’environnement Docker Desktop/WSL2. La phase 2 ajoute l’empaquetage déterministe et le transfert authentifié vers un registre OCI, la confiance des éditeurs, la provenance de build et la vérification SBOM, l’admission de confiance et le cycle de vie des versions, la compilation isolée avec un cache d’images natives persistant, l’audit administratif durable, les observations canari, la coordination manuelle des rollouts, la promotion canari contrôlée, le rollback atomique et les workflows opérateur. Le projet indique que la vérification locale et les observations canari copiées n’autorisent ni l’exécution ni la promotion, et que les déploiements gérés lient un ID d’opération conservé par l’appelant, une génération d’objet exacte et une version d’état de catalogue. La phase 0 est un spike de faisabilité local étroit : construire un invité Rust echo Component Model, le charger et l’invoquer via de véritables bindings Wasmtime, louer et récupérer une cellule d’exécution avec une file bornée, contenir les erreurs de domaine déclarées, les traps, les timeouts, l’annulation et la pression mémoire, et enregistrer un état d’activation borné. Le README indique explicitement qu’il ne prouve pas le routage, l’admission, la gestion des déploiements, la confiance/sécurité de production, l’état durable, l’invocation distante, le clustering, les SLO de production ni l’invariant des 100 000 services dormants. La construction et la validation utilisent une chaîne d’outils épinglée (Rust, Component Model, Protobuf, schéma, outils SDK) avec un environnement virtuel Python et make validate ; les tests coûteux tels que la sonde de catalogue à 100 000 versions et les soaks Linux natifs nécessitent une sélection explicite. make phase0-spike-demo exécute la démonstration exécutable, et make phase0-gate écrit un reçu lisible par machine. Les bindings et descripteurs générés sont isolés sous Cargo OUT_DIR ou target/contracts. Sous licence Apache 2.0.