DevOps, ¿construir o comprar? ¿Y qué es eso?

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

¿Qué es DevOps? Todos tienen una respuesta. Sin embargo, casi todas son diferentes.

CI / CD es a menudo la respuesta que se da. La integración continua y la implementación continua deben ser parte de DevOps, pero es solo una herramienta y un proceso para ayudar a lograr un resultado, no la definición de DevOps en sí. Pero espera, ¿es CI / CD un acrónimo de “Integración continua y despliegue continuo”? ¿O es “integración continua y entrega continua”? ¿O son ambos? ¿Y cuál es la diferencia de todos modos? Incluso dentro de CI / CD, no encuentra una consistencia en la definición.

IAC o Infrastructure-as-Code es otra respuesta común. IAC permite una implementación y expansión coherente y repetible de plataformas subyacentes. La definición de plataforma se mantiene como un conjunto de “plantillas estructuradas” que son de naturaleza “similar a un código”. Sí, IAC puede ser una parte esencial de DevOps, pero convertir a los profesionales de TI en desarrolladores no es la intención de DevOps, por lo que IAC no es la respuesta.

¿Qué pasa con la automatización de pruebas? La automatización de pruebas es vital para reducir el tiempo necesario para implementar un cambio en producción. Cuantas más pruebas manuales tenga, más largo será cada ciclo de implementación. Si bien Testing Automation es otra parte del rompecabezas de DevOps, no es solo la respuesta.

¿SRE o ingeniería de confiabilidad del sitio? Bueno, SRE y DevOps pueden considerarse como caras diferentes de la misma moneda: una desarrollada y definida por Google (SRE) y la otra desarrollada y definida de manera más orgánica dentro de la comunidad de TI más amplia (DevOps). Entonces, SRE es más un acrónimo (otro) de DevOps, que una definición.

Entonces, ¿qué es DevOps? En pocas palabras, DevOps significa ‘las personas que crean la aplicación, ejecutan la aplicación’. 

Una vez más, las personas que crean la aplicación, ejecutan la aplicación. Ahora, “aplicación” aquí puede significar “código” literalmente, o una “aplicación” o “solución” abstraída, formada por múltiples capas de tecnología. Sorprendentemente (o como era de esperar) la definición está ahí mismo en el título – “Dev” y “Ops”, unidos. Y es singular, es decir, un solo equipo con un solo conjunto de resultados.

DevOps presenta desafíos reales para que los equipos de TI lo implementen para muchas organizaciones que provienen de una estructura tradicional. Los equipos de TI a menudo se estructuran en un modelo funcional de diseño, construcción y ejecución, en silos. Este modelo se ha implementado independientemente de si los equipos de TI son internos o subcontratados, ya que la subcontratación se basaba en estas líneas funcionales. En este modelo, los proyectos de TI (ágiles o en cascada, no importa) crean o extienden soluciones, que se entregan al soporte, con mucho conocimiento perdido en el camino. Los equipos de operaciones a menudo llaman a esto la bomba de tiempo, arrojada por encima de la cerca donde esperan lo inevitable. En contra de este modelo, el “Dev” de DevOps se alinea con la implementación del proyecto “Construir” y las “Operaciones” con “Ejecutar”, con funciones de Soporte de Nivel 1, 2 3.

Entonces, ¿cómo puedes lograr DevOps de manera realista en tu organización? ¿Tienes que cambiar todo tu modelo funcional de TI a DevOps? ¿Necesitas realinear a todo tu equipo de TI o comenzar con un equipo? ¿Necesitas comprar toda la tecnología nueva o usar la que tienes?

Al igual que lograr algo de valor en los negocios, una implementación exitosa de DevOps ocurre con la alineación de las personas, los procesos y las herramientas adecuadas en una organización. Sin embargo, dado que los equipos de TI son equipos de TI, generalmente hay un gran énfasis en la parte de herramientas (y tecnología) de la solución, en lugar de la parte que más importa. Las opciones tecnológicas (CICD, IAC y automatización de pruebas, etc.) suelen liderar la implementación: “necesitamos Azure DevOps”. Así es como DevOps a menudo se convierte en “tenemos CI / CD, por lo que tenemos DevOps” o “tenemos automatización de pruebas, por lo que tenemos DevOps”. Por lo tanto, las definiciones anteriores existen y persisten.

Volviendo a la definición: las personas que crean la aplicación, la ejecutan. Son las  personas las que marcan la diferencia. DevOps es fundamentalmente un problema de personas. Sí, los procesos y las herramientas son importantes y esenciales para el éxito. Pero alinear a la gente con el modelo debe ser el primer y principal objetivo.

Los problemas de las personas pueden ser difíciles de resolver. “Los desarrolladores odian el trabajo de soporte” y “Los profesionales de TI no saben cómo codificar” son barreras (o quejas) comunes para el éxito de DevOps. Y habrá muchos más problemas enfrentados. Sin embargo, los problemas y las razones del error no son “no podemos acordar un proceso de lanzamiento” o “no podemos permitirnos Azure DevOps”. Estos pueden ser ciertos, pero pueden superarse de diversas formas. Los problemas de las personas son más difíciles de resolver.

Entonces, ¿cómo lo haces? Sabiendo que comienza con las personas, ¿cómo se establece una función DevOps exitosa? Bueno, hay 2 soluciones: constrúyelo o cómpralo. 

En la opción “constrúyelo”, es verdad que DevOps es cultural. La “cultura” organizacional en sí tiene muchas definiciones amplias, pero para simplificar, diremos que significa que los miembros del equipo abordan el trabajo de una manera similar, con la creencia de que es la manera correcta. Para que una organización logre una alineación cultural con un modelo DevOps, el equipo debe creer que la forma DevOps es la correcta. Sobre esto, hay muchas posibilidades de que se avecinen días difíciles. La cultura organizacional se define tanto de arriba hacia abajo como de abajo hacia arriba. El liderazgo puede establecer la expectativa de lo que debería ser la cultura y hacer todo lo posible para alinear los logros de la organización con estos principios culturales. Pero es en el “hacer” real del trabajo y las formas comunes en las que se hace lo que es la cultura. Y obtener la aceptación de un nuevo paradigma por parte de todos puede resultar difícil. Se requerirán algunas decisiones difíciles.

En el caso de las personas, en DevOps, los miembros del equipo de “desarrollo” sénior deberán participar en una lista de turno en una lista rotativa para el soporte de nivel 3 si las operaciones son 24 × 7. Esto puede ser un desafío para las personas y la organización de aceptar y administrar: se debe lograr el equilibrio entre el trabajo y la vida personal para evitar el agotamiento, por lo tanto, se necesita un compromiso de equipo con el proceso. ¿La ejecución “Ops” debe ser tan necesaria como la función “Dev” del equipo? ¿Por qué? Porque “Ops” es donde existe el retorno de la inversión. Es donde se gana el dinero. “Dev” es donde se crea valor. “Ops” es donde se entrega valor.

Además, en DevOps, los defectos son ciudadanos de primera clase acumulándose. Esto significa que los miembros del equipo de “desarrollo” dividen el tiempo entre el desarrollo de funciones y la resolución de defectos. Muchos desarrolladores dirían que siempre fue así, lo cual es cierto. Pero los plazos de entrega de las funciones siempre tuvieron prioridad sobre los defectos. Y, para la mayoría de los desarrolladores, es más divertido trabajar en las funciones. Simplemente no es tan interesante arreglar algo que creaste. Ahora, con un único conjunto de resultados para el equipo que abarca tanto Construir como Ejecutar, se aplica la igualdad a ambos. Esta puede ser una mentalidad desafiante de adoptar.

Para aquellos en el espacio tradicional de “Operaciones”, existe un mayor requisito para comprender los desafíos que existen en el mundo de los “Desarrolladores”. Como los equipos de DevOps tienen un único conjunto de resultados que abarcan todas las actividades, los de Operaciones se vuelven tan responsables del logro de los objetivos de los desarrolladores como todos los demás. A menudo puede ser un desafío para los miembros del equipo de operaciones considerar soluciones que se adapten al ciclo de vida de la aplicación de un extremo a otro, en lugar de solo al final. Para los miembros del equipo de “Operaciones”, el desafío de escala que proviene de la inclusión del mundo de los desarrolladores puede ser un desafío. Para su función, significa que la lista de requisitos para optimizar aún más la entrega solo se expandirá con el tiempo.

Estos son solo algunos de los numerosos desafíos de “Personas” que existirán en la versión “constrúyelo” de establecer DevOps efectivos en tu organización. Habrá muchos más. Desde decisiones sobre el conjunto de habilidades multifuncionales de las personas en los equipos, hasta una alineación organizacional más amplia para la entrega, cambios en las líneas jerárquicas, etc. Desde decisiones sobre un modelo DevOps centralizado hasta DevOps alineado con el producto: alinear a las personas con la mentalidad necesaria será fundamental desafío. Y ni siquiera hemos abordado el proceso, las herramientas y los cambios de financiamiento estructural necesarios para respaldar DevOps, todos trayendo sus propios desafíos diversos en el camino.

Para aquellos que siguen el camino de “constrúyelo”, se recomienda abordarlo de la misma manera que el desarrollo de software ágil. Hazlo MVP: encuentra un área dentro de TI donde se pueda implementar, implementa algo como un modelo MVP, luego falla, aprende e repite hasta que defina el estándar. Una vez que tengas algo que funcione, impleméntalo de manera más amplia.

¿La alternativa a la construcción desde cero? Simple – Cómpralo. Selecciona un socio que proporcione un servicio DevOps listo para usar. Y, de nuevo, se seguiría recomendando un enfoque KISS. Involucra a un socio para que demuestre la capacidad de DevOps para un área de TI que inicialmente puede ser una incubadora / aceleradora. Interactúa, asegúrate de que funcione para tu organización y luego trabaja con el socio para implementarlo de manera más amplia.

Como ejemplo de la opción de compra, nuestro servicio administrado de DevOps de MuleSoft es solo eso: diseñado explícitamente para ofrecer un resultado de DevOps para su ecosistema de MuleSoft.

• CI / CD: muchos clientes cuentan con soluciones CI / CD, por lo que, para aquellos que las tengan, nos aseguraremos de que se alinee con nuestra implementación de mejores prácticas, desde la administración del código fuente hasta los procedimientos de implementación de la canalización. Si no tiene nada en su lugar, realizaremos la transición progresiva de lo que tenga actualmente (incluso la gestión manual) a las herramientas de CI / CD y estableceremos procesos de lanzamiento.
• Automatización de pruebas: nos aseguraremos de que exista un nivel adecuado de pruebas automatizadas para las soluciones de MuleSoft. ¿No existe la automatización? Incluso podemos establecer progresivamente pruebas automatizadas para las soluciones existentes, asegurando que los ciclos de implementación se minimicen.
• Monitoreo de MuleSoft : la solución de monitoreo adecuada es fundamental para “Ops”. Para monitorear de manera efectiva MuleSoft, debe considerar las múltiples capas de abstracción involucradas para entregar la aplicación a los usuarios (los usuarios en este contexto pueden ser humanos u otros sistemas). Y dentro de cada capa, debe considerar los tipos de problemas que pueden ocurrir, cómo pueden detectarse y cómo deben manejarse cuando ocurren. Nuestro servicio administrado DevOps específico de MuleSoft se especializa en establecer este monitoreo para sus soluciones de MuleSoft.

Y, lo más importante, People. Nuestro equipo de servicios administrados está compuesto al 100% por ingenieros de MuleSoft certificados, ya culturalmente alineados para brindar DevOps. Nuestros equipos de DevOps comprenden que las características y los errores son ciudadanos de primera clase en la acumulación y que AMBOS deben equilibrarse para garantizar que su inversión obtenga el rendimiento requerido para su negocio.

Tendré más que decir sobre ese punto en la Parte 2 de la serie, discutiendo por qué DevOps es una consideración importante para las organizaciones de hoy.

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.