Cero downtime
Conocido como “blue/green o red/black” deployment donde todo el tráfico es redirigido al nuevo sistema una vez que se ha comprobado que la nueva instalación funciona correctamente y mientras tanto otra instancia de la misma aplicación atiende todas las peticiones, eso sí con la versión anterior.

Las aplicaciones de informática necesitan de mantenimientos constantes para operar con normalidad, en estos mantenimientos el proveedor de la aplicación puede: actualizar la configuración, subir nuevos “features” o resolver problemas conocidos, sin embargo el reto está en lograr realizar estas actividades sin que los usuarios finales perciban alguna afectación. Esto es conocido como “blue/green o red/black” deployment donde todo el tráfico es redirigido al nuevo sistema una vez que se ha comprobado que la nueva instalación funciona correctamente y mientras tanto otra instancia de la misma aplicación atiende todas las peticiones, eso sí con la versión anterior.


Proyecto: Red Black Deployment
El objetivo principal al desarrollar este proyecto bajo el concepto de Red Black Deployment, es lograr desplegar un nuevo build de un actor con cero downtime, con esta nueva versión del microservicio, los usuarios no notarán el cambio y podrán continuar utilizando el servicio sin ningún problema. Anteriormente, al no contar con esta técnica de liberación, se debía de realizar dicho cambio en horas de la noche, cuando el tráfico es menor, considerando que durante el proceso del ajuste, los microservicios del sistema no estarían disponibles.
Gracias a la implementación de la Red Black Deployment, se puede desplegar el nuevo build sin interrumpir el tráfico en el build original. Una vez listo para recibir tráfico, se realizará el cambio a esta nueva versión; todo esto sin afectar al usuario y pueda continuar utilizando los microservicios del sistema.
El objetivo se logró utilizando el sistema de orquestación Kubernetes apoyándose en varias de sus características: con los ‘deployment’, se desplegó la nueva versión del actor. Cuando este estaba listo para recibir tráfico, se procedió a realizar el cambio en el “service” de Kubernetes, el cual redistribuye el tráfico al nuevo microservicios.