Uno de los retos más importantes para cualquier proyecto Cloud es automatizar el proceso de despliegue de los diferentes artefactos generados. Del mismo modo es de gran importancia tener en cuenta las diferentes estrategias de despliegue que se pueden llevar a cabo, y aprovechar sus beneficios.
Automatizar el proceso de despliegue permite tener un proceso seguro que se encarga de tomar el software que se encuentra en desarrollo y llevarlo a ambientes de pruebas de desarrollo, QA, cualquier otro ambiente hasta finalmente poner el empaquetado en producción. Usualmente el proceso de despliegue en cualquier ambiente va a generar un tiempo de "downtime", lo cual significa que el ambiente sobre el que se esta desplegando va estar inactivo una cantidad de tiempo, que pueden ser desde segundos hasta minutos, dependiendo de la complejidad y tamaño del despliegue. Debido a lo anterior existe la estrategia de despliegue GREEN/BLUE deployment; la cual consiste en tener dos ambientes de producción idénticos, a uno lo llamaremos BLUE y al otro GREEN. En un momento dado por ejemplo BLUE se encuentra siendo usado por los usuarios y debemos realizar un despliegue en producción , como no deseamos afectar los usuarios, realizamos el despliegue sobre el ambiente GREEN, sobre el cual lanzamos nuestras pruebas finales. Cuando estemos seguros de la estabilidad de GREEN, realizamos un cambio en nuestro router para que el ambiente GREEN sea usado por los usuarios mientras que el ambiente BLUE queda disponible como backup, en caso de que GREEN presente problemas. Gracias a esta técnica, también obtenemos una estrategia de rollback, ya que en caso de que algo salga mal siempre tendremos un sitio backup.
Para usar este mecanismo sin ningún problema hay que considerar dos cosas. El diseño de la aplicación es sumamente importante ya que debe ser stateless al máximo para evitar perdida de datos de transacciones al momento de hacer el switch. Otro problema con el que nos podemos encontrar, es al momento de aplicar cambios sobre la base de datos, especialmente si estos cambios conllevan cambios de esquema; para reducir la complejidad de este problema, debemos separar el despliegue de actualizaciones de la aplicación y la actualización de schema de la base de datos. Primero aplicamos las actualizaciones de base de datos de tal forma que se soporte la nueva versión de la aplicación nueva y la versión vieja, posteriormente probamos que ambas aplicaciones funcionen. Luego desplegamos la nueva versión de la aplicación, cuando nuestra aplicación se encuentre estable en los ambientes BLUE y GREEN quitamos el soporte en la base de datos para aplicaciones antiguas.
Usando Azure
Azure nos ofrece diferentes alternativas para hacer este tipo de despliegues, todo depende de cual sean los productos que estemos usando. En el caso de que estemos usando los servicios PAAS( Platform as a Service) de Azure para nuestra aplicación, ya sean cualquiera de los App Service (Webapp, MobileApp,ApiApp, LogicApp) o algun Cloud Service. Estos productos traen una funcionalidad conocida como Slot; esta permite desplegar dentro de un AppService o Cloud Service diferentes instancias de la aplicación, estas comparten los mismos recursos de maquina pero no comparten el mismo dominio. Del mismo modo Azure ofrece una funcionalidad para llamar el switch entre slots, esto se puede hacer manual o por un servicio del API Rest que puede ser llamado por un cliente creado por nosotros o por el API resource manager de powershell. En la siguiente imagen podemos ver dentro de un Web app donde se encuentra la opción para configurar los slots.
No sería común que usáramos esta funcionalidad desde el portal ya que como lo mencione inicialmente, el deployment es un proceso automático, así que en un escenario real el despliegue a el ambiete GREE o BLUE sería realizado por nuestra herramienta de control de integración continua Visual Studio Online, Jenkins, etc. El job de integración continua se encargaría de desplegar en el ambiente de producción, ejecutar las pruebas automáticas y finalmente hacer el switch entre ambientes.
Si estamos utilizando los servicios IAAS( Infrastructure as a Software) de Azure ya sea, maquinas virtuales o contenedores docker, tenemos la opción de configurar un balanceador de carga sobre los ambientes BLUE/GREEN y sobre el configurar las reglas de enrutamiento. Para lo anterior lo que debemos hacer es apuntar el CNAME configurado en el DNS para que apunte a la url pública del expuesta en el balanceador, y dentro del balanceador configurar las reglas. Azure ofrece algunos balanceadores de carga de terceros junto con un balanceador de carga propio, pero en últimas podríamos configurar el balanceador que deseamos en una máquina virtual o dentro de un contenedor Docker. Lo siguiente a realizar sería configurar la integración continua para que por medio de servicios re configure el balanceador en caso de un despliegue .
Conclusión
Este método de despliegue es un método antiguo, pero no es usado comúnmente por falta de conocimiento y herramientas que permitan automatizar el proceso; pero el no usarlo no solo nos genera tiempos de downtime los cuales impactan directamente los SLAs de nuestro producto, sino que también nos obliga a tener unos procedimientos manuales de recuperación ante un despliegue fallido.
Referencias
Si desean saber más al respecto pueden ver los siguientes links:
