Estrategia de lanzamiento de Canary vs.Azul / Verde

Mi comprensión de una versión canary es que es una versión parcial para un subconjunto de nodos de producción con sesiones fijas activadas. De esa manera, puede controlar y minimizar la cantidad de usuarios / clientes que se ven afectados si termina lanzando un error grave.

Tengo entendido que una versión azul / verde es que tiene 2 entornos de producción reflejados ("azul" y "verde"), y envía cambios a todos los nodos de azul o verde a la vez, y luego usa la magia de red para controlar a qué entorno se enrutan los usuarios a través de DNS.

Entonces, antes de comenzar, si algo de lo que he dicho hasta ahora es incorrecto, ¡comience por corregirme!

Suponiendo que estoy más o menos encaminado, entonces un par de preguntas sobre las dos estrategias:

• ¿Hay escenarios en los que se prefiere el canario sobre el azul / verde y viceversa?
• ¿Existen escenarios en los que un modelo de implementación pueda implementar ambas estrategias al mismo tiempo?

La liberación azul-verde es más sencilla y rápida.

Usted puede hacer un comunicado de color azul-verde si se ha probado la nueva versión en un entorno de prueba y es muy cierto que la nueva versión funcionará correctamente en la producción. Usar siempre alternar funciones es una buena manera de aumentar su confianza en una nueva versión, ya que la nueva versión funciona exactamente igual que la anterior hasta que alguien cambia de característica. Dividir su aplicación en servicios pequeños que se pueden lanzar de forma independiente es otra, ya que hay menos para probar y menos para romper.

Usted necesita hacer un lanzamiento canario si no está completamente seguro de que la nueva versión funcionará correctamente en la producción. Incluso si es un probador minucioso, Internet es un lugar grande y complejo y siempre presenta desafíos inesperados. Incluso si usa alternancia de funciones, una podría implementarse incorrectamente.

La automatización de la implementación requiere esfuerzo, por lo que la mayoría de las organizaciones planearán usar una estrategia u otra cada vez.

Por lo tanto, realice la implementación azul-verde si está comprometido con las prácticas que le permiten tener confianza al hacerlo. De lo contrario, envía al canario.

La esencia de blue-green se implementa todo a la vez y la esencia de la implementación canary se implementa de forma incremental, por lo que, dado un grupo único de usuarios, no puedo pensar en un proceso que describiría como hacer ambas cosas al mismo tiempo. Si tuviera varios grupos independientes de usuarios, por ejemplo, utilizando diferentes centros de datos regionales, podría hacer azul-verde dentro de cada centro de datos y canario en todos los centros de datos. Aunque si no necesita una implementación canary dentro de un centro de datos, probablemente no la necesite en todos los centros de datos.

He escrito un ensayo detallado sobre este tema aquí: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

En mi opinión, la diferencia es si la nueva versión 'verde' está expuesta o no a usuarios reales. Si es así, lo llamaría Canary. Una forma común de implementar Canary es azul / verde regular con la adición de enrutamiento inteligente de usuarios específicos a la nueva versión. Lea la publicación para obtener una comparación detallada

Azul verde:

Canario:

Aunque ambos términos se parecen bastante entre sí, tienen diferencias sutiles. Uno confía en su versión de funcionalidad y el otro confía en la forma en que publica.

Canario

1. La versión canary es una técnica para reducir el riesgo de introducir una nueva versión de software en producción al implementar lentamente el cambio a un pequeño subconjunto de usuarios antes de implementarlo en toda la infraestructura.

2. Está a punto de tener una idea de cómo funcionará la nueva versión (se integrará con otras aplicaciones, CPU, memoria, uso del disco, etc.).

Azul verde:

1. Se trata más de una versión predecible sin tiempo de inactividad.
2. Retrocesos sencillos en caso de avería.
3. Proceso de implementación completamente automatizado

Aquí hay algunas definiciones en línea:

• Implementación azul-verde : al implementar una nueva versión de una aplicación, se crea un segundo entorno. Una vez que se prueba el nuevo entorno, sustituye a la versión anterior. A continuación, se puede apagar el antiguo entorno.

   

• Prueba A / B : dos versiones de una aplicación se ejecutan al mismo tiempo. Una parte de las solicitudes se dirige a cada uno. Luego, los desarrolladores pueden comparar las versiones.  
• Canary Release : se inicia una nueva versión de un microservicio junto con las versiones anteriores. Esa nueva versión puede tomar una parte de las solicitudes y el equipo puede probar cómo esta nueva versión interactúa con el sistema en general.

Un buen comienzo de definiciones. Creo que también ayuda a tomar una decisión para su estrategia si divide la definición de "liberación" en "implementación" y "liberación (funcionalidad)".

Implementar (binarios)

La acción del despliegue binario de su producto en un sistema (de producción).

Lanzamiento (funcionalidad)

La acción de administrar la disponibilidad de funcionalidad para (grupos de) usuarios.

¿Por qué? Por lo general, tiene (múltiples) dos inquietudes al "lanzar": 1) Errores / compatibilidad con versiones anteriores / etc. 2) Verificar la validez / usabilidad de las nuevas funciones

Entonces pregúntense, antes de elegir un Canary o Blue / green o cualquier estrategia de modo gris / mixto: ¿Qué preocupaciones tenemos al lanzar / implementar la nueva versión? Y solo entonces si conoce sus inquietudes, elija su estrategia.

Además, es posible realizar estrategias de implementación / lanzamiento más complejas. Por ejemplo, en algunas nubes / infraestructura es posible tener múltiples servidores de producción y transmitir la carga en diferentes proporciones a diferentes servidores y versiones de su producto, y monitorear la solidez antes de escalar una versión / implementación a todos los usuarios.

Marcado de funciones

La acción de "configurar" (fría o incluso caliente) qué funcionalidad está (no) disponible para qué (grupo) de usuarios

Si también hace algo como "marcar funciones", puede implementar primero, medir la solidez de su versión en la perspectiva de compatibilidad / error con versiones anteriores y lanzar nuevas funciones gradualmente a diferentes usuarios, o viceversa (reducir o incluso reducir la funcionalidad y / o binarios ). El marcado de características permite dividir la disponibilidad de la funcionalidad de la implementación de binarios y brinda una toma de decisiones mucho más detallada que solo "implementar / deshacer"