¿Qué es el despliegue azul-verde?

Un entorno está activo y sirve a los usuarios, etiquetado como “azul” y otro, el entorno “verde”, se utiliza para el despliegue y prueba de una nueva versión. Cuando se aprueba la nueva versión, el tráfico se redirige al instante del entorno azul al entorno verde.

La estrategia fue popularizada y nombrada por Jez Humble y David Farley en su libro seminal de 2010 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

Azul-verde es una técnica de despliegue continuo que permite la eliminación del tiempo de inactividad, la capacidad de emitir reversiones instantáneamente a una versión antigua. Proporciona pruebas A/B sencillas y crea un entorno seguro para el desarrollo sin el riesgo de que los usuarios finales se topen con una versión que no está lista.

Si bien la frase “azul-verde” es la más común, existen variaciones. Netflix emplea el color “rojo/negro”, pero el concepto sigue siendo el mismo. A veces, es posible que los desarrolladores quieran disponer de más de dos entornos. El esquema de nomenclatura de colores es eficaz para diferenciar entre dos entornos. Sin embargo, las organizaciones también pueden utilizar convenciones de nomenclatura como números de versión, identificadores de compilación o títulos personalizados, especialmente si hay más de dos entornos involucrados.

Si bien el concepto es simple, hay varios pasos y variables dentro de esos pasos para crear un despliegue azul-verde estable y seguro que aproveche los beneficios de la estrategia.

La creación de entornos idénticos para el despliegue azul-verde se puede lograr manualmente o mediante herramientas automatizadas. La infraestructura como código, o IaC, es un enfoque automatizado para el aprovisionamiento. La IaC utiliza archivos de configuración legibles por máquina, algo así como un conjunto de instrucciones o una receta para permitir el aprovisionamiento y la configuración automáticos de la infraestructura de TI de acuerdo con especificaciones predefinidas.

La IaC permite a los desarrolladores activar automáticamente una copia del entorno azul, que ya está operativo, para su uso como entorno verde. De este modo, los desarrolladores pueden editar estas plantillas según sea necesario, con la seguridad de que parten de una base confiable. El uso de la IaC ayuda a garantizar una replicación repetible y precisa.

La contenerización, en la que el código de las aplicaciones, las dependencias y las API se empaquetan en una “imagen de contenedor”, es otro enfoque. El uso de contenedores garantiza que todo el entorno sea idéntico. Kubernetes, una plataforma de orquestación de contenedores de código abierto, se utiliza comúnmente para la contenerización en el despliegue azul-verde.

Una vez creados los entornos, la aplicación se despliega en el entorno azul (en producción).

Un equilibrador de carga es un mecanismo, que a menudo se encuentra frente a los entornos de aplicaciones como una herramienta dentro de los proveedores de la nube o entornos de Kubernetes, que dirige el tráfico de producción según se desee. En este escenario, el equilibrador de carga dirige el tráfico al entorno azul en vivo.

Luego, el nuevo código con las actualizaciones de la aplicación se despliega en el entorno de producción verde. Debido a que el equilibrador de carga enruta el tráfico al entorno de producción azul, el verde es un espacio seguro para experimentar, probar y configurar. 

Cuando se complete el proceso de despliegue en el entorno verde, realice todos los pasos de validación necesarios. Estos pasos pueden incluir análisis de seguridad, comprobaciones de rendimiento, búsquedas de errores y mucho más.

Cuando el entorno verde sea validado y aprobado por todos los stakeholders necesarios, actualice el equilibrador de carga para dirigir el tráfico de la versión anterior azul a la nueva versión verde.

Esta transición será instantánea; los usuarios no verán en ningún momento un error ni nada más que los entornos azul o verde.

Las actualizaciones de DNS se pueden utilizar para dirigir a los usuarios al entorno deseado, pero puede haber retrasos significativos a medida que las cachés actualizan la dirección IP. Debido a estas preocupaciones, se prefieren los equilibradores de carga porque las actualizaciones surten efecto de inmediato.

Si bien el paso de validación debería haber detectado la mayoría de los posibles errores o problemas de rendimiento, sigue siendo importante monitorear el entorno verde recién activo. El software y los servicios de analytics pueden ayudar aquí. Comparar la actividad puede indicar si está sucediendo algo inusual.

Si algo sale mal, el tráfico de los usuarios puede redirigirse al entorno azul mientras los desarrolladores solucionan el problema.

El desmantelamiento de un entorno azul en desuso es opcional; algunas organizaciones pueden querer mantener el entorno azul indefinidamente en caso de que el entorno verde deba revertirse en algún momento. Pero también existen posibles razones de costo para desmantelar el entorno azul en algún momento de su ciclo de vida. Alternativamente, el entorno azul puede convertirse en el siguiente entorno experimental o verde.

El pipeline de integración continua/entrega continua es “un flujo de trabajo DevOps automatizado que optimiza el proceso de entrega de software”. Este pipeline facilita la entrega continua de cambios de código en las aplicaciones.

Es una práctica estrechamente integrada con el despliegue azul-verde: CI/CD permite el despliegue azul-verde y los despliegues azul-verde a menudo se integran en los pipelines de CI/CD para ayudar a lanzar actualizaciones de software sin tiempo de inactividad y riesgo reducido.

Los pipelines de CI prueban e integran automáticamente el nuevo código antes de que se integre en el repositorio central, lo que reduce el riesgo de que el código defectuoso llegue al despliegue. Los pipelines de CD aprovechan una estrategia de despliegue azul-verde para optimizar los lanzamientos rápidos sin afectar a los usuarios. El despliegue azul-verde proporciona una disponibilidad casi continua y una reversión segura, lo que desempeña un papel importante en el logro del objetivo general de CI/CD de lanzamientos de código frecuentes y confiables.

Derivado del modismo del canario en la mina de carbón, los despliegues canary son otra forma de reducir el riesgo al desplegar nuevas versiones de software.

Mientras que los despliegues azul/verde crean dos entornos separados, cada uno de los cuales suele alojar todo o nada del tráfico, canary adopta un enfoque diferente. Las versiones canary tienen un solo entorno, que aloja varias versiones.

En un despliegue canary, las nuevas versiones se lanzan primero a un pequeño porcentaje de usuarios. Luego, los desarrolladores pueden ver si los errores aumentan, el rendimiento disminuye o surgen otros problemas. Ese pequeño porcentaje de usuarios actúa como el “canario en la mina de carbón”. Si no hay problemas, el tráfico hacia la nueva versión aumenta de forma constante, comprobando errores todo el tiempo.

La principal ventaja de un despliegue canary sobre azul/verde es el costo de la infraestructura, ya que el despliegue canary utiliza solo un entorno y los despliegues azul/verde dos. Pero los despliegues canary también pueden ser más complejos y de mayor riesgo si se necesita una reversión, en comparación con la simple redirección de equilibrio de carga de azul/verde.

El método de despliegue canary puede ser útil si los errores potenciales no son una preocupación tan importante como poner una nueva versión frente a los usuarios lo más rápido posible, o si los desarrolladores desean monitorear el impacto con feedback real de la experiencia del usuario.

Dicho esto, también existe un enfoque híbrido. Los equilibradores de carga pueden dirigir parte del tráfico de usuarios, digamos el 1 %, al entorno verde y dejar que el 99 % vaya al entorno azul. Esto combina eficazmente ambas estrategias, proporcionando insights de despliegue canary con la capacidad de emitir reversiones de forma rápida y sencilla.

El despliegue azul-verde ofrece muchas ventajas, ya sea que se utilice en un despliegue de todo o nada o de tipo canary.

Dado que el equilibrador de carga redirige el tráfico al entorno deseado de forma instantánea, los usuarios finales nunca sufren tiempo de inactividad Esto es un gran beneficio en casos de alto tráfico, donde los tiempos de inactividad pueden generar problemas empresariales significativos.

Tener dos entornos separados, uno de los cuales se sabe que es seguro y operativo, permite a los desarrolladores deshacer instantáneamente cualquier cambio si surgen problemas. Si el entorno verde presenta problemas, el tráfico puede simplemente redirigirse al entorno azul.

Tener dos entornos separados simplifica el análisis de métricas, analytics y pruebas A/B para las diferentes versiones. Los datos de analytics y monitoreo se pueden conectar claramente al entorno azul o verde, lo que permite una comparación sencilla y controles de estado. Esto contrasta con el despliegue canary, que puede ser más difícil de distinguir, ya que ambas versiones están activas simultáneamente.

Un entorno verde y experimental permite realizar pruebas exhaustivas de nuevas versiones fuera de la vista del usuario final. Las nuevas versiones se implementan con un grado significativo de confianza en que funcionarán según lo previsto. En los casos en que esto no ocurra, el tráfico se puede redirigir instantáneamente al entorno azul estable.

Si bien el despliegue azul-verde ofrece muchos beneficios, existen posibles inconvenientes y casos de uso no óptimos que los equipos de desarrollo deben considerar.

Con dos entornos totalmente aprovisionados en ejecución, los costos de alojamiento e infraestructura pueden aumentar. No es necesariamente el caso de que estos costos sean precisamente el doble del costo de un solo entorno. En algunos casos, el entorno verde ejecutará una huella más pequeña o el entorno azul podría retirarse rápidamente o algunos recursos podrían compartirse entre los dos entornos. Pero es probable que haya algún aumento de costos.

Aunque no es exclusivo de los despliegues azul-verde, mantener la sincronización de bases de datos entre entornos antiguos y nuevos puede suponer un reto. Por ejemplo, en un sistema azul-verde que implica cambios frecuentes o complejos en el esquema, puede ser complicado mantener la compatibilidad.

Para evitar alterar el entorno en vivo, los cambios en el esquema deben ser compatibles con versiones anteriores, lo que significa que el nuevo sistema puede funcionar con el anterior. De lo contrario, es posible que los entornos requieran bases de datos independientes que deban sincronizarse en tiempo real. Esta sincronización bidireccional presenta sus propios riesgos, como incongruencias y degradación del rendimiento.

Para abordar este problema, las herramientas CI/CD, como GitHub Actions, incluyen procesos de despliegue de bases de datos que gestionan automáticamente las actualizaciones de esquemas. A veces, los cambios de esquema que son demasiado complejos pueden anular el valor del despliegue azul-verde.

En aplicaciones con estado, aquellas que mantienen datos persistentes entre solicitudes, los despliegues azul-verde pueden presentar problemas. Las aplicaciones con estado podrían incluir carritos de compras que mantienen su contenido a través de múltiples visitas o registros de mensajería. Si las bases de datos no se comparten y no son compatibles entre entornos, estos datos pueden perderse.

Las aplicaciones de microservicios suelen ser sistemas muy complejos formados por numerosos componentes diferentes que se pueden desplegar de forma independiente. Dado que los desarrolladores de microservicios podrían desplegar docenas de veces al día, la naturaleza incremental de un despliegue canary se considera una opción más segura.