De acuerdo a una encuesta del 2015 de la IT Revolution Press, en conjunto con Puppet Labs, las organizaciones que usan DevOps despliegan código 30 veces más rápido que otras, realizando despliegues múltiples cada día. Además, las fallas en los cambios se reducen con DevOps, y los servicios son restaurados hasta 168 veces más rápido de lo que son en organizaciones sin DevOps.

DevOps: Fallar más rápido y recuperarse más rápido

Concentrémonos en aquellos últimos dos puntos por un momento. Una cosa es clara: Adoptar DevOps también tiene sus recompensas desde el punto de la recuperación en caso de desastres, porque las herramientas y procedimientos que usted usa para mover las aplicaciones desde su desarrollo hasta las pruebas, a producción y de vuelta a desarrollo otra vez, también pueden ser aplicados a fallar y recuperarse de desastres e interrupciones de servicio. Las mismas herramientas que automatizan por completo al ciclo de vida DevOps, también pueden ayudarle a aprovechar al máximo el uso de los recursos que ya tiene para efectos de recuperación.

De hecho, hay muchas herramientas de código abierto que ayudan con esta automatización, como Chef y Puppet, que crean, lanzan y despliegan instancias de máquinas virtuales de manera automática y las configuran apropiadamente. Hasta funcionan a través de límites de seguridad, desplegándose en su laptop privada, en su centro de datos o incluso en la nube pública -Amazon Web Services y Microsoft Azure son dos de los principales proveedores de nube pública que respaldan a Chef y a Puppet. Al usar estas herramientas, puede no solo automatizar el despliegue de código nuevo que sus desarrolladores escriben en copias exactas del ambiente de sus máquinas de desarrollo y configuración; también orquestar y lanzar un ambiente de backup en la nube en cuestión de minutos.

Si combina a Puppet y Chef con una herramienta como Oracle Ravello (si su nube pública es Amazon Web Services o Google) en sus despliegues virtuales VMware y KVM, literalmente puede anidar hipervisores para poder ejecutar sus ambientes virtuales en la nube pública al ser desplegados –con networking, addressing y más- de manera automática y sin cambios. Estas son herramientas poderosas tanto desde la perspectiva de DevOps como desde la perspectiva de la recuperación en caso de desastres. Usted puede construir, probar y desplegar software rápidamente, así como mitigar fallas, proporcionar un failover robusto y recuperar soluciones usando las mismas herramientas. Un despliegue continuo se vuelve un failover continuo y una recuperación continua.

El principio más importante de DevOps es que los desarrolladores deberían estar escribiendo códigos y probando sus aplicaciones en una copia del ambiente de producción en donde se ejecutará su código. Usualmente, esto casi se logra usando soluciones de máquinas virtuales y contenedores como Docker operando en laptops o desktops individuales. Esto es mucho mejor, por supuesto, que solo escribir códigos a ciegas en Xcode o Visual Studio, y después enviar paquetes a los administradores de sistemas para que los desplieguen, pero dije ‘casi’ en la oración previa porque incluso este tipo de virtualización no simula en su totalidad las limitaciones de capacidad de un ambiente de producción del mundo real. Es difícil probar una carga real en contraposición a un microservicio en un contenedor operando en una Apple MacBook Air, por ejemplo. Pero la prueba de cargas podría llevarse a cabo de una manera más realista y accionable en contraposición con un servicio de despliegue completo de Azure Stack, por ejemplo.

Los ambientes de recuperación en caso de desastres como espacios potenciales de trabajo en DevOps

Algunas compañías encuentran que, a medida que adoptan DevOps a un nivel más profundo, sus desarrolladores solicitan con mayor frecuencia acceso a los ambientes de repuesto de recuperación en caso de desastres para mitigar esa restricción de “laptop o desktop”. Generalmente, las organizaciones de tamaño mediano y grande tienen inversiones significativas en infraestructuras que son más copias exactas de los ambientes en los que están operando las cargas de trabajo de producción críticas, y que se encuentran en standby en caso de que esas cargas de trabajo necesiten ser portadas en caso de una disrupción o desastre en el servicio.

Hoy en día, permanecen más que nada inmóviles, excepto por unos cuantos ejercicios de recuperación cada año. Pero piénselo: Esto implica bastante capacidad sin utilizar, esperando por un evento que podría pasar solo por unas pocas horas al año. ¿Existe alguna forma de aprovechar las tecnologías de virtualización, el storage area networking y el networking definido por software para que la capacidad de repuesto en caliente de la recuperación en caso de desastres pueda ser usada como “espacio de trabajo” DevOps para probar y planear mientras que permanecen disponibles para sus propósitos originales -aceptar cargas de trabajo tras un failover?

La respuesta es sí. Los hipervisores y las máquinas virtuales pueden cambiar en número en cuestión de segundos, y las redes definidas por software pueden ser redireccionadas e impulsadas a conexiones y puntos finales diferentes a través de scripts de manera automatizada. De hecho, en la mayoría de casos, los datos ya se encuentran accesibles para el ambiente, así que la aplicación regular y las pruebas de operación pueden, de hecho, funcionar con datos reales sin tiempos largos de copia. ¿Podría pedir un mejor desempeño de un ambiente de prueba en el mundo real que, esencialmente, trabaja en una copia exacta de su infraestructura de producción?

En el caso de necesitar un failover, puede hacer que su sistema de monitoreo dispare esos scripts, cambie los puntos finales de almacenamiento y apague las máquinas virtuales -y después tendrá de vuelta a sus repuestos en caliente. Luego de que concluya el “desastre”comilla”, puede restaurar manualmente los servicios revirtiendo todos los cambios que realizaron esos scripts automatizados. PowerShell es una gran manera de hacer esto en ambientes Windows, Hyper-V y VMware, y los scripts Bash son adecuados para Xen y también otros hipervisores. Por supuesto, Puppet, Chef y Ravello también pueden colaborar con este tipo de orquestación.

La idea aquí es conseguir que alguna capacidad no utilizada haga algo útil sin que olvide, en primer lugar, el propósito de su existencia por completo. Los desarrolladores necesitan acceso para realizar pruebas y encontrar problemas de desempeño en las capacidades y cargas más altas de lo que sus máquinas de desarrollo solas pueden soportar. Tener una infraestructura stanby hot sin hacer nada más que ser hot y estar en standy es quizás el extremo opuesto a la adopción de DevOps; con reimaginar este tipo de aplicación, podría tenerlo todo.

Preguntas por hacer

Cuando comience a pensar más respecto a la recuperación continua en caso de desastres, aquí hay unos puntos que debe considerar con su equipo.

¿Cómo hacemos visibles nuestros procedimientos de recuperación en caso de desastres? ¿A quién le pertenece el checklist de procedimientos a seguir? ¿Quién dispara los scripts o quién es responsable de la automatización? ¿Cómo podemos simular la falla de una sola aplicación, una carga de trabajo completa y de la propia infraestructura? ¿Qué tipo de situaciones causarían fallas en cada uno de esos elementos clave?

¿Qué fortalezas naturales puede enfatizar un empleado en base a la recuperación en caso de desastres? Aunque DevOps tiende a integrar los roles de los desarrolladores y las personas de operaciones, naturalmente va a haber empleados con experiencias y tendencias más fuertes orientadas a operaciones, a los que se les debería otorgar el poder de lidiar con la responsabilidad que requiere un failover. Por el lado de los desarrolladores, los programadores deberían ser responsables si es que su código generó un evento de failover, y aquellos programadores que se inclinan a ser superiores en la corrección de fallas podrían asumir más responsabilidad en esta situación.

¿Cómo puedo utilizar mejor los sitios de recuperación en caso de desastres e infraestructura existente por los que ya pagué? ¿Ese ambiente está instalado para construir y demoler la virtualización de manera sencilla? Y si no lo está, ¿qué necesito hacer para llegar a ese estado?

-Jonathan Hassell, CIO (EE.UU.)