Desde la Nube hasta la Computación en el Edge - Desatando el Poder de Webassembly en el Edge

Hola a todos. Bienvenidos a esta presentación. Vamos a hablar sobre la computación en la nube, la computación en el borde y la web assembly en el borde. ¿Cuál es la agenda para esta charla? Intentaremos cubrir los fundamentos sobre lo que estamos hablando cuando decimos computación en el borde o nube o web assembly. Sabes, algunos de estos términos a veces están un poco sobrecargados. Queremos asegurarnos de que todos estén en la misma página. Y luego veremos la combinación de Wasm más Edge como un emparejamiento hecho en el cielo y cómo estas dos tecnologías pueden trabajar juntas realmente bien. Y luego veremos un caso de uso o cómo Edge mismo está utilizando Wasm y la computación en el borde para lograr nuestros objetivos, técnicamente.

¿Quién soy? Soy Alex Gazelboni. Soy un ingeniero de software de Italia. He hecho algunas cosas en el pasado, desde e-learning hasta computación en la nube en AWS. Y hoy estoy trabajando en edgy como defensor de desarrolladores. Así que vamos a entrar en materia.

¿Qué queremos decir exactamente cuando decimos computación en el borde? Este es un término bastante amplio, si lo quieres. Hay muchas maneras diferentes de definirlo. La idea principal es que en lugar de computar en una ubicación central, como en un centro de datos, mueves la computación a otro lugar y la distribuyes a través de muchos nodos diferentes. Por ejemplo, puedes usar redes de entrega de contenido para distribuir la computación a través de cientos de puntos de presencia a nivel global. En algunos casos, distribuyes la computación directamente en los dispositivos del cliente. Y eso también es interesante. Por ejemplo, si estás haciendo IoT o fábricas inteligentes o ciudades inteligentes, comercio minorista inteligente, todas esas cosas que hacen computación en el borde en dispositivos IoT, por ejemplo.

Así que el enfoque de hoy no se trata tanto de cosas de IoT. Estamos tratando de enfocarnos en la web. Estamos tratando de enfocarnos en cómo agregar computación a la capa de CDN, redes impulsadas por contenido, donde típicamente tienes capacidades de computación. No voy a repasar toda la historia de la computación en la nube de los últimos 60 años. Si tienes curiosidad, pausa el video, tal vez revisa algunos de los hitos que ocurrieron, y te dejaré eso como tarea si estás interesado. Pero queremos enfocarnos un poco en la historia de los años más recientes. ¿Qué pasó en los últimos 15 o 20 años desde que nació la computación en la nube? Y eso es realmente útil para entender dónde está hoy la computación en el borde porque para algunas personas, incluso es lo mismo. La nube y el borde son solo una extensión de las redes globales de computación en la nube que tienen cientos de ubicaciones de borde y POPs alrededor del mundo.

Así que si miras el patrón, pasamos de la virtualización a las máquinas virtuales que están disponibles en minutos, gracias a la computación en la nube desde 2006 o así. Luego pasamos de máquinas virtuales como Amazon EC2 a contenedores, el mundo de Kubernetes, si lo quieres. Y luego, más recientemente, bueno, hace ya casi 10 años, pasamos de contenedores a funciones sin servidor, cosas como AWS Lambda, Google Cloud Functions, Azure Functions, y así sucesivamente. Así que todos estos proveedores de nube hoy están tratando de venderte IA. Pero hasta hace unos años, estaban empujando mucho, todas estas diferentes plataformas de computación, ya sea contenedores, máquinas virtuales, funciones sin servidor, y así sucesivamente. Y había otro patrón que estaba un poco oculto, en mi opinión, que es cómo las redes de entrega de contenido también han evolucionado. Estas nacieron hace décadas para proporcionar entrega de contenido y para proporcionar protección de datos, por ejemplo, para seguridad. Algunas de estas empresas son tan antiguas como Google desde los años 90. Por ejemplo, Akamai se fundó en el mismo año que Google, creo que 1998. Ya estaban casi hace 20 años.

Ya había formas de implementar lógica personalizada sobre estas enormes redes globales, principalmente para propósitos de almacenamiento en caché. Tal vez hayas oído hablar del lenguaje de configuración de Varnish, tal vez, donde podrías implementar almacenamiento en caché personalizado, redirecciones, lógicas, así. Pero más recientemente, si miras los últimos ocho, nueve, 10 años, hemos visto una adición interesante de capacidades de computación sobre estas redes, desde los edge workers o Lambda at edge, si miras CloudFront o CloudFront functions, o los CloudFlare workers en el espacio de CloudFlare, o una computación en el borde, si miras fastly. Muchas tecnologías diferentes bajo el capó, muchos lenguajes diferentes soportados, por supuesto, JavaScript y Node están casi siempre ahí, desde el primer día. Pero también hay una evolución interesante en el mundo de WebAssembly que veremos en un segundo.

Entonces, no se trata solo de computación. A menudo, cuando tienes capacidades de computación, necesitas más cosas como colas y bases de datos y servicios adicionales y almacenes de clave-valor y AI inferencia y lo que sea. Si miras este patrón, los proveedores de CDN hoy son casi como, o incluso sin casi, son prácticamente proveedores de computación en la nube también. Es solo un modelo de computación diferente y un modelo distribuido diferente donde no despliegas código a un centro de datos o a un pequeño conjunto de centros de datos centralizados en una ubicación específica, sino que distribuyes código a través de cientos y cientos de nodos en el borde o ubicaciones en el borde o puntos de presencia alrededor del mundo.

Ahora, déjame también presentarte el segundo pilar de esta charla, que es WebAssembly. Si nunca has oído hablar de WebAssembly antes, está bien. Creo que es posiblemente uno de los desarrollos más interesantes en este espacio en los últimos años. Ha pasado un tiempo. Ha estado presente durante casi nueve años ya. Como veremos más adelante, algunos proveedores de nube y algunos proveedores de borde ya te permiten desplegar aplicaciones WASM sobre sus plataformas de computación. Pero hagamos un rápido resumen histórico también. Esto fue anunciado en 2015, lanzado en 2017, y luego se convirtió en un estándar o recomendación del W3C a finales de 2019. Así que todavía es bastante reciente, cinco, seis años atrás. Y tal vez hayas oído hablar de esto en el contexto de ejecutar binarios de WebAssembly en el navegador. Y eso es asombroso. Puedes hacer muchas cosas interesantes. Pero también hay mucho potencial para ejecutar WebAssembly del lado del servidor. Y por eso estamos aquí hoy. Así que si has visto WebAssembly en el navegador, esto es útil. Y tal vez ya sepas que WebAssembly admite muchos lenguajes de programación desde Rust hasta C y Go y TypeScript y PHP, Rust, sabes, casi todos ellos. Veremos algunas limitaciones detalladas y datos curiosos más tarde. Pero probablemente es más interesante para los lenguajes de bajo nivel, de bajo nivel de abstracción. Así que tú construyes un binario súper eficiente como en C o Rust, y luego puedes usar ese binario portátil en cualquier lugar que desees. También hay una cita obligatoria aquí de 2019 donde el fundador de Docker dijo que si Wasm más Wazy, veremos qué es Wazy en un segundo, si esos existieran en 2008 cuando ellos estaban comenzando a construir Docker, no habrían necesitado construir Docker. Así que eso es un gran asunto si me preguntas.

Así que hay mucho potencial aquí, y la industria está tratando de entender ahora cómo hacer que estas cosas coexistan y funcionen juntas eventualmente también. Así que WebAssembly, hay mucha documentación de diseño genial ahí afuera. Hay diferentes versiones y modelos de los que podemos hablar. Y luego tienes Wazy, que es prácticamente una forma de proporcionar binarios de WebAssembly, acceso a capacidades adicionales como acceso al sistema de archivos, redes, APIs de hilos, sockets y así sucesivamente. Así que la visión aquí es que esto podría convertirse en el estándar para el desarrollo backend y para la distribución de binarios portátiles. Y luego también tienes el modelo de componentes de WebAssembly, que es ligeramente diferente, donde no construyes módulos, sino que construyes componentes para WebAssembly. Así que lo veremos en un segundo.

¿Cuáles son los beneficios en general de WebAssembly si nunca has visto esto? Así que la idea de portabilidad multiplataforma es increíble, donde puedes compilar y luego ejecutar el binario en cada sistema operativo, en cada arquitectura, literalmente en cualquier lugar gracias al formato binario. Y luego tienes un rendimiento casi nativo que es bastante sobresaliente por sí mismo, porque puedes construir algo en C o Rust o C++, y luego ejecutar ese binario con una velocidad similar a la del código nativo. Eso es bastante increíble. Tienes un tiempo de inicialización súper ligero y muy rápido. Así que iniciar un módulo o componente Wasm toma milisegundos. No es como una máquina virtual que toma minutos. No es como un contenedor Docker o un contenedor que podría tomar decenas de segundos. Aquí estamos hablando de algo similar a AWS Lambda o las funciones serverless que pueden literalmente iniciarse en cientos de milisegundos o decenas de milisegundos. Y luego mi favorito es el sandboxing seguro, donde por defecto un binario Wasm no tiene acceso a funcionalidades del sistema de archivos, red y sistema operativo en general. Así que tienes que proporcionar esos explícitamente. Y eso es bastante genial, especialmente, como veremos más adelante, para proporcionar una especie de sandboxing seguro para código no confiable. Y luego tienes soporte multilenguaje y es bastante versátil, como veremos.

El soporte de Node.js existe desde Node 8. Estamos hablando de 2017 aquí, así que ha estado presente por un tiempo. Ya mencionamos que el archivo .wasm puede ser implementado en cualquier lenguaje, pero ya puedes importarlo básicamente en tu código de Node.js. ¿Por qué harías esto? No lo sé, imagina que hay una gran biblioteca de aprendizaje automático o algo realmente complejo y computacionalmente intensivo implementado en C o C++ o Rust, y realmente quieres usar eso en tu aplicación de Node.js. Así es como lo harías. Para WASI, el soporte de Node.js ha estado presente desde 2020, desde Node 12. Ha salido de estado experimental desde la versión 20, así que en 2023. Y como mencionamos, esto proporciona una forma de dar a tus módulos o componentes acceso al sistema operativo y cosas como variables de entorno, sistema de archivos de red, y así sucesivamente. Y luego otro detalle interesante es que tienes esta idea de el lenguaje wit, que es un lenguaje de definición de interfaces que te permite definir interfaces específicas de dominio. Hay algunas estándar como relojes y funciones aleatorias y sockets del sistema de archivos, funcionalidades de CLI y HTTP. Estos se mapean al sistema operativo, pero también puedes definir tus propias interfaces específicas de dominio personalizadas, y eso es también lo que estamos haciendo en Edgy.

Por último, pero no menos importante, encuentras entornos de ejecución de WASM oficiales que te permiten ejecutar este WebAssembly con un enfoque en la velocidad y la seguridad y soporte de configuración y WASI sin tener que re-implementar todo manualmente en tu entorno de Node.js. Por ejemplo, en Edgy, usamos un WASM time, que está diseñado y desarrollado por la Bytecode Alliance. Así que no hay organizaciones con fines de lucro. Están trabajando en todo, compiladores, entornos de ejecución, herramientas y bibliotecas para WebAssembly. Están apoyados por muchas organizaciones grandes, famosas y populares, desde los proveedores de nube hasta los proveedores de Edge.

Muchas organizaciones y productos tienen interés en desarrollar y mejorar el panorama de WebAssembly. Así que encuentras muchas caras familiares aquí. Consulta el sitio web. Estoy tratando de compartir muchos enlaces útiles para que tú puedas profundizar un poco más por ti mismo. Y luego el WASM más Edge, creo que una de las mayores ventajas del Edge en comparación con un diseño típico de nube es que tu código se ejecuta de forma nativa en cientos y cientos de ubicaciones de Edge. Y esa es una gran diferencia en comparación con la nube.

Por lo general, una arquitectura de nube comienza como una aplicación centralizada, incluso monolítica, que se ejecuta en un solo centro de datos, si tienes suerte, en dos o tres zonas de disponibilidad dentro de una región. Incluso si estás ejecutando en AWS Lambda, es un servicio regional. Se ejecuta en un montón de zonas de disponibilidad dentro de una región de AWS. Y eso es bastante conveniente. En la mayoría de los casos, no necesitas más que eso. Pero especialmente si estás construyendo un sitio web o un producto con una audiencia global, rápidamente terminas involucrando algún tipo de CDN, ya sea para caché, para distribuir contenido, para agregar lógica personalizada y para hacer todas estas cosas lo más cerca posible de tus usuarios finales, porque tienes una audiencia global.

Bueno, con la computación en el Edge, todas estas cosas suceden automáticamente, y tu aplicación de Edge está distribuida globalmente en unos pocos clics. Así que otra cosa a tener en cuenta es que hay un intercambio justo cuando se trata de recursos. Por lo general, en el Edge, tienes menos potencia de cómputo, tienes menos recursos, en comparación con una máquina virtual, un contenedor o una función serverless. Pero también, las cosas necesitan suceder realmente, realmente rápido, porque a menudo tu aplicación de Edge se ejecuta justo antes o después de cada solicitud HTTP, así que estás añadiendo latencia a cada HTML o cada página o cada solicitud API. Así que normalmente, quieres ejecutar tu lógica de Edge en menos de 5 o 10 milisegundos, y eso es realmente rápido.

Así que, aunque es cierto que algunos proveedores de Edge o CDN están tratando de hacer esto menos problemático, sabes, la mayoría de las implementaciones de Edge necesitan ser conscientes de estas limitaciones, porque literalmente estás añadiendo latencia a cada solicitud si no tienes cuidado. Así que, por ejemplo, Bunny.net anunció recientemente sus Magic Containers hace unas semanas, y Akamai también parece estar impulsando su Managed Container Service, así que hay formas de ejecutar contenedores en el Edge que están surgiendo, así que échales un vistazo también. Pero en general, si sigues el camino tradicional del Edge, ejecutas tus aplicaciones como una simple aplicación de Edge.

Así que si recuerdas los beneficios clave de WASM que analizamos, rendimiento nativo, inicialización ligera, sandboxing seguro, estos son geniales para ejecutar WASM en el Edge, porque queremos ejecutar lo más rápido posible en unos pocos milisegundos. No podemos permitirnos segundos de tiempo de inicio para nuestros módulos WASM, y eso es genial, porque no necesitamos hacerlo, y también queremos eventualmente poder ejecutar código no confiable en el Edge, sabes, limitando el acceso al sistema de archivos de red y así sucesivamente. Así que WASM es bastante interesante si lo que estás tratando de hacer es similar a lo que estamos tratando de hacer en Edge, y por eso elegimos estas tecnologías, sabes, es una combinación interesante.

Así que en resumen, estamos tratando de construir una plataforma para servicios a nivel de aplicación impulsados por WebAssembly y computación en el Edge. Así que el servicio central en el que hemos estado trabajando se centra en análisis web y recolección de datos, y el objetivo final es permitir que nuestros clientes transformen los típicos SDKs pesados del lado del cliente como Google Analytics, Segment, los SDKs de Amplitude en componentes WASM que se ejecutan incluso antes de que la página se cargue en el navegador.

Así que puedes hacer toda esta recolección de datos segura, inbloqueable y con cero latencia o seguimiento directamente en el Edge. Eso es parte del producto central que estamos ofreciendo hoy. Y así también estamos trabajando en, sabes, soportar nuevos tipos de componentes en el futuro como pruebas A-B, banderas de características, inferencia de IA y mucho más, pero aún en el Edge y aún impulsados por WebAssembly.

También anunciamos recientemente un registro de componentes para componentes WASM. Así que como desarrollador, puedes construir, subir y compartir componentes WASM y luego usarlos sobre la plataforma Edge. Todos estos componentes son de código abierto, así que lo que realmente estamos tratando de hacer es crear una bonita comunidad de desarrolladores de componentes de código abierto. Así que si estás interesado, siéntete libre de echar un vistazo. De alguna manera, puedes casi ver esto como un NPM específico de dominio para componentes de WebAssembly de código abierto. Eso es bastante genial, en mi opinión. Así que puedes descubrir y subir componentes privados o públicos para ti mismo o para la comunidad o para tus clientes.