WASM remplacera les conteneurs
(creston.blog)« WebAssembly est le vrai Write-Once-Run-Anywhere »
« En 2030, plus personne ne se souviendra de Kubernetes »
Portabilité
- Les conteneurs ont résolu de nombreux problèmes du développement logiciel et étaient plus pratiques à utiliser que les VM
- Mais aujourd’hui, les conteneurs sont devenus pénibles à manipuler à cause d’outils complexes et d’un couplage fort entre le programme, le conteneur et Linux
- Les développeurs veulent se concentrer sur l’écriture du code et le déploiement des fonctionnalités, et l’apprentissage de Docker devient une distraction
- WebAssembly (WASM) remplace déjà les conteneurs dans certains domaines et offre une expérience de type « écrire une fois, exécuter partout »
- Plusieurs langages peuvent être compilés en WASM, et le manque d’interfaces système empêche encore son adoption à grande échelle, mais cela devrait bientôt être résolu
- La principale limite actuelle de WASM est l’absence d’interfaces système comme l’accès aux fichiers ou le réseau, mais c’est un problème qui se résoudra avec le temps
Comparaison avec la JVM
- WASM propose un concept similaire au « écrire une fois, exécuter partout » de la JVM, mais la JVM ne s’exécute pas dans les navigateurs web
- Le navigateur web est une cible de déploiement importante pour les applications, ce qui pousse de nombreux développeurs à éviter la JVM
- Récemment, des compilateurs de binaires statiques comme GraalVM, Kotlin Native et Scala Native émergent comme alternatives à la JVM
Microservices
- Dans une architecture microservices, les services sont reliés via HTTP, RPC ou un message broker
- Le coût et les problèmes de fiabilité des communications réseau sont les principaux inconvénients, mais la plupart des entreprises jugent que les avantages l’emportent
- Avec l’arrivée de plateformes serverless comme AWS Lambda, les microservices peuvent être déployés à l’unité, sous forme de fonctions individuelles
- Cloudflare Workers s’exécute dans un sandbox V8, ce qui permet d’appeler des fonctions dans le même runtime sans requête réseau
- Cela offre à la fois les avantages de développement des microservices et les performances d’exécution d’une architecture monolithique
- D’autres acteurs, comme Wasmer, développent également des solutions basées sur WASM
Adoption de WASM
- WASM est encore une technologie naissante, mais elle évolue rapidement et son support continue de progresser
- Aujourd’hui, il ne fonctionne pas encore parfaitement dans tous les environnements, mais des plateformes comme Cloudflare permettent déjà d’entrevoir cet avenir
- Si vous utilisez des langages dynamiques comme Python, Ruby ou PHP, il peut être avantageux d’apprendre en parallèle un langage compilé comme Go ou Rust, tout en attendant la maturation de WASM
8 commentaires
K8s est un outil d’orchestration de conteneurs ; avec wasm, est-ce que son utilité risque de diminuer ? Pour Docker, il y aura sans doute un certain impact, mais…
Le WASM, ça ressemble à une nouvelle imprimante 3D. On nous dit que « le nouveau monde arrive », mais au final, il n’y a pas grand monde qui l’utilise...
Il y a ici une collection de cas d’usage.
(À mon avis) ce qui paraît le plus crédible, ce sont surtout des domaines comme la CAO ou le traitement d’image.
Ça me rappelle soudain l’équipe de développement d’une solution qui se demandait autrefois comment implémenter des images médicales haute résolution sur le web.
Je regarde et je reproduis.
Même en 2030, il semble que k8s sera toujours bien présent.
Au final, il va donc falloir connaître à la fois Docker et WASM ? haha Cela dit, Docker est aussi devenu plus accessible à mesure que la technologie a mûri, donc j’imagine que WASM ira dans une direction similaire, vers une approche plus simple d’accès.
Au final, on a l’impression que tout va reposer sur les performances du runtime wasm ; est-ce que V8 ne va pas finir par occuper la même couche que la JVM ?
Je crains qu’un avenir nous attende où le comportement de WASM variera selon la version de V8, et où il faudra déboguer tout ça.
Avis Hacker News