DevOps: Estrategias de Despliegue

Beneficios de tener ciclos de desarrollo muy cortos:

• Tiempos para la comercialización de productos o servicios disminuyen
• Los clientes obtienen el producto en menos tiempo
• La retroalimentación del cliente fluye a velocidad acelerada, la cual permite al equipo de desarrollo iterar de manera más rápida y sencilla (uso de spring y controles de cambios)
• La moral del equipo aumenta (ven el fruto de su esfuerzo en producción)

Sin embargo, crea nuevos retos para el equipo de operaciones o DevOps. Con despliegues frecuentes puede dar una rentabilidad negativa (una sensación) o mala experiencia. Por lo cual, es importante establecer estrategias de despliegue para minimizar los riesgos del producto y del cliente.

Estrategia de Big Bang

Debes seleccionar las tareas y pendientes que necesitas completar y colocarlas en una lista para comenzar los siguientes planteamientos:

Empiezo a trabajar:

Los despliegues de Big Bang, como el nombre lo indica, actualiza completa o parcialmente la aplicación. Esto se deriva en los días en que el software se tiene distribuidores en servidores físicos y se instalan de manera manual a la máquina.

Este tipo de despliegues requiere que se ejecute una cantidad enorme de pruebas durante la fase de desarrollo, como también antes de hacer el despliegue. Regularmente esta estrategia puede estar asociada a la metodología Waterfall en el cual todo se ejecuta por etapas.

Estrategia Rolling

La estrategia de Rolling, minimiza algunos riesgos a comparación de Big Bang, sin tener un fácil rollback.

Consiste en reemplazar una nueva versión de la app, sin embargo, ambas versiones pueden existir por un tiempo en lo que se culmina el despliegue en los contenedores que se tengan. Dicho lo anterior, para trabajar con esta estrategia es preferible trabajarlo con contenedores (Docker, Kubernetes, etc.) para que los rollbacks resulten más sencillos a la hora de tener un error, además, en los despliegues consiste en destruir el contenedor con la versión anterior y generar la última versión de la imagen con los cambios que se hayan realizado.

A continuación, se muestran unos diagramas del comportamiento de dichos contenedores, teniendo en cuenta que se usa un balanceador de carga para poder dar de baja el contenedor cuando se este actualizando y una vez terminado el despliegue, levantar la aplicación y así sucesivamente por cada contenedor.

Los mayores inconvenientes de esta estrategia son:

• Puede ser un proceso muy lento (muchos contenedores por actualizar)
• Al ser un proceso simple repetido x veces, tiene más probabilidad de fallo y el rollback no es tán rápido como debería.
• Puede haber un momento de inconsciencia al haber distintas versiones en producción. Por ejemplo, dos llamadas a un GET pueden devolvernos distintos valores, aunque es cierto que esta situación es puntual.

Estrategia Blue-Green, Red-Black o A-B

Esta estrategia consiste en tener dos ambientes de producción de forma paralela (uno llamado blue y el otro llamado green)

Como se aprecia en la imagen anterior, la nueva versión se despliega en el ambiente green y se realizan pruebas en el nuevo entorno (funcionalidad y performance). Una vez que las pruebas son satisfactorias se cambia el tráfico de blue a green para que vayan los usuarios al nuevo ambiente. Sin embargo, para este tipo de estrategia se hace el cambio en el DNS para cambiar el tráfico el problema puede ser que exista un retraso en ver el cambio del nuevo sitio y se deriva por el TTL (time to live).

La alternativa es cambiar la configuración del balanceador de carga y en vez de cambiar el DNX, mejor cambiar la IP del equipo en el que está el entorno y el tráfico se dirija al nuevo server, como se ilustra en la siguiente imagen.

Estrategia Canary

Esta estrategia es muy parecida a green-blue excepto que es más reactivo (aversión) al riesgo. Se despliega el nuevo código de la aplicación en un apartado pequeño en el ambiente de producción. Una vez que la aplicación se encuentra alojada en el ambiente de producción se entura unos pocos usuarios. Esto minimiza el impacto en caso de encontrar un error.

Si no se reportan errores, la nueva versión se va actualizando al resto de la infraestructura de forma gradual. La imagen de a continuación demuestra la estrategia:

Conclusiones

Todas las estrategias son buenas, como todo, unas son más costosas que otras, unas tienen más riesgos que otras, tiene sus ventajas y desventajas, pero lo más importante es que dependerá de la infraestructura que cuente el cliente, como también el tipo de proyecto que se esté trabajando.

Somos una de las empresas consultoras con el más alto nivel de especialización tecnológica y transformación digital en el mercado mexicano, lo que nos permite atender las necesidades en los sectores automotriz, manufactura, moda y textil, turismo, logística, financiero y retail. No dudes en contactarnos.

Autor: Aarón Alfonso Herrera Jácome