Capacidades operacionales de un entorno DevOps

¿Cuáles son algunas de las capacidades que necesita implementar en un entorno DevOps?

Creación automatizada del entorno

En primer lugar, y posiblemente, antes que cualquier otra cosa, necesita capacidad de alistar entornos automáticamente y constantemente. Es una tarea fundamental pero no es fácil.

• Automáticamente: Significa permitir a una variedad de roles autorizados dentro de su organización configurar entornos bajo demanda, sin involucrar a ningún ser humano. Esto podría ser un entorno para desarrollo o un entorno de pruebas, y probablemente sea algo que necesitan hacer varias veces al día. También podría ser un proceso automatizado alistando un entorno en el que ejecutar pruebas de aceptación.
• De manera consistente: Los entornos que se “crean” deben reflejar con precisión el entorno de producción final. Hay dos formas de hacerlo:
  • Definir un método de creación de entornos, y utilizarlo para crear el entorno de producción, así como cualquier otro entorno cuando sea necesario. De esa manera, sabrá que todos los entornos coinciden.
  • Modelar un entorno a partir del entorno de producción. A continuación, puede aplicar ese modelo a cualquier otro entorno que necesite alistar.

Tecnologías de gestión de configuración emergentes, como DSC de Microsoft, o productos como Chef, Salt, Puppet y Ansible, son ejemplos de herramientas que ayudan a implementar algunas de estas capacidades. Cuando puede escribir algún tipo de documento de configuración que describe el entorno y, a continuación, tiene una herramienta que puede implementar ese documento donde y cuando quiera, se estará acercando a la capacidad necesaria. Los containers son otra tecnología que puede ayudar en este espacio, ya que le permite abstraerse de una serie de variables, reduciendo la transformación y complejidad.

Es fácil entender por qué esta es una capacidad tan importante. Si puede garantizar que todo lo que una aplicación puede ejecutar (desarrollo, prueba o producción) es exactamente el mismo, todo el tiempo, entonces es mucho menos probable que tenga problemas para mover el código de un entorno a otro. Además, al ofrecer a otros roles, como los desarrolladores, la capacidad de generar estos entornos bajo demanda, ayuda a facilitar más pruebas en el mundo real y elimina más problemas durante la fase de desarrollo.

No quiero minimizar la dificultad de crear esta capacidad, ni tampoco ocultar los problemas que esto trae a la gestión. Los entornos requieren de recursos para funcionar, por lo tanto, las organizaciones pueden estar justificadamente preocupadas por permitir a los desarrolladores “crear” máquinas virtuales a su antojo. Pero no estamos hablando de capacidades sin gestión alguna. Eso es algo que me mata cada vez que entro en una discusión sobre DevOps con ciertos tipos de organizaciones. “¡Bueno, una vez que demos a los desarrolladores permisos para crear las máquinas virtuales que quieran, será el fin del mundo!” Y de esta forma presienten una derrota temprana. Pero eso no es de lo que estamos hablando.

La razón por la que DevOps tiene “Ops” al final, es porque Operaciones no desaparece. Los desarrolladores no “toman el control”. Nuestro trabajo es proporcionar a los desarrolladores un conjunto gestionado de capacidades. Así que sí, un desarrollador que trabaja en un proyecto debe ser capaz de “montar” una máquina virtual sin la intervención de nadie, también de ser capaz de reciclarla, es decir, eliminar y volver a crear ese entorno en el momento que se requiera. Pero eso no significa que pueda llegar a cambiar la especificación del entorno por sí mismo, ni tampoco significa que obtendrá un dominio libre de la infraestructura de virtualización. No.

Permítanme ofrecer un ejemplo realmente simplista, pero increíblemente real, de lo que estamos hablando. El servicio Elastic Beanstalk de Amazon está diseñado para crear nuevos entornos, es decir, máquinas virtuales, más o menos a la carta, en respuesta a la carga del cliente. Cada nueva máquina virtual se inicia como una copia idéntica de una imagen del sistema operativo base y cada nueva máquina virtual puede cargar contenido, como un sitio web, desde un repositorio de GitHub. Así que ahí mismo, ha creado algo de la automatización y la coherencia que necesita. Con un “botón de inicio”, o en reacción a la carga del usuario, se puede automatizar la creación de nuevos entornos, y como todos provienen de fuentes conocidas estándar, este entorno será coherente..

Es muy probable que los desarrolladores necesiten cambios más allá de lo que hay en la imagen de base del sistema operativo, por lo que estos deben poder especificar elementos adicionales. Pueden establecer variables de entorno, especificar paquetes para descargar e instalar, y así sucesivamente. En el pasado, un desarrollador habría manipulado su entorno de desarrollo hasta que todo funcione, y luego con suerte comunicar los resultados de esa manipulación a alguien en de Operaciones. Ops entonces, con suerte, volvería a crear fielmente lo que el desarrollador hizo. ¿Pero se obtuvieron las versiones correctas de los paquetes? ¿Se configuraron todas las variables de entorno?

Sin embargo, en Elastic Beanstalk, los desarrolladores no sólo “modifican” el entorno. Eso es porque cada vez que una máquina virtual se apaga, se desvanece. Cualquier retoque que se haga se pierde. En el siguiente inicio, se vuelve a la imagen del sistema operativo base. Por lo tanto, como parte del origen del proyecto en GitHub, los desarrolladores pueden especificar un archivo de configuración que enumera explícitamente todos los paquetes adicionales, la configuración del entorno o lo que sea que necesiten. Dado que esa información de configuración forma parte de la fuente GitHub, cada nueva VM creada por Elastic Beanstalk se creará con la misma configuración exacta, cada vez.

Este es un enfoque muy DevOps, y en este caso, Amazon ha asumido el papel de “Ops”. Si un desarrollador quiere hacer un cambio ambiental, modifica la fuente del proyecto y luego le dice a Amazon que recicle el ambiente. Todo se apaga, y un ambiente nuevo y fresco se libera. Está completamente documentado, así que, si funciona de la manera que el dev quiere, entonces será perfecto cuando se usa para pruebas, producción o cualquier otra cosa. Y, de una manera típica centrada en la nube, Ops, es decir, Amazon, no tiene que involucrarse de ninguna manera. Han creado interfaces de automatización que permiten a cualquier usuario autorizado modificar lo que quiera.

Como una barra lateral, esta idea de DevOps es una especie de seguimiento del concepto de “nube privada”. Nube privada significa simplemente ejecutar sus recursos de TI privados de una manera similar a los proveedores de una nube pública, lo que implica la automatización en el lado de Operaciones. Se basa en una forma de especificar quién puede hacer qué, y luego dejar que lo haga por su cuenta. Con un proveedor de Cloud público, los permisos consisten más o menos en “lo que se paga”, pero en una situación de nube privada, los permisos pueden ser mucho más granulares o incluso completamente diferentes. Nadie sugiere que construya su propio AWS o Azure. Eso no es lo que significa nube privada. Sin embargo, verá que las capacidades de la nube privada son las mismas que debe proporcionar como persona de Operaciones, para habilitar un enfoque de DevOps dentro de su organización.

Infraestructura de desarrollo y pruebas

Como describí en el capítulo anterior, la administración de TI tradicional coloca algunas “puertas” bastante firmes entre desarrollo, pruebas y, especialmente, Operaciones. “Operaciones” es más o menos un sinónimo de “producción”. En DevOps, rompemos esa relación y eliminamos las puertas. Operaciones es responsable de la infraestructura, ya sea que la infraestructura se para soporte de desarrollo, de pruebas o a los usuarios de producción. Y esas diferentes fases del ciclo de vida de la aplicación se integran mucho más estrechamente en DevOps. Algunas de las cosas de alto nivel que necesitará son:

• Repositorios de código fuente. Git es un ejemplo común en estos días, al igual que Microsoft Team Foundation Server y algunos otros. Lo importante es que las herramientas de sus desarrolladores estén estrechamente integradas con lo que haya elegido. Idealmente, estos repositorios deberían tener, o ser capaces de integrarse con, algún tipo de “codificación avanzada”. Por ejemplo, el repositorio debería ser capaz de ejecutar pruebas predefinidas en el propio código antes de permitir el registro de cambios, y podría realizar una rutina automatizada de compilación y pruebas cada vez que se “detecte” código nuevo o cambios en el mismo.
• Tableros de instrumentos. Los desarrolladores y probadores necesitan tener acceso a las capacidades operativas que les han proporcionado, como la de reciclar un entorno de desarrollo virtual. Idealmente, se puede integrar esto como parte de su herramienta de gestión principal, o como un entorno de desarrollo integrado. Ser capaz de hacer clic en un botón para “compilar eso, preparar un entorno de desarrollo, cargar el código compilado y ejecutar la aplicación” es bastante potente. En los casos en que ese nivel de integración no sea posible, entonces necesitará proporcionar alguna otra interfaz para hacer que algunas de esas actividades sean fáciles de llevar a cabo.
• Herramientas de prueba. Una cierta cantidad de pruebas tiene que ser automatizada, para que los desarrolladores pueden obtener retroalimentación inmediata, y para que las pruebas se pueden ejecutar de la manera más coherente posible.

Esa última capacidad es quizás una de las más complejas. En un enfoque ideal (aunque ciertamente no el único, e incluso este será un ejemplo simplificado), un flujo de trabajo podría ser algo como esto:

1. El desarrollador escribe código.
2. El desarrollador ejecuta código en un entorno de desarrollo “privado”, realizando pruebas unitarias.
3. El desarrollador repite los pasos 1-2 hasta que esté satisfecho con el código y, a continuación, lo verifica en un repositorio.
4. El repositorio ejecuta ciertos controles de calidad, que podrían ser simplemente cosas como hacer cumplir las convenciones de codificación, antes de permitir el registro definitivo.
5. Si el check-in tiene éxito, el repositorio arranca una compilación automatizada del código. Esto se implementa en un entorno de pruebas recién creado.
6. Las herramientas de pruebas automatizadas ejecutan una serie de pruebas de aceptación en el código. Esto puede implicar proporcionar entradas específicas a la aplicación y luego buscar salidas específicas, “hackear” datos en una base de datos para probar la respuesta de la aplicación, etc. La creación de estas pruebas es realmente un esfuerzo de codificación en sí mismo, y puede ser completado por el desarrollador que trabaja en el código, o por un codificador de pruebas dedicado.
7. Los resultados de las pruebas se almacenan - a menudo como una parte del repositorio de código fuente.
8. Si las pruebas tuvieron éxito, la compilación se prepara para su implementación. La implementación puede ocurrir durante una ventana programada después de la compilación.

Puede ver que el trabajo humano aquí está casi todo del lado de los desarrolladores, que es una razón por la que la gente se refiere a DevOps como una “metodología de desarrollo de software”. Sin embargo, la pieza Ops proporciona toda la infraestructura y la automatización desde el paso 4, permitiendo que una construcción exitosa se pueda mover directamente al ambiente de producción.

Obviamente, las diferentes organizaciones tendrán diferentes puntos de vista. Algunas podrían obligar a las pruebas de aceptación de usuario como un paso manual adicional, aunque Ops podría ayudar a automatizarlo. Por ejemplo, después del paso 7, puede automatizar la creación de un entorno de prueba de aceptación de usuario, implementar el código en ese entorno y, a continuación, notificar a alguien que esté listo para realizar las pruebas. Su aceptación podría desencadenar el paso a producción, o su rechazo podría regresar al desarrollador y comenzar de nuevo en el paso 1.

El punto es que Operaciones debe proporcionar la automatización para que esta secuencia se ejecute con la menor intervención manual como sea posible. Ciertamente, Ops nunca debe actuar como un guardián. No son probadores de código. Si el código pasó los puntos de control de calidad que se han definido, entonces el código está listo para ser implementado, y todo eso debe ser tan automáticamente como sea posible. Incluso el despliegue - una vez aprobado, y en cualquier horario que se haya definido - debería ocurrir automáticamente.

Se puede ver a DevOps, como una filosofía abstracta, que en realidad requiere una gran cantidad de herramientas concretas. Y tal vez usted puede observar que, debido a que las organizaciones tienen todas diferentes maneras de administrar el proceso, sería difícil para los vendedores comerciales producir esa herramienta. En realidad, no existe un enfoque de “tamaño único” para DevOps, lo que significa que Operaciones acabará creando una gran cantidad de herramientas propias. Ahí es donde entran en juego las tecnologías de plataforma. Pueden proporcionar un conjunto de bloques de construcción que faciliten la creación de las herramientas de DevOps personalizadas que necesitará.

Supervisión de la experiencia del usuario final

Esta es quizás la parte más importante de una organización DevOps, y es la más fácil de pasar por alto.

Como una persona de operaciones de TI, es probable que ya esté bastante familiarizado con el monitoreo, y no se equivoca: es tan importante en DevOps como antes de DevOps. Supervisión no sólo para notificar a alguien cuando algo va mal, sino también supervisar las aplicaciones de perfil (y sus servicios de apoyo e infraestructura), para que se puedan resolver proactivamente los problemas antes de que se conviertan en graves.

Pero la definición de “seguimiento” de IT Ops a menudo no es tan inclusiva como debería ser. Tendemos a monitorear solamente las cosas que están directamente bajo nuestro control. Monitoreamos el uso de la red, la carga del procesador y el espacio en disco. Supervisamos la latencia de la red, los tiempos de respuesta del servicio y la salud del servidor. Controlamos estas cosas porque podemos afectarlas directamente.

Una de las mayores colaboraciones que una organización de DevOps puede tener, sin embargo, es monitorear la experiencia del usuario final. Es algo que nosotros, como gente de TI, no podemos tocar directamente, pero si la razón de ser de TI es entregar aplicaciones y servicios a los usuarios, entonces la experiencia del usuario final de esas aplicaciones y servicios es literalmente la única métrica que importa. ¿Por qué medimos la latencia de la red? Porque contribuye a la experiencia del usuario. ¿Por qué medimos el tiempo de respuesta del servicio? Experiencia de usuario. Intentamos medir indirectamente la experiencia del usuario final, porque a menudo no tenemos forma de medirla directamente.

La filosofía de desarrolladores y operaciones de DevOps llega a la cumbre con la supervisión de la experiencia del usuario final. Los desarrolladores deben crear aplicaciones con la capacidad de rastrear la experiencia del usuario final. Por ejemplo, cuando una operación común está a punto de comenzar, la aplicación debe rastrear la hora de inicio y, a continuación, seguir la hora de finalización. Cualquier paso importante entre ambos debe recibir una marca de tiempo, también, y esa información debe registrarse en algún lugar. En Operaciones, necesitamos proporcionar un lugar para que el registro - ese artefacto de rendimiento - viva, y necesitamos proporcionar una forma para que los desarrolladores accedan a él. Tenemos que determinar a que se parece el rendimiento “normal”, y definir una ruta para realizar el seguimiento de las afectaciones en esa línea base. Operaciones pueden ser responsables de la supervisión en sí, pero los desarrolladores, en su código, deben proporcionar la instrumentación para controlar lo que más importa.

Si los números de la experiencia del usuario final comienzan a disminuir -digamos, el tiempo que se tarda en realizar una consulta y mostrar los resultados comienza a hacerse más y más largo -, podemos buscar una instrumentación más detallada y ver si podemos encontrar la causa. ¿Es latencia de la red? ¿Tiempo de respuesta del servidor? ¿Alguna otra correlación que pudiera apuntar a una causa? Pero al medir directamente lo que nuestros usuarios experimentan, contamos con una métrica de alto nivel infalible que representa lo más real que podemos tener en el radar.

Estoy extendiéndome en el tema de monitorear de la experiencia del usuario final no sólo porque es útil e importante, sino también porque es uno de los ejemplos más fáciles de comprender acerca de lo que se trata DevOps. Tradicionalmente, los desarrolladores se han preocupado por la experiencia de los usuarios (en teoría), pero están extremadamente desconectados de ella. Operaciones en cambio, está muy conectado a lo que los usuarios experimentan (después de todo ellos reciben las llamadas al Help Desk), pero son relativamente impotentes para aplicar medidas correctivas. A través de la colaboración que impulsa la filosofía de DevOps, sin embargo, los desarrolladores y el personal de operaciones pueden unirse para hacer un trabajo colectivo mucho mejor.