Evolución de los estándares Wasm: construcción del modelo de componentes

Hay varios nuevos esfuerzos de estandarización en el espacio WebAssembly (Wasm), incluido lo que creemos que es una nueva forma de escribir aplicaciones de software. A modo de describir este nuevo modelo, me gustaría sumergirme en algo de la historia de Wasm como una forma de describir hacia dónde nos dirigimos.

El diseño de WebAssembly (Wasm) comenzó en 2015, años antes de convertirse oficialmente en el cuarto idioma de la web en 2019. Si bien muchos tecnólogos están familiarizados con Wasm como tecnología de navegador, Wasm en sí no depende de JavaScript ni de las API web.

El precursor de Wasm, asm.js , saltó a la fama en 2013. Un subconjunto de JavaScript que es altamente optimizable para navegadores y que puede actuar como un objetivo de compilación para lenguajes como C y C++. Una de mis charlas favoritas de todos los tiempos, "El nacimiento y la muerte de JavaScript", cubre un futuro ficticio inspirado en asm.js Tenga en cuenta las similitudes entre el futuro que finalmente pavimentamos con las predicciones de Wasm y Gary al ver su charla de PyCon 2014.

A menudo llamo a asm.js el mejor truco de todos los tiempos (de la manera más amorosa). ¿Quién hubiera pensado que un lenguaje de secuencias de comandos de alto nivel podría ser A")" un objetivo de compilación y B")" tan increíblemente rápido? En 2012, transfirí varias bibliotecas de C++ a asm.js y sentí que había desbloqueado el código secreto de un universo portátil.

La tecnología demostró varias cosas. Primero, existe la necesidad y el deseo de traer otros idiomas a la web, pero los desarrolladores no querían quedarse ahí. Los tipos de aplicaciones que se transfirieron eran computacional y gráficamente exigentes, desde herramientas de visualización de datos (como los componentes en los que trabajé en SAS) hasta juegos creados con Unity y Unreal Engine (UE3 se transfirió en 4 días ).

Es por eso que cuando se crearon el grupo comunitario W3C WebAssembly y el repositorio de diseño WebAssembly correspondiente en 2015, los proveedores de navegadores como Mozilla, Google , Microsoft y Apple estuvieron entre los primeros contribuyentes al esfuerzo y los primeros en ver una oportunidad tangible. El diseño requería un lenguaje con un formato binario que pudiera usarse como un objetivo de compilación portátil, optimizado para tamaño para permitir descargas rápidas y soporte para compilación de transmisión que permite que el módulo descargado tenga una instanciación casi instantánea. Lo que es más importante, estos módulos deben facilitar [entornos de ejecución] de espacio aislado como lo debe hacer cualquier código arbitrario que se ejecute en los navegadores.

¿Por qué Wasm más allá del navegador ?

Mucho de lo que se aprendió en las implementaciones del lado del navegador dio pistas sobre las muchas formas en que Wasm podría desarrollar su potencial más allá del navegador. La “nube” constituye un conjunto heterogéneo de arquitecturas informáticas, sistemas operativos y restricciones del sistema en una red mundial de maquinaria.

Considere algunas de las propiedades clave de Wasm como un objetivo de compilación portátil que es rápido, está aislado y se distribuye fácilmente gracias al formato binario compacto. Estas propiedades de Wasm lo convierten en la unidad de cómputo distribuible perfecta para la nube. Además, las empresas quieren crear aplicaciones para diferentes entornos, pero no quieren tener que refactorizar cada vez. Wasm elimina estas barreras.

Cuando me enteré por primera vez de asm.js , estaba buscando una solución para llevar nuestra aplicación Flash existente a HTML5. Esta aplicación ActionScript/Flex era una versión reescrita de su contraparte de Java, que era un puerto de versiones anteriores de la misma lógica comercial escrita en C. Esta historia puede parecerle descabellada si no ha trabajado en grandes empresas, pero puede encontrar este tipo de portabilidad entre cada época de la computación en cada organización que tiene la suerte de sobrevivir la prueba del tiempo.

Wasm permite la portabilidad total a cualquier tiempo de ejecución compatible con Wasm, incluidos navegadores, tiempos de ejecución creados específicamente para FaaS o algo diseñado para ejecutarse en arquitecturas diminutas para IoT. En la web, los módulos de Wasm pueden usar el código de "pegamento" de JavaScript para acceder a API web como WebGL, redes y dispositivos para hacer cosas más allá de la computación pura. Al final del día, un programa Wasm realmente solo opera con valores numéricos, o dicho de otra manera, un módulo Wasm es un montón de i32 en una gabardina. Para hacer cosas interesantes, un módulo Wasm debe poder llamar a funciones desde el tiempo de ejecución del host.

WASI: la frontera de Wasm del lado del servidor

Casi al mismo tiempo que WebAssembly 1.0 se convirtió en un estándar web recomendado, se creó un nuevo subgrupo dentro del grupo de trabajo W3C WebAssembly para explorar una interfaz a nivel de sistemas para WebAssembly conocida como WASI (WebAssembly Systems Interface). El grupo ha estado trabajando en la creación de un conjunto de interfaces estandarizadas desde entonces.

WASI existe para hacer que WebAssembly funcione bien en cualquier lugar, no solo dentro del navegador, sino que la característica clave que define a WASI es su modelo de seguridad basado en capacidades. La seguridad basada en la capacidad ha existido desde los años 60 ( Dennis & Van Horn, 1966 ), pero Dan Gohman diseñó una nueva versión al desarrollar ideas de Cloud ABI .

Comprensiblemente, esta tecnología pronto atrajo la atención de las empresas interesadas en ejecutar Wasm fuera de la web. Empresas como Fastly, Intel, Red Hat y Mozilla vieron la oportunidad de poner a Wasm a trabajar en la nube, en dispositivos y en el perímetro. Esas empresas fueron los miembros fundadores de Bytecode Alliance (BA), una organización sin fines de lucro para construir bases de software seguras para Wasm utilizando estándares como WASI. Muchas otras organizaciones pronto se unieron a BA, incluidos los principales actores de la industria del software, ¡y ahora cuenta con más de 30 miembros y sigue creciendo!

En los últimos dos años, hemos logrado un gran progreso en la creación de las herramientas necesarias para ejecutar Wasm en aplicaciones nativas de la nube . La comunidad aprendió mucho de estas primeras experiencias, y esto nos influyó para crear un nuevo estándar que ahora llamamos Modelo de componentes. El modelo de componentes está en un nivel más bajo que WASI, funciona bien con WASI pero no depende de WASI. Este es el resultado de nuestra visión de un ecosistema de software que no se basa solo en una unidad portátil de cómputo, sino algo completamente nuevo con módulos WebAssembly componibles, interoperables y de plataforma virtualizable.

Vamos a desglosarlo:

• Componibilidad: permite la reutilización de código modular de forma independiente del idioma.

• Virtualización de plataforma: la capacidad de colocar en capas las piezas específicas de la plataforma que un componente necesita para ejecutarse en un entorno determinado. Una propuesta anterior para la función de virtualización y composición de plataformas se denominó enlace de módulos.

• Interoperabilidad: con componentes componibles y virtualizables, necesitamos una forma de intercambiar información entre componentes. Comenzamos con una propuesta llamada tipos de interfaz, pero ahora también es una característica clave de la propuesta del modelo de componentes.

  
  

Esta es la historia de cómo el Modelo de Componentes comenzó a tomar forma. Cada una de las propuestas anteriores ahora ha sido refinada en este estándar general. Esperamos ver la próxima gran iteración estable de los estándares WASI y el modelo de componentes a finales de este año.

Estándares WASI: ¿dónde estamos ahora ?

A continuación, lo llevamos a través de una historia trazada de Wasm, WASI y el desarrollo del modelo de componentes.

2019 : objetivo de compilación pura, agregando interfaces tempranas que conectan llamadas del sistema al host. En muchos aspectos, parecía que nos dirigíamos hacia una versión WebAssembly de POSIX. Pudimos escribir una CLI realmente simple y ejecutarla con Wasmtime en un escritorio o en una función sin servidor.

2020 : las API de WASI se centran en el tipo de cosas que cualquier programa CLI podría necesitar, por ejemplo, el reloj del sistema o un sistema de archivos. El tiempo de ejecución Lucet Wasm de Fastly se fusionó con Wasmtime (un proyecto de BA).

2021 : Por supuesto, todos estos elementos continúan evolucionando y mejorando. En 2021, comenzamos a ver el desarrollo de nuevas interfaces WASI específicas para casos de uso, por ejemplo wasi-nn para cuando se necesita aceleración de hardware para la inferencia. Este es también el año en que Luke Wagner comenzó a definir el modelo de componentes.

2022 : comenzamos a ver nuevas API de nivel superior para hacer que los módulos Wasm funcionen bien en entornos de nube donde se necesitan capacidades como trabajar con un almacén de clave-valor o servicios de mensajería pub/sub. Finalmente, después de mucho trabajo, se introdujeron los enchufes WASI. 2023 : Estamos trabajando para lograr hitos de estabilidad para el modelo de componentes y los estándares WASI.

Mirando el viaje desde 2019, puede comenzar a ver cómo los estándares se han diversificado a medida que proliferan los casos de uso y los usuarios comienzan a elegir lo que hacen y lo que no necesitan. De un bloque ubicuo a un conjunto creciente de bloques de construcción más pequeños diseñados para operar entre sí dentro de un marco flexible: el modelo de componentes.

¿Qué es el modelo de componentes ?

En este modelo, los desarrolladores pueden elegir partes de su aplicación, implementadas en diferentes idiomas, como diferentes propuestas de valor. A medida que los desarrolladores comienzan a crear bibliotecas de componentes Wasm, otros desarrolladores pueden tratarlas como la caja de 'LEGO' más grande del mundo.

En un momento de círculo completo, creemos que vendrá una nueva innovación cuando el modelo de componentes comience a influir en la forma en que escribimos aplicaciones web. Esto tiene sentido cuando se considera que la web es uno de esos entornos geniales pero limitados, con usuarios muy impacientes, un caldo de cultivo para la experimentación fresca.

Por ejemplo, espero que los componentes faciliten aún más el diseño de un sistema de complementos independiente del idioma para una aplicación web. Si se necesita una pieza para un tiempo de ejecución de lenguaje como Python, varios componentes que aprovechan ese tiempo de ejecución de lenguaje podrían usarla. Compare esto con el mundo actual, donde solo tenemos módulos Wasm (no componentes) y estos generalmente se crean con todas sus dependencias de tiempo de compilación integradas en un solo binario. Si una aplicación grande admitiera complementos de terceros, es probable que cada complemento de Wasm tenga dependencias duplicadas que provoquen un aumento del tamaño y la memoria y descargas más lentas.

Con un sistema futuro de componentes de Wasm para la web, donde una sola aplicación puede elegir los componentes escritos en cualquier idioma, una aplicación solo necesitará descargar exactamente lo que necesita e interactuar con los componentes como cualquier otro módulo ES con una importación. En este mundo, el mejor componente subirá a la cima. Lo mejor podría significar la API más rápida o más limpia, pero lo más importante es que su característica definitoria no será el idioma de origen. ¡Que gane el mejor componente!

Construyendo una base técnica estable para WASI y Componentes

Una gran parte de hacer que los estándares WASI y el Modelo de componentes sean reales es el papel que desempeña el BA en la creación de un marco técnico utilizable: los SDK, las herramientas y los componentes principales; todo construido de manera consistente y segura, y accesible para todos como ejemplos de mejores prácticas.

Del mismo modo, el papel del Comité Directivo Técnico (TSC) de la BA será fundamental para proporcionar apoyo y gobernanza técnica para cada proyecto de la BA. Trabajamos junto con la gente diseñando el mejor conjunto posible de estándares en los grupos de trabajo W3C WebAssembly y WASI, lo que significa que colaboramos con ellos para asegurarnos de que todo funcione en la práctica. Los grupos W3C WebAssembly y WASI se centran en la finalización de estos estándares, y el BA se centra en hacerlos consumibles dentro de la comunidad lo más rápido posible para establecer un circuito de retroalimentación activo.

Otra parte importante de los estatutos de BA es permitir la interoperabilidad de lenguajes y entornos. El BA proporciona herramientas para generar enlaces de idiomas para muchos idiomas diferentes, pero un aspecto de cómo alcanzar el nirvana de interoperabilidad de idiomas es que necesitamos registros y administradores de paquetes en varios ecosistemas de idiomas para interoperar con los componentes de Wasm. Es por eso que estamos trabajando en el diseño de un protocolo de registro (llamado warg) como parte de SIG-Registries que permite que cualquier registro que implemente el protocolo publique, consuma, almacene y comparta componentes de Wasm.

Quizás la pieza más crítica de cualquier pila de software de Wasm es el tiempo de ejecución de Wasm, ¡y el BA alberga dos! Wasmtime está escrito en Rust y suele ser el banco de pruebas para experimentar con nuevas propuestas WASI y WebAssembly. WebAssembly Micro-Runtime ( WAMR ) está escrito en C y es compatible con muchas arquitecturas, incluidas las pequeñas como ESP32. Ambos tiempos de ejecución actúan como excelentes implementaciones de referencia de un tiempo de ejecución de Wasm. Los SDK y las herramientas para crear un módulo de Wasm están en línea con los estándares de Wasm, por lo que cualquier tiempo de ejecución de Wasm que cumpla con los estándares (incluidos los que no están alojados en el BA) puede construir sobre estas bases de software.

Dados todos los estándares nuevos y emocionantes que evolucionan a través de WASI y el Modelo de componentes y las implementaciones de Bytecode Alliance, ¡espero que 2023 sea un año emocionante!

Comience con Cosmonic gratis hoy: ¡Lanzamiento ahora!

Por Bailey Hayes | Director de Bytecode Alliance TSC y Cosmonic