¿Qué es la CDN moderna y por qué es importante?
Aún hay demasiados desarrolladores y empresas sumidos en la oscuridad de las redes de distribución de contenidos (CDN) antiguas que, como si de cajas negras se tratasen, no proporcionan la observabilidad en tiempo real, la seguridad integrada ni el control programático necesarios para ofrecer las experiencias dinámicas que exigen los usuarios y los profesionales en la actualidad.
Con la CDN moderna de Fastly, los desarrolladores disponen de todo lo necesario para crear experiencias digitales innovadoras que aumenten el valor de la relación con los clientes, las tasas de conversión, la fidelización y el importe medio de los pedidos. Las empresas dotadas de esta capacidad tienen más posibilidades de prosperar cuando dan a los desarrolladores las herramientas que necesitan para innovar y mantener los sitios y las aplicaciones seguros y competitivos.
En este webinar, los expertos de Fastly repasan:
La evolución de las CDN antiguas y el estado actual del sector de las CDN, fundado sobre ese castillo de naipes.
Las ventajas de la CDN moderna, con ejemplos reales de clientes de Fastly, Gannett y Stripe, cada uno con sus propios retos y expectativas que cumplir.
Cómo seleccionar un proveedor de CDN moderna y qué elementos lo pueden diferenciar de una CDN antigua, como las maneras de lograr un retorno de la inversión.
Este webinar te enseñará por qué es hora de plantearte cambiar tu CDN antigua por una diseñada para el desarrollo y los usuarios modernos.
[Leigh Clancy] Hola y gracias por asistir al webinar «¿Qué es la CDN moderna y por qué es importante?».
Durante este webinar, repasaremos la evolución y el estado actual de las CDN, las ventajas de una CDN moderna (con ejemplos reales), cómo elegir un proveedor de CDN moderna y en qué elementos fijarse. Podéis plantear vuestras preguntas en el chat, y las intentaremos responder durante la ronda de preguntas y respuestas del final. Hoy contamos con Lee Chen como ponente. Lee Chen es Vice President of Corporate Development and Strategic Partnerships de Fastly, y una de sus funciones es en calidad de patrocinador ejecutivo de nuestros productos multimedia. En Fastly ha dirigido todo tipo de equipos de producto, marketing y colaboraciones, y ha pasado los últimos 20 años en el ámbito multimedia y de entretenimiento, innovando en retransmisiones en vivo por internet. Antes de incorporarse a Fastly, fundó y dirigió varias empresas emergentes relacionadas con la tecnología y los e-sports. Y con esto cedo la palabra a Lee.
[Lee Chen] Gracias, Leigh. Hola a todo el mundo, y gracias por asistir a esta charla. Pondré las diapositivas en un segundo. Lo ve todo el mundo, ¿verdad? Hola, gracias por venir. Os lo agradezco mucho. Quizá suene raro, pero tengo muchas ganas de hablar a fondo de lo que es una CDN moderna y de su importancia. Antes de entrar en Fastly, como ha dicho Leigh, hará unos nueve años, tuve la suerte de pasar un tiempo trabajando en infraestructuras, y también en productos directos al consumidor. Yo empecé en la telefonía, presencié los primeros pasos de la banda ancha y también viví los comienzos de los e-sports cubriendo retransmisiones en vivo, y eso me hizo ver las muchas dificultades que conlleva la interactividad en tiempo real y la escalabilidad de esas plataformas para millones y millones de usuarios. Cuando entré en Fastly, seguí con mi trayectoria tratando de resolver problemas a la escala de internet en un montón de casos de uso distintos, y hoy tengo muchas ganas de compartir algunas de las cosas que he aprendido y hablar de su importancia en el contexto moderno del desarrollo.
Repasaré brevemente la evolución de la CDN moderna porque creo que es muy importante dar el contexto necesario a esta conversación. Luego analizaremos algunas ventajas, veremos ejemplos reales que me entusiasman y hablaremos de cómo elegir una CDN moderna para vuestro caso de uso en particular. También explicaré por encima por qué Fastly es una muy buena opción, pero espero que esta charla os dé que pensar sobre cómo podéis plantearos (o replantearos) la escalabilidad de vuestras aplicaciones no solamente para muchísimos usuarios, sino también en términos de rendimiento, alcance, seguridad y, quizá por encima de todo, control. Soy consciente de que el público de esta charla es muy amplio y de que podría pasarme horas hablando de este tema, pero voy a hacer el esfuerzo de contenerme e intentaré ir rápido. Como ha dicho Leigh, si tenéis preguntas, id dejándolas en la sección correspondiente y nos aseguraremos de dar respuesta a todas ellas.
Vamos allá.
¿Cómo se las arreglaban las empresas antes de las CDN? En la Prehistoria, es decir, en los albores de internet, se presentaron una serie de desafíos, sobre todo cuando una aplicación o un sitio llegaba a distintos rincones del mundo o se hacía muy popular, y son desafíos que siguen hoy en día. Tomad un sitio o una aplicación que creamos por primera vez: normalmente, no contamos con una red del borde repartida por el mundo que nos ayude a presentar el contenido de forma rápida y segura en los cinco continentes, de modo que terminamos lidiando con experiencias negativas porque la aplicación tarda en cargarse por la latencia, o el sitio no funciona porque los datos llegan fragmentados. Había que resolver este problema.
Para ello, podríamos establecer múltiples instancias de nuestro sitio o aplicación por el mundo, pero entonces costaría que los conjuntos de datos fueran coherentes entre sí.
Y ahí es donde entraron en juego las CDN. Las primeras CDN hacían más o menos lo mismo: creaban copias o daban la posibilidad de almacenar múltiples copias de los mismos datos en todo el mundo, ya fuera en memorias caché o puntos de presencia, con unos resultados un poco mejores porque creaban esas memorias caché para almacenar el llamado contenido estático de un sitio o aplicación. Hablamos de cosas como imágenes, vídeos, texto, etc.; cosas que no iban a cambiar muy a menudo, de modo que se resolvía el tema de la coherencia porque el contenido apenas cambiaba. Pero [ay, perdón], pero eso no tenía utilidad alguna si hablamos de contenido dinámico que cambiaba con frecuencia o, aún peor, que se personalizaba para el usuario, como podrían ser el estado de sesión, la página de inicio de un sitio de noticias o incluso la actividad en una cuenta de Twitter personal. Y, claro está, en los inicios de internet, la topología de la red era muy distinta. Para resultar efectivas, las primeras CDN tenían que colocar sus puntos de presencia, o POP, en plena red de consumo de última milla.
Así pues, con la evolución de todo internet, a medida que su escala, su prevalencia y el número de usuarios crecían exponencialmente, a las CDN se les iban acumulando año tras año los problemas relacionados con la arquitectura inicial. Donde había cientos de miles de servidores de caché en plena última milla de internet, había que tener cientos de miles de copias del mismo contenido repartidas por todo el mundo, y la primera vez que se accedía a algún contenido de estos servidores de caché, como una versión actualizada de la página de inicio, había que volver al origen para que el stack de aplicaciones pudiera recuperar ese contenido. Así, si una aplicación o un contenido gozaba de muchísima popularidad, estamos hablando de millones y millones de usuarios volviendo al origen para obtener la última versión de ese contenido. Ante esta situación, las empresas que contaban con una arquitectura desfasada implementaron algo llamado almacenamiento en caché intermedio, que podemos ver aquí, y eso significaba que «solo» decenas de miles de servidores hacían la función de origen para memorias caché de la última milla, pero igualmente estos volvían al servidor de origen para obtener la última copia de contenido. Por si esto fuera poco, el contenido se ofrece cada vez más en tiempo real. Han surgido DevOps y la integración y el despliegue continuos, que mejoran los flujos de trabajo de desarrollo y contribuyen a que las empresas iteren con mayor rapidez, pero a la vez plantean problemas cada vez más difíciles de resolver para las arquitecturas en el edge del pasado. Almacenar una copia anticuada de una página web no es bueno, pero es mucho peor tener múltiples versiones de contenido, API o incluso aplicaciones enteras en el edge que cada vez están más obsoletas. Así pues, aun con esas memorias caché intermedias y de la última milla a disposición, el grueso de la audiencia seguía dirigiéndose a menudo a los orígenes. Desde Fastly, lo primero que queríamos resolver era el problema de la escalabilidad horizontal y vertical, de ahí que implementásemos el edge de CDN. Ah, y si añadimos bots y otros ciberdelincuentes que pretenden aprovechar vulnerabilidades, extraer datos o hacer cosas peores, estos contenidos y aplicaciones ya cojean por todos lados. También quiero apuntar que en este gráfico no hay nada de observabilidad ni visibilidad real de lo que ocurre en el edge. Sabemos que con estas arquitecturas antiguas llegará un lote de registros en 24 o 48 horas, pero con eso no podremos diagnosticar ni resolver lo que ocurra en tiempo real.
Tampoco vemos que haya manera de invalidar lo que tenemos en el edge ni de saber el tiempo de desarrollo que vamos a necesitar para corregir el titular, el recuento de inventario u otro dato esencial para la marca o el negocio que esté en internet, todo ello con el aliento de la empresa en el cogote para hacerlo lo antes posible. Y ahí entra Fastly. ¿Qué diferencia a la CDN moderna y a Fastly? En primer lugar, desplegamos grandes POP que se sitúan en puntos clave de internet; no en la última milla, sino donde las vías de internet se juntan y se interconectan con todas las otras redes distantes del mundo. Así, tenemos CPU, discos y redes concentrados que aportan una mayor eficiencia a la hora de procesar y almacenar en caché, lo cual a su vez significa un mayor control y disponibilidad para vosotros, vuestro sitio web o vuestra aplicación. Y, como estamos en las grandes confluencias de internet, gozamos de una latencia y un rendimiento de red igual o mejor que las CDN antiguas. Esto se puede comprobar en las estadísticas de Citrix, que son públicas y ajenas a Fastly. De hecho, si alguien puede dejar el enlace en el chat se lo agradecería. En fin, que se pueden ver las métricas de latencia con evaluaciones independientes ajenas a Fastly, tratándose de una organización que evalúa a todas las empresas del sector, y seguramente la distribución de objetos dinámicos es una de las mejores maneras de conocer el rendimiento de latencia de cualquier red del edge. Además, la densidad de procesamiento de nuestros enormes POP permite ejecutar lógica compleja de aplicaciones en secuencias de comandos de configuración, o incluso aplicaciones completas en nuestro producto Compute en el edge, obedeciendo al flujo de peticiones de los usuarios que interactúen con las aplicaciones o sitios web. Si a esto le añadimos la reducción de peticiones a una sola o la protección específica que damos, ya no habrá decenas de miles de peticiones de nivel intermedio volviendo al origen, sino solamente una o dos peticiones con la protección redundante activada. En seguridad, un firewall de protección para API o aplicaciones web online forma parte del flujo de peticiones que vuelve a la aplicación, y hay que tenerlo en modo de bloqueo para que sea capaz de distinguir entre usuarios legítimos y maliciosos. Con una interfaz de API se puede controlar todo esto y toda la plataforma del edge para acceder mediante programación directamente desde los flujos de trabajo de desarrollo y hacer que propague cambios y actualizaciones a todo el mundo en cuestión de segundos, en vez de minutos u horas. La purga instantánea permite almacenar en caché y validar con una media de 150 milisegundos o menos, y la combinación de estos dos elementos proporciona un control casi en tiempo real tanto de las copias del contenido que están esparcidas por el mundo como de la lógica de la aplicación que dicta cómo se representará el contenido. Luego tenemos la observabilidad, que ya he mencionado antes: la capacidad de ver qué ocurre con la aplicación casi en tiempo real para poder reaccionar, solucionar problemas y analizarla para mejorar el rendimiento del negocio y la experiencia de uso, y no hablo de un simple flujo de registros, sino de algo con personalización absoluta. Si queréis capturar el identificador de un usuario con un flujo de test A/B, para eso están los registros de Fastly. Si necesitáis telemetría de la latencia de una región específica, para eso están los registros de Fastly. Si necesitáis un registro de auditoría para cumplir con la normativa, para eso están los registros de Fastly. Todo esto está a vuestro alcance de forma totalmente personalizable; y si lo juntamos todo, estamos ante unos kits de herramientas increíblemente útiles en un entorno de desarrollo moderno, y ese entorno de desarrollo debería incluir la CDN moderna.
¿Qué es una CDN moderna? He repasado muchas de estas capacidades en la diapositiva anterior, y una CDN moderna debería contar con estas funcionalidades y otras, pero si quiero que os quedéis con algo de esta charla es que una CDN moderna debería estar presente durante el proceso de desarrollo, sin convertirse en un obstáculo ni dejarse para el final. Debe ser un kit de herramientas que permita alcanzar los objetivos, tanto de la empresa como personales, y no un recurso de emergencia cuando llega el momento de crecer. En última instancia, una CDN moderna debería permitiros a vosotros y a vuestros equipos de desarrollo acelerar la iteración y la innovación. Los algoritmos de ordenación de páginas de Google miden los tiempos de carga de las páginas, que son una función de la latencia y la disponibilidad de contenido en memorias caché, así que la CDN moderna debe ser rápida y ágil para que mejore automáticamente el posicionamiento de vuestras páginas. También debe estar bien emparejada o conectada, en lo que a redes se refiere, con Google y otros buscadores del mercado. Una vez más, podéis consultar la clasificación de páginas o las métricas de latencia de Sodexis, que podéis utilizar para evaluar el rendimiento de forma rápida. También deberíais poder personalizar vuestro contenido en el edge. Tomando los casos de uso de los test A/B, imaginad si pudierais mandarlos al edge y ofrecer contenido de forma dinámica según las preferencias del usuario, con visibilidad incluida que os permitiera ajustar la experiencia de uso u optimizar los ingresos. La seguridad debería ser nativa y estar en el edge. Deberíais poder hacer algo más que unos ajustes básicos del almacenamiento en caché y pasar a ejecutar la lógica de las aplicaciones e incluso aplicaciones enteras en el edge. En fin, la lista es larga.
Hablemos de ejemplos del mundo real.
Gannett es el mayor editor de periódicos de los Estados Unidos y es conocido por sus ediciones locales, aunque su cabecera más famosa probablemente sea USA Today. En la invalidación de caché de noticias, lo que llamamos purga instantánea, es esencial mantener los últimos titulares y artículos siempre actualizados, pero imaginaos las posibilidades que se abren al tener un tiempo de purga de 150 milisegundos. Sin enrollarme demasiado, Gannett pudo considerar a Fastly una extensión directa, casi en tiempo real, de sus servidores de origen, solo que con un alcance mundial. Es probable que la página de inicio de Gannett se considere imposible de almacenar en caché y se presente de forma dinámica, con mucha personalización, muchos contenidos y cambios constantes en titulares y demás. Ofrecerla de forma dinámica significa que proviene directamente de sus servidores de origen, en la nube, y como la tienen que mantener actualizada en todo momento, con los últimos titulares y noticias, la realidad es que ofrecen de forma dinámica cualquier evento, como una noticia de última hora, un comentario o un «me gusta». Estos eventos se pueden capturar y utilizar mediante programación para activar una petición de purga vía API. Así pues, con la purga y la purga instantánea, estamos ante una nueva realidad que aligeró en gran manera su infraestructura y permitió pasar lógica de la aplicación al edge. El tiempo de envío de configuraciones globales mejoró en un 98,86 %, mientras que los costes del tráfico de salida se redujeron en un 35 % al trasladarlo por completo a Fastly.
Stripe también me gusta mucho como ejemplo. La empresa procesa mil millones de dólares al año, con picos de tráfico muy impredecibles causados por ofertas relámpago y búsquedas durante las fiestas. Por su negocio, tiene la obligación de ofrecer seguridad y también un rendimiento impoluto, ya que cualquier retraso en el proceso de pago puede hacer perder una venta al cliente y, por ende, ingresos a Stripe. Los picos de tráfico son el pan de cada día, y la empresa debe estar preparada para absorberlos y seguir procesando transacciones para sus clientes finales. Así pues, era imprescindible contar con una plataforma en el edge que pudiera adaptarse a esos picos sin que hubiera una estampida de peticiones a los servidores de origen, y eso es algo que Stripe vivió de primera mano con su proveedor anterior. Además, hay que tener en cuenta la regla de los dos segundos en páginas lentas, que dice que el usuario dejará el carrito o irá a buscar el producto en otro sitio pasado este periodo. En resumidas cuentas, el cliente final pierde la transacción si Stripe va muy despacio, por lo que hay que mejorar el rendimiento constantemente para evitar que los clientes pierdan ventas. Al integrar Fastly en la plataforma de aplicaciones del edge, Stripe logró reducir el tiempo de pago en un 80 %, lo cual es una mejora espectacular en la experiencia de uso.
¿Y cómo se elige una CDN moderna? Aquí tenemos en qué fijarnos antes de adquirir una CDN; y la primera columna está dedicada al desarrollo. Ya he dicho antes que una CDN moderna debe formar parte del proceso de desarrollo; no debe dejarse para después ni meterse con calzador. Si le sacamos provecho desde el principio, habrá ventajas para todo el negocio en general pero, y esto es muy importante, también para el equipo de desarrollo en particular, que podrá iterar e innovar a un mayor ritmo. Si todo va bien, el personal de desarrollo verá sus ventajas desde el principio y podrá centrarse en resolver desafíos del negocio y mejorar la experiencia de uso. Control, observabilidad, normativas, cumplimiento, asistencia técnica y programabilidad de seguridad integrada: todas esas son funcionalidades clave que deben estar ahí. La segunda columna trata sobre responder a las necesidades y los objetivos del negocio. El coste total de propiedad siempre es importante; también tendrá que entrar en la conversación una evaluación del impacto del tráfico de salida de la nube y cuántos servidores se deben ejecutar en EC2 o dondequiera que estén para dar cabida a la arquitectura de almacenamiento en caché correspondiente. Y, por último, hay que probarla antes de comprar, que ya no estamos en el 2000, el 2005 ni el 2010. Ah, y no hay que olvidarse de probar también la asistencia técnica. Una plataforma del edge de verdad, como una CDN moderna, debe poder integrarse y convertirse en una pieza fundamental del negocio y el stack, y personalmente intento escoger partners, proveedores y clientes con los que me sienta orgulloso de trabajar.
Hablando de esto, aquí hay unos cuantos números de los que estoy muy orgulloso. Hemos hecho crecer nuestra red hasta casi 200 terabits por segundo sin perder un ápice de rendimiento en los tiempos de despliegue de la función de purga a nivel mundial. Estamos ante un logro destacable porque aborda un problema de la programación descentralizada muy difícil de resolver, y estamos muy orgullosos de que todas las métricas de rendimiento hayan seguido mejorando a medida que crecíamos. Más del 90 % de nuestros clientes utilizan el WAF de última generación en modo de bloqueo total porque confían en que pondremos freno a los ciberdelincuentes y bots sin impedir el paso de usuarios reales y legítimos, lo cual es importantísimo, porque si el WAF está limitado a funcionar en modo de supervisión, solo hay constancia de los problemas cuando ya han surgido. Si lo tienes en modo de bloqueo total, significa que confías en que la tecnología y la investigación sobre seguridad que hay detrás del WAF son de primera clase, y que este será capaz de dar con los ciberdelincuentes y dejará pasar a los usuarios auténticos para que sigan interactuando con la aplicación o haciendo sus compras. No obstante, los números más importantes seguramente son los que confirman que nos volcamos con nuestros clientes. Todos hemos sido clientes en un momento u otro, y sabemos lo que es un buen trato, de modo que queremos trataros igual de bien a vosotros. Estas métricas de clientes son un reflejo de nuestra apuesta decidida y continua por esta filosofía.
Y con esto termino, muchas gracias por haberos conectado. Te devuelvo la palabra, Leigh.
[Leigh Clancy] Muchísimas gracias. Os recuerdo que podéis escribir vuestras preguntas y las responderemos ahora, y si no llegamos a todas os enviaremos la respuesta después, así que lanzaos y escribid las preguntas que se os ocurran.
[Lee Chen] Aprovecho para dejar de compartir pantalla.
[Leigh Clancy] Bueno, pues veo que tenemos una, parece que se trata de profundizar en la cuestión de tener un control total del desarrollo y de lo que ello implica.
[Lee Chen] Sí, muy buena pregunta. Pues mira, esto puede manifestarse de muchas maneras. Hay dos aspectos. Control significa que puedes interactuar con la configuración, los encabezados de control de caché, el contenido que tienes en la caché; en fin, que hay muchísimas cosas que está bien controlar en una CDN moderna y en una estrategia de almacenamiento en caché en el edge. En primer lugar, necesitas tener acceso, no puede ser una caja negra, ¿verdad? Fastly da acceso a través de la API o del panel de control, que no es más que un reflejo de la API, pero lo más importante es que cuando realizas esos cambios, se implementan en poquísimo tiempo en todo el mundo, en todos los nodos que manejan tu tráfico o tu configuración. Así, un tiempo de despliegue de 13 segundos implica que en cuestión de segundos tus cambios de configuración se propagarán por todo el mundo y se aplicarán como reglas al tráfico que atendemos por ti. El otro aspecto es qué controlas y por qué haces cambios, y ahí volvemos a la observabilidad. Si no ves qué efecto surten tus cambios casi en tiempo real, si tienes que esperar unas horas o incluso días para que el cambio aparezca en los registros o en cualquier otra herramienta de visibilidad u observabilidad que tengas, la verdad es que no sirve de mucho, porque puede que hayas enviado un cambio de configuración erróneo que, sin hacer caer el sitio web, puede que haya cambiado el logotipo por otra cosa que tendrá sus consecuencias para la marca. Así pues, observabilidad y control tienen que ser en tiempo real por necesidad, y así es como trabaja el personal de desarrollo hoy en día, y es algo en lo que creemos firmemente.
[Leigh Clancy] Fastly también es compatible con software de código abierto y estándares web, ¿verdad?
[Lee Chen] Sí, de varias maneras. Están integrados en el stack, de modo que somos compatibles con QUIC, HTTP3 y muchos otros estándares web en la plataforma. Además, colaboramos activamente con el ITF y otros organismos de estándares para ayudar a establecerlos. Por otro lado, también contamos con un importante programa de apoyo al código abierto, del que estamos muy orgullosos, con el que respaldamos proyectos de código abierto y la creación de código, repositorios y demás cosas que puedan resultar útiles, como NPM y otros importantes paquetes que se distribuyen a través de Fastly. En fin, desconozco exactamente el contexto de la pregunta, pero diría que ofrecemos compatibilidad en la plataforma y que se puedes trabajar con ello. Hay mucha información en docs.fastly.com. Apoyamos todo esto para poner de nuestra parte y aportar nuestra experiencia y perspectiva en la creación de estos estándares. Y en cuanto a los proyectos de código abierto, ofrecemos servicios gratuitos de distribución para asegurarnos de que estos proyectos llegan a la gente que realmente está interesada en usarlos.
[Leigh Clancy] Muy bien, y creo que tenemos una última pregunta sobre los eventos en vivo, los picos que provocan, y cómo Fastly ayuda a dar cabida a esas necesidades. Sé que ya has hablado sobre ello.
[Lee Chen] Sí. Pues mira, lo que he vivido con este problema, en primera persona, es que a veces sale muy, pero que muy bien, y otras veces sale tremendamente mal. Cuando hablamos de eventos en vivo y picos de tráfico, lo primero que se me viene a la cabeza es algo como la Super Bowl, en la que cada año millones y millones de personas siguen el partido de fútbol americano más importante del año. Pero claro, estamos hablando de un fin de semana fuera de lo normal. Durante las cuatro horas que dura, millones de personas se conectan para ver una transmisión en múltiples formatos y velocidades de bits distintos, de modo que se convierte en un pico de tráfico muy problemático. Se mide en terabits por segundo, decenas y cientos de terabits por segundo, pero si te fijas, te das cuenta de que puede pasar lo mismo con cualquier evento; por ejemplo, cuando un contenido se hace viral y de repente se produce un pico. Puede que des una noticia de última hora y se produzca un pico, que no tiene por qué ser gigante y de alcance mundial, sino que puede ser muy local o regional. Podría ocurrir, por ejemplo, con una alerta de tornado o con un evento local que despierta un interés repentino. Pues las CDN lidian con este problema así, que es para lo que se inventaron en su momento, porque no había solamente un problema de distribución, también había falta de escalabilidad horizontal y vertical simplemente por almacenar copias en caché. En principio, cualquier CDN puede manejarse en esta situación, y las CDN modernas en particular pueden hacerlo sin sobrecargar el origen. Ahí reside el último componente de la estructura, lo que llamamos la protección, que es la idea de que llevamos todo ese tráfico al edge porque tenemos una copia actualizada del contenido bien a través de nuestros edges o de las memorias caché de nuestros edges, o bien a través de los POP protegidos, de modo que solo hay una o dos peticiones que terminan volviendo al origen. Las CDN antiguas, en cambio, no presentan la misma ventaja en este aspecto, porque tienen miles y miles de memorias caché intermedias que se necesitan para pedirle al origen un contenido concreto y, acto seguido, enviarlo a los edges. Así pues, la estrategia que hemos adoptado y que hemos visto, que nuestros clientes han visto claramente, es que partimos con muchísima ventaja ante picos de tráfico de esa envergadura.
[Leigh Clancy] Perfecto. Muchísimas gracias, Lee, parece que no hay más preguntas, así que gracias por la presentación y muchísimas gracias a toda la gente que se ha conectado. Agradecemos mucho que nos hayáis dedicado algo de vuestro tiempo. Recibiréis un correo electrónico con un enlace de la grabación de este webinar, y si queréis probar Fastly dirigíos a fastly.com/es y haced clic en el botón «Prueba Fastly gratis». Y con esto lo dejamos, espero que tengáis muy buen día y gracias de nuevo por participar.
[Lee Chen] Muchas gracias a todo el mundo, que vaya muy bien.