Building the component model for Wasm

Hay varios nuevos esfuerzos de estandarización dentro del espacio WebAssembly (también conocido como Wasm), incluido lo que creemos que es una nueva forma de escribir aplicaciones de software. Como forma de describir este nuevo modelo e indicar hacia dónde nos dirigimos con los estándares de WebAssembly en general, me gustaría sumergirme en algo de la historia de Wasm.

El diseño de WebAssembly 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. Asm.js, un subconjunto de JavaScript altamente optimizable para navegadores, también 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, de Gary Bernhardt, cubre un futuro ficticio inspirado en asm.js. Si ve esta charla, que Gary presentó en PyCon 2014, no podrá evitar notar las similitudes entre el futuro que eventualmente pavimentamos con Wasm y las predicciones de Gary.

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. En primer lugar, 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 cuatro 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, que estuviera optimizado para el tamaño para permitir descargas rápidas y que tuviera soporte para la compilación de transmisión, lo 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 los entornos de ejecución en 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 encuentre este tipo de transferencia entre cada época de la informática en cada organización que tenga 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 tiempos de ejecución diseñados 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 de 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, pero 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 la década de 1960 (Dennis y 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. BA ahora cuenta con más de 30 miembros, ¡y está creciendo!

Durante 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, lo que nos llevó a crear un nuevo estándar que 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.

El modelo de componentes es el resultado de nuestra visión de un ecosistema de software más amplio para Wasm, no solo basado en una unidad portátil de cómputo, sino algo más grande y completamente nuevo, con módulos WebAssembly que se pueden componer, interoperar y virtualizar en plataforma. Analicemos eso.

• 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 se han perfeccionado 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.

¿Qué es el modelo de componentes WebAssembly?

En el modelo de componentes de WebAssembly, 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 de Wasm, otros desarrolladores pueden tratarlos como la caja de software “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 necesitara 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 las dependencias de tiempo de compilación de Wasm 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 futuro sistema 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 juega el BA en la creación de un marco técnico utilizable: los SDK, las herramientas y los componentes principales. Todo debe construirse 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. BA proporciona herramientas para generar enlaces de idiomas para muchos idiomas diferentes, pero lograr el nirvana de interoperabilidad de idiomas también requerirá registros y administradores de paquetes en varios ecosistemas de idiomas para interoperar con los componentes de Wasm. Por eso estamos trabajando en el diseño de un protocolo de registro, llamado warg, como parte de SIG-Registries. El objetivo es habilitar cualquier registro que implemente este protocolo para publicar, consumir, almacenar y compartir 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, escrito en Rust, suele ser el banco de pruebas para experimentar con nuevas propuestas WASI y WebAssembly. WebAssembly Micro-Runtime (Wamr), escrito en C, admite 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 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, ¡2023 promete ser un año emocionante para Wasm!

Bailey Hayes es directora de Cosmonic y directora del Comité Directivo Técnico de Bytecode Alliance.

—

New Tech Forum ofrece un lugar para explorar y discutir la tecnología empresarial emergente en una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para la publicación y se reserva el derecho de editar todo el contenido aportado. Envíe todas las consultas a newtechforum@infoworld.com.