Estas semanas en Cloudflare en Español

Hola, ¿qué tal? Buenos días, buenas tardes, buenas noches. Donde quiera que nos estén sintonizando en este momento o estén viendo la repetición de este programa de Cloudflare TV Estas Semanas en Cloudflare en Español.

Mi nombre es Alex Mayorga Adame y soy un ingeniero de soluciones en la oficina de Cloudflare en Austin, Texas, Estados Unidos.

Para los que nos sintonizan por primera vez, bueno, les platico un poco lo que hacemos en este programa es revisar las novedades que se han anunciado en Cloudflare en las últimas semanas.

Y también, si nos da tiempo, revisamos un poco una de las redes sociales de Cloudflare, que es Twitter.

Y todo esto lo hacemos en español.

También, un par de anuncios, tenemos un correo electrónico que pueden encontrar en la parte baja de la transmisión así como un número telefónico en caso de que tengan algún comentario que nos quieran hacer sobre el programa o alguna pregunta que nos quieran hacer y intentaremos responderlas durante la transmisión o en la transmisión siguiente, si no nos da el tiempo.

Bueno, dicho esto, comenzamos un poco. Revisamos Cloudflare.com diagonal whats-new y aquí tenemos las últimas novedades de producto de Cloudflare.

Tenemos un anuncio sobre Magic Transit que ahora tiene una API para rutas estáticas.

Lo que dice aquí el anuncio, esta nueva API para rutas estáticas de Magic Transit nos permite ver y actualizar las rutas de nuestros túneles de GRE.

Y así como controlar las rutas para cada uno de los prefijos o túneles que se tengan activos, también nos dice aquí que se puede modificar la prioridad, el alcance regional y el peso en el balanceo de SMP.

Ese es el primer anuncio que tenemos hoy.

Después tenemos un anuncio sobre la remoción de un encabezado llamado cf -request-id que fue removido el 1 de julio de 2021 y nos dice aquí que ya sea anterior a eso se había hecho una remoción de prueba el día 15 de junio y también nos indica que si utilizan este encabezado lo deben cambiar, o la sugerencia es cambiarlo por el encabezado cf-request-id.

Y también nos deja aquí un enlace a otras deprecaciones en la página de api .Cloudflare.com diagonal deprecations para que las visiten y estén al tanto sobre lo que se planea remover si es que hay algo.

Después tenemos otro anuncio que es la disponibilidad general del ruteo por proximidad en el load balancing de Cloudflare.

Nos dice aquí que esto nos permite establecer coordenadas de longitud y latitud para nuestros centros de datos que se encuentran en alguna de las pools y esta información la utilizará Cloudflare para enrutar al centro de datos de Cloudflare más cercano geográficamente a esa ubicación.

Bueno, eso es lo que tenemos aquí. Y bueno, como les comentaba, lo que sigue es revisar un poco lo que tenemos en el blog de Cloudflare.

Tenemos aquí un blog de Rishabh.

Un saludo a Rishabh que nos habla de Quick Tunnels. Bueno, Rishabh nos cuenta un poco que él fue un interno que trabajó en Cloudflare este verano y esto es un blog sobre lo que estuvo trabajando este verano con nosotros.

Bueno, nos cuenta que, obviamente, el equipo de ingeniería con el que estuvo trabajando ha estado incansablemente trabajando para mejorar la arquitectura de Tunnels.

Y nos cuenta un poco, bueno, como Tunnels es una tecnología de Cloudflare que permite establecer una conexión encriptada desde sus servidores de origen al borde de Cloudflare.

Nos cuenta aquí que esto funciona instalando un proceso demonio que se conoce como el conector.

Y bueno, esto permite que existan conexiones sin tener que abrir puertos en el firewall ni tener que crear listas de acceso.

Y bueno, nos cuenta aquí que había algunos detalles que hacían que la implementación de esto no fuera tan rápido como se deseaba.

Porque, bueno, aquí dice si se requería hacer un túnel de prueba, pues se tenía que crear la cuenta en Cloudflare, agregar el sitio, activarlo cambiando los nombres de servidores de nombres y también esperar por la propagación de DNS.

Y bueno, nos cuenta aquí que ahora existe una versión gratuita donde no se requiere este onboarding y que se puede lograr activar un túnel en cinco minutos o menos.

Bueno, aquí nos cuenta los pasos que se tienen que hacer.

Crear el túnel, configurar los servicios a los que estará conectando.

Enviar el tráfico al túnel y ejecutar el túnel.

Pero bueno, esto ahora es mucho más sencillo, como vemos aquí.

Ahora se hace simplemente invocando el comando Cloudflare tunnel.

Nos deja aquí una pantalla donde se ve cómo esto funciona.

Aquí podemos ver que ejecuta Cloudflare tunnel y cómo se hacen las conexiones remotas.

En este caso a dos datacenters en Cloudflare. Y se crean conexiones duplicadas para redundancia.

Nos dice aquí que una vez hecho esto, se crea un subdominio aleatorio en el sitio tryCloudflare.com.

Y también nos dice que en caso de que nuestro servicio no se encuentre en el puerto 8080, también se le puede indicar aquí en la URL el puerto que está utilizando.

Por ejemplo, aquí Rishabh nos cuenta que él tiene un juego que está en el puerto 3000.

Y esta es la forma en la que hace el rotamiento indicando el puerto aquí en este caso.

Después nos cuenta un poco cómo funciona la tecnología que utiliza esta solución.

Es Cloudflare Workers. Como nos dice Rishabh, ayuda a que esto se encuentre en el centro de datos más cercano al cliente en lugar de tenerlo en una locación centralizada.

Nos dice aquí cuando ejecutamos el comando, se inicia la conexión hacia Cloudflare.

Y bueno, como no hay detalles sobre la conexión, automáticamente se trata como si fuera un Quick Tunnel en este caso.

Después el worker recibe esa solicitud y genera un subdominio aleatorio y se lo notifica al demonio Cloudflare D.

Nos cuenta aquí también que para hacer la limpieza de los túneles que no están en uso, también utiliza otra tecnología que es Workers Ground Triggers.

Y nos deja aquí un enlace para el blog donde se detalla sobre ellos, si lo gustan revisar.

Y bueno, nos cuenta también que en este caso todos estos túneles se encuentran disponibles públicamente, entonces si alguien conoce la dirección aleatoria que se le asignó, pues puede acceder al servicio.

Pero bueno, obviamente pueden agregar con Cloudflare Teams, pueden agregar protección para políticas de cero confianza en este caso.

Bueno, nos dice acá que esto obviamente genera una experiencia más sencilla para los usuarios.

También nos cuenta que esta nueva versión de Quick Tunnels utiliza la última arquitectura de túneles que es Name Tunnels.

Aquí también tenemos un enlace al blog correspondiente. Y bueno, que los túneles ahora son mucho más resilientes en este caso, duran, como mencioné aquí, hasta meses en algunos casos.

Y bueno, nos cuenta un poco de lo que se espera que ocurra después.

Como ya mencionan, pues son más resilientes, más confiables, no se tiene que crear una cuenta.

Y entonces básicamente invitarlos a probarlo, porque pues teniendo la URL pueden compartirla con sus compañeros o con alguna audiencia o amigos que tengan.

Y también nos invita a discutir su blog.

Tenemos aquí enlaces a Reddit, Hacker News y Twitter en donde pueden ponerle sus comentarios a Richard.

Continuamos con otro blog de nuestro colega Chris, que nos cuenta un poco sobre la siguiente generación de servidores de borde de Cloudflare.

Esta es la onceava generación, utilizando Milan.

Bueno, nos cuenta aquí Chris un poco de su historia de cuando se unió a Cloudflare en 2014.

Él estaba como parte del equipo de SRE. Y bueno, nos cuenta que como parte de esa evolución, ahora él está trabajando con el equipo de ingeniería de hardware.

Que bueno, como menciona el departamento, no existía cuando él se unió.

Entonces también es parte como de la evolución que ha habido.

Nos cuenta aquí que la plataforma de servidores se renueva de entre 12 a 18 meses.

Obviamente para mantenerse al día con las últimas tecnologías.

Nos cuenta aquí y nos deja enlaces a los anuncios de las generaciones anteriores.

Tenemos la 10 que se anunció en febrero de 2020 y la 9 que se anunció en octubre de 2018.

Y bueno, nos cuenta que este paso de innovaciones o iteraciones es el adecuado porque permite estar al tanto de cambios en las últimas tecnologías.

Nos sigue platicando un poco que una de las cosas más importantes que se buscan al diseñar hardware es el reducir el consumo de energía.

Bueno, para el planeta y nos permite hacer un uso más eficiente de los racks y de la capacidad física que se tiene en los centros de datos de Cloudflare.

Nos cuenta que utilizan estos servidores las arquitecturas de ARM, conocida como Ampere.

Y nos deja aquí el enlace a otro blog en donde se detalla esta arquitectura.

Y nos cuenta aquí los servidores que se, perdón, los chips que se evaluaron en este caso.

Nos cuenta que se probaron con 48, 56 y 164 cores utilizando la tercera generación de Epic de ARM.

Aquí vemos una foto del chip. Y después nos cuenta un poco cómo fue el proceso de pruebas y validación.

Nos cuenta que se hizo cargas sintéticas y nos deja aquí el enlace al GitHub del sistema para hacer los benchmarks que se utiliza.

Ahí está el código disponible por si lo quieren revisar.

Y bueno, acá vemos un poco más de imágenes de cómo está ya montado uno de los servers.

Y nos cuenta el procesador que se utilizaba anteriormente.

Vemos ahí que anteriormente era de 48 cores y ahora en el siguiente modelo se usa el de 64 cores.

Y nos deja aquí una tabla comparativa de los distintos CPUs.

Nos cuenta que en este caso hay 33% más cores en la nueva generación.

Y también una mejora en el desempeño de 29%.

Contra el anterior. Nos muestra aquí, en cuanto a memoria RAM, también se aumentó de 256 GB a 384 GB.

Y también se aumenta la especificación de DDR4 ahí.

Bueno, también nos cuenta un poco de lo que se hizo para monitorear el desempeño de estos.

Y nos deja también enlaces de otros anuncios que se hicieron en la Semana de la Seguridad y en la Semana de Desarrolladores.

Por si gustan revisar esos blogs.

Tenemos aquí el cambio en los discos.

Como pueden ver. Y después tenemos algunas gráficas de cómo se mejora el desempeño con estos cambios.

Como podemos ver ahí, en azul tenemos la nueva generación.

Y obviamente en barras más altas es mejor desempeño.

Nos cuenta que encuentro a las tarjetas de red.

Bueno, en estas no hubo cambio, porque se considera que todavía estas son suficientemente performantes para seguir utilizándolas en la siguiente generación.

Nos cuenta también cómo se utiliza Firmware Open Source.

Y algunos de los beneficios que esto trae para la operación.

Y finalmente vemos aquí ya un servidor completamente montado.

Y nos cuenta un poco cómo han sido los cambios en las distintas generaciones.

De la 9 a la 10 y ahora a la 11.

Y deja aquí algunos agradecimientos por los colegas con los que estuve trabajando en este proyecto.

Y también obviamente nos dice que si alguno de ustedes está interesado en trabajar con hardware de última generación como el que se detalla en este blog.

Así como en Firmware de código abierto.

Pues pueden aplicar para unirse al equipo y ayudar a construir la generación siguiente de estos servidores.

Les dejo ahí un enlace por si gustan visitarlo.

Seguimos ahora con un blog de nuestro colega Ashcon.

Que nos cuenta sobre la introducción de los logs en el dashboard para Cloudflare Workers.

Bueno, y nos deja aquí un poco con una broma a Ashcon de que si estás escribiendo código, lo que puede salir mal, saldrá mal.

Y bueno, nos cuenta también la clásica historia de que funcionó en mis test locales, funcionó en staging, pero ahora no funciona en producción.

¿Pero por qué? Y bueno, obviamente dice que puedes hacer pruebas, puedes reducir los errores.

Y hacer debugging puede ayudarlos a encontrarlos.

Pero obviamente los logs siempre son primordiales para poder entender o mejorar alguna solución.

Sobre todo cuando está ocurriendo alguna incidencia que tenemos que resolver.

Y bueno, nos cuenta que ahí el login ayuda para cuando lo imposible ha sucedido y nos encontramos en una situación de error.

Y bueno, nos muestra aquí. Me parece que este es un video.

Nos muestra aquí este video cómo encontrar los logs en el dashboard de Cloudflare.

Vemos ahí que está recuperando los logs y después podemos ver directamente en el dashboard lo que está ocurriendo con ellos.

Podemos limpiar los logs y también se puede hacer un filtrado por errores, etc.

Nos cuenta aquí que esta lista de logs contiene excepciones y los encabezados que generan el request de HTTP.

También nos indica que hay una redacción automática de cuestiones sensitivas en las URLs o en los encabezados.

Como vemos ahí las cookies o las autorizaciones o cosas que se considera que tienen algún nombre sensible pues se redactan automáticamente.

También nos deja aquí un enlace a los objetos durables.

El beta que está abierto por si quieren participar. Ahí está un link que pueden hacer clic para registrarse en la beta.

Y también se hace un debugging de objetos durables con estos logs.

También nos dice que como ya veíamos en el video se tiene soporte para hacer el filtrado ya sea por el estado o el tipo.

Y también nos sigue contando que también está la herramienta de línea de comandos que es Wrangler.

En donde también se pueden ver en la línea de comandos.

Nos cuenta aquí un poco del código que se puede utilizar para hacer este login en la consola.

Nos cuenta que se pueden enviar e inclusive pasar objetos que se van a interpretar como JSON en este caso.

También nos cuenta aquí lo que decíamos sobre Wrangler.

Que también nos deja un enlace al GitHub de Wrangler en este caso para que lo puedan descargar en GitHub.

Y también nos cuenta de la actualización que se hizo en el subcomando tail de esta herramienta Wrangler.

Vemos aquí algunos ejemplos que se pueden filtrar por la IP.

Y cuando hubo alguna excepción también se puede hacer sampling.

Como vemos con este parámetro. Y también se pueden hacer búsquedas genéricas utilizando el parámetro de search.

Nos cuenta que se utiliza un formato muy fácil de leer con el formato pretty que vemos ahí.

Y aquí nos deja un pequeño video donde se están recuperando los logs de un GET en este formato.

Y ahí vemos un poco el error que aparece. Finalmente nos invita a probarlo.

Ya sea que utilizamos Wrangler Layer Tail o que vayamos directamente en el dashboard de Cloudflare a buscar los logs directamente.

Y nos deja aquí también un enlace a la página de desarrolladores en Cloudflare en donde podemos ver más información sobre esta característica.

Bueno, seguimos. Tenemos ahora un blog de nuestro colega Adam.

Un saludo a Adam. Que nos cuenta sobre PIN y ONPIN y un poco de las necesidades de utilizar esto en Rust.

Vemos aquí que Adam nos explica un poco lo que son los futuros en el caso de Rust.

Y bueno, él va en una explicación súper detallada.

No le voy a hacer justicia a este blog porque en Rust realmente solo he hecho el Hello World en una ocasión.

Y más bien los invito, si son programadores en Rust, a revisar este blog a detalle porque Adam va muy, muy a fondo en todo lo que es PIN y ONPIN y nos explica, como vemos aquí, la parte de las referencias.

Qué se hacen en Rust. Es muy, muy interesante el blog de Adam.

Invitarlos, como ya decía, si tienen un interés en Rust o tienen alguna pregunta sobre el uso de futuros en el lenguaje, pues aquí está el blog de Twitter.

Perdón, el blog en el blog de Cloudflare y también creo que estaba en el blog personal de Adam.

Así como les deja un enlace a su cuenta de Twitter en caso de que tengan más preguntas sobre este.

Y también, bueno, nos cuenta que su equipo está también contratando en este caso, de que si ustedes tienen interés en Rust o en protocolos de red, pues aplicar ahí para ponerse en contacto y ser parte del equipo en el que Adam trabaja.

También nos deja bastantes referencias a la documentación. Nos deja un enlace al GitHub donde tiene el código de ejemplo.

Un enlace a la presentación donde habló de este tema en el Meetup de Rust de la zona de La Bahía.

Y bastantes otros enlaces a otros blogs y a otros Twitters de personas que lo apoyaron en esta cosa.

Y también nos deja algunos agradecimientos para Nick. Un saludo a Nick Ballmer.

Que le ayudaron en la edición de este blog. Seguimos con otro blog de Mayer, que nos cuenta también de otro proyecto de un interno que trabajó en mejorar los chequeos de salud de Magic Transit y cómo hacerlos más responsivos.

Vemos aquí que, bueno, un poco en un diagrama nos cuenta cómo algunas rutas pueden estar bien, pero algunas otras pueden tener problemas cuando la red de Cloudflare trata de acceder a los servidores de los clientes.

Y nos cuenta un poco cómo funcionaban estas revisiones de salud anteriormente.

Nos cuenta que en un principio no se compartía nada, que básicamente cada servidor tenía que hacer todos los chequeos.

Y, bueno, nos hace un poco la comparativa como en esto del clima.

Que si para mí está lloviendo, puede ser que para la siguiente persona que no le caen gotas de agua, pues sea un día soleado.

Y, bueno, esto tenía una respuesta lenta en el caso de que hubiera lo que él describe como una tormenta.

Entonces ahora la mejora es que todas las estaciones meteorológicas cercanas comparten información.

Nos cuenta aquí que esto se logra con una tecnología de multicast.

Aquí vemos un poco un diagrama. El router envía la información y solo uno de los servers se comunica de vuelta.

Y, bueno, hace el símil de que esto es como cuando te suscribes a una lista de correo que todos los que están suscritos reciben ese mensaje.

Y, bueno, nos cuenta aquí que utilizó una tecnología que se llama Consistent Hashing para distribuir ese concepto de computación distribuida que se utilizó para este proyecto que hizo en el verano.

Y, bueno, finalmente nos cuenta los resultados que obtuvo.

Vemos aquí que se hizo una reducción importante en el uso de memoria de más del 70% y casi 85%.

Vemos ahí un poco la gráfica.

Y después tenemos también en el uso de CPU vemos una importante reducción.

Y, finalmente, nos deja aquí un enlace.

Bueno, que Magic Transit está por cumplir dos años y, bueno, esta es parte de las mejoras que se están haciendo.

Y nos invita a unirnos a su equipo.

Tenemos un par de minutos. Vamos a revisar si tenemos alguna pregunta.

Al parecer no ha llegado ninguna. Vamos a revisar ahora un poco de la red social Twitter de Cloudflare.

Vemos aquí una presentación o un webinar que van a tener de Waiting Room para cómo mejorar la experiencia de sus usuarios cuando están esperando en alguno de sus sitios web.

También tenemos aquí una sesión que hubo sobre el equipo de Europa de Mujeres en Ventas.

Tenemos ahí. Tenemos el Twitter del blog de Rishabh que ya revisamos.

Y también vemos aquí otro webinar sobre lecciones de ciberseguridad.

Tenemos un caso de éxito de Easy Cater con la solución de Zero Trust de Cloudflare.

Y, bueno, también veíamos ahí otro webinar que estaba sobre cómo asegurar APIs con Cloudflare.

Y, bueno, con esto me despido de ustedes y les agradezco por haberse sintonizado.

Y les invito a sintonizarse dentro de dos semanas. Que tengan un excelente día y un excelente fin de semana.

Hasta luego.