Resumen
La necesidad de incrementar la velocidad de entrega de los productos de software nos ha llevado a crear y adoptar estrategias, procesos y metodologías, tales como Ágiles, DevOps, DevSecOps, GitOps y MLOps.
Por lo cual es necesario tener capacitación para implementar una serie de herramientas para alcanzar la entrega continua de los productos. Sin embargo, de nada sirve entregar rápido si el producto o servicio no tiene la velocidad para adaptarse al incremento de la demanda y de recuperarse rápido en caso de caídas inesperadas.
El último eslabón de la cadena de entrega continua es donde vive y se ejecuta una aplicación. Y la herramienta más usada hasta el momento es Docker (tecnología en contenedores).
Los contenedores prometieron portabilidad, al igual que Java en su momento y por último las arquitecturas Serverless pero lamentablemente no han cumplido al 100%.
Tenemos otra oportunidad para alcanzar la verdadera portabilidad con WebAssembly, ya que se ejecuta a muy bajo nivel y en cualquier lado, incluso en navegadores, aumentando también la velocidad de ejecución.
Dando paso a otro factor que pudiera ser beneficiado: Escalabilidad, ya que un proceso WebAssembly arranca más rápido que un contenedor.
Introducción
WebAssembly (WASM) fue creado exclusivamente para ejecutarse en navegadores. Incluso fue declarado como un estándar el 5 de diciembre de 2019 por el World Wide Web Consortium (W3C), y se convierte en el cuarto elemento del stack web: HTML, CSS, JavaScript y WASM.
El hecho de que WASM permite ejecutar cualquier lenguaje dentro de un navegador, programas nativos de escritorio famosos se hicieron disponibles en versión web, como es el caso de Photoshop, Figma, Lucidchart, Canva, entre otros.
Una vez que WASM demostró su portabilidad y eficacia en los navegadores, la comunidad empezó a preguntarse si era factible llevarlo al lado del servidor, ejecutarlo en la nube e incluso pensar en un reemplazo de Docker.
Desarrollo
WASM puede llegar a garantizar una portabilidad real, sin depender totalmente de la arquitectura de los procesadores, ya que abstrae la capa del hardware.
¿Qué es WebAssembly?
Una definición del sitio oficial es:
WebAssembly (WASM abreviado) es un formato de instrucción binario para computadoras o máquinas virtuales basadas en stack. WASM está diseñado como destino de compilación portable para lenguajes de programación, permitiendo un despliegue en aplicaciones web tanto del lado del cliente como del servidor.
¿Por qué WebAssemby es disruptivo?
WASM como tecnología web, fue atractiva desde el principio porque era eficiente, rápida y segura. Uno de los objetivos principales de WASM fue ayudar a JavaScript a mejorar su velocidad, sin embargo, la comunidad empezó a explorar nuevos casos de uso, como compilar lenguajes de programación distintos a JavaScript, como C, C++, Rust, C#, etc. Y desplegarlos bajo WASM. Otros empezaron a desplegar programas completos en WASM y ejecutarlos en un navegador web.
Ahora se ha ido expandiendo a nuevos contextos como en las arquitecturas serverless, cuyo principio ha sido que los desarrolladores se enfoquen únicamente en construir soluciones sin preocuparse en la infraestructura, sin embargo, quien ofrece estos servicios son proveedores privados, entonces los desarrolladores se preocupan en dónde desplegar las soluciones serverless, porque no se pueden migrar o portar a un proveedor distinto de manera transparente.
WASM al ser un componente independiente de cualquier lenguaje, stack tecnológico y sistema operativo, ya está siendo adoptado por empresas para ofrecer servicios de arquitecturas serverless, como Cloudflare con sus workers, o para monitorear microservicios como Envoy con sus extentions, o para ejecutar aplicaciones web como NGNIX con sus units.
Un nuevo caso de uso se ha presentado por el éxito de WASM: ser un nuevo sistema operativo.
WASM ha ayudado a replantearse la forma de cómo trabajan los sistemas operativos, dando la oportunidad de empezar de nuevo. Sabemos que los paradigmas principales de los sistemas operativos no han cambiado desde 1970.
WASM se puede convertir en la nueva unidad de cómputo, ya que logra ejecutar cualquier lenguaje de programación, no tiene un estado, la información que entra y sale no tiene un formato específico, sino que se recibe y expone en crudo, es decir, puede llegar un string de Pyhton o de Rust y no debería haber problema.
Por lo tanto, esa unidad mínima se puede extender a través de un modelo de plugins, incrementando la funcionalidad con cualquier lenguaje de programación.
Ya no habría puentes o adaptadores para unir diferentes lenguajes de programación. No se perdería tiempo en tratar de acoplar todo en un ambiente o plataforma en específico.
Sin embargo, para alcanzar este entorno ideal se necesitan 4 factores que debemos mantener como comunidad:
- Ambiente agnóstico.
WASM está diseñado para ser un ambiente en sí, porque no se debe perder su esencia en el camino, agregando dependencias de terceros y privadas que limiten una verdadera portabilidad.
- Abstracción.
WASM no tiene una definición de redes, almacenamiento, datos y un sistema de archivos, haciéndolo más interoperable, ya que en cierto momento podemos hablar de almacenamiento key-value, en otros escenarios objetos simples o archivos como tal, todo de manera dinámica sin depender de una definición que limite la abstracción.
- Plugins como modelo.
WASM al ser la unidad mínima de cómputo, automáticamente nace con un alto nivel de seguridad, ya que no contempla un sistema de red por defecto, este se podría integrar como plugin y así muchos otros componentes, pero cuando la necesidad lo demande.
- Mantener los datos en crudo.
La ventaja que tiene WASM ante los modelos tradicionales que se basan en el sistema de archivos, es que WASM trabaja con datos como objetos en crudo, controlados dentro de su ambiente, pero con las reglas definidas de un lenguaje de alto nivel, pero traducidas a un lenguaje de bajo nivel gracias a su compilador, permitiendo la interacción con otros componentes de manera nativa.
Como se ha visto, WASM funciona como un sistema LEGO con una interface bien definida y estandarizada que podría unir funcionalidades legadas y nuevas, teniendo en cuenta, por supuesto, que el lenguaje más usado en WebAssembly es Rust, ya que genera los binarios más ligeros comparado con JavaScript, C++, Python, Go, entre otros. (Scottlogic 2023)
Conclusión
El ecosistema de WASM todavía sigue siendo pequeño comparado con todo un sistema operativo, sin embargo, ya vimos que hoy nos puede ayudar a crear mejores sistemas distribuidos modernos, mejorando notablemente lo que nos ofrecen los contenedores, microservicios y serverless.
Partiendo de lo mínimo, WASM ejecuta su tarea básica como Sandbox excepcionalmente. Todavía no podemos saber hasta dónde llegará al conectarle más componentes o si reemplazará o convivirá con lo que tenemos hoy en día, pero es un hecho que nos está ofreciendo nuevos enfoques para construir sistemas.
Referencias
W3C. (2019). World Wide Web Consortium (W3C) brings a new language to the Web as WebAssembly becomes a W3C Recommendation https://www.w3.org/press-releases/2019/wasm
WebAssembly. Página oficial: https://webassembly.org
Cloudflare. (2024): Cloudflare workers https://developers.cloudflare.com/workers
Envoy. (2024): Envoy extensions https://gateway.envoyproxy.io/latest/tasks/extensibility/wasm
Nginx. (2024): Nginx Units https://unit.nginx.org
The new stack (2023): Why WebAssembly Will disrupt the OS https://thenewstack.io/why-webassembly-will-disrupt-the-operating-system/?utm_referrer=android-app%3A%2F%2Ffm.player%2F
The new stack (2023): 4 factors of a WebAssembly Native World https://thenewstack.io/four-factors-of-a-webassembly-native-world/?utm_referrer=android-app%3A%2F%2Ffm.player%2F
Scottlogic. (2023): The state of WebAssembly https://blog.scottlogic.com/2023/10/18/the-state-of-webassembly-2023.html
