Estas Semanas en Cloudflare en Español

Hola, ¿qué tal? Buen día, buenas tardes, buenas noches, en donde quiera que estén sintonizando este programa o en donde quiera que estén reproduciéndolo más tarde. Mi nombre es Alex Mayorga, soy un ingeniero de soluciones en Cloudflare para Latinoamérica. Hoy es primero de noviembre de 2024. Y bueno, antes que nada, primero unas sentidas disculpas por el pequeño inconveniente técnico que tuvimos en la transmisión anterior con mi conexión a Internet. Pero bueno, sabemos que el Internet puede llegar a fallar. Entonces, vamos adelante. Para los que nos sintonizan por primera ocasión, recordarles que tenemos medios de contacto en la parte inferior de la página donde están visualizando esta transmisión. Ahí se pueden comunicar con nosotros para cualquier pregunta, comentario que nos pueda ayudar a mejorar este programa o cualquier duda que podamos ayudarles a resolver. Bueno, muchas cosas. Primero, acabamos de salir de el mes de concienciación sobre la ciberseguridad. Espero que todo mundo haya podido rotar sus passwords, eliminar todo aquel software que no requieren, actualizar todo aquel que sí requieren. Y bueno, mejor que mejor empezar a migrar a Passkeys para no tener que mantener contraseñas. También, bueno, el día de ayer se celebró Halloween para todos aquellos. Un saludo a sus dentistas, no coman demasiadas dulces. Y bueno, hoy es en México de donde yo soy originario, Día de Muertos. Como pueden ver, hoy yo me disfracé de el servidor de DNS más rápido en el mundo, el 1.1.1.1. Entonces, vayamos ahora con el contenido del programa. Siempre revisamos las novedades de producto de Cloudflare en el sitio Cloudflare.com diagonal whats .medionew. Siempre pueden encontrar las últimas novedades en cuanto a productos de Cloudflare o noticias de la compañía. Tenemos primero que se está liberando en el mes de septiembre la última, una edición especial de nuestra revista de net para modernizaciones digitales. Entonces, invitarlos a que puedan descargar esta revista o leerla en línea sobre cómo podemos utilizar inteligencia artificial para modernizar, cómo podemos utilizar Cloudflare para mitigar riesgos de seguridad y poder obtener o recuperar el control de nuestros ambientes complejos de tecnología. Ustedes lo pueden encontrar en el enlace y invitarlos a leer y también las siguientes ediciones de la revista o igual ediciones anteriores. Después tenemos el anuncio en donde Cloudflare fue nombrado en el cuadrante mágico de Gartner para soluciones de sase de vendedor único. Pueden acceder al reporte del analista en el enlace correspondiente. También tenemos otro reporte de analista en donde Cloudflare es reconocido como un contendiente fuerte en la ola de Forrester para administración de bots. Este reporte del tercer cuarto de 2024 lo pueden encontrar también en el enlace cuando lo requieran. Tenemos un otro cuadrante mágico de Gartner en donde se habla de Secure Service Edge, donde Cloudflare también es nombrado dentro de este cuadrante. Pueden descargar el reporte de analista cuando sea que lo requieran en el enlace correspondiente. Igualmente para la ola de Forrester de Secure Service Edge en el primer cuarto del año de 2024, Cloudflare fue reconocido como un contendiente fuerte. De nuevo el enlace disponible acá. También tenemos White Papers en la guía de compradores de sase, donde pueden descargar si están comenzando en este proceso de evaluar. Pueden utilizar esta guía de compras cuando lo requieran. Tenemos también el anuncio donde Cloudflare comenzó a participar en este espacio de conectividad y seguridad de sase para la simplificación de las operaciones de red y de seguridad. Algunas características adicionales que se anunciaron pueden leer nuestro anuncio en este enlace. Y finalmente también tenemos otro reconocimiento, en este caso de GigaOM, que reconoce a Cloudflare como líder y contendiente extremadamente fuerte en el espacio de CDN. De nuevo tienen el reporte de analista acá. Y bueno, también tienen todo el histórico de anuncios que han aparecido en el sitio. De nuevo, Cloudflare.com-whats-medionew. Ahí pueden enterarse de todas estas novedades. Seguimos y lo siguiente que revisamos es el portal de recursos de Cloudflare. Específicamente nos enfocamos en webinars, pero siempre me gusta recordarles que, bueno, tenemos blogs, videos, whitepapers, tenemos libros electrónicos, guías de soluciones, distintos infográficos y múltiples reportes. Pero bueno, acá hablamos específicamente de los webinars en donde vamos a tener una demostración de nuestras soluciones de seguridad de aplicaciones. Esta se va a realizar el día 5 de noviembre en un horario amigable para nuestros amigos de Europa y Asia, en donde pueden observar esta demostración de todas nuestras distintas herramientas de seguridad de aplicaciones que les ayudarán a proteger sus aplicaciones web o todos aquellos servicios que publiquen en Internet. Tenemos ese mismo día en un horario más amigable para nuestros amigos de Europa y América. El mismo demo de seguridad de aplicaciones que pueden sintonizar para que mis colegas les muestren todas las novedades que tenemos ahí. Después tenemos un evento más de esta serie de demos en donde hablaremos específicamente de mejorías en el desempeño. Esto va a ocurrir el día 7 de noviembre. De nuevo tenemos dos ediciones y la tenemos también para Europa, América y Asia y Europa. Esto igual el día 7 de noviembre. Tenemos una sesión más de esta serie de demos de aplicaciones para seguridad que ocurrirá el día 12 de noviembre, de nuevo en horarios amigables con diferentes regiones del mundo. Y siguiendo con estas demos de desempeño también vamos a tener un par más el día 14 de noviembre, de nuevo en horarios adecuados para distintas regiones como Europa y Asia. América y Europa también. Y tenemos también todos aquellos webinars si por alguna razón estaban interesados en atender alguno de manera directa, pero su agenda no se los permitió, siempre pueden acceder a las grabaciones de todos los webinars anteriores en este mismo sitio de Cloudflare.com-resource-hub. Seguimos ahora con la última parte del programa. En donde revisamos el blog de Cloudflare. Recordar el blog de Cloudflare lo encontramos en blog.Cloudflare.com y ahí siempre de nuestros amigos y colegas de Cloudflare están publicando novedades, descubrimientos, noticias que son relevantes para todos nosotros. Entonces para el día de hoy tenemos un blog post donde nuestro colega Boris nos habla de cómo hicieron la migración de AWS a Cloudflare para Baseline, que es la herramienta de observabilidad que tenemos, y con ello simplificaron su arquitectura y mejoraron su desempeño. Nos habla aquí que en más de un 80% de reducción de costo en este caso. Entonces vamos allá a ver qué nos cuenta Boris. Bueno, primero nos da un poco una introducción de cuándo Baseline se unió a Cloudflare en abril de este año. Ellos anteriormente habían desarrollado su arquitectura en funciones de Lambda, tenían ahí varias bases de datos y tenían también algunos queues. Nos comenta que bueno, había bastante complejidad, tenían costos crecientes y obviamente se está volviendo mucho más popular su plataforma. Y bueno, a partir de ello cambiaron a construir en la plataforma de Workers de Cloudflare. Y nos cuenta aquí que bueno, básicamente se ahorraron un poco más del 80% en su factura del cómputo. Y nos da aquí un detalle específicamente de lo que estaban consumiendo. En cuanto por ejemplo a cómputo, utilizaban Lambda y gastaban $650 ahí por día. Entonces al cambiar a Cloudflare con Workers se ahorran de manera significativa, se reduce a sólo $25 ese consumo diario. Después tenemos los costes para su CDN que se redujeron de $140 a $0 en este caso. También la parte del streaming de los datos y las analíticas o bases de datos consumían con anterioridad $1,150 en Kinesis y EC2. Y bueno, esto se vio reducido al utilizar las analíticas de Workers a $300. Entonces obteniendo un gran total diario de casi $2 ,000 con AWS y $325 con Cloudflare. Entonces ahí haciendo la matemática Boris muestra que hay una reducción de casi el 83%, un poco más del 80%. También menciona que obviamente cuando se hizo el anuncio de que se unían a Cloudflare en baseline, obtienen un incremento importante en la cantidad de usuarios. Y bueno, estaban ya procesando billones de eventos en su infraestructura. Entonces se triplica el número de usuarios activos en su plataforma y eso obviamente les genera retos en cuanto a la escalabilidad, la confiabilidad y obviamente como ya vimos los costes. Entonces ellos emprendieron un journey en donde estuvieron migrando de esta arquitectura inicial, en donde vemos que utilizaban distintas tecnologías de AWS. En algunos elementos los describe acá a más detalle, sus receptores de datos, sus data streams y sus procesadores que podemos ver acá, utilizando diversas tecnologías. Por ejemplo, ingestan data desde múltiples fuentes como puede ser telemetría de OpenTelemetry, logs en este caso de Cloudflare o de CloudWatch o de Vercel. Y bueno, también la validación y autenticación. Estos receptores decía que los tienen implementados en lambdas de AWS o los tenían en aquel tiempo y obviamente usaban CloudFront y Fargate en ese aspecto también. Después tenemos que para el procesamiento de nuevo utilizaban lambdas y para su clúster de ClickHouse utilizaban EC2. También orquestaban utilizando Firehose, Bucket CS3, SQS, Dynamo y RDS para manejo de errores, reintentos y almacenamiento de metadatos en este caso. Nos cuenta un poco más a detalle de todo lo que hacían en estas distintas funcionalidades, pero algo interesante es que menciona que había cierta falta de predictibilidad en lo que pudiese ser el crecimiento potencial de esas cargas de trabajo en los distintos servicios que ya mencionaba. Y también nos cuenta que en ciertos movimientos de los datos había que esperar bastante tiempo, hasta un 70% de tiempo de espera para las funciones que tenían ahí. Resume entonces Boris, que bueno, lamentablemente pues recibían muchas alertas, no podían innovar a la velocidad que ellos deseaban y también pues tenían un poco los costes fuera de control. Otro punto que menciona Boris es el hecho de, dada la regionalidad de AWS, pues ellos estaban desarrollando en el oeste de la Unión Europea y esto obviamente se veía reflejado en un desempeño no ideal para sus clientes que se encontraron en otras regiones fuera de la Europa continental. Entonces eso obviamente resultaba en una experiencia subóptima para todos aquellos usuarios fuera de esta región. Después nos cuenta un poco cómo migraron esta arquitectura hacia Cloudflare, utilizando la plataforma de desarrollo de Cloudflare y vemos aquí un poco cómo luce después. Están utilizando la CDN y el WAF de Cloudflare para transmitir eventos y acá tienen varios workers que están realizando distintas funciones. También almacenan transacciones en la base de almacenamiento de KB, procesan nuevamente con workers y utilizan objetos durables para el registro de errores y utilizan también el motor de analítica de Cloudflare Workers en su arquitectura. Entonces nos comenta que, bueno, básicamente hoy usan workers para absolutamente todo lo que hacen. Todos sus receptores de datos y sus procesadores funcionan en workers y con esto pues tienen el beneficio que tienen todos los usuarios de workers de reducir el tiempo de inicio de sus distintos cargas de trabajo y también el tema de que están desplegados globalmente. Entonces se olvidan un poco de la parte de la regionalización que mencionábamos antes. Esto, obviamente, sus usuarios y sus desarrolladores obtienen una menor latencia cuando están trabajando en baseline. Después nos comenta que ellos utilizan de manera importante llamadas remotas de Javascript nativo y esta latencia reducida les ayuda a simplificar sus comunicaciones o sus componentes de comunicación de manera importante. Tenemos aquí un pequeño bloque de código donde nos muestra esa simplicidad y también nos cuenta que están utilizando el beneficio de la limitación de velocidad que workers les permite tener y con esto pueden hacer limitación de velocidad cuando anteriormente ellos lo tenían que construir básicamente utilizando Dynamo y ElastiCache. Nos comenta aquí también que están utilizando esta función de espera para también reducir la latencia de las llamadas para sus receptores de datos. Después nos pasa a mencionar Poris cómo utilizan objetos durables para el procesamiento de datos. Utilizan ello para la detección de errores en tiempo real y detección de patrones en los logs que analizan e ingesta. Y un poco vemos de nuevo un diagrama en donde nos muestra un poco cómo era más complejo la arquitectura antes de la migración y hoy utilizan simplemente objetos durables porque obtienen un control más preciso en cuanto a consistencia y concurrencia. Después nos comenta también cómo utilizan las funciones de analítica de workers para obtener alta cardinalidad en sus analíticas a gran escala. Comenta ahí que, bueno, ellos antes administraban su clúster de ClipHouse en casa, digamos, y bueno a pesar de que eso es divertido e interesante, en realidad los distraía de construir la función básica de dar observabilidad a los desarrolladores que es la función de baseline. Y bueno, al hacer la migración a estas funciones de analítica en workers, básicamente pueden gastar su tiempo directamente en la creación de mejoras del producto y en mejorar la experiencia para sus usuarios. Mención acá que esta analítica de workers les permite escribir eventos de manera síncrona para poder escalar en sus bases de datos de alta cardinalidad en cuanto a las analíticas. Y bueno, nos comenta que, bueno, ya que ahora están en Cloudflare también han agregado mejoras directamente en la plataforma de Workers Analytics para también tener alta dimensionalidad en adición a la alta cardinalidad en este caso. También nos habla cómo utilizan la parte de Cloudflare Adaptive Bitrate en las analíticas para tener telemetría con distintos grados de resolución. Y nos menciona ahí que puede variar desde 100% hasta 0.0001% en la información de los datos. Y esto también les permite tener órdenes de magnitud de mayor velocidad cuando están accediendo a estas tablas de datos. Entonces ahora con esta tecnología pueden seleccionar cuál es la tabla más apropiada para las consultas de sus usuarios y lo cual les permite optimizar tanto el tiempo de consulta como la precisión de los datos que sus usuarios reciben. Y con ello garantizan que puedan obtener el resultado óptimo y preciso con el tiempo de búsqueda más reducido posible, independientemente del tamaño del dataset o el tiempo que estén consultando sus usuarios. Y bueno, comenta que anteriormente ejecutaban estas búsquedas en el dataset completo y esto obviamente era no óptimo para la experiencia del usuario. El nuevo sistema les entrega respuestas a las consultas más rápidas para todos los usuarios en todos sus casos de uso. Después nos comenta que en adición a estos componentes básicos de workers, objetos durables y la analítica, también utilizan otros componentes de la plataforma de desarrollo, como lo es Queues para mensajes asíncronos. También utilizan D1 como su base de datos transaccional e igualmente Workers KB para almacenamiento distribuido y Jono para sus APIs. Después continúa Boris contándonos cómo realizaron esta migración. Nos comenta que ellos tienen una arquitectura basada en eventos y bueno, van almacenando todas las interacciones con el usuario en el sistema. Entonces toda esta migración implicó cambiar o transicionar esta arquitectura que ya tienen, sin tener en ningún tema con la disponibilidad del servicio o la consistencia en los datos. Nos cuenta ahí que migraron de EventBridge y SQS hacia Cloudflare Queues y utilizaron este modelo de Strangler FIG para incrementalmente hacer la migración desde AWS hacia Cloudflare. Comenzaron reemplazando partes específicas del sistema o todos aquellos nuevos servicios que necesitaban crear en Cloudflare Workers y con esto evitar cualquier disrupción del sistema. Crearon una Cloudflare Queue centralizada que están utilizando como el backbone de los procesamientos de transacciones de sus eventos. Entonces todo esto lo están enviando hacia ese Cloudflare Queue y después enrutaban dinámicamente a las distintas partes de las aplicaciones. Sincronizaban con D1 y KB. Entonces tenían un espejo entre AWS y Cloudflare durante el periodo de transición. Esto les permitió tener consistencia en los datos y no perder continuidad en la interacción de los usuarios con sus sistemas de baseline. Después vemos ahí un pequeño segmento de código donde explican el procesamiento de eventos. Después migraron su Data Pipeline de AWS a Cloudflare, comenzando de fuera hacia adentro. Entonces comenzaron con los receptores de datos. Después comenzaron a escribir la telemetría en ambas plataformas durante el periodo de retención de los 30 días que tienen ahí. Y finalmente reescribieron todos sus lambdas y contenedores de ECS en Workers y finalmente apuntaron en el DNS a las cargas hacia Workers en lugar de las funciones de Lambda. Y bueno, dice que pudieron lograr todo esto en menos de tres meses con tres ingenieros a pesar de la complejidad. Luego vemos ahí ya unas gráficas que nos provee Boris en cuanto a la reducción en el coste, tanto en Lambdas como en CloudFront. Y también en la reducción de Kinesis en este caso. Entonces tenemos ahí la gráfica en cuanto al tiempo. Misma cosa para EC2. Y bueno, en conclusión nos comenta Boris que con esta transformación que realizaron hacia Cloudflare pudieron escalar y construir de mejor manera su plataforma. Y bueno, ahora sus servicios se ejecutan de manera completamente serverless en un sistema globalmente distribuido que les da mejores eficiencias en costo y en agilidad. Entonces esto también les ayuda a reducir el overhead y pueden concentrarse en iterar más rápido y entregar mejores herramientas de observabilidad a sus usuarios. También nos comenta que podemos comenzar a utilizar hoy Workers Logs, que también es donde han estado trabajando y van a planean entregar muchas nuevas funcionalidades de alertamiento, seguimiento de errores y construcción de consultas de eventos. Todo esto lo esperamos para inicios del próximo año 2025. Bueno, con esto llegamos a la conclusión de este programa, estas semanas en Cloudflare en español. De nuevo recordarles cualquier tipo de comentario, consulta o cualquier feedback que nos quieran hacer llegar pueden encontrar los medios de comunicación en la parte baja de la página de la transmisión. No me queda nada más que agradecer su atención y desearles que tengan un excelente resto del día, un excelente resto de la semana y del mes. Que estén muy bien. Hasta la próxima.