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.

Si bien los orquestadores como los kubernetes ayudan a realizar estas tareas con más facilidad y transparencia, se pueden usar otras técnicas y herramientas más pequeñas para lograrlo según sea el caso. Por ejemplo, para aplicaciones web se puede instalar más de una instancia de la aplicación detrás de un load balancer como el Httpd de Apache como se muestra en la siguiente figura:

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.

Cuando llega la hora de hacer el deployment de la nueva versión se puede deshabilitar el tráfico sobre los servidores A y B, instalar la nueva versión, realizar pruebas, habilitar el tráfico nuevamente y finalmente realizar el mismo proceso con los servidores C y D. El “cero downtime” radica en el hecho de que siempre hay al menos 2 servidores atendiendo las peticiones, por lo tanto el usuario final no ve ninguna afectación del servicio.

Un par de tips finalmente:

1.Para llevar esto a cabo es necesario habilitar el plugin de mod_proxy. Eso le va a permitir al httpd comportarse como un load balancer. Adicionalmente se puede usar esta pantalla

Para realizar los pasos anteriormente descritos manualmente.

2. Considerar y diseñar la aplicación para trabajar sin datos de sesión o usar la configuración del sticky session en el httpd para que los usuarios sean redirigidos al servidor correcto siempre.

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.