Canarios en el CloudFront

Hola a todos. Gracias por unirse. Mi nombre es Vijay Ramesh. Soy VP de desarrollo de aplicaciones en Demandbase. Y hoy quiero hablarles un poco sobre lo que me gusta llamar canarios en la nube frontal.

Antes de comenzar, solo tenemos unos 10 minutos hoy y eso no es mucho tiempo. Pero de alguna manera lo es. Hay mucho contenido por ahí. Hay muchas cosas que aprender, muchas cosas en las que profundizar y no tanto tiempo en un día determinado. Así que permítanme ir al grano primero y hablar un poco sobre lo que aprenderán si pasan los próximos nueve minutos y medio aquí escuchando mi charla.

En primer lugar, quiero hablar sobre lo que significa diseñar sus sistemas CI/CD frontend de manera que permita a sus equipos moverse más rápido con menos riesgo. Y como parte de esto, ¿qué significa pensar en su red de entrega de contenido como parte integral de la arquitectura de su aplicación? Y finalmente, quiero tocar un poco cómo el tipo de negocio que dirige, el tipo de producto que fabrica, el tipo de clientes y mercado que atiende, cómo eso puede ayudar a determinar lo que shift left podría significar para sus equipos frontend.

Y brevemente, como dije, soy VP de desarrollo de aplicaciones en Demandbase. Con más de 20 años de experiencia, me he enfocado en construir aplicaciones ricas sobre grandes plataformas de datos y aprendizaje automático. Actualmente, lidero tres de nuestros grupos de ingeniería de aplicaciones.

Antes de comenzar, retrocedamos un paso y veamos un diagrama de arquitectura que puede resultar familiar para aquellos que llevan mucho tiempo en esto, ¿verdad? En los días previos a los CDN, e incluso en los días previos a las aplicaciones de una sola página, era común tener un sistema monolítico como una aplicación Rails, que era atendida por un balanceador de carga, y las solicitudes de un cliente web llegaban al balanceador de carga y se dirigían al backend, que servía su propio frontend. Avancemos un paso más e introduzcamos un CDN, ¿de acuerdo? En Demandbase utilizamos AWS, por lo que utilizamos CloudFront, ¿y qué obtenemos al introducir un CDN como este? Creo que el mayor beneficio es la caché en el borde. Si Demandbase está construyendo su aplicación React y la almacena en la región este de EE. UU., digamos en Virginia, mientras tanto, como usuario que se encuentra en Berkeley, California, quiero poder obtener esos activos estáticos desde una caché en el borde que esté cerca de mi ubicación, y CloudFront permite esto de manera nativa, por lo que como usuario que llega desde California, accederé a la caché en el borde en la región oeste de EE. UU. Tal vez ya tengamos la última compilación allí, por lo que ni siquiera necesito acceder al origen, o en caso de que necesite hacerlo, el origen actualizará la caché en el borde para que el siguiente usuario, por ejemplo, desde San Francisco, obtenga la aplicación completa. Aquí es donde debemos empezar a pensar en cómo la introducción de esta tecnología CDN afecta a nuestra estrategia de CI/CD. En este caso, debemos asegurarnos de invalidar la caché al implementar nuevas compilaciones, para que un usuario que llegue desde una de estas ubicaciones de la costa oeste pueda obtener la última compilación. También hablemos un poco sobre los requisitos previos para el sistema CI/CD con el que comenzamos cuando realmente queríamos implementar el enfoque shift left. En primer lugar, tenemos entornos de desarrollo y puesta en escena, entornos completos de preproducción, y una forma de que un desarrollador ejecute la aplicación frontend completa localmente, pero interactuando con el backend de puesta en escena o desarrollo. En segundo lugar, tenemos una amplia suite de pruebas de integración de Selenium, y estas pruebas solo se ejecutarán realmente en el entorno de puesta en escena, debido a la dependencia general de un backend estable. En el entorno de desarrollo, los equipos de backend pueden probar ramas de funciones y cosas por el estilo, y también debido a la dependencia general de una cierta calidad y volumen de datos que solo están disponibles en nuestro entorno de puesta en escena. Luego, tenemos un sistema CI/CD. Como mostré, estamos utilizando GitLab aquí. Pero imagina un sistema que pueda ejecutar análisis, verificaciones de seguridad, todas las cosas de lint que necesites hacer, y también ejecutar todas tus pruebas unitarias cuando un desarrollador realiza un conjunto de cambios en tu rama de desarrollo. En Demandbase, hacemos una rama de lanzamiento semanal, donde, por ejemplo, cada lunes creamos un candidato de lanzamiento a partir de la rama de desarrollo, lo implementamos en puesta en escena, pasamos martes y miércoles ejecutando una suite de pruebas de integración, regresión, carga, validación manual, y luego implementamos en producción todos los jueves. Con eso en mente, comencemos a implementar el enfoque shift left. Nuestro primer objetivo era permitir que los diseñadores de UX, los PM o incluso otros desarrolladores del equipo pudieran revisar completamente un cambio de rama antes de fusionarlo. Pero, por supuesto, nuestros diseñadores y PM a menudo no saben cómo usar Git. No quieren aprender a usarlo. Incluso para un desarrollador, no queremos que tengas que guardar tus cambios, cambiar a la rama de tus compañeros, cargar eso localmente y todo eso solo para ver qué está sucediendo. Comencemos a implementar el enfoque shift left. Aquí tienes un ejemplo del pipeline de GitLab que creamos. Imagina que tengo mi rama de función y la convierto en una solicitud de extracción a la rama de desarrollo. Como dije, vamos a ejecutar todas estas verificaciones, análisis, pruebas unitarias y todo eso. Pero lo más importante, al final de este proceso, vamos a construir la aplicación completa y enviarla a nuestro origen de puesta en escena, pero en esta ruta específica, directamente a esas ramas y luego a una ruta con nombre. Y para admitir esto desde el lado del CDN, introdujimos Lambda en el borde, que permite que CloudFront ejecute una función sin servidor, ya sea en la solicitud que llega o en la respuesta que sale. Esto nos permitió hacer una simple reescritura de ramas. Entonces, si intento acceder a una implementación de rama específica en CloudFront, Lambda en el borde lo capturará, reescribirá la ruta y cargará el origen adecuado. Y finalmente, esto se integra muy bien con GitLab.

Entonces, nuestros diseñadores, nuestros PM pueden simplemente ver un MR, hacer clic en el botón de ver la aplicación y ya están listos para comenzar. Muy bien. Buen progreso, pero queremos seguir avanzando hacia la izquierda. Y como mencioné, el nombre de la charla es Canarios en CloudFront, así que hablemos de los canarios ahora.

Queríamos admitir lanzamientos canary de nuestra última versión en desarrollo en el entorno de puesta en escena para poder ejecutar todas estas pruebas de integración completas, pruebas de regresión, pruebas de carga, todas esas suites de pruebas antes de cortar una versión de lanzamiento. Nuestro pipeline de GitLab puede admitir esto. Entonces, después de que mis cambios se fusionen en desarrollo, ejecutaremos análisis, ejecutaremos pruebas, construiremos bibliotecas, todo eso. Implementaremos automáticamente la compilación en el entorno de desarrollo, pero también construiremos este paquete canary y lo enviaremos al entorno de puesta en escena nuevamente, en una ruta de canary. Para hacer esto, tuvimos que ser un poco más complejos en la forma en que manejamos esto con Lambda en el borde de nuestro CloudFront, porque queríamos la capacidad de mover a los usuarios de forma automatizada entre la versión canary y la versión actual. Introdujimos un esquema de cookies y lo incorporamos en la clave de caché del borde para que un usuario que solicite web.demandbase.com cargue la versión canary o la versión actual según la presencia de estas cookies. Luego, en nuestra aplicación React, queríamos agregar un poco de flexibilidad en esto. Estamos utilizando launch darkly de manera bastante extensa para la gestión de flags de características en Demandbase. Seguimos haciéndolo aquí. Pero también queríamos agregar un método donde un desarrollador pudiera cambiar fácilmente entre la versión actual y la versión canary. Entonces, el bootstrap de React realiza algunas comprobaciones con respecto a los flags de características, el estado de las cookies y determina si es necesario volver a cargar desde CloudFront, lo que permitirá que la caché del borde verifique esas cookies y cargue la compilación adecuada. Muy bien. Ahora tenemos canarios hasta el entorno de puesta en escena. Los estamos utilizando para probar la compilación antes de cortar una rama de lanzamiento. Entonces, ¿hacia dónde vamos ahora? ¿Cuál es el siguiente paso si queremos seguir avanzando hacia la izquierda? Bueno, en primer lugar, pensamos en implementar este canary en producción. Similar a lo que hacemos para muchos de nuestros servicios backend en Demandbase, esto nos permitiría implementar la compilación verde, ejecutar un subconjunto de tráfico en ella, comprender si funciona correctamente y luego redirigir todo el tráfico. Sin embargo, creo que es importante pensar en quiénes son tus clientes y en qué mercado te encuentras. Demandbase es una empresa de SaaS B2B, ¿verdad? Y en particular, esto se vuelve un poco más complicado porque siempre queremos evitar que múltiples usuarios dentro del mismo cliente experimenten diferentes versiones de la aplicación. Y como dije, utilizamos flags de características en gran medida, pero en su mayoría son específicos del cliente. Es decir, un cliente en particular puede tener una función alfa activada, pero es bastante raro activar cosas para usuarios individuales y hacer que tengan una experiencia diferente a la de otros usuarios en ese mismo cliente. Y finalmente, tenemos esta gran cantidad de usuarios internos, empleados de Demandbase que utilizan nuestra plataforma para el marketing, ventas y publicidad de Demandbase, así como empleados de Demandbase que brindan soporte a nuestros clientes. Al hablar con el equipo de PM y algunos de los equipos de implementación y soporte al cliente, nos dimos cuenta de que estos flujos de trabajo son realmente críticos para la misión. No es un grupo de usuarios adecuado para decirles: `Vamos a implementarlos en una nueva compilación y luego los cambiaremos a todos una vez que estemos satisfechos`.

Entonces pensamos, bueno, ¿hacia dónde deberíamos ir desde aquí? ¿Qué significa shift left en este caso? Para nosotros, esto significaba pruebas de integración dirigidas contra nuestros empleados en ramas. Como mencioné, tenemos estas suites completas de pruebas de integración, carga, regresión, todas estas suites de pruebas y son lentas, algo costosas y requieren datos estables y un backend estable para ejecutarse. Pero ahora, con nuestro shift left inicial, vamos a ejecutar todas esas suites todas las noches contra la última versión en desarrollo. Pero ya es demasiado tarde. Si hay un problema, si hay un error, el código ya se ha confirmado. Lo que realmente nos gustaría es encontrar esos problemas en la solicitud de fusión misma antes de que llegue a la rama de desarrollo. También notamos que los cambios individuales a menudo se dirigen a alguna área funcional específica, lo que nos permitiría ejecutar un subconjunto de las pruebas de integración, ¿verdad? No vamos a tomar las tres horas completas, pero tal vez 15, 20, 30 minutos de un subconjunto de la suite realmente podrían ayudar aquí. Entonces, Lambda en Edge nos permite dirigir nuestras suites de automatización según la demanda, a la compilación canary o a la compilación actual. No fue mucho trabajo decir, vamos a hacer que esto también admita una compilación de rama para ejecutar un subconjunto de las pruebas. Nuestro último paso aquí en el que estamos trabajando activamente es conectar nuestro sistema CI/CD que permitirá a los desarrolladores elegir qué partes de la suite de pruebas de integración quieren ejecutar contra las solicitudes de fusión en la rama antes de enviarlas para su revisión por pares. Eso es todo lo que tengo por hoy, muchas gracias por tomarse el tiempo y unirse. Si echa un vistazo al enlace aquí, Demandbase siempre está contratando desarrolladores front-end y back-end en Estados Unidos e India. Si alguno de estos temas le interesa o desea obtener más información, por favor, eche un vistazo al enlace o contácteme. Muchas gracias y que tenga un buen día.