Los enfoques tradicionales de «big bang» para el desarrollo de software son incompatibles con los requisitos de alta flexibilidad, agilidad y despliegue continuo de las actuales plataformas de software en la nube y DevOps.
No basta con preparar una lista de comprobación de pasos manuales para ejecutar durante el despliegue de la versión de producción. Si lo hace, no es realmente ágil, ni es un DevOps adecuado.
Despliegue azul-verde: Una visión general
El despliegue azul-verde es un enfoque del despliegue de software que reduce el tiempo de inactividad y el riesgo de las nuevas versiones de software mediante la creación de dos entornos idénticos: activo (azul) e inactivo (verde).
El entorno activo es donde se ejecuta la versión actual del software y los usuarios generan tráfico de producción. El entorno inactivo es donde se despliega y prueba la nueva versión del software.
Una vez que la nueva versión está probada y lista, el tráfico se cambia del entorno activo al inactivo, convirtiéndolo en el nuevo entorno activo. Puede repetir este proceso cuando sea necesario.
Contexto DevOps
El despliegue Blue-Green encaja bien con la mentalidad y los procesos DevOps porque admite la entrega y el despliegue continuos de software al tiempo que minimiza el tiempo de inactividad para los usuarios de producción y elimina el riesgo de un fallo en el lanzamiento de producción.
Disponer de dos entornos idénticos permite probar y desplegar nuevas versiones de software sin afectar al entorno de producción actual. Esto significa lanzamientos más rápidos y frecuentes, que es un aspecto clave de DevOps.
Además, la capacidad de cambiar rápidamente de un entorno a otro es una condición primordial para una rápida reversión en caso de problemas, lo que también es importante en un entorno DevOps.
Principios clave del despliegue azul-verde
#1. Dos entornos idénticos
El despliegue Blue-Green requiere la creación de dos entornos idénticos. Es decir, idénticos desde el punto de vista de los datos y los procesos. Uno es activo (azul) y el otro inactivo (verde).
El entorno azul es donde los usuarios de producción ejecutan sus procesos cotidianos. El entorno verde está siempre sincronizado con el azul, pero los probadores ejecutan allí sus casos de prueba. Aunque este entorno no sea el de producción, usted ejecuta las pruebas en condiciones reales, ya que se trata de un entorno similar al de producción.
#2. Cambio de tráfico
Una vez que la nueva versión del software está probada y lista, se cambia el tráfico del entorno activo al inactivo, convirtiéndolo en el nuevo entorno activo.
El cambio es instantáneo. Todo el despliegue es ya cosa del pasado. No hay ventana de tiempo de inactividad. Los usuarios no necesitan hacer nada para llegar al nuevo entorno. Son redirigidos automáticamente, y todos al mismo tiempo.
#3. Redirección rápida
La capacidad de cambiar rápidamente el tráfico entre entornos también implica una rápida reversión en caso de problemas. Esto garantiza un tiempo de inactividad mínimo y que la aplicación siga estando altamente disponible.
Si algo va mal en el entorno verde, todos los usuarios volverán instantáneamente al entorno azul original estable sin ningún problema.
#4. Pruebas automatizadas
Las pruebas automatizadas son un aspecto clave de la implantación azul-verde. Garantiza que la nueva versión del software se pruebe a fondo antes de desplegarla en el entorno activo.
Si usted no tiene una cantidad significativa de las pruebas automatizadas en sus sistemas (incluyendo pruebas unitarias, pruebas funcionales y pruebas de regresión por lo menos), entonces probablemente ni siquiera tiene mucho sentido pensar en implementar el despliegue Blue-Green.
La falta de pruebas automatizadas le ralentizará drásticamente. El tiempo necesario para probar el nuevo entorno (verde) será tan largo que, para cuando pueda cambiar al entorno verde, ya será «demasiado viejo» desde la perspectiva del ciclo de vida del desarrollo de software.
#5. Entrega continua
El despliegue azul-verde forma parte de una canalización de entrega continua, lo que en última instancia significa lanzamientos más rápidos y frecuentes de software a la producción.
Puede hacer el cambio tan pronto como esté listo para probar una nueva versión de software en el entorno verde. Dado que el despliegue ya está hecho y sólo tiene que hacer el cambio de tráfico en sí, es tan rápido que puede hacerlo todos los días. Suponiendo que sea rápido también en las actividades de prueba, obviamente.
Ciclo de vida típico
La plataforma que ejecuta el despliegue Azul-Verde tiene su propio ciclo de vida específico de pasos y procesos a ejecutar. En esto suele consistir
- Construir una nueva versión del software. Esto implica compilar el código, ejecutar pruebas automatizadas y crear un artefacto desplegable.
- La siguiente etapa consiste en desplegar la nueva versión del software en el entorno inactivo (verde). Esto implica configurar el entorno, desplegar el artefacto y configurar los ajustes necesarios.
- Una vez desplegada la nueva versión del software en el entorno verde, ejecute pruebas automatizadas para asegurarse de que la nueva versión funciona correctamente. Esto incluye pruebas funcionales, pruebas de regresión, pruebas de integración y, si es excepcional, incluso pruebas de rendimiento.
- Cambie el tráfico del entorno activo (azul) al inactivo (verde). Esto implica actualizar el equilibrador de carga o la configuración DNS para dirigir el tráfico al entorno verde. Por supuesto, le conviene que esto se haga mediante procesos automatizados.
- Una vez realizado el cambio, supervise la aplicación para asegurarse de que funciona correctamente. Esto incluye la supervisión de errores, problemas de rendimiento y otras cuestiones.
- Este paso es opcional, y en realidad no querrá llegar a él con demasiada frecuencia. Pero si alguien detecta algún problema sustancial, vuelva a cambiar el tráfico al entorno azul para realizar una reversión instantánea. De nuevo, sin ningún tiempo de inactividad o desconexión relacionada con los usuarios de producción. Sólo tiene que actualizar el equilibrador de carga o la configuración DNS para dirigir el tráfico al entorno azul.
- Una vez que resuelva esos problemas y esté listo para volver a la nueva versión, cambie el tráfico de nuevo al entorno verde. Así que de nuevo – actualice el equilibrador de carga o la configuración DNS para dirigir el tráfico de nuevo al entorno verde.
- Por último, una vez que la nueva versión del software sea estable y funcione correctamente, dé de baja la versión antigua del software que se ejecuta en el entorno azul. La necesitará para construir otra versión nueva de su sistema.
Implementación de canalizaciones CI/CD
Implementar el despliegue azul-verde en una canalización CI/CD DevOps será un proceso natural.
Un requisito previo importante es que ya disponga de esos dos entornos idénticos. Dado que será un proceso automatizado, puede utilizar la infraestructura como herramienta de código como AWS CloudFormation o incluso scripts Terraform agnósticos de la nube para crear/recrear/actualizar los entornos por usted dentro de las canalizaciones automatizadas.
Una vez que tenga esto, es un paso relativamente fácil hacia la creación de un proceso de despliegue totalmente automatizado. Sólo tiene que reutilizar los pipelines ya existentes para la creación de los entornos azul y verde. Sin embargo, esta vez necesita incluir en la canalización también procesos de prueba.
El proceso de conmutación de tráfico puede automatizarlo con herramientas como AWS Elastic Load Balancer o NGINX. Se trata de actualizar el equilibrador de carga o la configuración DNS para dirigir el tráfico al entorno verde una vez que la nueva versión del software esté probada y lista.
La siguiente pieza del rompecabezas es la monitorización. Para ello, utilice herramientas como AWS CloudWatch,New Relic o Datadog.
Por último, reutilice las canalizaciones existentes incluso para desmantelar el antiguo entorno azul. Depende de usted si ejecuta primero destroy para todos los servicios y componentes antes de recrearlos desde cero o, alternativamente, puede limitarse a actualizar los scripts para cada servicio de la cadena. Por lo general, destruir y volver a crear es una opción más segura, ya que con la actualización, tiene muchos más casos de esquina a considerar.
Mejores prácticas de despliegue azul-verde
¿Tiene curiosidad por saber cómo aprovechar al máximo el despliegue Blue-Green? He aquí algunos consejos derivados de la práctica.
Disponga de una sólida estrategia de migración de bases de datos
Al desplegar una nueva versión del software, es importante asegurarse de que el esquema de la base de datos se actualiza correctamente. Utilice una estrategia de migración de bases de datos como Flyway o Liquibase para gestionar los cambios en el esquema de la base de datos.
Utilice una herramienta de análisis Canary
Aunque el despliegue can ario es un enfoque alternativo, puede utilizar algunas de sus técnicas para perfeccionar su despliegue azul-verde.
Utilice una herramienta de análisis canario como Kayenta o Spinnaker para analizar el rendimiento de la nueva versión del software en un entorno real. Se trata de comparar el rendimiento de la nueva versión del software con el rendimiento de la versión antigua del software.
Utilice un marco de conmutación de funciones como Togglz para activar o desactivar funciones en la nueva versión del software. Esto permite un despliegue gradual de las nuevas características y permite un retroceso rápido si es necesario.
Utilice un equilibrador de carga con comprobaciones de estado
Utilice un equilibrador de carga como AWS Elastic Load Balancer o NGINX con comprobaciones de salud para asegurarse de que el tráfico sólo se dirige a instancias sanas. Esto garantiza que la aplicación siga estando altamente disponible y que se minimice el tiempo de inactividad.
Utilice un plan de reversión con reversión automatizada
Disponga de un plan de reversión en caso de problemas y automatice el proceso de reversión utilizando una herramienta como AWS CodeDeploy u Octopus Deploy. Esto garantiza que se minimice el tiempo de inactividad y que la aplicación siga estando altamente disponible.
Esto se aplica sobre todo al entorno verde siempre que descubra algún problema importante con la nueva versión.
No necesita un plan de reversión para el entorno azul, ya que éste permanece intacto por el cambio, y puede volver a este entorno estable siempre que lo necesite y de forma instantánea.
Desafíos de la implantación azul-verde
La implementación del despliegue Blue-Green puede presentar algunos retos para los equipos de desarrollo. He aquí algunos desafíos típicos:
- Configurar y gestionar dos entornos idénticos puede ser complejo y llevar mucho tiempo. Esto requiere experiencia en herramientas de infraestructura como código, como Terraform o CloudFormation. Es necesario contar con un equipo de desarrollo experimentado capaz de hacer frente a estos retos técnicos.
- Al desplegar una nueva versión del software, es importante asegurarse de que el esquema de la base de datos se actualiza correctamente. Esto puede suponer un reto, especialmente si el esquema de la base de datos es complejo. Necesita disponer de procesos sólidos de despliegue de bases de datos que puedan gestionar de forma automática y fiable las actividades de actualización del esquema.
- Analizar el rendimiento de la nueva versión del software en un entorno real puede ser todo un reto. Para ello se requieren conocimientos en herramientas de análisis canario como Kayenta o Spinnaker.
- Implementar los cambios de características puede ser todo un reto, especialmente si la aplicación tiene un gran número de características. Esto requiere una cuidadosa planificación y coordinación entre los equipos de desarrollo.
- Probar la nueva versión del software en un entorno real puede ser todo un reto, sobre todo si la aplicación tiene un gran número de usuarios o servidores. Necesita que los casos de prueba estén automatizados en la medida de lo posible. Además, sus procesos rutinarios acabarán incluyendo mucha coordinación entre los equipos de desarrollo y de pruebas.
- Disponer de una buena solución de monitorización es una realidad muy poco frecuente, pero para unas operaciones DevOps adecuadas, es imprescindible. Tan pronto como sea factible, vaya e invierta el tiempo en construir esa solución con servicios probados (AWS CloudWatch, New Relic, Datadog).
Diferencia entre el despliegue azul-verde y el canario
Aunque la diferencia con los procesos de despliegue tradicionales es bastante obvia (en los procesos de despliegue tradicionales no hay dos entornos paralelos funcionando con versiones de software diferentes), la diferencia con el despliegue Canary puede ser un poco más interesante.
El despliegue azul-verde implica dos entornos (azul y verde). Pero al mismo tiempo, los dos entornos están constantemente sincronizados en términos de datos. Una vez que la nueva versión se ha probado y se considera lista, el tráfico pasa del entorno activo al inactivo, convirtiéndolo en el nuevo entorno activo. No se pierde tiempo en desplegar el nuevo código y no hay tiempo de inactividad de la producción. Todos los usuarios de producción trabajan todo el tiempo en el entorno actualmente activo, y ni siquiera notan el cambio.
El despliegue canario consiste en desplegar una nueva versión del software a un pequeño subconjunto de usuarios mientras la mayoría de usuarios o servidores siguen utilizando la versión actual. Se trata de un despliegue gradual en lugar de un cambio completo. Los probadores son, en este caso, usuarios directos de producción, aunque sólo un subconjunto definido de ellos. Este grupo está probando activamente la nueva versión con los procesos de producción y, cuando finalmente sea estable, la nueva versión se extenderá al resto de los usuarios.
Entonces, ¿cuál es mejor?
La respuesta de un consultor «depende» es la que más encaja aquí, por muy mezquina que pueda sonar.
Si la prioridad de su sistema es ante todo la alta disponibilidad, entonces la implantación Azul-Verde será su elección.
Si su mayor preferencia es una respuesta más rápida y un despliegue más controlado (aunque más lento) de la nueva versión del sistema, entonces el despliegue Canario tiene ventajas sobre el Azul-Verde.
Lo importante es que ambos son lo suficientemente ágiles como para considerarse lo suficientemente buenos para la creación seria de sistemas DevOps.
Casos prácticos
Netflix utiliza el despliegue Blue-Green para desplegar nuevas versiones de su servicio de streaming. Al utilizar el despliegue Blue-Green, Netflix puede desplegar nuevas versiones de su servicio sin afectar a la experiencia del usuario. De hecho, Netflix también utiliza el despliegue Canary en paralelo para otros casos, por lo que no es poco realista combinar diferentes enfoques del despliegue DevOps bajo el mismo techo.
Asimismo, Amazon y Etsy utilizan el despliegue Blue-Green para desplegar nuevas versiones de su plataforma de comercio electrónico.
Otro caso es LinkedIn, que utiliza el despliegue Blue-Green para desplegar nuevas versiones de su plataforma de redes sociales.
Por último, pero no menos importante, IBM utiliza el despliegue Blue-Green para desplegar nuevas versiones de su plataforma en la nube.
Estas empresas han implantado con éxito el despliegue Blue-Green en las infraestructuras de sus plataformas y sirven de ejemplo para otras.
Palabras finales
Al igual que el canario, el despliegue Blue-Green busca la mejor optimización de sus procesos y metodologías ágiles ya existentes para ofrecer un nuevo software sin problemas de tal forma que nadie se dé cuenta en absoluto. Este es el objetivo último de este tipo de enfoques. Usted entrega constantemente y muy a menudo, pero nadie lo sabe, nadie lo nota y, al final, a nadie le importa.
Puede resultar un poco frustrante para el equipo de desarrollo que no haya cotilleos en la empresa sobre sus últimos lanzamientos. Pero, en mi opinión, éste es exactamente el mejor servicio que se puede ofrecer. Nadie habla de ello, pero todo el mundo lo utiliza día a día.
A continuación, consulte las preguntas y respuestas más frecuentes de las entrevistas sobre DevOps.