Blog de Raymundo Vásquez Ruiz

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.jsrequiramos 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.