estrategia blue-green. BlueGreenDeployment. ARR
María NET Developer - Mírame a los ojos
La pérdida de servicio en actualización de aplicaciones
Una de las grandes problemáticas que han afectado a las empresas que ofrecen servicios tecnológicos es la pérdida de servicio o downtime durante los pases de aplicaciones a producción.
Esto supone que no se puede ofrecer servicio durante la actualización y por tanto, tradicionalmente, se han empleado horarios para la actualización que tengan el menor impacto en la calidad de servicio que obtienen los usuarios o que buscan reducir la pérdida de negocio derivada de la indisponibilidad.
Además, cada vez con mayor asiduidad, no es posible realizar actualizaciones con downtime debido a la naturaleza global o crítica de ciertos servicios. Es más, en ciertos tipos de negocio, la pérdida de servicio puede resultar fatal a largo plazo ya que se es menos competitivo al tener downtimes.
Para solventar dichos problemas se emplean estrategias de actualización de aplicaciones sin pérdida de servicio como, por ejemplo, el blue-green. La estrategia blue-green se emplea de la siguiente manera.
Dada una versión de una aplicación en producción (digamos v1.1.0), cuando se quiere actualizar a la v1.2.0, se realizan los siguientes pasos:
- Se parte de una situación en la que la v1.1.0 se encuentra en producción recibiendo el 100% del tráfico.
- La versión v1.2.0 se despliega de forma independiente a la versión anterior de forma que ambas están en ejecución a la vez. Sin embargo v1.2.0 no recibe tráfico productivo. (Esto puede requerir, como mucho, disponer del doble de infraestructura de la que emplea la versión v1.1.0 durante la ventana de actualización).
- Se migra de forma total el tráfico productivo de una versión a otra, de forma que la v1.2.0 recibe el 100% del tráfico. La v1.1.0 sigue activa pero sin tráfico durante una ventana de tiempo. En caso de que la actualización sea satisfactoria, se elimina la versión antigua.
De esta forma, es posible realizar la actualización de la aplicación sin downtime.
Pero además:
- En caso de detectarse errores en la nueva versión, se invertiría la operación de migrado de tráfico volviendo a operar con la v1.1.0 como hasta antes de empezar el proceso de actualización. A este proceso se le denomina rollback. Así se puede evaluar el porqué del fallo en la actualización sin dejar de prestar servicio.
Mario Dal Lago
El lun., dic. 25, 2017 a 19:04, María NET Developer - Mírame a los ojos<mmiramealosoj...@gmail.com> escribió:
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/altnet-hispano.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
María NET Developer - Mírame a los ojos
Requisitos previos son las descargas de los siguientes ejecutables.
1. WebDeploy_amd64_en-US
2. WebPlatformInstaller_3_10_amd64_en-US
3. WebFarm2_x64
4. requestRouter_x64
5. rewrite_amd64