Estas Semanas en Cloudflare en Español

Hola, buenos días, buenas tardes, buenas noches, donde quiera que estén sintonizando esta transmisión en vivo o viéndola en alguna grabación en Cloudflare TV.

Bienvenidos a Estas Semanas en Cloudflare en Español. Mi nombre es Alex Mayorga Adame y soy un ingeniero de soluciones de Cloudflare para Latinoamérica.

Un poco de logística del programa para todos aquellos que nos sintonizan por primera vez.

En la parte baja de la transmisión pueden ver algunos medios de contacto en donde pueden colocar sus preguntas o cualquier comentario que tengan sobre el programa y estaremos encantados de responderles.

Bueno, lo que hacemos en este programa es básicamente revisar todas las novedades de Cloudflare que hayan ocurrido en el mes en y vamos allá entonces.

El primer recurso que revisamos es Cloudflare.com diagonal whats -new, en donde ustedes pueden ver en todo momento las novedades de producto de Cloudflare.

Tenemos aquí un anuncio para comenzar de una nueva funcionalidad en la que tenemos R2 Super Slurper, que es una herramienta que nos permite extraer datos de un proveedor de almacenamiento existente para traerlos a R2, que es nuestra oferta que les permite ahorrar costes en tráfico de egreso.

Nos menciona aquí que, bueno, se han agregado muchas nuevas funcionalidades a esta versión beta que tenemos disponible, incrementando la velocidad, la fiabilidad y las capacidades de copia de R2 Super Slurper en este caso.

Después tenemos una novedad sobre analistas, en donde Cloudflare es un nuevo proveedor que aparece en el cuadrante mágico de Gartner del 2023 para soluciones de Secure Service Edge.

Cloudflare es el único proveedor que es reconocido en este cuadrante de Secure Service Edge.

También tenemos otro reconocimiento de analistas, en donde Cloudflare aparece como una alternativa recomendada por GigaOM Radar, con la solución que ya mencionábamos de Cloudflare R2, con un rendimiento sobresaliente y, bueno, es un contendiente en este reporte de GigaOM que observamos acá.

Igualmente, una novedad más es GigaOM reconoce a Cloudflare como una de las mejores soluciones de seguridad para el DNS, reconocido como líder y fast mover en este informe.

Tenemos otro reporte de analistas, en donde Gartner, en su guía de mercado para soluciones de seguridad de correo, reconoce a Cloudflare como un proveedor representativo en esta categoría de soluciones de nube y en seguridad de correo.

Tenemos otro reporte de analista, en donde Cloudflare es reconocido como una empresa líder en servicios de CDN, con un rendimiento sobresaliente en este informe de GigaOM Radar para CDN en el año 2023.

Un reporte más de analistas que tenemos acá, en donde Kupinger Cole reconoce también en su referente de liderazgo para soluciones SASE, Cloudflare es reconocido como un líder en este segmento.

Tenemos después nueva funcionalidad que se agregó a la funcionalidad de Waiting Room.

Nos permiten ahora poner reglas de omisión, con lo cual podemos saltearnos la sala de espera y tener un control más preciso de los clientes que decidimos colocar en espera.

Y ahora nuestros clientes Enterprise pueden acceder a estas reglas de Waiting Room.

También tenemos un anuncio de una beta abierta para análisis de correo vía API de Microsoft 365.

Esta beta nos permite la integración con la API de Microsoft Graph, en donde podemos incorporar esta implementación de manera rápida y flexible en la solución de correo electrónico que mencionábamos, Cloudflare Área 1.

Y tenemos finalmente un anuncio de funcionalidad, en donde el control de versiones para las zonas que se encuentran en Cloudflare ya también está disponible de manera general para todos los clientes Enterprise.

Esto nos permite gestionar de forma segura el control de versiones de nuestras zonas, decidiendo cuándo un cambio se va a implementar de manera gradual.

Bueno, seguimos entonces con otro recurso que visitamos.

Es Cloudflare.com diagonal webinars.

Aquí directamente nos va a llevar en el centro de recursos a los seminarios web que tenemos disponibles próximamente.

Tenemos, por ejemplo, un seminario en donde vamos a estar hablando de cómo acelerar el camino hacia un ambiente Zero Trust en nuestro correo electrónico.

Y bueno, esto será el día 6 de junio.

Y bueno, se hablará de cómo estas herramientas como Cloudflare Área 1 nos pueden ayudar en nuestra jornada hacia una ruta de Zero Trust y asegurar el correo electrónico para todos nuestros usuarios.

Después tenemos el siguiente webinar el día 7 de junio, en donde vamos a hablar de SASE y Zero Trust.

Esto como una combinación ganadora para asegurar nuestra red en dondequiera se encuentre.

Después el siguiente webinar que tenemos sería el 14 de junio, en donde vamos a estar hablando de las novedades que se anunciaron durante la reciente semana de desarrolladores que ocurrió del 15 al 19 de mayo.

Y bueno, ahí estaremos hablando de los nuevos anuncios que se realizaron, en cómo se está mejorando la experiencia para los desarrolladores con las herramientas de desarrollo de Cloudflare.

También el anuncio de la beta cerrada de nuestras herramientas de inteligencia artificial.

Ahí también estará disponible. Después seguimos con otro webinar que tenemos el día 15 de junio, para defender a nuestros usuarios de ataques en el lado del cliente, en los browsers de nuestros visitantes.

Estos ataques, normalmente conocidos como ataques a la cadena de suministro, o de dependencias, o de tipo Magecard, pueden ser prevenidos con herramientas de Cloudflare, como Cloudflare PageShield.

Entonces en este webinar se hablará un poco más sobre cómo protegernos de este tipo de problemas.

Y bueno, también recordarles que todos los webinars o seminarios web que hayan ocurrido con anterioridad, están disponibles en esta misma página y los pueden observar bajo demanda cuando su agenda lo permita.

Aquí simplemente haciendo clic en los enlaces de ver ahora.

Bueno, finalmente revisamos más novedades que podemos encontrar en el blog de Cloudflare.

Y bueno, vamos allá. Tenemos un blog de nuestros colegas Tom y Lucas, donde nos hablan de recolección dinámica de datos utilizando variables de workers en la solución de Cloudflare Saras.

Bueno, aquí nos cuentan un poco de cómo Cloudflare Saras fue creado como un manejador de soluciones de terceros que permite hacerlo más veloz, más privado y más seguro.

Y bueno, obviamente esto permite a la personal de marketing tener un entendimiento más claro del journey de nuestros usuarios sin tener que comprometer la velocidad de las páginas.

Saras permite transitar de una manera fácil de algún manejador en el lado del cliente que ustedes utilicen, mover esto hacia la red de borde de Cloudflare.

Nos dice aquí, bueno, que normalmente estos equipos van a tener un plan de taggeo de las páginas.

Pueden, por ejemplo, asignar un nombre de página o algún atributo que les dé más contexto a sus desarrolladores.

Tenemos acá, por ejemplo, algunas opciones en otras alternativas, como puede ser Google Tag Manager, que permite utilizar variables custom en JavaScript y también en la solución de Adobe existe el concepto de Custom Code Data Elements.

Y, por ejemplo, acá nos mencionan que estas funcionalidades pueden ser utilizadas para remover, por ejemplo, información personal identificable.

Vemos aquí un ejemplo en donde esta variable está básicamente agregando los precios individuales de aquello que se encuentra en el carrito de compras de un visitante.

Y, bueno, esto, como mencionan aquí, es el poder ejecutar JavaScript customizado.

Es una característica muy poderosa que da gran flexibilidad y que pudiese haber estado faltando en Cloudflare Saras en su momento.

Pero acá nos cuentan cómo utilizando variables de workers en Cloudflare Saras ahora esto es posible.

Nos comentan aquí un poco cómo funciona en la parte de un request que se hace a un sitio que está utilizando el proxy de Cloudflare.

Hay algunas funcionalidades que se ejecutan antes de llegar a lo que es el servidor de origen, como puede ser el firewall, las mitigaciones de ataques didos, el caché y lo que mencionan aquí que son los First Party Workers.

Y, bueno, en este caso los First Party Workers tienen algunas características de permisos especiales y Cloudflare Saras es considerado uno de estos First Party Workers.

Después nos muestran aquí cómo se puede crear una variable en Saras.

Vemos aquí cómo se le asigna un nombre, un tipo de variable y el valor.

Y después estas variables pueden ser utilizadas en los componentes de Cloudflare Saras utilizándolas dentro del dashboard.

Aquí vemos cómo se agrega una de ellas, por ejemplo.

Después tenemos un poco el código que nos muestra cómo se despachan estas variables y lo que se pudiese hacer con ellas en código de workers.

Nos hablan después de los beneficios que tenemos al utilizar estas variables de workers en Cloudflare Saras.

Podemos utilizar mayor contexto en la construcción.

Podemos hacer el seguimiento de propiedades y las mismas variables, como se menciona ahí.

Y esto se mantiene en la sesión del visitante junto con aquellos otros atributos.

Tenemos también un beneficio adicional que es en cuanto a velocidad, ya que esto es mucho más rápido que llamar código JavaScript en el lado del cliente, dado que esto pues agregaría una visita de ida y vuelta para obtener esta información.

Y en cambio con Cloudflare Saras todo esto se realiza en el borde de la red de Cloudflare.

También tenemos la parte de que podemos aislar estos ambientes, ya que esto se realiza dentro del worker y no está en el browser del visitante.

Por lo tanto, previene la inserción de bugs que pudiesen ocurrir en el código de workers que pudiesen afectar la experiencia de usuario.

Bueno, ahora después Tom y Lucas nos cuentan un ejemplo práctico de cómo están migrando un custom JavaScript o una variable de custom JavaScript de Google Tag Manager a una variable en Cloudflare Saras.

Vemos aquí la configuración, nos explican un poco lo que hacen cada una de las líneas en esta función.

Y después vemos cómo esto se convierte en la sintaxis del código de Cloudflare Saras.

Podemos ver que esto permite agregar también información de un CRM, en este caso, a través de las APIs.

Aquí nos muestran esa llamada de API ficticia que se encuentra aquí en el código.

Estas variables de workers están disponibles al día de hoy para todos los clientes pagos de la solución de workers, que tiene al día de hoy un coste de cinco dólares al mes.

Básicamente lo que hacemos es crear un worker, ya sea vía el dashboard de Cloudflare, donde vemos aquí los cuatro simples pasos que podemos seguir, o también lo podemos hacer vía código utilizando la herramienta Wrangler con estos comandos que nos colocan aquí nuestros colegas.

Posteriormente podemos crear esta variable vía el dashboard en Saras, en donde nuevamente agregamos el nombre de la variable, el tipo de variable en este caso es un worker, y con esto ya la tenemos disponible.

Posteriormente podemos usar esta variable ya creada directamente en la configuración de Saras, que estará disponible en la lista de variables que tenemos disponibles en el dashboard.

Bueno, siguiendo con el blog, tenemos un blog post de nuestro colega Sam, donde nos habla de la notificación que está haciendo Cloudflare para deprecar la solución Railgun.

Nos cuenta aquí que Cloudflare estará deprecando este producto Railgun el día 31 de enero del 2024.

En este momento, llegado ese día, todos aquellos deployment de Railgun dejarán de funcionar.

Entonces, a partir de este anuncio que se publicó en el blog, los usuarios tienen ocho meses para migrar a alguna otra alternativa, dependiendo del caso de uso para el que utilicen Railgun.

Después Sam nos cuenta un poco sobre la historia de Railgun, que tiene un poco más de una década que fue lanzado, y nos comenta que desde ese entonces diferentes nuevos productos de Cloudflare en distintas áreas también se crearon para resolver problemas similares de los que estaba resolviendo Railgun.

Pero realmente nunca se hizo un anuncio de depreciación del componente Railgun.

Esto pues dio algunos problemas. Por ejemplo, no se invirtió en dar mayor soporte a Railgun, nuevas funcionalidades no se creaban, y también el hecho de mantener el componente evitó que se realizaran nuevas mejoras.

Bueno, también nos comenta Sam, que obviamente entendemos que esto puede generar un trabajo o un esfuerzo de migración, y nos va a hablar de los recursos que tenemos y las opciones para reemplazarlos.

Railgun, en este caso, nos comenta Sam, es básicamente una herramienta que nos permitía tratar de transmitir la menor cantidad de contenido dinámico, utilizando deltas en los cambios que puede haber en una página.

Y esto para permitir acelerar la carga de la página para los usuarios finales.

Nos comenta que Railgun tiene dos componentes, lo que sería un listener y también un servicio que está en la red de Cloudflare.

Esto establecía una conexión TCP que mantenía el registro de los cambios en las páginas.

Y esto enviaba solo las deltas de los cambios en la página.

Nos comenta algunas de las razones por las que se ha decidido deprecar Railgun.

En este caso, él nos habla de que no ha habido nuevos releases de Railgun desde 2015.

Y bueno, esto afecta la habilidad de resolver nuevos problemas para los clientes en otras soluciones.

También nos comenta que existen alternativas mejores que se pueden adoptar como un reemplazo.

Y bueno, dado que el componente en realidad era bastante estable, digamos que no se motivó a los equipos a actuar y moverse a soluciones más nuevas.

La razón para la deprecación actualmente nos comenta Sam, que en estos ocho años, desde la última versión de Railgun, ha habido muchas mejoras en la red de Cloudflare.

Por ejemplo, se ha triplicado la capacidad con 285 ciudades que mantienen hoy centros de datos de Cloudflare.

También nos comenta que el hardware mismo se volvió más capaz y eficiente.

Y también nos habla sobre el hecho de que todos los centros de datos de Cloudflare proveen todos los servicios a nuestros clientes.

Habla aquí, menciona, por ejemplo, soluciones o servicios como Zero Trust, Cloudflare Workers, etcétera.

El mantener Railgun distrae un poco el poder invertir en nuevas soluciones y también puede presentar algunos riesgos de seguridad que menciona ahí, que no se consideran aceptables mantener.

Nos comenta que, bueno, de no hacerse este cambio, básicamente la red en general de Cloudflare quedaría en un peor estado y también los propios usuarios de Railgun tendrían una peor experiencia.

Después avanza Sam contándonos un poco en las alternativas que tenemos disponibles para Railgun, dependiendo del caso de uso que le estén dando en este momento.

Por ejemplo, la opción de mantener una conexión persistente con la red de Cloudflare sin tener que tener una IP pública estática.

Nos comenta aquí que esto está disponible con la solución actual de Cloudflare Tunnel, en donde esto funciona de manera similar a lo que sería el listener de Railgun, creando una conexión saliente hacia la red de Cloudflare.

Y bueno, Cloudflare Tunnel está disponible al día de hoy sin ningún costo.

Otro caso de uso que describe aquí Sam es el usar Railgun como el frente para múltiples servicios en una infraestructura.

Y nos comenta que Cloudflare Tunnel también puede ser desplegado en este tipo de modo de bastión, en donde provee conectividad para múltiples servicios que incluso pueden ser diferentes de HTTP y también se pueden hacer réplicas de Cloudflare Tunnel para mantener alta disponibilidad.

Otro caso de uso es el utilizar Railgun para tener mejoras en el desempeño.

Nos habla aquí Sam que en este caso, por ejemplo, Cloudflare Tunnel utiliza Argo Smart Routing, que es una tecnología que permite optimizar la milla media y la última milla del tráfico, lo cual reduce el tiempo de conexión en hasta un 40%.

Los recursos web que utiliza Argo, por ejemplo, son en promedio 30% más rápidos.

Otra alternativa que tenemos disponible para optimizar ese desempeño es Cloudflare Network Interconnect, que provee la habilidad de conectar directamente, ya sea de manera virtual o física, Cloudflare a la red de los clientes, permitiéndoles tener una rampa de entrada hacia Cloudflare desde sus servidores de origen.

Tenemos también otro caso de uso que menciona Sam en este caso, es el utilizar Railgun para reducir la cantidad de datos que egresan de la infraestructura hacia Cloudflare.

Esto, bueno, nos menciona que algunos proveedores cobran unas tasas muy elevadas para realizar esto, pero algunas de las inversiones que ha hecho Cloudflare en tiempo para eliminar esto, pues son la creación de Bandwidth Alliance, en donde se evita este tipo de tarifas.

Vemos ahí que si esta infraestructura corre en Oracle Cloud, Microsoft Azure, Google Cloud, Backblaze y una docena más de proveedores, el costo de egreso hacia Cloudflare debiese ser cero.

Tenemos también que menciona Sam, Cloudflare R2, que también es una solución que no paga esas tasas de egreso en este caso.

Es una solución compatible a nivel de API con S3 y puede, como ya veíamos al inicio del programa, con herramientas como Slurper, migrarse de manera muy sencilla.

Entonces nos comenta Sam un poco el tiempo de esta migración.

A partir del anuncio que se publicó en este blog, y también se hizo llegar a través de correo electrónico, la fecha de deprecación será el 31 de enero de 2024 y al siguiente día las conexiones de Railgun básicamente dejarán de funcionar.

A partir de los días próximos nuevos deployment de Railgun ya no podrán realizarse y las conexiones existentes seguirán funcionando hasta el día de la deprecación.

Sobre cómo obtener ayuda, nos menciona aquí que todos aquellos clientes que tengan un contrato pueden contactar directamente con su equipo de éxito del cliente para detallar sus planes de migración y cualquier pregunta adicional que pudiesen tener.

También nos cuenta que hay un especialista disponible en cada región para atender cualquier solicitud de ayuda durante estas migraciones.

El resto de clientes que no cuenten con un contrato pueden contactarse a través de los foros de discusión en donde nos menciona Sam que hay personal del staff atendiendo las dudas y preguntas en todo momento.

Nos menciona aquí también que se enviarán periódicamente notificaciones vía correo electrónico para notificar a todos aquellos clientes que aún estén utilizando Railgun durante este proceso de deprecación.

Finalmente Sam y todos en Cloudflare agradecemos a todos los usuarios de Railgun que han utilizado Cloudflare para acelerar sus aplicaciones y mejorar sus negocios.

Obviamente estamos contentos de poder ofrecer nuevas funcionalidades más modernas que le sigan permitiendo llegar más rápidamente a sus audiencias.

Bueno, en este momento estamos llegando al final de nuestra transmisión. Nuevamente agradecerles por su atención el día de hoy y espero tengan un excelente resto del día y nos vemos próximamente en otra emisión de estas semanas en Cloudflare en español.

Que tengan un excelente día.