jeudi, 28 mars 2024

SpiderLightning : rendre les applications cloud WebAssembly portables

La combinaison de WebAssembly et de Kubernetes est un développement intéressant. Là où les conteneurs traditionnels peuvent être volumineux et prendre du temps à se déployer, même en utilisant des distributions Linux hôtes dédiées allégées, les applications WebAssembly nécessitent simplement un environnement d’exécution standard et, comme il s’agit de fichiers binaires dédiés, nécessitent beaucoup moins de ressources système. Cela en fait une alternative attrayante aux conteneurs pour les applications qui doivent évoluer rapidement ou doivent fonctionner dans des environnements contraints.

La prise en charge de WebAssembly par Microsoft dans son service Azure Kubernetes est un grand vote de confiance dans cette technologie, et son ajout récent de la prise en charge du runwasi containerd shim simplifie le déploiement en utilisant Kubernetes pour gérer directement le code WebAssembly. Cette prise en charge s’appuie sur de nouveaux frameworks d’application WebAssembly qui aident les développeurs à utiliser WebAssembly, en collaboration avec le runtime Wasmtime pour l’interface système WebAssembly sans navigateur (WASI).

Présentation de SpiderLightning

L’un de ces frameworks est la filiale de Microsoft SpiderLightning de Deis Labs. Conçu spécifiquement pour créer des applications distribuées et nommé d’après un type d’éclair qui peut parcourir des centaines de kilomètres à travers les nuages, SpiderLightning est une implémentation d’un ensemble d’interfaces d’application communes pour les applications WASI, utilisant le langage de définition d’interface WIT.

Il existe une forte corrélation entre la conception de WebAssembly (et plus précisément de WASI) et les besoins des développeurs qui créent des applications distribuées natives du cloud. Il contourne les différences entre les différentes plates-formes de fournisseurs de cloud, mais pas comme un moyen d’éviter le verrouillage et de permettre la portabilité. Au lieu de cela, il se concentre sur la façon dont nous pouvons fournir une véritable plate-forme multicloud indépendante des services qui peut aller du matériel de pointe standard aux hyperscalers, en utilisant tout, du matériel Raspberry Pi aux derniers serveurs multicœurs et multiprocesseurs d’Intel, AMD ou Arm .

WASI fournit nous plusieurs des éléments nécessaires pour y parvenir vision, quoique sous une forme assez rudimentaire. Ce n’est pas surprenant; Nous en sommes encore aux tout premiers jours d’une nouvelle plate-forme et nous ne devrions pas nous attendre à ce qu’elle ait la maturité de quelque chose de plus de 20 ans, comme la JVM ou le .NET CLR. Malgré tout, il est clair que les concepteurs de la plate-forme en ont tenu compte et fournissent les outils nécessaires pour accélérer le développement des extensions de la plate-forme.

Étendre WASI avec WIT

Un élément clé de cette extensibilité est le modèle de composant WebAssembly. Défini par le groupe de travail WebAssembly comme l’équivalent Wasm d’un modèle de processus de système d’exploitation, c’est la base de la façon dont WASI implémente ses interfaces. Un élément clé de toute approche de bas niveau comme celle-ci est un langage de définition d’interface, qui permet de spécifier comment les interfaces interagissent avec le code. Pour Wasm, et en particulier pour le modèle de composants, l’IDL standard est wit, ce qui nous donne une manière concise et lisible par l’homme de définir des interfaces qui sont développés en code WebAssembly.

Pour utiliser WASI pour créer des applications distribuées, nous avons besoin d’un ensemble d’extensions qui nous permettent d’abstraire les services spécifiques au fournisseur en tant qu’interfaces. Au lieu d’avoir à utiliser des API distinctes pour S3 sur AWS et le stockage Blob sur Azure et le code pour les gérer, nous pourrions avoir un seul composant de stockage qui fournirait un ensemble commun d’interfaces sur toutes les plateformes, avec le service de gestion d’instance WASI sous-jacent. implémentations spécifiques.

C’est là qu’intervient SpiderLightning, avec un ensemble de interfaces qui implémentent de nombreuses fonctionnalités d’applications distribuées courantes. Vous pouvez écrire du code qui fonctionne avec ces interfaces et vous assurer qu’il est portable. Vous n’avez pas à vous soucier de l’infrastructure et vous pouvez simplement écrire le code qui implémente votre logique métier. Deis Labs décrit SpiderLightning comme « un ensemble de pièces Lego » avec des composants qui fournissent des fonctionnalités telles que des magasins clé-valeur, des API gRPC, des files d’attente de messages, etc.

Avoir un ensemble de définitions WIT n’est que le début ; Pour créer un environnement véritablement portable, nous avons besoin d’une implémentation conçue autour d’API et de services cloud communs. Deis a implémenté un framework de preuve de concept SpiderLightning appelé light< /a> qui se trouve au-dessus de l’environnement d’exécution familier wasmtime WASI.

Démarrer avec le léger

Comme de nombreuses parties de la chaîne d’outils de développement cloud native, light est un outil CLI. Vous pouvez l’installer en exécutant un script d’installation hébergé sur GitHub sur un système UNIX (les développeurs Windows peuvent utiliser le sous-système Windows pour Linux). Le script télécharge un fichier tar qui contient le binaire léger puis extrait et installe la CLI.

L’outil créera et remplira une application WASI. Il vous suffit de définir la version des interfaces SpiderLightning qu’il utilisera. Vous pouvez utiliser Rust ou C, en vous assurant que les cibles de compilateur appropriées sont installées. Une fois votre application compilée, vous pouvez exécuter le code à l’aide de la commande légère, en ciblant le fichier Wasm compilé pour votre application et en utilisant une configuration SpiderLightning pour mapper les interfaces aux implémentations.

Ce fichier de configuration est essentiel pour travailler avec light. C’est ainsi que vous détaillez les fonctionnalités que votre code doit utiliser, sous la forme d’un type de ressource et d’un nom. C’est important car cela vous aide à basculer entre les fonctionnalités d’infrastructure prises en charge sans modifier votre code. Vous pouvez changer de fournisseur de stockage pour un fournisseur plus adapté à votre environnement cible. Le code exécuté en périphérie peut utiliser des ressources locales, un code destiné à votre propre cloud privé peut cibler un élément familier de votre infrastructure, et un autre destiné à un cloud public peut utiliser l’un des services de plate-forme du fournisseur.

Le résultat fournit un code portable qui s’exécutera sur AKS consommant des ressources Azure, tout en évoluant vers le matériel de périphérie et jusqu’à votre propre centre de données. Cela vous aide également à vous assurer que les informations de compte sont conservées en dehors de votre référentiel de code, en utilisant la configuration légère pour conserver ces données et gérer les connexions.

Pour que cela fonctionne, votre application doit importer la définition WIT de SpiderLightning pour la fonctionnalité que vous utilisez. Cela décrit comment votre code doit fonctionner avec l’interface : comment il appelle le service, les commandes prises en charge, les charges utiles envoyées et les retours attendus. Le service réel utilisé est géré par le temps d’exécution léger, ce qui vous permet de vous concentrer sur les problèmes que votre code résout plutôt que sur les spécificités de l’utilisation d’Azure ou de tout autre cloud pris en charge.

Création de nouvelles capacités SpiderLightning

À l’heure actuelle, SpiderLightning est un travail en cours, avec la prise en charge d’un sous-ensemble des fonctionnalités prévues et même alors, avec seulement certains des services proposés. Le magasin clé-valeur est le plus mature à l’heure actuelle, ainsi que son support de messagerie. C’est un projet open source et conçu pour être extensible, avec un processus de création de nouvelles dépendances pour de nouveaux services. Avec la prise en charge d’AKS, Microsoft est incité à ajouter ses propres fonctionnalités à la plate-forme, et une feuille de route approximative suggère que ces services et une sélection de services AWS sont prévus.

Nous en sommes encore aux premiers jours de l’utilisation de WebAssembly pour créer des applications distribuées, mais des outils comme SpiderLightning sont très prometteurs. En fournissant un niveau d’abstraction à partir des services de plate-forme, c’est un moyen intrigant de créer des applications portables inter-cloud qui évoluent de manière ascendante et descendante. Il sera intéressant de suivre l’évolution des outils et des frameworks WASI comme SpiderLightning alors qu’ils échangent des idées et des concepts. La communauté WebAssembly vise clairement à fournir un ensemble standard d’outils pour prendre en charge le code portable qui peut interagir avec une gamme de services hôtes aussi large que possible. SpiderLightning est peut-être la première étape d’un long voyage, mais c’est clairement une étape longue et confiante.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici