Por si fuera poco con Node, Deno, Bun o Just, ahora habrá que sumar a otro: LLRT (Low Latency Runtime) de Amazon, enfocado a funciones serverless. Éramos pocos y parió la abuela, como se suele decir por España.
Desde hace unos años florecen frameworks JavaScript como si no hubiera un mañana, ahora parece que empieza a suceder lo mismo con los Runtimes. Si quieres un resumen sobre cómo funciona JavaScript, puedes consultar el primero de una serie de artículos que publiqué hace un tiempo: Destripando JavaScript - Parte 1.
Si no tienes práctica con las funciones serverless, puedes mirar este post dónde te explico cómo Crear una API en AWS con API Gateway y Lambda con Python.
Este runtime se ha diseñado para solventar la cada vez más notable demanda de aplicaciones Serverless y se supone que permite un inicio 10x más rápido y un coste total menor de 2x comparado con otros runtimes de JavaScript en el servicio serverless de AWS Lambda.
Se ha hecho en Rust y utiliza QuickJS como motor de JavaScript. También es bueno decir que, en el momento de escribir este post, es un paquete experimental y solo apto para pruebas (y valientes).
Por supuesto es compatible con paquetizadores o bundles como ESBuild, Rollup o Webpack, entre otros. Es esencial usar alguno.
¿Cómo se justifica este nuevo Runtime?
Es evidente que cabe preguntarnos esto después de todos los nuevos actores de mercado que han aparecido en los últimos años. Los creadores de LLRT nos dicen que el resto de Runtimes, todo y ser proeficientes, están muy enfocados a aplicaciones de uso general, no están diseñados a medida para un entorno serverless.
Además, los otros Runtimes dependen de compiladores JIT (Just-In-Time) para las compilaciones dinámicas de código y la optimización durante la ejecución. Esto, aunque a la larga tiene muchas ventajas en el rendimiento, para un entorno tan cortoplacista y efímero como es el de las funciones serverless, esto supone una carga bastante alta a nivel de memoria.
Aquí es donde LLRT entra en juego, pues se diferencia del resto por el hecho de no usar un compilador JIT, lo cual le da dos ventajas: el tamaño del runtime se reduce mucho y sin esa carga se aprovechan de forma más eficiente los recursos de procesado y memoria para las tareas de ejecución. Esto permite reducir enormemente, hasta diez veces, los tiempos de arranque de las funciones.
Puedes consultar toda la información e instrucciones para probarlo en su repositorio de GitHub.
Conclusiones
Si bien el nuevo Runtime parece prometedor, surge la pregunta de si su adopción será generalizada. Algo me dice que sí, este nuevo Runtime va a prosperar. AWS es el principal proveedor cloud, millones de usuarios usan AWS Lambda y eso puede allanar bastante el camino del éxito.
Ahora bien, teniendo en cuenta que algunos de los principales casos de uso para funciones serverless son la implementación de microservicios, procesamiento de eventos, tareas programadas, aplicaciones IoT, me pregunto si es realmente crítico y necesario tener que reducir tanto los tiempos de arranque de la función.
Estamos hablando de que una función puede arrancar en pocos milisegundos ¿tan impacientes somos?
Seguro que hay casos en los que pueda venir bien, como en aplicaciones que procesan datos en tiempo real o las que usan un backend serverless, pero dudo bastante que los usuarios acabaran notando mucha diferencia.
Donde quizá sí que se note diferencia es en el coste de ejecución de las funciones. Desde luego, para un volumen alto aquí sí que podemos ver notables cambios, aunque me pregunto si esto puede incentivar una subida de precios por parte de Amazon para este servicio.
El resto de actores de mercado también pueden verse incentivados a sacar su versión "light" para serverless. Veremos.
Lo que más claro me queda es que la popularidad de JavaScript no deja de crecer.