Hace apenas cuatro años, anunciamos Cloudflare Workers, una plataforma sin servidor que se ejecuta directamente en el perímetro.
A lo largo de esta semana, hablaremos de las muchas formas en que Cloudflare está ayudando a acelerar las aplicaciones que ya existen en la web. Pero si hoy es el día en que decides hacer realidad tu idea, desarrollar tu proyecto en el perímetro de Cloudflare e implementarlo directamente en los conductos de Internet es la mejor manera de garantizar que tu aplicación sea siempre rápida, para cada usuario, independientemente de su ubicación.
Han pasado algunos años desde que hablamos de cómo Cloudflare Workers se compara con otras plataformas sin servidor en lo que respecta al rendimiento, así que decidimos que era hora de contaros algunas novedades. Aunque la mayor parte de nuestro trabajo en la plataforma Workers en los últimos años se ha centrado en mejorar su eficacia con nuevas funciones, API, almacenamiento, filtrado y herramientas de observabilidad, no hemos descuidado el rendimiento.
Ahora Workers es un 30 % más rápido que hace tres años en el percentil 90. Además, es un 210 % más rápido que Lambda@Edge y un 298 % más rápido que Lambda.
¡Ah!, y también hemos eliminado los arranques en frío.
¿Cómo mides el rendimiento de las plataformas sin servidor ?
He ejecutado cientos de pruebas comparativas de rendimiento entre distintas CDN en el pasado. La fórmula es sencilla. Utilizamos una herramienta llamada Catchpoint, que realiza solicitudes desde nodos de todo el mundo al mismo activo, e informa sobre el tiempo que ha tardado cada ubicación en devolver una respuesta.
La medición del rendimiento sin servidor es un poco diferente. Dado que lo que estás comparando es el rendimiento computacional, en lugar de un activo estático, queríamos asegurarnos de que todas las funciones realizaran la misma operación.
En nuestro blog de 2018 sobre pruebas de velocidad, hicimos que cada función simplemente reportara la hora actual. A efectos de esta prueba, se descalificaron los productos "sin servidor" que no cumplieron los criterios mínimos para poder realizar esta tarea. Los productos sin servidor utilizados en esta ronda de pruebas ejecutaron la misma función, de idéntica complejidad computacional, para garantizar resultados precisos y justos.
También es importante tener en cuenta qué es lo que estamos midiendo. La razón por la que el rendimiento es importante es porque afecta a la experiencia de los clientes finales reales. No importa cuál sea el origen de la latencia — DNS, congestión de la red, arranques en frío [...] al cliente no le importa, le preocupa perder el tiempo esperando a que se cargue su aplicación.
Por lo tanto, es importante medir el rendimiento en términos de la experiencia del usuario final, de extremo a extremo, por lo que utilizamos puntos de referencia globales para hacerlo.
El siguiente resultado muestra las pruebas ejecutadas desde 50 nodos en todo el mundo, en Norteamérica, Sudamérica, Europa, Asia y Oceanía.
Blue: Cloudflare WorkersRed: Lambda@EdgeGreen: Lambda
Como puedes ver en los resultados, cuando se trata de velocidad, Workers puede garantizar la mejor experiencia para los clientes, no importa en qué parte del mundo se encuentren los usuarios.
En el caso de Workers, obtener el mejor rendimiento a nivel global no requiere ningún esfuerzo adicional por parte de los desarrolladores. Los desarrolladores no necesitan equilibrio de carga ni configurar regiones. Cada implementación se activa al instante en la vasta red perimetral de Cloudflare.
Incluso si no pretendes dirigirte al público a nivel global, y tu base de clientes está convenientemente ubicada en la costa este de Estados Unidos, Workers puede garantizar la respuesta más rápida a todas las solicitudes.
Arriba, tenemos los resultados de Washington, D.C., lo más cerca posible de us-east-1. Y, de nuevo, sin ninguna optimización, Workers es un 34 % más rápido.
¿Por qué?
¿Qué define el rendimiento de una plataforma sin servidor?
Aparte del rendimiento del propio código, desde la perspectiva del usuario final, el rendimiento de las aplicaciones sin servidor es básicamente una función de dos variables: la distancia a la que se ejecuta una aplicación desde el usuario y el tiempo que tarda en el propio entorno de ejecución en ponerse en macha. La constatación de que la distancia con el usuario se está convirtiendo cada vez más en un cuello de botella para el rendimiento de las aplicaciones está obligando a muchos proveedores de soluciones sin servidor a adentrarse cada vez más en el perímetro. La ejecución de aplicaciones en el perímetro, más cerca del usuario final, mejora el rendimiento. Con la llegada de la red 5G, esta tendencia seguirá acelerándose.
Sin embargo, muchos proveedores de nube en el ámbito de soluciones sin servidor se encuentran con un problema crítico a la hora de abordar la cuestión cuando compiten por un rendimiento más rápido. Y es que la arquitectura heredada que utilizan para desarrollar sus soluciones no funciona bien con las limitaciones inherentes del perímetro.
Dado que el objetivo del modelo sin servidor es abstraer intencionadamente la arquitectura subyacente, no todo el mundo tiene claro cómo los proveedores de nube heredados como AWS han creado soluciones sin servidor como Lambda. Los proveedores de nube heredados ofrecen soluciones sin servidor mediante la implementación del proceso en contenedores para tu código. El proveedor escala automáticamente todos los diferentes procesos en segundo plano. Cada vez que se implementa un contenedor, se activa todo el entorno de ejecución del lenguaje con él, no solo tu código.
Para ayudar a abordar el primer gráfico, que mide el rendimiento global, los proveedores están intentando alejarse de su gran arquitectura centralizada (unos pocos centros de datos grandes) a un mundo distribuido basado en el perímetro (un mayor número de centros de datos más pequeños en todo el mundo) para acortar la distancia entre las aplicaciones y los usuarios finales. Pero hay un problema con este enfoque. Los centros de datos más pequeños implican menos máquinas y menos memoria. Cada vez que los proveedores siguen una estrategia de centros de datos pequeños pero numerosos para operar más cerca del perímetro, aumenta la probabilidad de que se produzca un arranque en frío en cualquier proceso individual.
De esta manera, se crea, en la práctica, un límite de rendimiento para las aplicaciones sin servidor en arquitecturas basadas en contenedores. Si los proveedores heredados con centros de datos pequeños acercan tu aplicación al perímetro (y a los usuarios), habrá menos servidores, menos memoria y más probabilidades de que una aplicación necesite un arranque en frío. Para reducir la probabilidad de que eso suceda, han vuelto a un modelo más centralizado, pero implica ejecutar tus aplicaciones desde uno de los pocos grandes centros de datos centralizados. Estos centros de datos centralizados más grandes, por definición, casi siempre van a estar más lejos de tus usuarios.
Puedes verlo en el gráfico anterior si observas los resultados de las pruebas cuando se ejecutan en Lambda@Edge. A pesar de la menor proximidad al usuario final, el rendimiento de p90 es más lento que el de Lambda, ya que los contenedores tienen que activarse con frecuencia.
Las arquitecturas sin servidor basadas en contenedores pueden moverse hacia arriba y hacia abajo en la frontera, pero en última instancia, no hay mucho que puedan hacer para cambiar esa curva de frontera.
¿Qué hace que Workers sea tan rápido?
Workers se diseñó desde cero para crear un modelo sin servidor que prioriza el perímetro. Dado que Cloudflare empezó con una red perimetral distribuida, en lugar de intentar trasladar la computación desde grandes centros de datos centralizados al perímetro, trabajar con esas limitaciones nos obligó a innovar.
En una de nuestras publicaciones anteriores del blog, hemos discutido cómo esta innovación se tradujo en un nuevo cambio de paradigma con la arquitectura de Workers desarrollada sobre aislamientos ligeros V8 que pueden activarse rápidamente, sin arranques en frío en cada solicitud.
La ejecución de aislamientos no solo nos ha dado una ventaja desde el primer momento, sino que a medida que V8 mejora, también lo hace nuestra plataforma. Por ejemplo, cuando V8 anunció Liftoff, un compilador para WASM, todos los WASM Workers se volvieron más rápidos al instante.
Del mismo modo, cada vez que se realizan mejoras en la red de Cloudflare (p. ej., cuando añadimos nuevos centros de datos) o en la pila (p. ej., la compatibilidad con protocolos nuevos y más rápidos como HTTP/3), Workers se beneficia instantáneamente de ello.
Además, siempre estamos tratando de mejorar Workers para que la plataforma sea aún más rápida. Por ejemplo, el año pasado, lanzamos una mejora que ayudó a eliminar los arranques en frío para nuestros clientes.
Una ventaja clave que ayuda a Workers a identificar y abordar las deficiencias de rendimiento es la escala a la que opera. En la actualidad, Workers da servicio a cientos de miles de desarrolladores, desde aficionados hasta empresas de todo el mundo, y atiende millones de solicitudes por segundo. Cada vez que realizamos mejoras para un solo cliente, toda la plataforma se vuelve más rápida.
Rendimiento que importa
El objetivo final del modelo sin servidor es permitir que los desarrolladores se centren en lo que mejor saben hacer: crear experiencias para sus usuarios. Elegir una plataforma sin servidor que pueda ofrecer el mejor rendimiento desde el primer momento significa una cosa menos de la que los desarrolladores tienen que preocuparse. Si dedicas tu tiempo a la optimización para los arranques en frío, no lo dedicas a desarrollar la mejor función para tus clientes.
Al igual que los desarrolladores quieren crear la mejor experiencia para sus usuarios mejorando el rendimiento de su aplicación, nos esforzamos constantemente por mejorar también la experiencia de los desarrolladores que utilizan Workers.
De la misma manera que los clientes no quieren esperar respuestas lentas, los desarrolladores no quieren esperar ciclos de implementación lentos.
Aquí es donde la plataforma Workers destaca una vez más.
Cualquier implementación en Cloudflare Workers tarda menos de un segundo en propagarse globalmente, por lo que no querrás perder tiempo esperando a que se implemente tu código, y los usuarios pueden ver los cambios lo antes posible.
Por supuesto, no solo es importante el tiempo de implementación en sí, sino la eficiencia de todo el ciclo de desarrollo, por lo que siempre intentamos mejorarlo en cada paso, desde el registro hasta la depuración.
¡Compruébalo tu mismo!
No hace falta decir que, por mucho que intentemos mantenernos neutrales, siempre seremos un poco parciales. Por suerte, puedes comprobarlo por tí mismo.
Te invitamos a registrarte e implementar tu primer Worker hoy mismo, ¡solo te llevará unos minutos!