DevOps: irse por las nubes

¿Qué es DevOps?

Conjunto de procesos, métodos y sistemas para agilizar la comunicación, colaboración e integración entre departamentos de desarrollo (Dev), operaciones (Ops), Seguridad (Sec) y calidad (QA)

Es un concepto que busca la integración entre las áreas de desarrollo, operaciones, seguridad y calidad para satisfacer los cambiantes requerimientos de negocio, mientras se minimizan los riesgos que implica ese cambio.


¿Por qué debería de interesarme?

DevOps no es la respuesta a un problema tecnológico, lo es a un problema de negocio.


¿Y cuál es el problema?

1. Muchos proyectos están fallando debido a problemas en la transferencia (sea a producción, sea del conocimiento), que afectan en tiempo, dinero y alcance. Básicamente: un problema de velocidad de adaptación.

2. La operación del software desarrollado es YA un requisito no funcional, que evita la pérdida de tiempo, dinero y modifica el alcance. Un software que no contempla las necesidades de quienes realmente van a gestionarlo, es por definición, un software abocado a ser "odiado" y que no provocará interés en ser mantenido o ampliado.

3. Existe un "muro de confusión" entre Desarrollo y Operaciones, causado por una combinación de motivaciones, procesos y herramientas no siempre con objetivos alineados. Aún peor es el escenario donde Desarrollo es un ente externo a Operaciones.

4. El equipo que realizó en desarrollo raramente tiene que lidiar con los resultados a largo plazo de sus decisiones respecto a la arquitectura y decisiones, por lo que no cuentan con incentivos para mantener una cultura de explotación y mantenimiento de las aplicaciones que desarrollan

5. Los equipos de soporte, mantenimiento y operaciones, generalmente, cuentan con escasos recursos, tienen pocas oportunidades de cambiar de proyecto -fruto de la falta de transferencia de conocimientos-, y deben alternar sus tareas entre diferentes proyectos. Esto usualmente lleva a unas prácticas de operación que hacen que la calidad total del producto se deteriore a medida que pasa el tiempo, que a su vez implica que sean necesarias más horas de soporte.

6. El equipo del proyecto generalmente no se ve involucrado en el análisis de los problemas en el entorno de producción, y no sienten la necesidad de implementar los mecanismos necesarios para encontrar la causa raíz de un problema.

7. El equipo de desarrollo tan sólo realiza un limitado número de liberaciones de software para su puesta en producción, por lo que no encuentran incentivos a la hora de automatizar tareas y procesos, ni realizar pruebas en entornos de pre-preducción


¿Qué ventajas aporta?

La solución combina las visiones del área de Desarrollo (eminentemente innovadora) con la de gestión de la infraestructura (eminentemente conservadora) , integrando ambas bajo unos procesos que posibiliten la sencillez de operación de la plataforma, faciliten la creación de interrelaciones entre las tareas de estos grupos y habiliten nuevos procesos colaborativos, todo ello siempre enfocado hacia la mejora continua, la estabilidad y la obtención del máximo beneficio de la inversión en infraestructuras y equipos de operaciones y desarrollo, para lo cual es necesario que se realicen pruebas de calidad de los productos.

Todo nace con una idea
El proceso de negocio fundamental de cualquier organización es llevar una idea desde su concepción hasta el punto en el que genera beneficios, sean tangibles o intangibles. Para ello es necesario afinar los procesos que lo llevarán a cabo: algunos de ellos se centran en aspectos tecnológicos y otros en aspectos humanos. Aquí es donde entran en juego desarrolladores, operadores, calidad , arquitectos, gestión del cambio, seguridad... cada uno tiene que hacer su parte, del mismo modo que se trabaja en una cadena de montaje.

Si quitamos el contexto de los procesos de negocio ¿Qué nos queda?
Pues queda un montón de gente haciendo ”sus labores”, con lo que se pierde totalmente el incentivo de luchar contra la ineficiencia, la duplicación de esfuerzos, y el desacoplamiento de objetivos entre estos grupos.

!Salvese quien pueda!
Empiezan las acusaciones cruzadas: "falta documentación, ¿esto quién lo ha hecho? ¿por qué?"
Por lo tanto, y por el bien de ”nuestro negocio”, nuestra misión es reaccionar ante las demandas de más servicios, más estables, más productivos y en menos tiempo, de la forma más rápida, eficiente y disponible posible.

La palabra de moda es Ágil

¿Esto no suena mucho a las metodologías ágiles utilizadas en el desarrollo de software?

En efecto, sus aproximaciones a la solución de los problemas del negocio son similares, y por lo tanto, no deben de crearse ”islas de procesos, herramientas y personas”

Mientras que Agile Dev se centra en la creación y entrega de software, DevOps se centran en mejorar la integración y facilitar flujo entre las distintas fases de operaciones, acortando el ciclo de tiempo desde la concepción a la operación de un proyecto. Cuando nuevas metodologías de desarrollo (como aquellas conocidas como ágiles) son adoptadas en una organización TI basada en la tradicional separación por roles se crea una tensión interdepartamental fruto de la necesidad de ajustar las interrelaciones entre estos departamentos.

Por ello, DevOps es algo más: es un conjunto de procesos y métodos para aumentar la comunicación y colaboración entre departamentos. Las organizaciones que no ajustan estas deficiencias comunicativas, ven como paulatinamente la efectividad aumenta en el área de desarrollo, pero empiezan a ocurrir problemas en el resto de las áreas de las TI.

La adopción de DevOps está siendo impulsada por factores como:
1. El uso de procesos y metodologías de desarrollo ágiles

2. La demanda de mayor agilidad en la puesta en producción de versiones

3. Amplia disponibilidad de infraestructura virtualizada y en la nube, tanto interna como externa, y los cambios de mentalidad y métodos de trabajo que ello implica.

4. Incremento de uso de herramientas de la gestión de la configuración y automatización del CPD.

5. El uso de prácticas producción Just In Time: «producir los elementos que se necesitan, en las cantidades que se necesitan, en el momento en que se necesitan».

La mejora de la relación y colaboración aumenta la eficiencia y reduce el riesgo en la entrega, asociado a los cambios frecuentes en las prioridades, requisitos y objetivos de los procesos productivos.


¿Por qué se crea esa fricción?


Muchas organizaciones dividen las áreas de desarrollo y operación TI en diferentes departamentos. Mientras que los primeros son presionados por la necesidad de proveer frecuentes entregas de software con nueva funcionalidades, los segundos tienen como objetivo principal la estabilidad, disponibilidad y eficiencia de la infraestructura TI, lo que ralentiza la entrega del Servicio y su valor para el negocio.

• Los grupos de desarrollo no son conscientes acerca del impacto de su código en el área de operación de sistemas. Simplemente lo liberan sin involucrar a Operaciones TI en las decisiones que corresponden a la arquitectura de la aplicación.

• Los grupos de desarrollo fallan a la hora de comunicar la configuración o los cambios necesarios sobre el sistema base

• plican configuraciones manualmente en sus puestos de desarrollo y no documentan el proceso paso a paso. Muchas veces es necesario realizar ciclos de "prueba-error" hasta que se logra el resultado deseado, dando el resultado de que no se tiene claros qué pasos son los mínimos para que se apliquen efectivamente los cambios necesarios.
• Suelen tender a utilizar herramientas optimizadas para el desarrollo rápido, que son muy diferentes de los entornos donde realmente se van a ejecutar las aplicaciones, donde lo que prima es la estabilidad y el rendimiento.
• Dado que programan en sus propias estaciones de trabajo, generalmente no se utiliza el sistema operativo que será el utilizado en la fase de producción dando lugar a problemas e incompatibilidades.
• Durante el desarrollo, suelen utilizar entornos centralizados, mientras que en la producción cada vez es más frecuente encontrar sistemas distribuidos entre varias máquinas, sobre todo en entornos en la nube.
• Los desarrollos están basados en los requisitos funcionales extraídos de las necesidades del negocio.Sin embargo, el área de operaciones TI se centra en requisitos como disponibilidad, estabilidad, rendimiento...
• Operaciones intenta minimizar los riesgos en la infraestructura de la peor manera posible: evitando los cambios
• Si se evitan los cambios frecuentes en operaciones, pero estos siguen sucediendo en desarrollo, se crea una cola de cambios cada vez más grande que termina por colapsar ambos procesos, necesitando cambios más grandes.
• Cambios más grandes implican mayores riesgos
• Operaciones puede no estar completamente al tanto de las particularidades internas de la aplicación, haciendo difícil el diagnostico de problemas y procedimientos de puesta en producción.
• Desarrollo puede no estar completamente al tanto de las particularidades internas de la plataforma, haciendo difícil la adaptación del código a ésta .

¿Cómo se lleva a la práctica?

Fruto de lo anterior, ha aparecido un nuevo rol en TI cuya principal misión es la coordinación de las tareas de despliegue en los entornos de pre-producción. La necesidad de estos nuevos perfiles vienen de:

• La necesidad de "acercar" desarrollo y operaciones
• Transmitir el conocimiento la cada vez más compleja infraestructura TI: múltiples componentes desacoplados que establecen relaciones de interdependencia, que muchas veces no son visibles.
• Potenciar el número de entregas a producción, utilizando técnicas de desarrollo ágil e iterativo
• Equipos distribuidos: outsorcing, factorías de software, near-shore, off-shore, ...

El rol de Coordinador de Releases es similar al de un controlador aéreo, realizando tareas de coordinación entre diferentes equipos a fin de lograr una orquestación de las entregas, usando recursos compartidos por los equipos. Su área de competencia encaja dentro de la Gestión del Cambio, que es una disciplina relativa a la gestión de todo tipo de cambios en la infraestructura TI, y que es un rol principal en ITILv3.

El mantra de el coordinador de versiones es:

• Si cuando se escribe una aplicación se usan tests unitarios y pruebas de integración para asegurarnos de que la aplicación cumple las expectativas ¿Por qué no hacer lo mismo con la infraestructura?
• Cambios pequeños implican menores riesgos.
• Hay que proveer a los desarrolladores de más conocimiento de la plataforma sobre la que se ejecuta.
• Hay que proveer a los operadores de un conocimiento más profundo de la aplicaciones.
• Instauración de procesos simples y conocidos por todos, frente a procesos complejos y conocidos sólo por expertos
• Automatización de todo lo que no sea extremadamente necesario realizar a mano.
• Establecimiento de una metodología de colaboración activa entre las áreas implicadas, utilizando prácticas de SCRUM y/o Kanban

Conclusión

Podríamos concluir con que DevOps es en realidad una disciplina que combina las de áreas de ingeniería del software y operaciones, que se focaliza en el desarrollo del software para dar soporte a la infraestructura sobre la cual se ejecuta el software con el que los usuarios interactúan. A veces es conocido como desarrollo de sistemas , desarrollo de infraestructuras o infraestructure as code

¿Qué hace diferente un devops frente al clásico perfil de administrador de sistemas o desarrollador?

1. Habilidad de escribir código más allá de simples scripts. Dado que la infraestructura ya no depende del hardware, el comportamiento y componentes de la infraestructura pasa a codificarse y debe de ser considerada como parte del programa

2. Focalización en la estabilidad y disponibilidad de la plataforma. Un claro legado del área de operaciones, y el principal motivo de ésta.

3. Seguimiento exhaustivo de los estados en transición. Dado que ahora el software cambia rápidamente , las transiciones entre los estados de desarrollo, pruebas, pre-producción y producción deben de recibir toda la atención que se merecen.

4. Un ángulo de visión diferente del Negocio. Mientras que la misión de los desarrolladores es crear software que aporte ganancias al negocio, los devops tienen la misión de la prevención y reducción de eventos que impactan en el negocio. La clave está por lo tanto en el equilibrio entre estas facetas.


5. Los devops son los usuarios del software que ellos mismos desarrollan. Por lo tanto, nadie más que ellos van a sufrir las consecuencias de malgastar tiempo extra en encontrar la información necesaria para cumplir con sus objetivos.

6. Arquitectos, desarrolladores, tester, ... todos juntos. Si DevOps orbita alrededor de la colaboración entre "islas de roles", es natural que se establezcan las prácticas culturales necesaria como para que la diseminación del conocimiento se lleve a cabo y sea efectivo.

7. Consciencia de la existencia errores. No importa cuánto esfuerzo se ponga en el diseño de un sistema: un sistema complejo, tarde o temprano, experimentará un error imposible de predecir, fruto de la interacción (no programada) de los componentes. En Google, Amazon, y otros entornos distribuidos por ejemplo, han modelado sus sistemas teniendo esto en cuenta.

8. Calidad en producción. Algunas tareas no pueden ser adecuadamente probadas en entornos de prueba más pequeños o menos complejos que el entorno de producción. El desarrollo en fases y otras técnicas intentan reducir el riesgo, pero debemos ser conscientes de que obtener métricas de disponibilidad, capacidad, etcétera, sólo son válidas en el entorno de producción

9. Primero manual, después automatización. Cuando se valida un proceso productivo ES el momento de automatizarlo. Desarrollo no contará con tiempo para implementar el método automatizado, acuciado por los plazos. En producción, por lo tanto no será aceptable código que no cuente con código que automatice el despliegue y la operación

10. Los sistemas distribuidos son la norma. Los Sistemas de Información, con la explosión de la virtualización y el despliegue en Cloud, tienden a ser completamente distribuidos y sin estados. Esto es pasar de un modelo donde el Sistema de Información se modela "dentro de un CPD" a un modelo donde no sólo no existe el concepto de propiedad, sino que además los servicios pueden ejecutarse en distintas máquinas en distintos CPDs, tanto internos como externos.