馃摝 WebAssembly y los microservicios

Actualmente el modelo de microservicios en aplicaciones web es usado para permitir un manejo eficiente de demandas y costos de las soluciones de software. Todo microservicio comienza con un servidor HTTP que se encarga de un s贸lo dominio del problema, por ejemplo: un microservicio para autenticaci贸n y autorizaci贸n, otro para manejo de agendas, otro para tratamientos m茅dicos, otro para reportes, etc.

Una de las ventajas de este modelo es la posibilidad de proveer recursos independientes a cada uno de los microservicios optimizando as铆 los costos que pueden implicar. Viene tambi茅n con sus desventajas ya que los sistemas distribu铆dos se pueden volver dif铆ciles de razonar y de mantener tras cierto tiempo.

Actualmente existen diferentes formas de lanzar microservicios en la nube:

  • Contenedores Docker. Los contenedores permiten a los desarrolladores lanzar una aplicaci贸n empaquet谩ndola dentro de un sistema virtual. Este sistema virtual es ejecutado sobre un motor de contenedores el cual le provee funcionalidades para el sistema de archivos, redes, etc. Actualmente esta soluci贸n es bastante popular, es ofrecida por AWS, Google Cloud, Azure, etc.
  • V8 isolates. El motor de Google que soporta Node.js y distintos navegadores tambi茅n ofrece un modelo de ejecuci贸n que permite lanzar aplicaciones javascript en un proceso aislado que comparte un mismo contexto con otros procesos. Cloudfare hace uso de esta implementaci贸n en su soluci贸n de c贸mputo de frontera llamada Workers.
  • microVMs. Usando im谩genes docker y el sistema de virtualizaci贸n de Linux es posible crear m谩quinas virtuales de forma r谩pida y a un costo menor que una m谩quina virtual tradicional. La diferencia con los contenedores es que una microVM es ejecutada directamente en el hardware del servidor con la ayuda de un orquestador llamado Firecracker. Esta es una soluci贸n ofrecida por fly.io.

Estas tres soluciones requieren que la aplicaci贸n sea empaquetada junto con todas sus dependencias para ser lanzada dentro de alguno de estos tipos de modelos de ejecuci贸n. Esto implica que tan s贸lo para poder enviar un “Hola mundo” a trav茅s de HTTP en un framework ligero como Express.js requiramos de miles de l铆neas de c贸digo.


WebAssembly viene con la promesa de ofrecer velocidad, seguridad y ligereza, algo que quiz谩s podr铆a situarlo entre una m谩quina virtual y V8 isolate. Adem谩s, al ser un destino de compilaci贸n, es independiente de cualquier lenguaje de programaci贸n.

Existen ya algunos proyectos que est谩n d谩ndole vuelo a WebAssembly en un ambiente de microservicios. Los que m谩s me han llamado la atenci贸n son Spin y Wasmcloud. Cada uno de ellos ofrece un modelo basado en eventos para invocar binarios WASM. Para el inter茅s de los microservicios, uno de estos eventos es una petici贸n de servicio mediante HTTP.

Estos entornos de ejecuci贸n son similares al modelo de Function as a Service (FaaS) en el sentido de que s贸lo debemos escribir las partes del c贸digo que van a responder a los eventos. Todo lo que ocurre antes de esta invocaci贸n queda fuera de la preocupaci贸n de los desarrolladores.

Al igual que muchas otras tecnolog铆as anteriores estos proyectos vienen tambi茅n con la promesa de escribir una y s贸lo una vez componentes de aplicaciones e integrarlas dependiendo de las necesidades, algo similar a un monorepo de binarios.

En lo personal esto es algo que me atrae mucho del concepto de WebAssembly, espero el momento en que por fin dejar茅 de escribir m贸dulos de autenticaci贸n y autorizaci贸n una y otra vez. En este caso lo veo m谩s factible debido a su independencia de un lenguaje de programaci贸n y a que WASI ofrece independencia del entorno de ejecuci贸n.

Desafortunadamente es a煤n muy pronto para juzgar sus capacidades y ventajas ya que en estos momentos WebAssembly a煤n no es capaz de cumplir con lo cometido por dos razones principales:

  1. Los archivos binarios son grandes (comparado a simples funciones) debido a que actualmente no es posible compartir m贸dulos entre ellos. Esto implica que cada uno debe venir empaquetado con todas sus dependencias. Cabe mencionar que es algo que ya est谩 en desarrollo dentro del proyecto.
  2. WASI no ofrece un mecanismo para permitir conexiones HTTP con lo cual cada proyecto est谩 lanzando sus formas de interactuar con este protocolo y permitir puntos de acceso, causando diversificaci贸n en las soluciones. Este punto es considerado por algunos como una especie de vendor lock-in.

Espero que pronto podamos encontrar soluciones basadas en WebAssembly que permitan hacer un uso eficiente de los recursos mediante un modelo optimizado de invocaci贸n que dependa de pura demanda y con la gran ventaja de no tener que volver a comenzar cada vez que queremos lanzar un nuevo proyecto.

Las ganancias en eficiencia y reducci贸n de costos ser铆an grandes, m谩s all谩 de lo simplemente econ贸mico.

Write a comment