¿Qué es la implementación azul-verde?

Hay un entorno operativo que presta servicio a los usuarios, denominado “azul”, y otro, el entorno “verde”, que se utiliza para la implementación y las pruebas de una nueva versión. Cuando se apruebe la nueva versión, el tráfico pasa al instante del entorno azul al entorno verde.

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

Azul-verde es una técnica de implementación continua que permite eliminar el tiempo de inactividad, la capacidad de emitir instantáneamente reversiones a una versión anterior. 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.

Aunque la denominación “azul-verde” es la más común, existen variaciones. Netflix utiliza “rojo/negro”, pero el concepto sigue siendo el mismo. A veces, los desarrolladores pueden querer tener más de dos entornos. La combinación de nombres de los colores es eficaz para diferenciar dos entornos. Sin embargo, las organizaciones también pueden utilizar convenciones de nomenclatura como números de versión, ID de compilación o títulos personalizados, especialmente si hay más de dos entornos implicados.

Aunque su concepto es sencillo, hay varios pasos y variables dentro de esos pasos para crear una implementación azul-verde estable y segura que se beneficie de los beneficios de la estrategia.

La creación de entornos idénticos para la implementación azul-verde puede realizarse manualmente o utilizando herramientas automatizadas. La infraestructura como código, o IaC, es un enfoque automatizado del aprovisionamiento. IaC utiliza archivos de configuración legibles por máquina, un poco 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.

IaC permite a los desarrolladores poner en marcha automáticamente una copia del entorno azul, que ya está operativa, para utilizarla como entorno verde. Los desarrolladores pueden entonces editar estas plantillas según sea necesario, sabiendo que parten de un lugar fiable. El uso de IaC ayuda a garantizar una replicación repetible y precisa.

La contenerización, en la que el código de aplicación, las dependencias y las API se empaquetan todos juntos 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 habitualmente para la contenerización en la implementación azul-verde.

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

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

A continuación, el nuevo código con las actualizaciones de la aplicación se implementa en el entorno de producción verde. Como 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 el proceso de implementación en el entorno verde esté completo, realiza todos los pasos de validación necesarios. Estos pasos pueden incluir análisis de seguridad, comprobaciones de rendimiento, análisis de errores y mucho más.

Cuando el entorno verde esté validado y aprobado por todas las partes interesadas necesarias, actualiza el equilibrador de carga para dirigir el tráfico de la versión azul anterior 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 pueden utilizarse para dirigir a los usuarios al entorno deseado, pero puede haber retrasos significativos mientras las cachés actualizan la dirección IP. Debido a estas preocupaciones, se prefieren los equilibradores de carga porque las actualizaciones entran en vigor de inmediato.

Aunque la fase de validación debería haber detectado la mayoría de los posibles errores o problemas de rendimiento, sigue siendo importante supervisar el nuevo entorno que acaba de entrar en funcionamiento. El software y los servicios de análisis pueden ayudar en este sentido. 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 coste para desmantelar el entorno azul en algún momento de su ciclo de vida. Por otra parte, 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 de DevOps automatizado que optimiza el proceso de entrega de software". Este pipeline facilita la entrega continua de los cambios de código en las aplicaciones.

Es una práctica estrechamente integrada con la implementación azul-verde: CI/CD permite la implementación azul-verde y las implementaciones 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 a la implementación. Los pipelines de CD aprovechan una estrategia de implementación azul-verde para optimizar los lanzamientos rápidos sin afectar a los usuarios. La implementación azul-verde proporciona una disponibilidad casi continua y una reversión segura, lo que desempeña un papel importante en la consecución del objetivo general de CI/CD de lanzamientos de código frecuentes y fiables.

Inspiradas en la expresión “el canario en la mina de carbón“, las implementaciones “canary” constituyen otra forma de reducir el riesgo a la hora de implementar nuevas versiones de software.

Mientras que las implementaciones 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 una implementación canary, las nuevas versiones se publican primero para un pequeño porcentaje de usuarios. A continuación, los desarrolladores pueden ver si aumentan los errores, disminuye el rendimiento 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 una implementación canary sobre la azul/verde es el coste de la infraestructura, ya que la implementación canary utiliza solo un entorno frente a las implementaciones blue/green dos. Pero las implementaciones canary también pueden ser más complejas 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 implementación canary puede ser útil si los posibles errores no son una preocupación tan importante como presentar una nueva versión a los usuarios lo antes posible, o si los desarrolladores desean monitorizar el impacto con comentarios reales sobre la experiencia del usuario.

Dicho esto, también hay 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 perspectivas valiosas sobre la implementación inicial y la capacidad de realizar reversiones de forma rápida y sencilla.

La implementación azul-verde ofrece muchas ventajas, ya sea que se utilice en una implementación de todo o nada o de tipo canary.

Dado que el equilibrador de carga cambia el tráfico instantáneamente al entorno deseado, los usuarios finales nunca experimentan tiempo de inactividad. Se trata de un beneficio importante para los casos de gran tráfico en los que el tiempo de inactividad puede producir importantes problemas empresariales.

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.

Contar con dos entornos independientes simplifica el análisis de métricas, la evaluación de datos y las pruebas A/B para las diferentes versiones. Los datos de análisis y monitorización pueden conectarse claramente al entorno azul o verde, lo que permite una comparación sencilla y comprobaciones de estado. Esto contrasta con la implementación canaria, 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 lanzan con un grado significativo de confianza en que funcionarán según lo previsto. En los casos en que este no sea el caso, el tráfico puede redirigirse instantáneamente al entorno azul estable.

Aunque la implementación azul-verde ofrece muchos beneficios, existen posibles desventajas y casos de uso no óptimos que los equipos de desarrollo deberían considerar.

Con dos entornos totalmente aprovisionados en funcionamiento, los costes de alojamiento e infraestructura pueden aumentar. No es necesariamente el caso de que estos costes sean precisamente el doble del coste de un solo entorno. En algunos casos, el entorno verde tendrá 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 costes.

Aunque no es exclusivo de las implementaciones 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 implique cambios frecuentes o complejos en el esquema, puede resultar complicado mantener la compatibilidad.

Para evitar problemas en el entorno activo, los cambios en el esquema deben ser compatibles con versiones anteriores, lo que significa que el nuevo sistema debe poder funcionar con el antiguo. Si no lo son, los entornos pueden requerir bases de datos separadas que deben sincronizarse en tiempo real. Esta sincronización bidireccional presenta sus propios riesgos, como las incoherencias y la degradación del rendimiento.

Para abordar este problema, las herramientas de CI/CD, como GitHub Actions, incluyen procesos de implementación 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 de la implementación azul-verde.

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

Las aplicaciones de microservicios suelen ser sistemas muy complejos formados por muchos componentes diferentes que se pueden implementar individualmente. Dado que los desarrolladores de microservicios pueden querer implementar docenas de veces al día, la naturaleza incremental de una implementación canary se considera una opción más segura.