Wasm es el nuevo CGI
(roborooter.com)- Wasm no es un protocolo CGI, sino que puede verse como el siguiente modelo de aplicación que cambiará la unidad de ejecución y la forma de despliegue de las apps web, tal como lo hizo
cgi-bin - CGI, FastCGI, Rack/WSGI y serverless han venido rediseñando el procesamiento de solicitudes y la administración de servidores, y su objetivo común ha sido facilitar la creación y el mantenimiento de aplicaciones de alto rendimiento
- Los módulos Wasm se ejecutan en un runtime host y, mediante memoria aislada y snapshots, pueden mantener un estado de ejecución limpio mientras reducen el costo de arranque
- La ausencia de hilos nativos, la imposibilidad de usar JIT, el costo de copiar datos y la inmadurez de Interface Types y module linking son las principales limitaciones del modelo de ejecución en servidores basado en Wasm
- Cuando las funciones serverless y las funciones de edge se combinan con entornos de ejecución Wasm, se pueden reducir los costos de cold start y aislamiento, y combinar con más ligereza módulos de varios lenguajes
Del CGI al serverless: el modelo de aplicaciones web
- La esencia de CGI estaba menos en el protocolo Common Gateway Interface en sí y más en el modelo de aplicación de invocar por URL scripts o ejecutables colocados en la carpeta
cgi-bin - Ese enfoque fue uno de los primeros modelos de aplicaciones web que convirtió la web de un archivo de documentos en una red de aplicaciones interactivas
- Como ejecutaba un proceso nuevo por cada solicitud, hoy en día el costo de iniciar procesos y parsear scripts se vuelve un cuello de botella importante
FastCGI y la evolución de los servidores web por lenguaje
- FastCGI introdujo un modelo en el que procesos de larga vida manejan solicitudes CGI para reducir los problemas de rendimiento de CGI
- El servidor web no lanza un proceso nuevo por cada solicitud, sino que se comunica con uno o más procesos de larga ejecución
- Como las aplicaciones CGI existentes se habían creado bajo la suposición de que el proceso terminaba después de cada solicitud, era fácil que aparecieran fugas de recursos en un entorno de larga ejecución
- Después se volvió común el uso de servidores web basados en el lenguaje, y las aplicaciones comenzaron a construirse alrededor del modelo de solicitud/respuesta
- Era habitual colocarlas detrás de servidores web ricos en funciones y ya probados, como Apache o nginx, para aislar la aplicación de solicitudes lentas y de los detalles de HTTP
- Las implementaciones de servidor usaban distintas estrategias de gestión de procesos, como
forkpor solicitud, hilos del sistema operativo o del lenguaje, y modelos de eventos o reactor
- La interfaz Rack de la comunidad Ruby también influyó en el servidor de aplicaciones Flask de Python y en la especificación WSGI
- Simplificándolo, una solicitud está compuesta por el método HTTP, un hashmap de headers y una cadena de bytes o stream de entrada
- Una respuesta está compuesta por un código de estado, un objeto de headers y una cadena de bytes o stream de salida
El compromiso entre autoscaling en la nube y serverless
- En los modelos basados en servidores físicos o virtuales, había que administrar directamente cuántos servidores estaban en ejecución
- Si el tráfico era alto, los servidores de aplicaciones podían volverse lentos
- Si el tráfico era bajo, muchas máquinas podían quedar ociosas
- El autoscaling en la nube permite ajustar la cantidad de servidores de aplicaciones según CPU, carga de memoria o franja horaria
- Escalar nuevas máquinas puede tomar de 2 a 20 minutos, según la aplicación y la configuración
- La expansión también depende de los recursos disponibles en la región del proveedor cloud
- El cómputo serverless que combina Amazon Lambda y API Gateway creó un modelo en el que se administran funciones en lugar de servidores
- Garantiza un solo proceso, CPU aislada y memoria aislada por solicitud
- El proceso puede reutilizarse durante varias horas como máximo, pero si no se usa se pausa o se elimina
- AWS puede escalar hacia arriba o hacia abajo en cuestión de segundos según el volumen de solicitudes
- El modelo serverless tiene trade-offs claros
- Debido al costo de crear procesos nuevos, algunas solicitudes sufren cold start cuando escala la concurrencia
- Como el proceso puede pausarse después de responder, manejar conexiones TCP persistentes entre solicitudes se vuelve complicado
- Las APIs de base de datos sobre HTTP son populares en el modelo serverless porque toleran muchas conexiones y escalan hacia arriba y abajo con facilidad junto con las funciones
- La característica de proporcionar CPU y memoria dedicadas por solicitud puede ser ventaja o desventaja según la carga de trabajo
- Algunas cargas reducen la gestión de recursos y bajan preocupaciones de costo y escalabilidad
- Otras pueden ser más eficientes cuando un solo proceso maneja muchas solicitudes o aprovecha memoria compartida para batching y caché
- Se presentan tanto casos de aplicaciones web basadas en CMS que redujeron costos en 90% al migrar a serverless, como casos de servicios de analítica de eventos que redujeron costos en 90% al volver a un modelo basado en servidores
El modelo de ejecución de Wasm en el servidor
- Wasm se desarrolló al principio para ejecutar código de alto rendimiento en el navegador, y está relacionado con intentos como asm.js
- WebAssembly es un formato binario de instrucciones para una máquina virtual basada en pila, diseñado como destino portable de compilación para múltiples lenguajes de programación
- Permite desplegar aplicaciones cliente y servidor en la web
- Fue diseñado para codificarse en un formato binario eficiente en tamaño y tiempo de carga
- Busca una ejecución cercana a la velocidad nativa aprovechando funciones comunes de hardware entre distintas plataformas
- Hoy en día, varios lenguajes pueden compilarse a instrucciones Wasm y ejecutarse tanto en navegador como en servidor
- El modelo de aislamiento y seguridad exigido por el navegador también resulta útil para aplicaciones de servidor
- Permite aislar código no confiable de una forma mucho más liviana que una VM o un contenedor Docker
- Entornos serverless basados en V8 como Node.js, Cloudflare Workers y Deno aprovechan la capacidad de ejecución de Wasm acumulada en el navegador
- También existen entornos nativos de Wasm como Fastly, Shopify y Suborbital
Módulos, host, memoria y snapshots
- Como un módulo Wasm es un conjunto de instrucciones para una máquina virtual, necesita un runtime para ejecutarse
- El runtime compila Wasm genérico para la arquitectura local y proporciona el entorno de ejecución
- Algunos entornos ofrecen una interfaz parecida a la API POSIX de sistemas Linux
- Otros solo exponen funciones específicas del sistema host y permiten ejecutar funciones exportadas por el módulo
- Los programas WebAssembly se componen por modules, y la VM que ejecuta el módulo se llama host
- El módulo es la unidad de despliegue, carga y compilación
- Reúne definiciones de tipos, funciones, tablas, memorias y valores globales
- Puede declarar import y export, y ofrecer inicialización en forma de segmentos de datos, segmentos de elementos y función
start
- Las “memories” de Wasm se representan como arreglos continuos de bytes sin interrupciones, y el host las asigna en el momento de la instanciación
- Cada módulo guest obtiene aislamiento de memoria
- Esa memoria funciona como la RAM de la máquina virtual
- Puede entregarse vacía o precargarse con segmentos de datos
- Gracias a este método de aislamiento del módulo, es posible pausar un módulo y guardar su memoria como segmentos de datos
- Es un concepto parecido al snapshot de una máquina virtual
- Se pueden iniciar varias copias de un módulo pausado
- Wizer instancia un módulo Wasm, ejecuta sus funciones de inicialización y luego reescribe el binario Wasm registrando el estado de la instancia
- Inicializa directamente el estado de los valores globales
- Registra las regiones de memoria distintas de cero
- Elimina los segmentos de datos existentes y los reemplaza por segmentos de datos de las regiones de memoria registradas
- Este enfoque ofrece una ejecución limpia como la de un proceso nuevo, pero evita el costo de arranque de un proceso nuevo
- Es algo cercano a CGI sin las desventajas de CGI
- En términos actuales, es cercano a serverless sin cold start
Limitaciones y ventajas de Wasm
- Wasm no tiene threads en su configuración nativa
- Las operaciones bloqueantes deben trasladarse a métodos del host
- El host puede ofrecer wrappers de lectura y escritura para archivos o interfaces de red, pausar el módulo o proporcionar callback handlers
- Se puede construir un modelo reactor o bloqueante, pero hasta que se aplique la thread proposal, el diseño del entorno de ejecución sigue teniendo mucho peso
- Por motivos de seguridad, no se permite la generación dinámica de código Wasm, por lo que no es posible la compilación JIT
- En el runtime, no se puede tratar el código mismo como una dirección
- Entornos de ejecución cuyo rendimiento depende del JIT, como V8 o CRuby, no pueden ejecutarse en una VM Wasm o tendrían que renunciar al JIT
- Se ha propuesto un enfoque de “pre-jit” que produce en la etapa de build un runtime optimizado para scripts, pero no se ha usado ampliamente
- Como la interfaz básica entre un módulo Wasm y el host es la memoria, mover datos puede requerir copias
- Es posible compartir chunks de memoria, pero eso depende del modelo de memoria del runtime y de si se permite o recomienda
- En la mayoría de los runtimes, la comunicación zero-copy entre módulos y operaciones de I/O se considera difícil
- Mover datos en streaming hacia dentro y fuera de un módulo Wasm puede ser más lento que manejarlo en el host
- La VM Wasm ofrece un alto nivel de control en términos de control de consumo
- Algunos runtimes pueden imponer límites de CPU contando instrucciones, como el concepto de fuel de Wasmtime
- La VM puede limitar memoria y tiempo de reloj real
- Interface Types y module linking pueden reducir el tamaño de los módulos y mejorar la velocidad de I/O y la usabilidad
- Interface Types se pueden usar, pero todavía no son un estándar ratificado
- Module linking tiene prototipos funcionales, pero todavía no existe un enfoque estándar
- Wizer actualmente puede entrar en conflicto con module linking, y aunque hay enfoques personalizados para resolverlo, no hay un ganador claro
- Interface Types apunta a permitir que objetos neutrales entre lenguajes crucen los límites de memoria de Wasm sin costosos procesos de codificación y decodificación
- El enfoque común hoy es copiar JSON dentro y fuera de la memoria
- Por defecto, un módulo Wasm solo puede acceder a lo que se le proporciona, así que su modelo de seguridad es pequeño y claro
- En general, ejecutar código Wasm no confiable es relativamente seguro
- La superficie de ataque de la VM es más pequeña que la de Docker u otros modelos de aislamiento
- Como ejecuta instrucciones transformadas sobre el hardware host, los ataques por timing son posibles, aunque existen mitigaciones
- También se puede compilar Wasm a binarios nativos, pero la superficie de ataque se vuelve mayor
Funciones de edge y ejecución de funciones basada en Wasm
- Si los entornos de ejecución y herramientas de desarrollo de Wasm se vuelven de uso general, incluso los lenguajes de scripting podrían verse presionados a adoptar un runtime Wasm y enfoques de preboot como Wizer
- En teoría, una aplicación podría reanudarse desde una copia con snapshot en cada solicitud y ejecutarse más rápido que con otros modelos actuales
- Incluso un CLI local podría escribirse en Ruby, desplegarse como módulo Wasm con snapshot y conectarse a un runtime Ruby en Wasm para obtener tiempos de arranque cercanos a una utilidad en C++ y limitarse a operar solo dentro del directorio del proyecto
- El primer gran cambio sería mover las funciones al edge, cerca del usuario
- El cómputo se realiza cerca del usuario y no cerca de la base de datos
- Vercel Edge Functions se presenta como ejemplo basado en V8, aunque comparte varios principios
- next-auth puede controlar el acceso a páginas prerenderizadas a partir de tokens de login JWT
- Puede servir contenido dinámico personalizado compuesto con datos cacheados en el CDN
- Otro cambio sería reemplazar en aplicaciones serverless las funciones basadas en procesos por funciones basadas en Wasm
- Suborbital permite crear directamente un entorno de ejecución de funciones basado en Wasm y también ofrece encadenar funciones Wasm como workflows
- Muchas plataformas de ejecución recomiendan un solo módulo por solicitud y no aprovechan del todo la posibilidad de compartir memoria o invocar rápidamente varios módulos
- Si Interface Types se estandariza, podría aparecer un modelo de datos de middleware parecido a Rack
- Wasm también puede ejecutarse dentro de una función Lambda
- Se pueden usar versiones snapshot de aplicaciones sobre infraestructura existente
- La combinación es interesante, pero se presenta como una mezcla tecnológica que eventualmente podría desaparecer
Hacia el próximo modelo de aplicaciones web
- Wasm se presenta como una tecnología capaz de mejorar el rendimiento, facilitar la seguridad a nivel de proceso y reducir los costos de build y ejecución de funciones serverless
- Puede ejecutar casi cualquier lenguaje, y con module linking e Interface Types puede reducir de forma importante la latencia entre funciones
- La idea central para considerar a Wasm como el nuevo CGI es que, cuando cambian las restricciones del sistema, se vuelven posibles cosas que antes no lo eran
1 comentarios
Opiniones de Hacker News
No entiendo bien en qué se diferencia WASM de tecnologías anteriores como Java Applet, ActiveX, Silverlight o Macromedia Flash.
Pensé que ya habíamos aprendido la lección sobre ejecutar código compilado de terceros no confiable en el navegador, y parece una arquitectura que traslada el costo de cómputo del servidor al cliente con el pretexto de mejorar la experiencia del cliente.
Sus implementaciones tenían muchas vulnerabilidades y al final quedaron prácticamente inutilizables en el navegador; otras tecnologías ni siquiera parecían haber hecho esa promesa desde el principio.
JavaScript sí cumplió esa promesa en la práctica, y hoy los navegadores ejecutan JavaScript descargado desde cualquier dominio sin preguntarle al usuario si confía en él.
WASM corre sobre el motor de JavaScript y ofrece garantías de seguridad similares, así que no hay una diferencia fundamental con el bytecode de la JVM; la diferencia real es que WASM demostró su seguridad y la JVM no.
Hoy Google Chrome es lo bastante seguro como para que miles de millones de personas puedan ejecutar WASM malicioso sin que sus teléfonos queden comprometidos, y se puede llevar ese motor al servidor para ejecutar scripts de varios usuarios dentro de una sandbox fuerte y compartir recursos.
La alternativa es la virtualización: compilar el código como un bloque de WASM y ejecutarlo en un gran servidor WASM, o empaquetar un binario amd64 con un kernel de Linux recortado y correrlo en una VM.
Por ahora no está claro que haya un ganador evidente; cada enfoque tiene sus ventajas y desventajas.
A diferencia de la JVM, WASM ofrece memoria lineal y, por defecto, no tiene recolección de basura, así que encaja mejor como objetivo de compilación para un conjunto más amplio de lenguajes, como compilar C/C++ con Emscripten o apuntar a Rust.
WASM es bytecode, y creo que la mayoría de las implementaciones comparten mucho con el motor de JavaScript y el runtime del host.
El traslado del costo de cómputo entre cliente y servidor es parte de una tendencia de la industria que desde hace mucho oscila entre clientes pesados y clientes ligeros, y ese péndulo seguirá moviéndose.
Existe una especificación de validación que el bytecode de Wasm debe cumplir, y gracias a ese subconjunto validado, muchas de las vulnerabilidades de seguridad que veíamos en tecnologías pasadas se vuelven imposibles de raíz.
Puede que sigan siendo posibles ataques que dependan de fallas de hardware, como Heartbleed o Rowhammer, pero no se puede, por ejemplo, engañar a la VM para que interprete un número como puntero y así referencie memoria fuera de su propia memoria Wasm.
El bytecode de Wasm es relativamente simple de convertir a código máquina, por lo que su implementación puede ser más pequeña y rápida que usar una VM.
No pertenece a una empresa en particular, tiene una especificación pública bien escrita que cualquiera puede usar, y al estar adoptado como estándar web no requiere extensiones del navegador.
El cómputo del lado del cliente ya ocurre con JavaScript, y el código Wasm puede ser eficiente de formas que no son posibles con JavaScript, así que con más razón.
En los Applet estaba mediado en cierta medida, en ActiveX casi nada, y la “plataforma exterior” de WASM es más o menos el runtime de JavaScript, mientras que la plataforma exterior de los Applet se parece más a execve(2).
WASM puede usarse para eso, pero no siempre es así; además, otras respuestas ya cubrieron bien diferencias como una mejor sandboxing y aislamiento.
Decir que “Amazon inauguró la era del cómputo serverless con Lambda” pasa por alto que Google App Engine salió en 2008, 6 años antes que Lambda.
Esos productos ya existían desde hacía varios años y hasta tenían nombre; no entiendo bien por qué se les puso el nombre “serverless” ni de dónde salió.
App Engine tenía workers batch y workers web, y Heroku también.
Ambos eran productos anteriores a Docker, así que quizá por eso la gente los percibe distinto, aunque creo que Lambda tampoco se lanzó desde el principio con Docker.
Decir que “por razones de seguridad no se permite la generación dinámica de código Wasm, por lo que la compilación JIT es imposible” no me parece correcto
Para permitir cosas como hot reloading limpio de código, se acerca a una función esencial
Me parece que el argumento de seguridad es débil
JS puede hacer hot reload en tiempo de ejecución o incluso generación de código más radical sin romper la seguridad, y si se recarga dinámicamente todo el runtime de Wasm preservando la memoria, también se podría imitar la generación de código o el hot reload, aunque la experiencia de usuario sería tosca
No veo por qué tendría que ser técnicamente imposible, y si es una medida de seguridad, parece demasiado fácil de eludir
El bytecode de WASM es conceptualmente muy parecido a cosas pensadas para compilación JIT, como .NET IL o el bytecode de Java
WASM no me gusta mucho porque parece un proyecto con una dirección poco firme y poca voluntad de hacerlo triunfar a tiempo
El nombre sugiere “assembly para la web”, es decir, lenguaje máquina para una CPU virtual, pero en realidad es una representación intermedia para backends de compiladores, y además se planean funciones de alto nivel como soporte para recolección de basura, así que el concepto es poco claro
También siguen faltando funciones básicas como el hot reload mencionado, threading que no parezca un hack, integración directa con el DOM sin JavaScript, APIs de gráficos/cómputo de bajo overhead y acceso de bajo nivel al audio
Es difícil ejecutar apps multimedia grandes sin compromisos importantes
Wasm no puede marcar memoria como ejecutable y, en la práctica, separa código y memoria como una arquitectura Harvard
Además, tampoco puede saltar a una posición arbitraria del código, y ni siquiera existe una instrucción de salto como tal
Aquí JIT significa compilar y ejecutar código nativo durante la ejecución, lo que en un navegador o en el sandbox de Wasm se convierte en una gran debilidad de seguridad
Esto está incorporado en el diseño y en el conjunto de instrucciones, así que no es algo que se pueda eludir fácilmente; se pueden ver más detalles en https://webassembly.org/docs/security/
Wasm se parece a .NET IL o al bytecode de Java en que el motor se encarga del JIT, pero darle al usuario permiso para salir del runtime, crear código nativo y saltar hacia él es peligroso
Por eso, igual que con JIT, al ejecutar código WASM por primera vez puede verse un pequeño “tirón de calentamiento”, aunque ha mejorado mucho en los últimos años
Además, tengo entendido que en el navegador se pueden crear dinámicamente bloques de WASM, instanciarlos y ejecutarlos
No sé si eso es posible en otros runtimes de WASM, y en el navegador hay que pasar por JavaScript, pero de todos modos eso es necesario si se quiere acceder a cualquier “API web”
WASM convierte una VM dedicada a un lenguaje específico, como la VM de JavaScript, en una VM de propósito general que puede usarse en cualquier lugar donde se use una VM de JavaScript
Por supuesto, no se limita solo a eso
Propósito general significa que, si existe un compilador o intérprete, se puede ejecutar casi cualquier cosa, incluido JavaScript
Como por lo general se implementa como parte del motor de JavaScript, hereda muchas características como el sandboxing y el acceso a esas APIs
La estandarización de ese acceso todavía está en curso, pero al final las cosas que hoy solo pueden hacerse con JavaScript también serán posibles en WASM, y además serán posibles muchas más cosas que con JavaScript son difíciles o imposibles
También podrían ejecutarse más rápido y con más fluidez
El punto central de WASM es eliminar muchas de las limitaciones que existían en entornos donde JavaScript es popular
JavaScript es un lenguaje que divide opiniones, así que pasaría de ser la única opción a ser una opción entre varias
WASM ha sido descrito como reemplazo de JavaScript, reemplazo de Docker, reemplazo de Java y reemplazo de CGI; en pocas palabras, es todo eso y más
Hay demasiadas herramientas que hacen cosas parecidas y sus límites no están claros
Aunque al final uno logre que todo funcione, personalmente se siente frágil, y para alguien que no se dedica profesionalmente a eso resulta intimidante
Últimamente, cuando tengo que construir algo para la web, uso leptos; la experiencia de desarrollo es mucho mejor y, aunque todavía ni siquiera es 1.x, se siente más estable que encadenar cinco herramientas para transpilar, ofuscar, minificar y empaquetar bundles de JS
Al leer este artículo me acordé de una ley de software que antes se mencionaba mucho
La ley dice que una aplicación suficientemente grande y longeva termina reimplementando todo el stack de software sobre el que corre, incluso el sistema operativo, y que lo reimplementa mal
No sé bien cuál es la fuente, pero suele cumplirse bastante
“Todo programa en C o Fortran suficientemente complejo contiene una implementación ad hoc, especificada de manera informal, llena de bugs y lenta de la mitad de Common Lisp”
El patrón más general se llama Inner-Platform Effect
Si ampliamos la premisa del título, para que WASM sea el verdadero sucesor de ese linaje tendría que ser tan fácil como subir y desplegar una app PHP en un stack LAMP de cualquier proveedor de hosting
Por ahora no parece tan fácil como la experiencia de despliegue de PHP
No sé qué esperan que cambie en el hosting
Yo lo veo distinto
Creo que el futuro es local-first
Es un modelo en el que la app se ejecuta casi por completo dentro del navegador del usuario, con muy poca ayuda del servidor
Apps como Figma, Linear y Superhuman usan este modelo con mucho éxito, y Stackblitz también en cierta medida
Si una app con cierto nivel de complejidad como Figma puede ejecutarse casi por completo dentro del navegador del usuario, creo que la mayoría de las apps también pueden
Del lado del servidor, la función principal es sincronizar datos entre distintas instancias cuando el usuario usa la app desde varios lugares
Se están creando herramientas como Electric-SQL, aunque todavía no están maduras; cuando estas librerías maduren, esta área crecerá mucho
Serverless en general existe para que empresas como Amazon y Azure ganen dinero, y al final terminará como CGI
WASM también puede tener éxito, pero probablemente sobre todo dentro del navegador del usuario
Microsoft usa WASM para C#/Blazor, pero no creo que dotnet dentro del navegador vaya a volverse tan rápido como JavaScript, así que no me parece el enfoque correcto
Nadie habla de eso porque no puede escalar a 1 billón de impresiones de anuncios por segundo
Cada vez que alguien escribe una función serverless, le agrega 10 pies al yate de Bezos
Si estás offline o en un lugar con wifi inestable, no puedes cargar un diseño; y, salvo que haya cambiado recientemente, si después de editar se corta el wifi y cierras el navegador, no se guarda
Y tampoco es una idea para nada nueva
Estamos desarrollando Blazor WASM y, en términos de rendimiento, dotnet no es el problema
¿Básicamente están recreando la JVM y su ecosistema?
A veces rehacer X incorporando las lecciones del pasado puede ser una idea realmente excelente
Por ejemplo, cuando alrededor de 2010 empecé a investigar cómo ejecutar código C/C++ en el navegador, compilar C/C++ a la JVM era prácticamente imposible
En esa época los Java Applets todavía tenían sentido, así que habría sido bueno si eso hubiera sido posible, pero WASM aún no existía y Emscripten sí; eso llevó a asm.js y, finalmente, al nacimiento de WASM
Como alguien que en clases de lenguajes de programación de los 2000 tocó class loaders y escribió ensamblador de JVM a mano, ni siquiera estoy seguro de que la JVM sea el punto más alto en esta área
Es cierto que hizo posible un ecosistema enorme, pero la interfaz con la que la JVM se encuentra con el mundo exterior es un desastre realmente tosco
Durante más de 20 años, cada vez que me topé con algo relacionado con la JVM, solté un quejido
Si comparas el empaquetado y el ecosistema de Rust con Python o, peor aún, con C++, se ve que una reinvención que incorpore las lecciones de las últimas décadas puede ser algo muy bueno
Unir dos archivos wasm en uno solo y hacer que la fusión de memoria quede bien sigue siendo muy difícil
Puede que el modelo de componentes lo arregle, pero tiene demasiados elementos innecesariamente inflados, así que la adopción en Safari podría tardar mucho
Desde hace mucho pienso que WASM va a ir hacia un mundo en el que reemplace el código de funciones Lambda en la nube
Tradicionalmente se considera que WASM se ejecuta sobre la plataforma host, pero no hay razón para que tenga que ser así
Por la naturaleza de sandbox de WASM, técnicamente también podría ejecutarse fuera del sistema operativo o en ring0 para evitar gran parte del overhead del sistema operativo
Compilar a WASM simplifica mucho varios problemas de despliegue para los usuarios, y el entorno de hosting tiene mucho margen para optimizar
Incluso podría ser posible hardware personalizado para ejecutar WASM más rápido
Tener que ejecutar automáticamente código arbitrario no confiable proveniente de una fuente arbitraria no confiable es malo, y tampoco se puede decir que cumpla el mismo rol que CGI del lado del servidor