L'avenir de WebAssembly à travers les yeux d'un ingénieur vétéran de Kubernetes

Lors de l'étape de Pasadena des Kubernetes Community Days (co-localisée avec SCaLE 20x), j'ai eu la chance de parler à une centaine de passionnés de Kubernetes , pour donner mon point de vue sur WebAssembly, à travers l'objectif d'un vétéran de Kubernetes.

Je devrais nuancer cela en disant que j'ai de la peau dans ce jeu particulier. Je suis dans Kubernetes depuis le début - en commençant tôt avec Docker (0.6-ish) et en travaillant avec Kubernetes depuis la 1.2 - en construisant des plates-formes Kubernetes avant qu'elles ne soient une chose. J'ai été l'un des principaux mainteneurs de Helm pendant 4 ans et co-créateur de Bindle et Krustlet - un premier effort pour que WebAssembly fonctionne bien avec Kubernetes. Une longue façon de dire que je comprends tout à fait, je comprends les forces et les points faibles des conteneurs et de Kubernetes.

Je viens également de l'espace WebAssembly, fortement impliqué depuis 3 ans environ. Avec des pieds dans les deux camps, voici mon point de vue sur ce à quoi ces deux initiatives ouvertes sont bonnes et à quoi l'intersection pourrait - et devrait - ressembler.

Kubernetes et Docker ont changé la donne car ils ont permis aux ingénieurs et développeurs de plateformes de décomposer le monolithe en microservices et applications, gérables indépendamment du reste de l'infrastructure. WebAssembly va encore plus loin, nous permettant de diviser des applications individuelles en composants composables qui peuvent être échangés à chaud, gérés et configurés séparément de leur environnement. Wasm est, essentiellement, tout ce que nous voulons dans le code côté serveur : sécurisé par défaut, portable, polyglotte (en particulier dans le navigateur), rapide, efficace et hautement évolutif.

Alors, comment Kubernetes et Wasm se croisent-ils ? Tout d'abord, abordons le moulin à rumeurs des médias sociaux et brisons certains mythes.

Mythe #1 : Wasm tuera les conteneurs.

Non. Définitivement pas. Personne ne va réécrire Redis pour qu'il fonctionne dans le navigateur alors qu'il fonctionne parfaitement dans les conteneurs. Il y a tellement de cas où Kubernetes est la bonne solution. Il existe un certain nombre de grandes applications d'entreprise (Drupal, Redis, nginx) qui existent depuis longtemps et qui ne passeront pas bientôt à Wasm.

Mythe n°2 : Je devrais continuer et exécuter Wasm dans mes conteneurs, n'est-ce pas ?

Nous ne disons pas que vous ne devriez pas, mais ce n'est peut-être pas le bon point de départ et vous pouvez simplement ajouter des couches supplémentaires de complexité. Vous avez la surcharge de démarrage du conteneur Docker (qui n'est pas multiplateforme), ajoutée à la surcharge de démarrage de WebAssembly. Cela ne vaut probablement pas la surcharge de performances, en particulier avec tous les outils disponibles que je mentionnerai plus tard]

Mythe #3 : Wasm n'est pas compatible avec Kubernetes.

Oui c'est le cas! C'est une histoire "Mieux ensemble". Tout est évolutif avec les ordinateurs. Ce n'est pas parce que nous avons créé des machines virtuelles que nous n'avons pas besoin de matériel physique. Et ce n'est pas parce que Wasm est arrivé que nous n'avons pas besoin de conteneurs. Pour voir cela en action, lisez comment nos amis d'Adobe transforment leur architecture Kubernetes avec Wasm .

Comme aux débuts de Kubernetes, nous sommes dans cette phase où les choses se cassent et évoluent très rapidement. La mise en réseau est toujours difficile côté serveur au niveau brut de Wasm. Nous aurons bientôt le support des sockets et les choses évoluent rapidement. Les chaînes d'outils de langage et le code performant de bas niveau sont également cruciaux, mais pas encore là. C'est quand même un moment excitant. Les normes WASI (non-browser Wasm) ont parcouru un long chemin, même au cours des deux dernières semaines - nous en reparlerons plus tard.

Pourquoi Wasm ?

La vérité est que Kubernetes a ses limites, en particulier à la périphérie . Bien que de nombreux progrès aient été réalisés (un énorme bravo à des projets comme K3), les choses ne peuvent aller que jusqu'à présent. Kubernetes est censé être exécuté dans des clusters qui font le plus souvent partie de la même région géographique. Lorsque quelque chose fonctionne dans une tour cellulaire, une centrale électrique ou un magasin physique, Kubernetes n'évolue pas très bien. Nous avons vu cela lorsque nous avons parlé aux membres de notre communauté. Wasm est véritablement une architecture multiplateforme et fonctionne très petit, ce qui en fait un meilleur candidat pour la périphérie.

Le coût et l'utilisation sont également des facteurs importants . Nous avons parlé à plusieurs entreprises du Fortune 100 et leur utilisation du serveur Kubernetes se situe autour de 25 à 35 % de la capacité totale, avec quelques-unes jusqu'à 50 à 60 %. Beaucoup ont réduit leurs équipes Kubernetes internes parce que c'est trop cher. Wasm nous permet d'emballer beaucoup plus dans un espace plus petit et d'en tirer une meilleure utilisation.

La sécurité est également un avantage majeur de Wasm. Les conteneurs sont assez sécurisés, mais il existe de nombreuses nuances qui créent de la complexité, en particulier pour les développeurs. Par défaut, un module WebAssembly ne peut rien faire à moins que vous ne lui accordiez le privilège de le faire.

Que pouvons-nous faire avec Kubernetes et Wasm en ce moment ?

Cela dit, qu'est-il réellement possible de faire avec Wasm et Kubernetes en ce moment ? Passons en revue trois des plus grands scénarios dans lesquels vous pouvez tirer parti de Wasm immédiatement.

runwasi en conteneur CNCF

Une façon vraiment cool d'utiliser Wasm est de découvrir le merveilleux projet runwasi qui fait partie de l'écosystème containerd de la CNCF. Essentiellement, runwasi vous permet d'exécuter un environnement d'exécution WebAssembly via un shim conteneur à l'intérieur de Kubernetes. C'est une bien meilleure option que d'essayer d'exécuter Wasm dans un conteneur car il exécute WebAssembly directement, comme ce serait le cas si vous deviez faire tourner un conteneur dans un pod.

Maillages de service, quelqu'un ?

Envoy et d'autres maillages ont déjà la possibilité d'écrire des plugins à l'aide de WebAssembly. Avec ceux-ci, vous pouvez écrire un filtrage personnalisé et d'autres modèles de plug-in en utilisant n'importe quel langage qui se compile en WebAssembly.

wasmCloud

Nous savons que les entreprises voient déjà un intérêt à associer Kubernetes à Wasm dans une multitude de cas d'utilisation différents. Mais wasmCloud le fait passer au niveau supérieur en raison de sa capacité à connecter des ordinateurs disparates dans une topologie de réseau plat. Ma deuxième démo a montré à quel point il est facile de déplacer le même code sur trois nœuds différents, chacun à un emplacement différent. Dans ce cas, mon Mac à Pasadena, un cluster Digital Ocean K8s à New York et wasmCloud. Pas de refactoring, même code, n'importe où. Ensuite, la plate-forme Cosmonic (construite sur wasmCloud) apportera à Wasm le type d'approche complète dont les entreprises auront besoin lorsqu'elles passeront à la production.

Vous voulez essayer wasmCloud sur une plateforme gérée ?

Commencez gratuitement avec Cosmonic dès aujourd'hui. Lancez maintenant !

Modèle de composant

Enfin, et le plus excitant, les choses évoluent rapidement dans cet espace. Découvrez la conférence WASM I/O de Bailey Hayes et Dan Chiarlone qui a montré à quel point nous avons progressé dans la définition des normes WASI et du modèle de composants - c'était la première vue de ce à quoi nous voulons vraiment que l'avenir ressemble. Vous pouvez suivre les progrès ici et rejoindre la Bytecode Alliance pour entendre les dernières nouvelles au fur et à mesure.

- Par Taylor Thomas , responsable de l'ingénierie chez Cosmonic

Si vous souhaitez en savoir plus, avez des questions ou souhaitez discuter, connectez-vous avec nous sur Discord ou Slack .