[12/06/2021] Muchas organizaciones han comenzado a incorporar DevOps en su combinación de TI, ya sea para proyectos pequeños o a mayor escala.
Aunque DevOps puede proporcionar una serie de ventajas -entrega más rápida de aplicaciones y funciones, mejora de la comunicación y la colaboración entre los equipos de desarrollo y operaciones, resolución más rápida de los problemas y prestación iterativa de servicios de TI-, no hay garantías de éxito.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Como ha señalado la empresa de investigación Gartner, "DevOps se está convirtiendo rápidamente en la corriente principal, pero siguen existiendo dudas sobre cómo este enfoque relativamente nuevo de la cultura, la automatización y el diseño de la plataforma puede cumplir lo que promete". Muchas organizaciones todavía se enfrentan a obstáculos para implementar y escalar una práctica DevOps, señala la firma.
Hasta el 2022, el 75% de las iniciativas de DevOps no cumplirán con las expectativas debido a problemas relacionados con el aprendizaje y el cambio organizacional, señala Gartner.
Estos son algunos de los obstáculos más comunes que hay que evitar.
Falta de habilidades necesarias
La brecha de habilidades tecnológicas puede afectar a prácticamente todos los aspectos de TI y DevOps no es una excepción. Si los miembros del equipo de los lados de desarrollo u operaciones de DevOps no tienen las habilidades que una organización necesita, cualquier intento de obtener beneficios de DevOps fracasará.
"Es clave que los miembros del equipo tengan tanto habilidades duras como blandas", señala Sam Babic, vicepresidente senior y director de innovación del proveedor de servicios de contenidos Hyland.
La empresa emplea DevOps y la automatización en varias áreas del negocio. "Estas prácticas se aprovechan dentro de nuestra organización de TI para satisfacer las necesidades operativas del negocio, como la contabilidad, las finanzas, las ventas, el marketing, etc.", anota Babic. Hyland también utiliza DevOps para crear los productos de software que entrega a sus clientes a través de varios canales.
Para los productos basados en la nube que siguen un modelo de entrega continua, "utilizamos DevOps y la automatización para actualizar la fuente única de software que comparten todos los clientes, así como para actualizar cualquier modelo de datos y otros componentes periféricos necesarios para el funcionamiento", sostiene Babic. "Este entorno también aprovecha la automatización para el monitoreo".
Y el entorno requiere habilidades duras en una serie de áreas, como el sistema de orquestación de contenedores Kubernetes; aplicaciones de gestión de lanzamientos; herramientas de aprovisionamiento de software, gestión de la configuración y despliegue de aplicaciones; herramientas y servicios de control de versiones como GitHub; lenguajes como Python, JavaScript, Bash y Node.js; y diversas tecnologías de seguridad.
"Dado que las cargas de trabajo que gestionamos para nuestros clientes están en la nube, el equipo debe conocer a fondo las plataformas en la nube y los servicios en la nube que están disponibles", afirma Babic.
Desde el punto de vista de las habilidades blandas, la comunicación y la colaboración son vitales. "Es necesario que los campeones [de DevOps] se comuniquen claramente y con frecuencia para compartir ideas y prácticas", anota Babic. "En aquellas áreas en las que los equipos operan como un servicio compartido, deben entender las consideraciones de despliegue de los distintos productos y trabajar estrechamente con los equipos de producto para asegurar que sus productos se alineen con las estrategias de despliegue en las primeras etapas de diseño".
Los bucles de retroalimentación son importantes para que las prácticas de automatización mejoren constantemente, señala Babic.
No establecer procesos bien definidos
DevOps es un proceso, una cultura y una disciplina que une las tareas de desarrollo con los procedimientos operativos, comenta Emal Ehsan, director de Cervello, una unidad de la consultora de gestión global Kearney.
"Cada organización debe examinar sus enfoques actuales y trazar un conjunto fundacional de procesos y procedimientos para construir DevOps como una competencia central, y analizar cuál sería el impacto de esos cambios", anota Ehsan. "Una vez hecho esto, tómese el tiempo para construir las capacidades fundacionales con la expectativa de que la fontanería adicional requiera planificación".
Eso puede ser un cambio de ritmo intimidante para las organizaciones que valoran los procesos ágiles y las victorias tempranas, indica Ehsan. "Pero lo compensará con el trabajo de mayor calidad del trabajo que se puede reiterar una y otra vez", afirma.
La primera vez que se pone en marcha el proceso, es posible que el despliegue lleve más tiempo del previsto, pero los siguientes podrían hacerse en una fracción del tiempo, señala Ehsan. El retorno de la inversión para el costo inicial vendrá inevitablemente de esas iteraciones posteriores, añade.
Durante la fase fundacional, también es muy importante definir qué significa el "éxito" y cómo se va a medir", anota Ehsan. "¿Se está reduciendo el número de interrupciones de la aplicación en un 20%? ¿Se está aumentando en un 30% el porcentaje de implantaciones exitosas en el primer intento de lanzamiento de versiones? ¿Se están reduciendo los plazos de entrega de nuevos entornos de infraestructura en cuatro días?"
Definir el éxito tiene dos objetivos. "El primero es dar la base para fomentar una mayor adopción", señala Ehsan. "El segundo es dar al equipo un objetivo tangible. Si su equipo es competitivo por naturaleza, una valla alta puede impulsar los mejores resultados, mientras que los equipos con miedo al fracaso pueden necesitar un objetivo más bajo para generar confianza tanto en el proceso como en los miembros de su equipo. En ambos casos, el éxito suele impulsar la excelencia más allá del objetivo".
Empezar demasiado a lo grande
Las empresas no deben desplegar iniciativas DevOps a gran escala, porque eso puede abrumar a los recursos, incluyendo a los equipos de desarrollo y operaciones.
"Las transformaciones DevOps son 'elefantes' que no se pueden comer de un solo bocado", señala Ehsan. "Escoja un punto de enfoque inicial -por ejemplo, un pequeño proyecto que requiera input de diferentes departamentos- e implemente DevOps ahí".
Los conjuntos de herramientas que una empresa utilizará para lograr sus objetivos tendrán diferentes niveles de madurez, y también las personas que los implementen, sostiene Ehsan. "El apoyo cultural y tecnológico para sus casos de uso iniciales podría estar en sus inicios, y no importa lo bien planificado que esté su enfoque, inevitablemente llegará un momento en el que descubra que no puede hacer lo que necesita de la manera que pensó que podría hacerlo", indica.
Si una empresa se ve abrumada por un programa de DevOps para el que no estaba preparada, el mejor antídoto es asegurarse de que tiene una variedad de solucionadores de problemas en el equipo que aborden las tareas desde diferentes ángulos, anota Ehsan.
"Las pequeñas victorias y la buena colaboración se vuelven contagiosas, por lo que asegurarse de que se cuenta con el equipo adecuado, flexible y capaz de pivotar cuando sea necesario, ayudará a garantizar el éxito inicial y la adopción del proceso en general", afirma Ehsan.
Proporcionar demasiada o muy poca autonomía
Uno de los mantras perdurables de DevOps es dar a los equipos la autonomía necesaria para determinar su forma particular de trabajar y obtener resultados, afirma Ola Chowning, socia de la empresa de investigación y asesoramiento tecnológico ISG.
"El obstáculo aquí es que demasiada autonomía puede dar lugar a la dispersión de la arquitectura, tanto lógica como con herramientas; a la incapacidad de cambiar fácilmente a los miembros del equipo entre los equipos de DevOps; y a un verdadero desafío con la supervisión de la gestión del rendimiento de la organización", anota Chowning.
"Hemos visto múltiples ejemplos de demasiada autonomía", incluyendo una proliferación de herramientas, estilos y métodos.
Tampoco es buena la poca autonomía, que incluye el establecimiento de barreras que ralentizan el trabajo y el suministro de herramientas que no son óptimas para una necesidad específica del equipo, sostiene Chowning.
Una buena práctica para abordar el reto del equilibrio de la autonomía es crear un organismo de normalización, como un centro de excelencia (CoE). Éste debería estar formado por profesionales de varios equipos, que establezcan barandillas en torno a las áreas en las que los estándares puedan impulsar la eficiencia y que ayuden en la selección y uso de herramientas, metodologías y parámetros de gobernanza.
"Siente las bases de los estándares necesarios. Cosas que debe hacer, como el control de versiones, la seguridad, la privacidad, etc.", anota Chowning. "Permita que los equipos aporten necesidades fuera de los estándares actuales al CoE para la mejora continua" en herramientas, procesos y formas de trabajo. Además, rote a las personas que componen el CoE, añade, permitiendo que participen más miembros del equipo.
Asumir que DevOps es un modelo único
Cuando las empresas despliegan DevOps de forma más amplia, suele haber una inclinación a estandarizar todo para simplificar la implementación, señala Chowning. Eso podría no ser una buena idea.
"Los productos específicos pueden tener menos o más necesidad, o menos o más capacidad de soportar todos los elementos de dicho modelo estándar", indica Chowning. "Esto puede deberse a la arquitectura, a la necesidad del negocio -altas tasas de cambios frente a bajas- y a otras características".
Por ejemplo, un cliente de ISG intentó impulsar tanto la responsabilidad de desarrollo como la operativa en todos sus equipos de productos utilizando un modelo consistente y estándar. Uno de los equipos trabajaba en un entorno de mainframe, que rara vez necesitaba cambios.
Cuando el cliente intentó que el equipo operativo se hiciera cargo de las tareas de desarrollo, descubrió que el equipo carecía de las habilidades o la experiencia necesarias para realizar el trabajo. "Sin embargo, cuando buscaron contratar recursos con experiencia en desarrollo, descubrieron que el precio de mantener estas habilidades a tiempo completo -cuando rara vez hacían cambios de desarrollo- representaba más costo del que podían obtener en beneficio", indica Chowning.
La experiencia llevó a reconocer que esta capacidad tecnológica en particular no se prestaba a un alto grado de DevOps desde una perspectiva de equipo. "Incluso el estándar de automatización y herramientas se consideró inadecuado, dada la arquitectura y el plazo de sustitución eventual en solo uno o dos años", agrega Chowning.
En lugar de adoptar un modelo DevOps único, ISG recomienda crear modelos "full DevOps" y "minimal DevOps". "A partir de estos dos modelos, cree una lista de requisitos mínimos que se aplican a ambos y de los que cada equipo podría beneficiarse, y conviértala en sus prácticas y principios centrales de DevOps", señala Chowning. "Así, terminará con múltiples niveles de DevOps que difieren de un equipo a otro y que incluso permiten que cada equipo 'suba de nivel' o 'baje de nivel'".
Descuidar la medición del impacto del cambio
DevOps significa cambio y el cambio no siempre va bien. Es mejor descubrir antes que después si algo no está funcionando como debería.
"Si está haciendo pruebas automatizadas en un nuevo pipeline de despliegue, las advertencias tempranas podrían salvarlo de desastres posteriores", señala Ehsan. "Por desgracia, nadie se da cuenta de los incendios que nunca se produjeron ni celebra al electricista que no quemó la casa".
Con el tiempo, las organizaciones que recogen métricas sobre el impacto de DevOps cosecharán los beneficios a través de la calidad del trabajo y la satisfacción de los clientes, interna y externamente, porque las cosas funcionan.
Además, es difícil justificar el tiempo y los dólares gastados en DevOps sin mostrar el impacto, sostiene Ehsan. "Si quiere que los equipos de ventas añadan tiempo de espera, que el director financiero apruebe el presupuesto y escalar el ejercicio al resto de su organización, necesitará datos y resultados para mostrarles", agrega.
No crear una cultura DevOps
Para que DevOps tenga éxito, los equipos deben apasionarse por él y eso pasa necesariamente por crear la cultura adecuada.
"La cultura es clave. El equipo tiene que ser uno que quiera trabajar con métodos DevOps", dice Brian Balzer, vicepresidente de tecnología digital y transformación empresarial en la empresa embotelladora G&J Pepsi.
"Tienen sus roles, pero quieren trabajar juntos para lograr el objetivo", señala Balzer. "Tienen que tener habilidades interdisciplinarias y un buen conocimiento del negocio. Si los miembros del equipo solo quieren trabajar en su disciplina o en su descripción de trabajo definida, tendrá problemas".
G&J Pepsi ha estado operando en el marco de DevOps desde el 2009 y lo adoptó oficialmente como una disciplina definida en el 2018. "Debido a que éramos un equipo pequeño, esta forma de trabajar no fue necesariamente una elección para encontrar una definición formal de cómo trabajar, sino más bien una necesidad de entregar valor a la organización, sobrevivir a la tecnología siempre cambiante [y] completar proyectos", anota Balzer.
Ha tomado mucho tiempo crear un entorno y un equipo de DevOps, incluyendo una rigurosa educación y formación. En otoño del 2020, la empresa contrató a un coach agile para que evaluara sus procesos y el funcionamiento del equipo. "Esto fue muy valioso, y después de unos meses habíamos reestructurado la manera en la que organizábamos nuestro equipo", comenta Balzer. El equipo ha progresado y ahora funciona sin problemas con el método DevOps.
"El equipo ha adoptado esta nueva forma de operar, sus cadencias, y ahora está empezando a cumplir", sostiene Balzer. "Medimos nuestro rendimiento, nuestra capacidad de hacer storyboards y el valor que aportamos a la empresa. Y lo que es más importante, estamos creando credibilidad con el equipo ejecutivo, hemos mejorado drásticamente las relaciones con nuestros socios comerciales y hemos aumentado la adopción de los productos que implementamos en toda la organización".
Basado en el artículo de Bob Violino (CIO) y editado por CIO Perú
Puede ver también: