LA PALETA DE DESPLIEGUES: AZUL, VERDE Y AMARILLO (CANARIO)

A nadie le gustan las implementaciones o los despliegues en viernes o fin de semana, en ventanas contra el tiempo a la media noche de nuestra vida cuando se va perdiendo la esperanza: ya sea infraestructura nueva o software con una característica novedosa o una aplicación revolucionaria. La nube vino a intensificar este escenario en un reino donde literalmente no se pone el sol y la disponibilidad se pretende absoluta.

El objetivo es crear, probar e implementar software preferentemente sin estado y preservando la capa de datos para mover las cargas consistentemente sin alterar las bases de datos operativas o con la capacidad de deshacer los últimos cambios; todo en entornos específicos pero heterogéneos corriendo en máquinas virtuales o contenedores; teniendo firewalls, balanceadores de carga, gateways o una red de distribución de contenido.

La integración e implementación continuas de software automatizan el desarrollo y la prueba de funciones o sistemas completos tanto como su despliegue a fin de minimizar la indisponibilidad de servicios, los tiempos fuera y los problemas en producción; sin embargo pueden aumentar los problemas de funcionalidad y seguridad debido a la liberación de versiones para que no afecten al usuario, léase negocio. De ahí que la estrategia de despliegue es crítica y define la “personalidad” empresarial.

La implementación azul-verde permite implementar la nueva aplicación o característica en la mitad verde (prueba) sin afectar a la azul (productiva); para ello se divide el entorno de aplicaciones en dos partes con los mismos recursos, preferentemente por un balanceador de carga local o global que integra ambientes incluso geográficamente separados.

Si la prueba funcional, de seguridad incluso de carga es exitosa el balanceador apunta a la totalidad del ambiente con el cambio implementado, sin afectaciones al usuario; si no lo fue se regresa a la construcción anterior y el ciclo inicia de nuevo. La “personalidad azul–verde” tiene un enfoque típico de DRP, centrado en el hardware, donde la idea es hacer un “switcheo completo” en caso de que algo salga mal, es el preferido de los administradores de infraestructura.

El despliegue de canario es más sutil: crea un pequeño entorno de prueba con nodos y recursos dedicados, aislados del entorno principal. El enfoque canario es sin duda incremental, crea subconjuntos que son desplegados en fases, de la variedad de arquitecturas dos son las substanciales:

• Principal y repuesto: al frente un balanceador maneja dos nodos uno principal y uno de repuesto en el cual se hace el desarrollo y la integración continua, una vez ejecutadas se agrega al balanceador de modo que sea consumido por grupo limitado de usuarios “conejillos de indias” por un tiempo limitado; esto asegura que los cambios son seguros antes de propagarlo al resto del clúster.
• Funciones alternas: se crean e implementan cambios en la aplicación controlados por su configuración, de modo que desata o no esos cambios. Se aparta un nodo del clúster sin necesidad de cambiar algo en el balanceador de carga, se despliega y se agrega y se activa la función para varios usuarios “conejillos de indias” liberando los cambios por configuración antes de propagarlo al resto.
• Híbrido (nodos y funciones): combina el uso de los dos nodos (principal y repuesto) con el control por configuración de funciones alternas; se usa para seccionar el tamaño del “focus group” con la prueba de múltiples funcionalidades. Se aumenta el control pero también el costo.

La “personalidad canario” tiene un enfoque típico de control de daños u orientado al riesgo (en función del tamaño del “focus group”: 10, 20, 30… 60%), controla el incremento y sus efectos; gira entorno a la aplicación por lo que es el predilecto de los desarrolladores.

¿Cuál es la mejor estrategia de implementación? La respuesta es “depende”, depende del tipo de aplicación y su tamaño–complejidad o misión crítica, depende del entorno de destino, depende de la cantidad de infraestructura a mano, depende del tamaño del ‘focus group’. Tanto el despliegue azul-verde como el canario son mecanismos eficaces. Incluso la mejor estrategia puede estar fuera de esta limitada paleta.

Más allá de mis preferencias como ex–desarrollador el despliegue canario tiene ventajas y desventajas: es más económico que el azul–verde porque no requiere dos entornos “completos” incluso puede prescindir de cambios en el balanceador y dado que está enfocado a la aplicación se pueden probar características por más tiempo de forma simultánea lo cual puede aumentar el costo del desarrollo de las pruebas incluso de la integración continua, lo cual obliga a tener un control estricto de versiones y equipos de desarrollo.

Es ideal para entornos que pueden mantener poca infraestructura y aplicaciones basadas en componentes configurados, permite regresar fácilmente a una versión previa, sin daños colaterales, o propagarlos creciendo el grupo objetivo incluso de un solo nodo. Pero si tiene la capacidad para mantener dos entornos de hospedaje y las construcciones son estables, es decir, mayormente compatible con versiones anteriores, el despliegue azul-verde ofrece más beneficios.

Sin importar cuál se elija, cualquier método requiere de una arquitectura de software ad hoc a la del entorno o del despliegue general, así como una correcta planificación que incluyen listas de verificación por característica, servicio, infraestructura o configuración; se requiere equilibrar la integración y entrega continuas con una estrategia o plan de respuesta a incidentes, de planes B y roll–backs automatizados.

El desafío del desarrollo y la entrega de software en épocas de la nube intensifican el reto pero basta con recordar que las aplicaciones son la corona del reino.

Enrique López T.