Estas semanas en Cloudflare en Español

Hola, bienvenidos a Estas Semanas en Cloudflare en Español. Buenos días, buenas tardes o buenas noches, donde quiera que nos estén sintonizando o volviendo a ver la grabación de este programa. Mi nombre es Alex Mayorga Adame y soy un ingeniero de soporte técnico en la oficina de Cloudflare en Austin. Para los que nos sintonizan por primera vez, bueno, en este programa revisamos un poco de las novedades de Cloudflare que han ocurrido en las últimas semanas. Y bueno, vamos a comenzar. Lo primero que vemos es la página de Cloudflare.com diagonal whats -new. Y bueno, aquí tenemos un poco de los últimos anuncios de producto que vamos a revisar. Comenzamos aquí con una novedad que nos cuenta sobre la remoción del header cf-request-id que bueno, como indica acá, está programado para ser retirado el día primero de julio del 2021. Y bueno, como una prueba para la remoción del encabezado, se estará removiendo temporalmente el día 15 de junio, como una prueba. Entonces, recordar, o más bien avisarles que si tenían alguna dependencia de este encabezado por alguna razón, la recomendación que se muestra acá es cambiar a utilizar el header cf-rate. Y bueno, aquí también nos deja un enlace a los anuncios de precauciones que se encuentran en la página de la API de Cloudflare. Avanzamos con el siguiente anuncio que es la disponibilidad general del balanceo de cargas con proximidad. Como nos menciona acá, bueno, load balancing, como ya sabrán, se utiliza para aumentar la resiliencia de las infraestructuras, proveyéndoles la capacidad de dirigir tráfico a distintos servidores. Y bueno, ahora con proximity o el redireccionamiento por proximidad, se tiene la habilidad de colocar coordenadas geográficas para indicar la posición de los centros de datos en donde se encuentran dichos servidores. Y de esta forma, las solicitudes que llegan a Cloudflare son redirigidas al que se encuentre más cercano geográficamente. Tenemos también otro anuncio acá, que es el soporte de Node.js en Cloudflare Workers. Y bueno, como ya sabrán, Cloudflare Workers es la plataforma serverless de Cloudflare y que ahora tiene la capacidad de utilizar Node.js directamente en la plataforma. Y lo cual permitirá a los desarrolladores crear aplicaciones más complejas, como se indica en esta parte. Bueno, la siguiente sección que revisamos es el blog de Cloudflare, el cual lo pueden encontrar en el sitio de blog.Cloudflare.com. Y también, bueno, si no quieren esperar a las emisiones del programa, pueden colocar su correo electrónico en este espacio y haciendo clic en el botón de suscripción, pueden recibir directamente a su correo electrónico todos los blogs que vamos a revisar el día de hoy. Vamos a comenzar con este blog de nuestro colega Cristian. Un saludo a Cristian, que él trabaja en el equipo de Workers. Y nos tiene un blog en donde nos cuenta cómo construir juegos en tiempo real utilizando Workers, objetos durables y la plataforma de Unity para desarrollo de juegos. Bueno, acá nos cuenta sobre la inclusión de objetos durables en el ecosistema de Workers, lo que nos permite tener consistencia en las aplicaciones. Y también nos cuenta acá sobre el anuncio de la inclusión de WebSockets, que ahora también funcionan junto con objetos durables. Y nos cuenta cómo esto le facilitó empezar a construir algo con lo que ha estado trabajando últimamente que son videojuegos. Nos cuenta aquí también que utiliza, como ya mencionábamos, la plataforma de Unity. Y vemos aquí que nos pone un tweet en donde nos cuenta cómo estaba probando su juego. Como vemos acá, utiliza Unity, WebGL y WebSockets. Y también utiliza la plataforma de Cloudflare Pages. Y por el lado serverless tiene Workers y tiene objetos durables y WebSockets. Bueno, también nos relata acá y quizá vamos a alcanzar a revisar este otro blog. Recientemente se publicó un blog en donde se hace una demo del juego Doom en Workers. También vamos a revisarlo por ahí. Y bueno, aquí vemos un poco el modelo de cómo funciona esta situación en el lado de los clientes. Que envían sus entradas por el lado del serverless, se reciben las entradas, se actualiza el estado del juego y cada uno de los clientes está continuamente en un ciclo actualizando la entrada de los otros participantes. Y obviamente en el servidor se está continuamente actualizando el estado del juego. Nos cuenta un poco acá más a detalle sobre el objeto durable del personaje en este caso. Vemos aquí el código con el que implementa esta parte. Y nos cuenta también que esto está disponible en el... Hay un template de WebSockets que podemos acceder aquí. Y básicamente está revisando que haya un encabezado de upgrade para iniciar el WebSocket. Después nos cuenta que tiene una función para manejar la sesión donde realiza la mayor parte de la lógica del juego. Aquí vemos un poco más del código. Y después nos cuenta cómo maneja la posición de los jugadores en los objetos durables en Unity. Y acá nos cuenta que en general todos los juegos en 3D utilizan este tipo de situaciones. También vemos un modelo del mundo que utiliza el juego. Ahí vemos por ejemplo el personaje en el punto donde va a iniciar. Y un poco cómo está todo esto funcionando con los WebSockets. Es un blog muy interesante de Christian. Y nos deja para finalizar el enlace al GitHub y también al Discord de Cloudflare Workers. Si quieren o tienen algún proyecto similar a este pueden por ahí platicar en Discord con Christian directamente. Siguiendo con el blog tenemos una entrada de Otto. Un saludo a Otto. Que nos presenta el lanzamiento del Centro de Operaciones de Seguridad como servicio de Cloudflare. Aquí Otto nos cuenta que obviamente una de las partes que Cloudflare ha intentado hacer es siempre democratizar y hacer más disponibles cuestiones como seguridad. Para que esto sea disponible no solo a organizaciones grandes o que tienen muchos recursos. Y nos cuenta ahora la parte, como siempre ya sabemos, la misión de Cloudflare que es tratar de ayudar a construir un mejor Internet. Y que siempre intentamos que nuestros servicios sean accesibles y con un buen costo-beneficio. Nos cuenta aquí, bueno, que muchas organizaciones nos comentan que tienen mucho amor por nuestros productos, por su simplicidad de uso y cómo los ayudan a practicarse en las áreas de ciberseguridad. Y bueno, nos pasa al anuncio que mencionábamos del Centro de Operaciones como servicio que se encuentra ahora generalmente disponible y lo que nos provee, que podemos ver aquí, es el monitoreo en 24-7 para cuestiones de alertas de seguridad y disrupciones operacionales. También puede hacer alertamiento personalizado, realizar análisis e identificar vectores de ataque y obviamente implementar contramedidas y mitigar los incidentes que estos ataques puedan funcionar o ocasionar. Nos cuenta aquí un poco de las razones por las cuales se decidió construir esta oferta. Y bueno, el objetivo principal es ofrecerle a los clientes un servicio de monitoreo y mitigación de ataques que ellos pueden aplicar en capa 3 y capa 7. Más bien dicho, de la capa 3 a la capa 7. Nos muestra aquí un poco el diagrama de lo que ya mencionábamos las funcionalidades de reportar, de monitorear, alertar, investigar y responder. Nos dice que se monitorea, como ya decíamos, 24-7. Si se encuentran anomalías en este caso, se hace el alertamiento y obviamente los ingenieros empiezan a investigar los vectores de los ataques e indicar recomendaciones para actualizar configuraciones o algunas otras soluciones que se pudieran aplicar. Y también se hace la mitigación inmediatamente de estas situaciones con planes que los clientes ya hayan predeterminado para estos casos. Y finalmente se hacen los reportes que convengan en la cadencia que el cliente haya determinado. Y bueno, nos cuenta aquí un poco por qué esta solución sería más efectiva. Se hace un monitoreo del tráfico de los clientes, lo que hace que no sea necesario configurar algunos parámetros para que se hagan las detecciones, sino que se monitorea por un tiempo lo que representa el tráfico normal para una organización y después en base a eso se hace el alertamiento y todas las operaciones. También reduciendo los falsos positivos y tratando de reducir la fatiga de alertas al enviar menos alertas que no sean relevantes. Y también, como mencioné acá, se utiliza un acercamiento holístico a todas las potenciales brechas de seguridad que puedan existir. Y bueno, nos sigue contando acá cómo se está trabajando con partners para ofrecer esta funcionalidad. Nos lista aquí algunos de los partners iniciales que vemos aquí sus logotipos. Tenemos a Wipro, a GlobalDots, Insights Technology y BeyondID, que son los partners iniciales para el lanzamiento de esta oferta. Y nos deja aquí un enlace si desean obtener este servicio aquí en correo electrónico para que puedan ponerse en contacto y saber un poco más sobre esta oferta del Centro de Operaciones de Seguridad como servicio. Seguimos con un blog de nuestros colegas Alex y Seidon que nos cuentan un poco de un nuevo header o encabezado de HTTP que es el encabezado cdn-cache-control. Y lo que esto hace es ofrecernos más precisión para el control de CDNs. Vamos a ver aquí un poco lo que nos cuentan Alex y Seidon sobre esto. Bueno, nos cuenta aquí que ellos están muy emocionados de anunciar el soporte de este nuevo encabezado de HTTP ya que provee un control más preciso de lo que se estará guardando en los cachés de CDNs, incluido Cloudflare. Y bueno, nos cuenta que esto es como una evolución del encabezado existente cache-control. Y también nos cuenta cómo se relaciona con otros encabezados como s-max-age y también con otros como stale-while-revalidate. Tenemos aquí que nos cuenta un ejemplo que en algún sitio puede tener un caché directamente en su origen y también puede tener un distinto caché para la CDN. Pero nos cuenta aquí que un problema puede ser que no todos interpreten el encabezado de la misma manera y esto podría generar problemas. Tenemos por ejemplo aquí el caché con max-age en el origen y después el s-max-age que lo tomaría la CDN en este caso de 6000. Y finalmente lo que despliega directamente el navegador. Nos cuenta acá que este encabezado se desarrolló como una solución estándar de la industria con la IETF. Y nos dice un poco más sobre este encabezado. Nos cuenta un poco sobre cómo es la precedencia de los encabezados. Aquí nos cuenta que con este encabezado que ya mencionábamos, Cloudflare evalúa el encabezado para tomar decisiones de lo que se almacena en caché. Y bueno, también hay uno específico para Cloudflare. Agregando Cloudflare antes del encabezado, este será solamente mantenido en Cloudflare y no se reenviaría a otras CDNs como en el caso anterior. Que menciona aquí, se enviaría en caso de que haya CDNs después de Cloudflare. Otra opción es obviamente enviar los dos encabezados. Y aquí vemos un poco una tabla de cómo aplicaría esto. El cache control aplica en el cache del servidor de origen. Si es que se tiene alguno en la red inicial. Si hubiera alguna CDN antes de Cloudflare, esta escucharía por este otro encabezado, CDN. Y también Cloudflare, en este caso, escucha tanto por el Cloudflare específico, como por el CDN cache control. Y si hubiera CDNs, más CDNs después, se puede aplicar también este y en el navegador como tal, va a respetar el cache control. Nos cuenta un poco aquí con la interacción en page rules y cómo esto funciona en este caso. Y después nos da algunos ejemplos. Por ejemplo, aquí tenemos el de Acme Corporation, en donde vemos cómo se utilizan estos encabezados en este caso. Y aquí, bueno, lo vemos gráficamente. En este caso tenemos el cache control con max -age. Y es max-age. Y después tenemos el específico de Cloudflare, que en este caso se aplica aquí. Y tenemos otro para el resto de CDNs, que se aplica en caso de que hubiera otras CDNs en este caso. Vemos acá otro de Industrias ABC, en donde podemos ver también los encabezados en este caso. Que se tiene también en este caso el encabezado stale, stale-if-error, que está establecido a 400 en este caso. Y también en este caso hay stale-if-error para los distintos CDN cache control. Aquí vemos un poco el diagrama de cómo esto afecta los stales. Y bueno, en este caso nos invita a comenzar a utilizar estos nuevos encabezados, si somos los usuarios finales. Y también invita a otros proveedores de CDN para que comiencen a iniciar el soporte del encabezado CDN -cache-control. Después tenemos un blog de Martin, este me parece, si mal no recuerdo, es un blog de un invitado, en este caso Martin, que es un ingeniero de DevOps en Labyrinth Labs. Y nos cuenta un poco cómo hacer el monitoreo de Cloudflare Analytics, utilizando herramientas como Grafana y Prometheus en este caso. Nos cuenta un poco aquí cómo se hace el diseño de esta solución. Nos enlaza aquí a la API de Cloudflare Engo, donde se utiliza, en este caso, para hacer la analítica con GraphQL. Nos menciona aquí el grupo que va a estar utilizando, en este caso de la API. Y nos enlaza nuevamente también aquí a la descripción específica de los datasets. Vemos aquí un poco cómo está la arquitectura que se va a utilizar. Como vemos acá, se va a estar utilizando la visualización en Grafana, obteniendo vía Thanos en Prometheus la información de la API de Cloudflare. Y también nos muestra que va a estar aquí alertando, ya sea a través de Slack o de VectorOps. Nos deja aquí la imagen de Docker para comenzar a utilizar esta solución. Y vemos aquí un poco el código que está exponiendo estas métricas. Nos indica que la configuración es sencilla, simplemente se tiene que colocar nuestro correo electrónico de la API de Cloudflare, así como la llave del mismo, para comenzar a utilizar la solución. Y nos muestra aquí un poco cómo se visualizan estos datos, ya en los paneles de Grafana que vemos aquí. Y después nos cuenta un poco de los planes a futuro que se tienen para esta solución. Agregar nuevas métricas, agregar, por ejemplo, para la parte analítica de Firewall, o de ataques de denegación de servicio. Y nos deja un enlace a LabyrinthLibs, que es una compañía que generalmente ayuda a organizaciones que quieren desarrollar o desplegar este tipo de soluciones. Entonces, invitarles a leer este blog si quieren hacer el monitoreo de la analítica de Cloudflare, ya sea en Prometheus y en Grafana. Seguimos con un blog de Celso, Bob Gia Celso, en Portugal. Y tenemos aquí un poco de lo que mencionaba Cristian, sobre el juego de Doom en multiplayer en Cloudflare Workers. Bueno, nos cuenta aquí que esta idea original fue de John Braham Cumming, nuestro CTO en Cloudflare. Y bueno, ¿qué pasaría si hacemos un port multiplayer de Doom en la red de borde de Cloudflare? Y bueno, nos cuenta que obviamente eso fue algo que lo motivó para sacar su lado nerd y comenzar a trabajar en esto. Vemos aquí un poco lo que se tuvo que trabajar en este caso para que funcionara este juego. Vemos aquí un poco los beneficios en este caso de utilizar la red de Cloudflare para este proyecto. Y nos cuenta un poco la historia de Doom, un poco sobre John Carmack cuando creó el juego. Y nos deja aquí un enlace, bueno, por si quieren jugar con sus amigos o invitarlos a jugar, tenemos ese sitio, silentspacemarine.com Y nos da un poco de la información de cómo esto está funcionando. Vemos aquí una captura de pantalla del juego de Doom. Nos cuenta aquí en este caso que no hay main loop, tampoco se utiliza UDP. Y un poco la arquitectura en este caso del WebSocket. También hay aquí algo del código que nos deja Celso en este caso. Y nos detalla aquí un poco el ruteador de mensajes, lo que está haciendo. Básicamente acepta las conexiones y hace un ruteo en la tabla donde se originan las conexiones. Y recibe los mensajes y los reemite a los clientes que necesiten esas actualizaciones. Muy detallado el blog de Celso, entonces invitarlos a visitarlo o simplemente si desean jugar, para que se conecten directamente ahí y puedan jugar con sus amigos. Nos cuenta aquí un poco de cómo implementó el sitio utilizando Cloudflare Pages. Nos cuenta que hay un WebAssembly de Doom y también como ajusta para la entrada del cliente. Y bueno finalmente si tienen esas ganas de regresar al mundo noventero y jugar un poco de Doom, pues aquí nos recuerda nuevamente el sitio. Aquí vemos un pequeño video de cómo está cargando el juego. Y bueno, invitarlos para jugar un poco con sus amigos en este caso. El demo ahí está. Y nos deja como siempre los enlaces a los GitHub correspondientes. Tenemos el WebAssembly de Doom y un poco el roteador de mensajes que ya mencionábamos, que obviamente lo pueden descargar y empezar a utilizar. Bueno, siguiendo con nuestro programa, lo que hacemos al final es revisar un poco la red social Twitter de Cloudflare. Tenemos aquí un tweet en donde nuestra co-founder Michelle habla en un podcast sobre cómo hacer escalamiento con resiliencia. Después invitarlos a ver Cloudflare TV, continuar viendo Cloudflare TV. Tenemos el día de las carreras en Cloudflare TV, el día de hoy. Para que estén atentos a mí hay un programa muy completo. Después tenemos un webinar al que se pueden registrar para modernizar el manejo de datos de sus clientes. También tenemos acá una invitación para registrarse a Cloudflare Connect. Ya está disponible el registro, aquí está el enlace, Cloudflare.com, diagonal connect. Donde habrá presentaciones y invitados que estarán hablando sobre demos interactivas. Después tenemos un caso de un cliente, que en este caso se trata de ProPublica, que nos cuenta cómo utilizan Cloudflare Workers para mejorar el caché de sus sitios. Tenemos aquí el tweet que corresponde a CDN Cache Control, que ya revisábamos en el blog. Otro tweet que vemos aquí sobre el día de las carreras en Cloudflare. Con esto agradecerles que se hayan sintonizado e invitarlos a la siguiente emisión. Que tengan un excelente día.