MicroVMs ahora manejan las solicitudes de Edge Functions de Netlify, y la compañía dice que el cambio reduce la latencia en aproximadamente 5 veces en el punto medio, al tiempo que mejora la confiabilidad. La actualización no afecta cómo los desarrolladores escriben o utilizan las funciones.
Cada día, aproximadamente mil millones de Edge Functions se ejecutan a través del sistema, atendiendo a clientes como Sunweb y Loto-Québec. Estas funciones gestionan la personalización, el enrutamiento y la autenticación. Hasta no hace mucho tiempo, cada solicitud se enviaba a un servicio de ejecución alojado. Hoy, operan dentro de MicroVMs ubicados dentro de la propia red de borde de Netlify.
El cambio produce una llamada de bienvenida que tarda aproximadamente de 5 a 6 ms en el punto medio, habiendo reducido el tiempo de 25 a 40 ms en el sistema anterior. Las invocaciones que comienzan en frío, necesitando que se obtengan imágenes primero, rondan un promedio de alrededor de 9 ms. El nuevo sistema envía los registros de las funciones de borde de vuelta 5 veces más rápido y ofrece una promesa de confiabilidad del 99,998%.
Cómo viaja la solicitud
La solicitud encuentra su camino hasta el nodo de borde de Netlify más cercano, que luego la maneja. Ese nodo finaliza la conexión TLS y realiza una verificación, comparando la ruta de la solicitud con las rutas de Edge Functions del despliegue.
Cuando no hay una ruta que coincida, la solicitud se dirige a la caché y luego al servidor de origen. Pero cuando hay una ruta que coincide, la solicitud saldría completamente de la red de Netlify con la configuración anterior. Se iba a través de Internet, se ejecutaba la función de borde y regresaba a Netlify para continuar.
La solicitud permanece confinada a la red de Netlify en todo momento. En lugar de llegar directamente a su destino, se le pasa a un nodo de cómputo ubicado dentro de esa red. Ese nodo luego dirige la solicitud a un MicroVM, que podría estar ya en ejecución de una llamada anterior o podría crearse de forma nueva para una nueva, dependiendo de si la invocación es cálida o fría.
La Especificación de la Máquina
Antes de que la solicitud se reenvíe, el nodo de borde genera una especificación para la máquina encargada de ejecutar la función. Esa especificación identifica tres imágenes por nombre: el tiempo de ejecución, la imagen de plataforma de Netlify y la imagen de la función de borde. También establece los límites de CPU, memoria y conexión.
En cada invocación, la solicitud transporta la especificación con ella. El hash de la especificación, combinado con detalles específicos del sitio, forma un ID de servicio, el cual mantiene dos implementaciones con diferente código o diferentes variables de entorno separadas como servicios distintos. Nunca terminan compartiendo una única MicroVM.
Lo más importante es evitar que las fallas de la empresa sean posibles en absoluto. Una implementación que podría haber sido comprometida en cambio se ejecuta dentro de su propia MicroVM aislada, de modo que incluso si de alguna manera se libera del entorno de ejecución, no puede alcanzar a dañar a otros clientes ni la capa de cómputo subyacente.
Los aís ladores V8, sin importar su nombre, no proporcionan este nivel de aislamiento.
Eligiendo un Nodo de Cómputo
Los nodos de cómputo se encuentran detrás de cada región, y el nodo de borde elige uno usando el hash de encuentro, de modo que el mismo servicio siempre termina en el mismo nodo. Esa adherencia es lo que le da a Netlify su estrategia de almacenamiento en caché, ya que las solicitudes distribuidas uniformemente a través de la colmena de otro modo producirían un mayor nivel de inicios en frío.
La forma más rápida de enviar solicitudes a una función es dirigir todas a un solo nodo de cómputo. Esa también es la ruta para crear un cuello de botella — cuando una función muy utilizada lucha por recursos contra todo lo demás que se ejecuta en esa misma máquina. Cuando un servicio atrae una gran proporción del tráfico de una región y permanece fijo en un solo nodo, llena ese nodo mientras perjudica a otros servicios.
Creando el Servicio
El nodo de cómputo recibe una solicitud que transporta una especificación de máquina junto con un ID de servicio. Comienza verificando si un servicio que coincida con ese ID ya ha sido configurado. Si se encuentra una coincidencia, la solicitud se pasa entonces a ese servicio para que pueda enviar su propia solicitud a la MicroVM.
Netlify puede vincular varias MicroVM a las Funciones Edge de un sitio a través de un servicio, y permite configurar parámetros para escalar MicroVM hacia adentro y hacia afuera. Cada servicio está configurado de modo que una MicroVM se apaga después de manejar un número fijo de solicitudes, lo que evita que las MicroVM permanezcan activas indefinidamente.
Las mismas señales indican al sistema que inicie una nueva MicroVM con anticipación, antes de que se apague una existente.
Cuando no existe un servicio para las funciones de borde del nodo de cómputo, se crea uno. El nodo entonces examina si posee todas las imágenes listadas en la especificación de la máquina en el disco. Aquellas que faltan se obtienen del nodo de borde y se descargan en el disco. Este método asegura que Netlify solo descarga las imágenes de las funciones de borde que están siendo utilizadas en esa región.
Lo que ven los Desarrolladores
No ha cambiado nada en lo que respecta a escribir o usar Edge Functions. Todo sigue funcionando igual: importaciones de URL, paquetes npm, módulos integrados de Node, declaraciones netlify.toml y desarrollo local. La única diferencia es que las funciones mismas ahora son más rápidas y más resistentes.
Los Números Detrás del Cambio
Aquí está lo que Netlify reporta, y las cifras dejan en claro el caso.
- ~5–6ms en la mediana (p50), en comparación con 25–40ms en la infraestructura anterior
- 47.4% más rápidas las invocaciones p99
- 99.998% de disponibilidad
- 5 veces más rápida la entrega de registros de las funciones de borde
Las invocaciones en frío ocurren en aproximadamente el 1.2% de todas las invocaciones y tardan unos 9ms en promedio. La compañía dice que el cambio también mejora la seguridad y la confiabilidad, y abre más posibilidades para ejecutar cómputos complejos en el borde.
Lo que Esto Significa para los Clientes
El número de disponibilidad es la verdadera historia aquí, incluso aunque la disminución de la latencia mediana obtiene el reconocimiento principal. Un sistema distribuido que promete una disponibilidad del 99.998% ofrece una sólida promesa de confiabilidad.
Las características de enrutamiento y personalización construidas sobre Edge Functions dependen de que esos servicios permanezcan disponibles. Si fallan, el flujo de la solicitud se interrumpe.
El número inicial de solicitudes también destaca. Con el 1.2% de las llamadas realizadas, el problema es lo suficientemente pequeño como para que el enfoque de almacenamiento en caché descrito anteriormente mantenga la mayoría de las solicitudes listas. Sin embargo, el costo de inicio en frío de 9 ms aún demuestra que el plan acepta cierta demora como parte de cómo funcionan las cosas.
El diseño de aislamiento de Netlify merece atención también. Cada implementación obtiene su propio MicroVM, lo que significa que se evita el problema de ejecución compartida común en muchas plataformas sin servidor. Si una implementación se ve comprometida, no puede liberarse de su entorno de ejecución e interferir con otros clientes.
El inicio del sistema tarda más de lo que lo haría de otra manera. Una invocación en frío promedia 9 ms, lo que importa para las aplicaciones interactivas. La latencia mediana se sitúa en 5–6 ms, por lo que la mayoría de las solicitudes finalizan rápidamente. La cifra de disponibilidad del 99.998% muestra que los valores atípicos ocurren raramente, lo que apunta a una configuración confiable.
La colaboración entre Netlify y Unikraft, descrita por el equipo de esta última, indica que la empresa no está desarrollando esta tecnología sola. La transición de un servicio de ejecución alojado a la ejecución de MicroVM dentro de su propia red requiere un importante esfuerzo de infraestructura, lo que refleja la ambición detrás del producto.
Destaca que la empresa describe sus propios compromisos, incluido el riesgo de punto caliente y la demora de inicio en frío, en lugar de presentar solo las ganancias. La mayoría de los proveedores de servicios en la nube solo comparten sus mejores cifras. Netlify ha elegido publicar tanto los beneficios como los costos.
Lo que resulta es una plataforma de Edge Functions que se mueve más rápido y demuestra ser más confiable, sin necesidad de que los desarrolladores modifiquen ni siquiera una sola línea de código. La combinación de esas dos cosas —una ganancia en rendimiento que va de la mano con la ausencia de fricción para las personas que escriben el código— es precisamente el tipo de actualización que llama la atención.
Cualquiera que esté construyendo sobre Netlify se dará cuenta de que Edge Functions se ejecuta más rápido y de manera más confiable ahora, sin ningún cambio en cómo se comporta su código existente. La infraestructura subyacente sufrió un cambio drástico, pero la superficie permaneció completamente sin cambios.
«5x más rápidas las funciones Edge: V8 aísla a Firecracker MicroVMs», netlify.com.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.