Llegamos a ustedes gracias a:



Columnas de opinión

Profundizando en los detalles de DevOps

Por: Matthew Heusser, consultor principal de Excelon Development

Matthew Hwusser, Excelon Development.

[02/07/2015] La idea básica detrás de Dev y Ops (desarrollo y operaciones) es conseguir que los dos roles trabajen juntos. Esto suena obvio, pero piense por un momento acerca de cómo los roles han sido implementados tradicionalmente. Operaciones es responsable por el funcionamiento normal y la confiabilidad; la manera más sencilla de mantener los sistemas operando es bloquearlos y evitar que cambien. El trabajo de un desarrollador de software es crear un cambio. Desde el principio, los incentivos para un rol están desalineados con el otro. La primera parte de DevOps, el indicio de una idea es también el rompimiento de barreras entre los dos roles. He aquí un ejemplo.

Por años, inclusive décadas, los administradores de sistemas han escrito pequeños scripts -Bash, Perl, Awk y Sed- para automatizar operaciones repetitivas y configuraciones. Estos scripts son código. Pero, a pesar del código, los administradores de sistemas escriben sin seguir ninguna de las prácticas que los programadores deben seguir. Probablemente no tienen requisitos, ni procesos formales de prueba, ni procesos de despliegue... puede que ni siquiera tengan control del código fuente. Sin estándares para el trabajo, probablemente el código esté en un lenguaje de programación distinto al del código de producción. Puede que incluso haya cosas que a los programadores les gustaría volver a utilizar, pero ni siquiera saben que existen. Si los roles realmente trabajaran juntos, en lugar de hacerlo en silos, podrían compartir conocimiento, prácticas e inclusive código base.

La automatización de las tareas repetitivas de los administradores es algo para lo cual los programadores están excepcionalmente calificados. Y este resulta ser un punto de partida clásico para los DevOps.

DevOps como concepto

Construir. Desplegar. Ejecutar. Volver a ejecutar las unidades de prueba. Integrar y revisar la automatización de punta a punta. Todos estos son procesos de negocios sencillos y definibles. Están tan bien definidos que los administradores de sistemas frecuentemente tienen manuales, FAQs y páginas de wikis que pueden copiar, pegar y reemplazar variables en ellas para realizar su trabajo diario.

Los programadores automatizan las cosas; eso es lo que hacen. Así que ¿por qué no combinar el rol del desarrollador (automatización) con el de operaciones (despliegue y mantenimiento)?

La superposición de esos roles -automatizar las partes de operaciones y pruebas que tengan sentido hacerlo- es el núcleo de la idea de DevOps. También va en contra de las ideas convencionales de TI y de ingeniería de procesos, en los que términos como "separación de tareas" implicaría que DevOps es algo malo. Nuevamente, todos esos documentos de procesos en Cascada insinúan que el software Scrum o Agile podría ser algo malo, también. Así están las cosas.

DevOps
Dos maneras de hacerlo

Un enfoque es simplemente rotar a los desarrolladores a las operaciones por unas semanas o meses. La teoría dice que el programador de operaciones revisará el código base actual en el control de versión correcto, automatizará las tareas rutinarias de manera inteligente, creará librerías de código reutilizable, reemplazará la instalación de máquinas físicas con máquinas virtuales creadas a través de código, y así por el estilo. Ciertamente hay algo de ganancia inmediata, pero parece ser probable que los programadores en operaciones sean aplastados por las cargas de trabajo o las políticas, y que la actual adopción de DevOps sea limitada.

Otra forma de hacer esto es incrementar las responsabilidades de soporte del equipo de desarrollo. Por ejemplo, un equipo de programación podría tomar toda la responsabilidad, desde la construcción hasta el despliegue y el soporte, rotando un programador a través de soporte, dos veces a la semana. Esto le proporcionaría a los desarrolladores una amplia exposición a la forma en que el código base funciona desde fuera, y también les ayudaría a sentir el sufrimiento de dar soporte a su propio trabajo. (Inclusive un grupo más pequeño de operaciones necesita soportar cierta infraestructura, como los servidores de producción y las bases de datos).

Automatizando los builds

Las herramientas de integración continua (CI -Continuous Integration) son probablemente las más populares y ampliamente utilizadas de aquellas mencionadas aquí. Algunas empresas continúan realizando builds, pero el potencial para los builds automatizados va más allá del paso de la compilación. Puede incluir el logueo y etiquetado de builds, preparando todo para clasificar y almacenar el build exacto en un archivo conectado al número y rama de correspondientes; y -posiblemente- también se pueda conectar los builds a las funciones.

Una vez que un build está completo, también puede ejecutar todas las pruebas unitarias -todo el tiempo- y luego realmente desplegar el software al servidor de desarrollo, prueba o ensayo. Las herramientas de CI pueden entonces ejecutar servicios web o verificaciones de GUI de extremo a extremo para ver si algo importante ha fallado con el nuevo código. Esta no es una entrega continua -el código no es empujado automáticamente a producción en cada compromiso. Algunas organizaciones compran un servidor virtual nuevo y fresco desde cero para cada despliegue, en lugar de "actualizar un entorno de desarrollo simple; algunos crean múltiples entornos virtuales, uno o más por programador).

Si el daño que un defecto puede ocasionar está en función de su gravedad y cómo mucha gente lo ve, entonces encontrar pronto el problema y arreglarlo puede limitar el daño. Encontrar el problema cuando se ha expuesto solo a un pequeño porcentaje de usuarios no siempre es posible, pero el monitoreo y la alteración visual pueden ayudar.

Hay una gran cantidad de información en las bitácoras de los servidores -desde qué tiempo están tomando las solicitudes en ser atendidas, hasta cuántos errores 404 y 500 está experimentando el sistema. Si se visualizan esos errores en un gráfico -quizás utilizando herramientas de código abierto como Grphite- el equipo puede ver esos problemas a medida que ocurren y tomar las medidas pertinentes. Una vez que el trabajo está completo, los pasos para un despliegue de producción pueden ser automatizados y colocados detrás de una página Web -o al menos una interfaz de línea de comandos. Cuando el servidor CI haga el siguiente build, el sistema de despliegue continuo solo necesitará ir un paso más allá, para producción.

El botón push despliega una ventaja en los arreglos de botones push, lo cual se combina con el monitoreo de producción para reducir drásticamente el tiempo de salida en vivo (TTL - Time to Live) de un defecto.

Banderas de configuración

Las banderas de configuración son un mecanismo para reducir aún más el tiempo de salida en vivo. En lugar de necesitar cambiar el código de producción, el programador cambia su código con un bloque de "(función) if { } alrededor del nuevo código. Para desplegar la función de vuelta, el programador cambia un archivo en el disco que almacena la bandera como encendida o apagada. Como esto no es un cambio de código, no requiere un nuevo despliegue/build. "Configuración de banderas: una historia de amor, de Noah Sussman, cubre este concepto en profundidad.

Imagine una bandera de configuración que está estratificada más por tipo de usuario, por lo que funcionalidad solo corre en empleados, luego en una familia de empleados, luego en beta u otros clientes que desean asumir el riesgo, luego en clientes regulares, luego en "la empresa y con clientes que tienen aversión al riesgo. El equipo puede desplegar una nueva función gradualmente, monitoreando el sistema y solicitando al usuario un feedback constante, antes de desplegar la función a una base amplia de usuarios. Aunque las implementaciones varían, una versión de esta estrategia, llamada "Prueba en producción, es descrita con cierto detalle en el libro del 2008 "Cómo probamos software en Microsoft.

Las ideas de arriba son en su mayoría conceptos; hay muchas formas de implementarlas, tanto en forma comercial como con código abierto. Una táctica común es crear una granja de servidores virtuales en una nube pública o privada. Los nuevos builds se crean pero no se despliegan -entonces el sistema cambia el balanceo d carga a la nueva máquina. Esto crea un "cambio de servicio desconocido para el usuario, y mantiene el sistema antiguo por al menos unos cuantos minutos, en caso de algo salga drásticamente mal. Configurar un conjunto de máquinas, reales o virtuales, requiere una gran cantidad de automatización de scripting -dos herramientas diseñadas para ayudar con esto, y comúnmente asociadas con DevOps son Chef y Puppet.

Quizás lo más decepcionante de todo lo relacionado con DevOps es la idea de que DevOps es un nuevo rol, o que esto crea un tercer "equipo, el equipo "DevOps. Aunque algunos desarrolladores pueden elegir hacer la automatización del build/despliegue o el trabajo de infraestructura, la idea era hacer que estas disciplinas funcionen juntas -no crear otro rol especializado que se encargue de los detalles que resultan demasiado oscuros de entender para otras personas como para hacerse cargo.

La prueba DevOps es una forma de evaluar rápidamente la medida en que su equipo ha adoptado DevOps y que se pueda dar el siguiente paso. Es una evaluación rápida y sencilla, lo cual significa que es imperfecta. Aun así, la prueba ha comenzado. Inténtelo. El próximo paso depende de usted.

Matthew Heusser, CIO (EE.UU.)