Canarios en el CloudFront

Rate this content
Bookmark
Slides

* introducción a la arquitectura de aplicaciones de base de datos (gateway + backend, aplicación de React de múltiples módulos + biblioteca de componentes, etc.)
* Profundización en el pipeline de CI/CD para construir y publicar la biblioteca de componentes, implementar aplicaciones antes de los canarios (rama, dev, staging, prod), rol de Lambda@Edge
* Nota adicional: aplicaciones de múltiples módulos, habilitando el nivel adecuado de modularidad, y B2B SaaS vs B2C
* Primer problema de los canarios: ejecutar una regresión completa de FE contra el backend estable (candidato a lanzamiento) temprano y frecuentemente, antes de que se corten los candidatos a lanzamiento de FE
* Segundo problema de los canarios: ejecutar una regresión puntual de FE aún más temprano, antes de que se fusionen las MR
* Tercera pregunta de los canarios: ¿cómo se ve esto en producción? Una vez más, B2B SaaS vs B2C
* ¡Resultado final: Canarios en el CloudFront!

12 min
06 Jun, 2023

Video Summary and Transcription

La charla de hoy aborda el diseño de sistemas de CI/CD frontend, la integración de CDNs y el impacto del tipo de negocio en los equipos frontend. El orador comparte su experiencia con la integración de CDNs y su impacto en su estrategia de CI/CD. Se discuten las versiones canary y los desafíos de implementar despliegues canary en producción. Además, se destaca la importancia de las pruebas de integración para el shift left y la detección de problemas antes de fusionar en la rama de desarrollo.

Available in English

1. Introducción a los Canarios en la Nube Frontal

Short description:

Hoy hablaré sobre el diseño de sistemas CI/CD frontend para un desarrollo más rápido y menos arriesgado. También discutiré la importancia de considerar su red de entrega de contenido en la arquitectura de su aplicación. Por último, exploraré cómo el tipo de negocio y el mercado objetivo pueden afectar el enfoque de shift left de sus equipos frontend.

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.

2. Introducción a la Integración de CDN y Estrategia CI/CD

Short description:

Soy VP de desarrollo de aplicaciones en Demandbase con más de 20 años de experiencia. Introdujimos un CDN en nuestra arquitectura, aprovechando CloudFront para el almacenamiento en caché en el borde. Esto afectó nuestra estrategia CI/CD, ya que necesitábamos invalidar la caché con cada nueva compilación. Nuestro sistema CI/CD incluye entornos de desarrollo y puesta en escena, pruebas de integración de Selenium y GitLab para análisis, verificaciones de seguridad y pruebas unitarias. Seguimos un proceso de rama de lanzamiento semanal, implementando en puesta en escena para pruebas antes de pasar a producción. Para facilitar la revisión de ramas, creamos un pipeline de GitLab que ejecuta verificaciones, análisis y pruebas, y envía la aplicación al origen de puesta en escena. También introdujimos Lambda en el borde para la reescritura de ramas. Esta integración con GitLab permite a los diseñadores y PM revisar fácilmente los cambios de rama.

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.

3. Canary Releases and Shifting Left

Short description:

Nuestro pipeline de GitLab admite lanzamientos canary de la última versión en desarrollo al entorno de puesta en escena. Utilizamos un esquema de cookies y gestión de flags de características para permitir a los desarrolladores cambiar fácilmente entre la versión actual y la versión canary. Sin embargo, la implementación del canary en producción es complicada debido a la necesidad de evitar diferentes versiones de la aplicación para usuarios dentro del mismo cliente. Tenemos una gran cantidad de usuarios internos y sus flujos de trabajo son críticos para la misión. Como resultado, decidimos centrarnos en pruebas de integración dirigidas contra nuestros empleados en ramas.

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`.

4. Shift Left and Integration Testing

Short description:

Nos dimos cuenta de que ejecutar pruebas de integración contra nuestros empleados en ramas era esencial para el shift left. Nuestras suites de pruebas existentes eran lentas, costosas y requerían datos y backend estables. Sin embargo, ejecutar estas suites todas las noches contra la última versión en desarrollo no era suficiente, ya que ya era demasiado tarde para identificar problemas. Queríamos detectar problemas en la solicitud de fusión antes de que llegara a la rama de desarrollo.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.

Workshops on related topic

JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
GraphQL Galaxy 2021GraphQL Galaxy 2021
161 min
Full Stack GraphQL In The Cloud With Neo4j Aura, Next.js, & Vercel
WorkshopFree
In this workshop we will build and deploy a full stack GraphQL application using Next.js, Neo4j, and Vercel. Using a knowledge graph of news articles we will first build a GraphQL API using Next.js API routes and the Neo4j GraphQL Library. Next, we focus on the front-end, exploring how to use GraphQL for data fetching with a Next.js application. Lastly, we explore how to add personalization and content recommendation in our GraphQL API to serve relevant articles to our users, then deploy our application to the cloud using Vercel and Neo4j Aura.

Table of contents:
- Next.js overview and getting started with Next.js
- API Routes with Next.js & building a GraphQL API
- Using the Neo4j GraphQL Library
- Working with Apollo Client and GraphQL data fetching in Next.js
- Deploying with Vercel and Neo4j Aura
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.