Los beneficios de DevOps: cómo moldear a su equipo para que tenga éxito

En la parte 1 , exploramos la definición de DevOps y abordamos algunos de los desafíos que existen al implementar DevOps en organizaciones de TI. En la parte 2, veremos los beneficios de usar el modelo DevOps dentro de sus equipos.

Volviendo a la definición de DevOps de la Parte 1, DevOps se puede definir simplemente como: las personas que crean la aplicación, ejecutan la aplicación. Entonces, ¿por qué DevOps? ¿Por qué adoptar este enfoque? ¿Cómo es mejor que el modelo tradicional de función dedicada Build / Run que se implementa comúnmente en las organizaciones de TI? ¿Qué problemas resuelve? Repasemos algunas de las fallas clave del enfoque tradicional de compilación o ejecución. Estas deficiencias darán una idea de cómo DevOps puede ser más beneficioso para las organizaciones.

En el modelo tradicional de función dedicada Build / Run, cada función tiene prioridades en competencia de manera efectiva. “Build” quiere moverse lo más rápido posible, implementando funciones en Producción en el ciclo más corto posible. “Run” quiere estabilidad por encima de todo. Si alguna vez ha sido el técnico responsable durante un P1, sabe lo intensa que es esta situación. Y hará todo lo que esté a su alcance para evitar que esto ocurra. A menudo, esto significará minimizar la tasa de cambio en el sistema de producción. Los profesionales de TI son conscientes de la naturaleza frágil de muchas soluciones de TI. El adagio “Si no está roto, no lo arregles” se modifica para que los profesionales de TI digan “no lo toques para que no se rompa”. Por lo tanto, “Ejecutar” a menudo quiere ralentizar el ciclo de Cambio tanto como sea posible. La tasa de cambio deseada es una prioridad conflictiva en este modelo,

El modelo funcional genera externalidades en la forma en que trabajan: el lenguaje elegante de su trabajo empuja los problemas que crean a los demás. Como “Build” a menudo se ejecuta en la ejecución del proyecto (Waterfall, Agile o algo intermedio, no importa), la mayoría se establece utilizando el modelo de caso de negocios común que dice efectivamente “Si invertimos X, obtendremos Y”. Una vez aprobado, el éxito del proyecto es a menudo una medida de la parte “Invertir X” del caso de negocio, es decir, medidas de éxito puntuales, presupuestarias o centradas en hitos. Y asegurarse de que la “Inversión X” parezca exitosa a menudo puede ocurrir a expensas del lado “entonces obtendremos Y” de la ecuación, que es la parte más importante de la ecuación, es el rendimiento. Para que un proyecto reclame el éxito al cumplir con sus medidas de éxito a tiempo / dentro del presupuesto / centradas en los hitos, los problemas conocidos en un proyecto de construcción a menudo quedan sin resolver. Son “arrojados por encima de la valla” para que “Run” se ocupe de ellos después de que el proyecto haya terminado.

Cada desarrollador de cada proyecto ha escrito una función que tiene una probabilidad razonable de causar problemas importantes una vez implementada. Entonces, ¿por qué ocurre esto y por qué no lo corrigen? ¿Son malos en su trabajo? ¿Escriben el código con flojera? Si haces esta pregunta, probablemente no seas un programador. Siempre puede distinguir a los codificadores de los no codificadores, es decir, las personas que han escrito incluso aplicaciones básicas frente a las que nunca han escrito una línea de código. Los no codificadores no pueden comprender que los errores están 100% seguros en las soluciones de TI. En su propia experiencia, un “error” son los errores ortográficos en un correo electrónico o documento de Word, con su error claramente resaltado (incluso corregido) por la propia aplicación antes de que se envíe a su destinatario. sus errores son claros y fáciles de corregir e imaginan que debe ser el mismo al escribir software. Irónicamente, incluso existen errores en este contexto, ya que los creadores de contenido no se molestan con la revisión básica y emiten contenido con errores ortográficos. Pero este punto escapa a los no codificadores. Los errores son ciertos en TI y ocurren con mayor frecuencia en casos excepcionales, que son difíciles de prever para los desarrolladores.

“¿Funciona en mi máquina…?” A menudo se presenta como una defensa combinada, una declaración fáctica y una pregunta cuando un profesional de TI le informa al desarrollador un error de producción. El probablemente atónito IT Pro murmurará en respuesta “bueno, no se está ejecutando en su máquina…”. El problema es que, como la máquina de los desarrolladores, es un entorno de circuito cerrado. Los casos de excepción generalmente no se experimentarán en este entorno. Incluso los intentos de imitar entornos de producción en un entorno de desarrollador individual se quedan muy cortos, espere, no entornos de producción. Por lo tanto, incluso cuando el desarrollador tiene la sospecha de que una función está mal escrita, puede cumplir con su objetivo funcional, pasar rondas de prueba y ser liberado. Esto crea un error de bomba de tiempo, esperando que ocurra ese caso de excepción,

Parece que los desarrolladores, ¿verdad? Equivocado. Aquí está la cuestión: los desarrolladores son la parte superior de la cadena alimentaria de TI. Es el pequeño y sucio secreto de TI. Los desarrolladores pueden realizar literalmente todas las demás funciones de TI (probador, profesional de TI, administrador de red), pero no funciona al revés. Los probadores, los profesionales de TI, los administradores de red NO PUEDEN codificar como los desarrolladores, aunque a menudo actúan con la actitud que pueden. Su secuencia de comandos no es un código de aplicación. Por lo tanto, no se equivoque, los desarrolladores son las estrellas del rock, están tratando de construir el futuro para sus clientes.

En el lado Run de la valla, los equipos “Run” generan sus propias externalidades. A menudo, esto es un subproducto de las circunstancias en las que operan. La financiación de la “ejecución” de TI a menudo se considera un costo puro en el caso de negocio, no una inversión. En lugar de objetivos puntuales o dentro del presupuesto, los objetivos del equipo de Run son a menudo una visión poco realista de “hacer más con menos” constantemente. En la práctica, esto generalmente se convierte en “hacer menos con menos”. Las actividades importantes se descartan a medida que los recursos se dispersan. De hecho, estas pueden ser las actividades exactas que habrían evitado que ocurriera un caso excepcional, como ayudar a los Desarrolladores a establecer un entorno de desarrollo similar o habilitar herramientas que minimicen el riesgo de cambios de producción, como la alternancia azul / verde. Al igual que los desarrolladores, es un error pensar que los profesionales de TI son malos en su trabajo.

Prioridades en conflicto. Se crean externalidades. Salida lenta y de baja calidad. Hay más: herramientas y procesos separados. Bombas de tiempo de producción. Enfoque en silos. Estos son solo ALGUNOS de los problemas con el modelo funcional tradicional Build / Run.

Entonces, ¿cuál es el mejor enfoque? ¡DevOps por supuesto! DevOps tiene como objetivo garantizar que se logre el equilibrio adecuado entre el progreso de las características de la aplicación (la “compilación” tradicional) y la estabilidad de la aplicación (la “ejecución” tradicional), ya que la propiedad de DevOps existe en AMBOS el código (donde se construirán nuevas características) la aplicación Productionised (el tradicional “Run”).

Los beneficios de DevOps

Al ver cómo se desempeña DevOps en el contexto de los problemas descritos, resulta fácil ver por qué DevOps funciona y, en la mayoría de los casos, es un modelo operativo superior:

• “Prioridades en conflicto” se convierte en “Un conjunto de objetivos de equipo”– En primer lugar, no hay conflicto de resultados entre Dev y Ops, ya que los objetivos son los mismos. En lugar de que el equipo de Build Project tenga la tarea de entregar nuevas funciones lo más rápido posible, el equipo de DevOps es responsable de lograr una tasa rápida de cambio. En lugar de que el equipo de Operaciones sea el único responsable de brindar la disponibilidad de las aplicaciones, el Equipo de DevOps es responsable de maximizar el tiempo de actividad. El equipo trabaja de manera cohesiva para lograr estos resultados, incluso en las circunstancias en las que ha definido roles dentro de sus equipos de DevOps. De esta forma, se logra el equilibrio perfecto entre progreso y estabilidad. Es importante destacar que este no es un escenario de compensación. En DevOps, tanto la tasa de cambio como la estabilidad generalmente ven mejoras. El equilibrio es que, en DevOps, los objetivos se establecen en pie de igualdad. No comprometes uno por el otro.
• “Externalidades creadas” se convierte en “Boomerangs de calidad”– En DevOps, los problemas creados son bumeranes: sus fallas vuelven a morder y el equipo debe trabajar en conjunto para resolverlos. Como desarrollador, esto significa que el código mal escrito que causa un incidente de alta prioridad encontrará su camino de regreso para que lo arregle. El equipo debe implementar en la práctica un enfoque más riguroso de la garantía de calidad, lo que generará resultados de mayor calidad. En el lado de Operaciones, necesita conocer el contexto de la aplicación; para la disponibilidad y el rendimiento de la aplicación, ahora no hay separación de la capa de la aplicación y las capas abstractas que se encuentran debajo, como SO, VM y Red. Se requiere la propiedad de un extremo a otro y el equipo y los clientes confían en proporcionar una plataforma y un entorno que respalden el logro rápido de los resultados del cliente.
• Las “bombas de tiempo de producción” se convierten en “obstáculos de velocidad de producción” : DevOps no garantizará que nunca tenga una interrupción de producción o un problema de producción significativo. Sin embargo, el marco minimizará estos problemas y será más eficaz en la detección temprana. El trabajo en equipo y las herramientas se combinan para aumentar la producción de calidad, lo que minimiza las bombas de tiempo. La telemetría de la aplicación DevOps puede detectar el rendimiento o los comportamientos de la aplicación que se desvían de la línea de base: el canario en la mina de carbón para la detección temprana de problemas importantes de producción. Estos se combinan para mejorar la confiabilidad de la aplicación, lo que ayuda a maximizar el retorno de la inversión.
• “Herramientas y procesos separados” se convierten en “Herramientas y procesos que abarcan el resultado”: DevOps es fundamentalmente un problema de personas. Sin embargo, las herramientas y los procesos son importantes. DevOps fomenta un conjunto singular de herramientas que abarcan la capacidad de la solución de un extremo a otro, no un conjunto de herramientas para desarrolladores y un conjunto de herramientas para operaciones. Este singular conjunto de herramientas (y procesos de apoyo) es fundamental para lograr los resultados del equipo. CICD, automatización de pruebas, control de fuente, monitoreo y telemetría de aplicaciones, IAC, implementaciones azules / verdes: estos se vuelven esenciales para que el equipo entregue los resultados en plazos más cortos y produzca resultados de mayor calidad. Cubriremos el tema de Herramientas y procesos en una publicación posterior.
• “El enfoque en silos se convierte en” “Trabajo en equipo para cumplir”: lo que a menudo no es evidente es el poco trabajo en equipo que se requiere para la implementación de un proyecto de TI. A las personas se les asignan roles, toman entradas y producen salidas. La colaboración generalmente se limita a la resolución de problemas arquitectónicos. Se siente como el trabajo en equipo, pero no lo es. Es algo más parecido a un relevo de varios carriles en analogías deportivas, donde la gente toma el testigo por su pierna. Incluso para proyectos ágiles, así es como se ejecutan comúnmente. En el caso de DevOps, no hay una fecha de finalización ni una línea de meta que alcanzar. DevOps se parece más al baloncesto. Es posible que tenga posiciones definidas (armador, escolta es igual a desarrollador, probador, etc.) y es posible que tenga responsabilidades principales alineadas con los individuos, pero todos trabajan juntos no solo para anotar en un extremo (¡lanzamiento de funciones!) Sino también para defender a la oposición en el otro. (¡maximice el tiempo de actividad!). Esta implementación del trabajo en equipo produce mejores resultados y una mayor satisfacción del equipo que realiza el trabajo.

En resumen, lo que hace que DevOps sea un modelo preferido sobre el modelo tradicional de función dedicada Build / Run es que, cuando se implementa correctamente, DevOps es un modelo operativo superior para IT Build AND IT Run. Es lo mejor de ambos mundos.

Volviendo a nuestro servicio administrado de MuleSoft DevOps, nuestro servicio está construido y entregado con estos objetivos en mente. El equipo que construye sus soluciones MuleSoft, ejecuta las soluciones, por lo que tenemos un conjunto de objetivos de equipo que nos esforzamos por lograr. Se producen resultados de mayor calidad de manera constante y se maximiza el tiempo de actividad de la aplicación. Establecemos las herramientas y procesos que apoyan los objetivos end-to-end del servicio.

“¿Pero qué pasa si no creamos la aplicación? ¿Estás diciendo que no podemos ejecutar DevOps? ”

“Ejecutamos proyectos y necesitan tener una fecha de finalización. ¿Estás diciendo que no podemos ejecutar DevOps? ”

“¿Cómo encaja Agile con DevOps? Si ejecutamos Agile, ¿estás diciendo que no podemos ejecutar DevOps? ”

Estas son grandes preguntas que abordaré en otra publicación de blog.

Obtén más información sobre nuestro servicio administrado MuleSoft DevOps o contáctanos para una discusión en profundidad: connect.mx@capgemini.com

Jeff Nowland es director de MuleSoft Managed Services en Capgemini y tiene 10 años de experiencia en Managed Services.