Operaciones como desarrollo

Hay un cierto temor al respecto de tener un equipo DevOps como apoyo, y es que el equipo de Operaciones se convierta en una especie de equipo de desarrollo de propósito especial. Este temor, de hecho, crea uno de los mayores malentendidos acerca de DevOps: creemos que DevOps significa “Operaciones convirtiéndose en codificadores”.

DevOps no significa que Operaciones se convierta en un grupo de desarrollo. Significa que Operaciones trabajara para suavizar el camino entre el codificador y el usuario. Resulta que la forma más sencilla de operar es automatizando, y la forma más común de automatizar suele implicar cierta codificación. Por lo tanto, DevOps normalmente ocasionará que Operaciones tenga que codificar, al menos hasta cierto punto.

La mayoría de los sistemas operativos que Operaciones administra tiene algún lenguaje de programación diseñado para facilitar la automatización operacional. En Linux, por ejemplo, Perl y Python son lenguajes de scripting muy comunes. En Microsoft Windows, PowerShell ha asumido ese papel. Así que no estamos hablando de programación en C, C++, C#, u otro lenguaje de programación “profunda”. Se trata más bien de “scripting”, que por lo general en un lenguaje de nivel superior que está diseñado para tareas de automatización operacional. Como mencione en el capítulo anterior, la habilidad principal que Operaciones debería proporcionar a un entorno DevOps es la capacidad de automatizar en un lenguaje de scripting apropiado para su ambiente.

Pero una vez que Operaciones comienza a producir unidades de automatización, es decir, código, las Operaciones mismas necesitaran comenzar a actuar como una tienda de DevOps. Esas unidades de automatización son la aplicación que el codificador (Ops) entrega al usuario (en este caso, otros roles en el equipo de TI). Así que Operaciones necesita las herramientas y los enfoques de gestión que permitan liberar rápidamente su código, probarlo y desplegarlo en producción. Como los usuarios (por ejemplo los desarrolladores) generan constantemente nuevas necesidades Operaciones deben estar preparado para responder a esas necesidades.

Todo este concepto es a menudo uno de los mayores obstáculos para fomentar una mentalidad de DevOps en cualquier organización, especialmente en aquellas que están fuertemente apoyadas en ambientes de Microsoft Windows. El obstáculo se debe a que los administradores de Windows, en general, no han tenido la necesidad de “aprender a automatizar”, en gran parte porque el sistema operativo sólo comenzó a ofrecer esta capacidad en 2006 y solo ofreció una capacidad significativamente mejorada hasta 2012. Los administradores entonces como no han tenido las herramientas, no han aprendido las técnicas. El cambio siempre es aterrador para algunas personas (y para algunas organizaciones), por lo tanto, moverse de una administración basada en GUI (que no admite DevOps) a una administración basada en código (que sí se admite) puede ser aterrador.

Muchos administradores, una vez más, en un ambiente Windows, están acostumbrados a utilizar herramientas GUI para la administración de sus entornos. Tal vez se quejen de que las herramientas no funcionen de la manera que quieren, pero generalmente están lo suficientemente cerca y es por ello que las utilizan. Pasar a un mundo centrado en DevOps, sin embargo, introduce nuevas variables. ¿Qué tipo de código se está entregando? ¿Qué metodología utilizan los desarrolladores? ¿Cuáles son los problemas de producción en torno a la estabilidad y la disponibilidad? ¿Cuánto espacio hay para el error? ¿Qué tipo de ventanas de mantenimiento están disponibles? ¿Cómo se comunica con la base de usuarios? El gran número de variables significa que casi todas las organizaciones son únicas, lo que significa que las herramientas disponibles en el mercado no van a ser suficientes para resolver su problemática. Consecuentemente, DevOps casi que exige que Operaciones construya sus propias herramientas y procesos, generalmente “pegando” algunas tecnologías de plataforma. Eso es lo que he tratado en el capítulo anterior, aunque desde una perspectiva ligeramente diferente.

Ese proceso de “pegamento” es donde Operaciones se desvía hacia su propio desarrollo. Es posible que utilice el Administrador de máquinas virtuales de Microsoft System Center para administrar su infraestructura virtual, pero escribirá algún código para que haga lo que desee de acuerdo con sus procesos particulares. Puede utilizar Chef para manejar la configuración declarativa de entornos de máquinas virtuales, pero escribirá algún código para decirle a Chef exactamente qué es lo que desea y para administrar los elementos personalizados que sólo existen en su entorno.

Otro resultado de este enfoque de DevOps es que, una vez que se pone en ello, comienza a tratar su infraestructura como código, y comienza a abordar la gestión de la infraestructura de una manera más ágil. La virtualización, en particular, ha hecho esto tremendamente fácil, porque podemos eliminar y volver a crear entornos masivos con el solo toque de un botón. ¿No le gusta la configuración actual del entorno? No hay problema: modifique el documento de configuración declarativa y recicle el entorno. ¿No está contento con el resultado? Repita. Reconfigurar el entorno puede (y debe) ser tan fácil como modificar una estructura similar a un código, así como modificar una aplicación es tan fácil como cambiar el código. En otras palabras, una vez que utilice código, o algo parecido, para describir cómo debería verse su entorno, básicamente está tratando la infraestructura como código. Las metodologías de desarrollo como Agile y Lean comienzan a convertirse en una opción para gestionar infraestructura… y de repente, usted ya se está convirtiendo en DevOps.

Combinar mentalmente con todos estos conceptos - infraestructura como código, Operaciones como codificadores de pegamento - realmente abre algunas posibilidades. Ya no está limitado a este enfoque de “grandes proveedores”, donde tiene que encontrar una pila de proveedores que satisfaga todas sus necesidades (lo cual nunca fue realmente práctico). En su lugar, se siente cómodo utilizando los componentes de varios proveedores según sea necesario, porque crece confiado en su capacidad de pegarlos todos juntos en la estructura que necesita.