WebAssembly: ¿el próximo paso en la evolución de la conteinarización?

WebAssembly (Wasm) ha evolucionado significativamente desde su creación. Originalmente concebido para ser ejecutado en un entorno aislado en el navegador, Wasm soporta ahora un grupo notable de funcionalidades fuera de éste, como el acceso a sistemas de ficheros, ejecución multihilo o un mecanismo de composición. Uno de los casos de uso que se investigan en la actualidad es la del remplazo de los contenedores por Wasm.

¿Es esto factible? ¿Lo será en el futuro próximo?

La evolución de WebAssembly y WASI

Wasm fue originalmente creado como una alternativa a JavaScript en los navegadores que fuera capaz de ejecutar código con un rendimiento cercano al de una aplicación nativa, es decir, una aplicación fuera del navegador compilada para una plataforma específica. Con la introducción de WASI las aplicaciones de Wasm pueden ejecutarse fuera del navegador e interactuar con el sistema anfitrión. WASI ha pasado por varias versiones, introduciendo nuevas características:

• Preview 1. Introdujo sistemas de ficheros básicos, variables de entorno, relojes y generación de números aleatorios.
• Preview 2. Introdujo los componentes de Wasm para mejorar la interoperabilidad entre módulos.

Al margen de las versiones de WASI, también existen implementaciones de hilos en Wasm actualmente incompatibles con la Preview 2 y el modelo de componentes. A la vista de las funcionalidades implementadas actualmente, queda patente que todavía queda un largo camino por recorrer, puesto que faltan elementos clave por implementar, como sockets, memoria compartida, funcionalidades avanzadas del sistema de ficheros, etc.

WebAssembly como alternativa a los contenedores tradicionales

Wasm presenta una serie de características que han centrado el foco de la investigación en remplazar los contenedores por entornos de ejecución de Wasm para desplegar aplicaciones en la nube. En primer lugar, Wasm es varios órdenes de magnitud más rápido en iniciar la ejecución de una aplicación que los contenedores clásicos (unas milésimas de segundo en el caso de Wasm y hasta varios segundos en las aplicaciones containerizadas). En segundo lugar, Wasm es más portable, ya que las aplicaciones no son compiladas para una plataforma (arquitectura y sistema operativo) específica, mientras que los contenedores sí. Finalmente el entorno de ejecución de Wasm es considerablemente más ligero que uno basado en contenedores y, de la misma forma, las aplicaciones de Wasm también son más ligeras que las imágenes de contenedores.

A pesar de estas propiedades, Wasm aún enfrenta una serie de desafíos. Por un lado, la falta de madurez de WASI aún impide implementar algunas funcionalidades en Wasm, lo que hace que no todas las aplicaciones existentes que se puedan ejecutar en contenedores puedan ser portadas a Wasm. Por el otro, las dependencias deben ser compiladas y añadidas al binario resultante, lo cual dificulta la gestión de dependencias. Adicionalmente, las dependencias incompatibles con algunas funcionalidades de Wasm y WASI no pueden ser compiladas directamente a Wasm. Finalmente, Wasm no implementa ningún mecanismo que permita asignar recursos a los módulos en función de la demanda.

Lo mejor de ambos mundos: Spin y wasmCloud

En la actualidad ya existen varios sistemas comerciales que utilizan una mezcla de Wasm con sistemas basados en contenedores como Kubernetes. Esta unión de ambas tecnologías trata de superar las limitaciones de ambas explotando sus puntos fuertes. Dos de estos ejemplos son Spin y wasmCloud, dos sistemas que utilizan Kubernetes para lanzar máquinas virtuales de WebAssembly.

• Spin. Actualmente Microsoft Azure y Fermyon ofrecen la ejecución de aplicaciones Wasm en Kubernetes utilizando Spin. Spin utiliza Kubernetes para gestionar y orquestar las aplicaciones de Wasm, pero remplaza los contenedores dentro de los pods por máquinas virtuales de Wasm.
• wasmCloud. A diferencia de Spin, wasmCloud no elimina totalmente los contenedores: en lugar de desplegar máquinas de Wasm directamente dentro de los pods, lanza contenedores que pueden contener múltiples instancias de la máquina virtual de Wasm.

Este tipo de sistemas se benefician de las ventajas de los contenedores (la gestión de dependencias y la gestión de recursos) y de las de Wasm (una mayor portabilidad, un entorno de ejecución más ligero y tiempos de inicio inferiores).

Conclusión

Aunque WebAssembly fuera del navegador ha avanzado considerablemente con la introducción de WASI, todavía existen limitaciones que impiden la adopción generalizada de Wasm como remplazo de los contenedores en entornos como el de la nube. La falta de madurez de WASI junto a la dificultad para gestionar las dependencias que no pueden ser compiladas dificulta la adopción de Wasm. Aún así, podemos ver ejemplos en la industria que demuestran el creciente interés por esta nueva tecnología. Podemos concluir que Wasm no está listo todavía para remplazar los contenedores, pero el entorno de ejecución del futuro será probablemente una mezcla de ambos.