Los líderes de TI que buscan una entrega más rápida de aplicaciones y servicios están recurriendo cada vez más a DevOps. Pero combinar el desarrollo y las operaciones es un asunto complicado.
Muchas organizaciones han comenzado a incorporar DevOps en su combinación de TI, ya sea para proyectos pequeños o a gran escala.
Si bien DevOps puede proporcionar una serie de beneficios: entrega más rápida de aplicaciones y características, mejor comunicación y colaboración entre los equipos de desarrollo y operaciones, resolución más rápida de problemas y entrega iterativa de servicios de TI, no hay garantías de éxito.
Como ha señalado la firma de investigación Gartner, “DevOps se está convirtiendo rápidamente en algo común, pero quedan dudas sobre cómo este enfoque relativamente nuevo de la cultura, la automatización y el diseño de plataformas puede cumplir lo que promete”. Muchas organizaciones aún enfrentan obstáculos al implementar y escalar una práctica de DevOps, dice 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, dice Gartner.
A continuación, se muestran algunos errores comunes que se deben evitar.
Falta de habilidades requeridas
La brecha de habilidades tecnológicas puede afectar prácticamente todos los aspectos de TI, y DevOps no es una excepción. Si los miembros del equipo de desarrollo u operaciones de DevOps no tienen las habilidades que una organización necesita, cualquier intento de obtener beneficios de DevOps probablemente fracasará.
“Es clave para los miembros del equipo tener habilidades tanto físicas como blandas”, afirma Sam Babic, vicepresidente senior y director de innovación del proveedor de servicios de contenido Hyland.
La empresa emplea DevOps y 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 contabilidad, finanzas, ventas, marketing, etc.”, explica 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 automatización para actualizar la única fuente de software que comparten todos los clientes, así como para actualizar cualquier modelo de datos y otros componentes periféricos necesarios para la operación”, señala Babic. “Este entorno también aprovecha la automatización para el monitoreo”.
Y el medio ambiente requiere habilidades sólidas en varias áreas, incluido el sistema de orquestación de contenedores Kubernetes; aplicaciones de gestión de versiones; aprovisionamiento de software, gestión de la configuración y herramientas de implementación 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 administramos para nuestros clientes están en la nube, el equipo debe ser muy consciente de las plataformas en la nube y los servicios en la nube que están disponibles”, declara Babic.
Desde la perspectiva de las habilidades blandas, la comunicación y la colaboración son vitales. “Es importante que los campeones [de DevOps] se comuniquen de forma clara y frecuente en el intercambio de ideas y prácticas”, dice Babic. “En aquellas áreas donde los equipos operan como un servicio compartido, deben comprender las consideraciones de implementación de los diversos productos y trabajar en estrecha colaboración con los equipos de productos para garantizar que sus productos se alineen con las estrategias de implementación en las primeras etapas de diseño”.
Los ciclos de retroalimentación son importantes, por lo que las prácticas de automatización mejoran constantemente, manifiesta Babic.
No establecer procesos bien definidos
DevOps es un proceso, una cultura y una disciplina que combina las tareas de desarrollo con los procedimientos operativos, dice Emal Ehsan, director de Cervello, una unidad de la firma de consultoría de gestión global Kearney.
“Cada organización debe analizar sus enfoques actuales y trazar un conjunto fundamental de procesos y procedimientos para construir DevOps como una competencia central, y cuál sería el impacto de esos cambios”, señala Ehsan. “Una vez hecho esto, tómese el tiempo para desarrollar las capacidades fundamentales con la expectativa de que la plomería adicional requiera planificación”.
Ese puede ser un cambio de ritmo intimidante para las organizaciones que valoran los procesos ágiles y las victorias tempranas, dice Ehsan. “Pero lo compensará con un trabajo de mayor calidad que se puede reiterar una y otra vez”, dice.
La primera vez que se arma el proceso, la primera implementación puede demorar más de lo esperado. Pero las implementaciones posteriores podrían realizarse en una fracción del tiempo, dice Ehsan. El retorno de la inversión por el costo inicial inevitablemente provendrá de esas iteraciones posteriores, agrega.
“Durante su fase fundamental, también es muy importante definir qué significa” éxito “y cómo lo medirá”, declara Ehsan. “¿Está reduciendo el número de interrupciones de aplicaciones en un 20%? ¿Aumentar el porcentaje de implementaciones exitosas en el primer intento para lanzamientos de versiones en un 30%? ¿Reducir cuatro días los plazos de entrega a nuevos entornos de infraestructura? “
Definir el éxito tiene dos propósitos. “El primero es brindarle la base para fomentar una mayor adopción”, dice Ehsan. “El segundo es darle al equipo un objetivo tangible. Si su equipo es competitivo por naturaleza, una barra alta puede generar los mejores resultados; mientras que los equipos que temen fallar 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 a menudo impulsa la excelencia más allá del objetivo “.
Empezando demasiado grande
Las empresas no deben implementar iniciativas de DevOps a gran escala, ya que pueden abrumar los recursos, incluidos los equipos de desarrollo y operaciones.
“Las transformaciones de DevOps son ‘elefantes’ que no se pueden comer de un bocado”, bromea Ehsan. “Elija un punto de partida de enfoque, por ejemplo, un pequeño proyecto que requiera aportes de diferentes departamentos, e implemente DevOps allí”.
Los conjuntos de herramientas que una empresa utilizará para lograr sus objetivos tendrán diferentes niveles de madurez, al igual que las personas que los implementen, afirma Ehsan. “El soporte cultural y tecnológico para sus casos de uso inicial puede estar en su infancia, y no importa qué tan bien planeado esté su enfoque, inevitablemente llegará un momento en el que descubrirá que no puede hacer lo que necesita hacer de la manera que pensaba que podía hacerlo”.
Si una empresa se ve abrumada por un programa de DevOps que no estaba preparada para asumir, el mejor antídoto es asegurarse de tener una variedad de solucionadores de problemas en el equipo que abordan las tareas desde diferentes ángulos, dice Ehsan.
“Los pequeños logros y la buena colaboración se vuelven contagiosos, por lo que asegurarse de tener el equipo adecuado que sea flexible y pueda girar cuando sea necesario ayudará a garantizar el éxito inicial y la adopción del proceso en general”, dice Ehsan.
Proporcionar demasiada o muy poca autonomía
Uno de los mantras perdurables de DevOps es dar a los equipos la autonomía para determinar su propia forma particular de trabajar y obtener resultados, dice Ola Chowning, socia de la firma de asesoría e investigación tecnológica ISG.
“El problema aquí es que demasiada autonomía puede resultar en una expansión arquitectónica, tanto lógica como con herramientas; incapacidad para cambiar fácilmente a los miembros del equipo entre equipos de DevOps; y un verdadero desafío con la supervisión administrativa del desempeño organizacional ”, dice Chowning.
“Hemos visto varios ejemplos de demasiada autonomía”, incluida una proliferación de herramientas, estilos y métodos. La poca autonomía, incluida la creación de barreras que ralentizan el trabajo y la provisión de herramientas subóptimas para una necesidad específica del equipo, tampoco es buena, dice Chowning.
Una buena práctica para abordar el desafío del equilibrio de la autonomía es crear un organismo de normalización, como un centro de excelencia (CoE). Esto debe estar compuesto por profesionales de varios equipos, que establezcan barreras alrededor de las áreas donde los estándares pueden impulsar la eficiencia y para ayudar con la selección y el uso de herramientas, las metodologías y los parámetros de gobernanza.
“Establecer el piso de los estándares necesarios; cosas que debe hacer, como control de versiones, seguridad, privacidad, etc. ”, asevera Chowning. “Permitir que los equipos traigan necesidades fuera de los estándares actuales al CoE para la mejora continua” en herramientas, procesos y formas de trabajo. Además, rotar a las personas que componen el CoE, dice, lo que permite que participen más miembros del equipo.
Suponiendo que DevOps es un modelo único
Cuando las empresas implementan DevOps de manera más amplia, a menudo hay una inclinación a estandarizar todo para simplificar la implementación, dice Chowning. Puede que no sea una buena idea.
“Los productos / capacidades específicos pueden tener menos o más necesidad, o menos o más capacidad, para admitir todos los elementos de un modelo estándar de este tipo”, dice Chowning. “Esto puede deberse a la arquitectura, las necesidades comerciales (altas tasas de cambios frente a las bajas) y otras características”.
Por ejemplo, un cliente de ISG intentó impulsar tanto el desarrollo como la responsabilidad operativa en todos sus equipos de productos utilizando un modelo estándar coherente. Uno de los equipos estaba trabajando 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 para realizar el trabajo. “Sin embargo, cuando buscaron contratar los recursos con experiencia en desarrollo, descubrieron que el precio de mantener estas habilidades a tiempo completo, cuando rara vez realizaban cambios de desarrollo, representaba más costos del que podían percibir en beneficio”, dice Chowning.
La experiencia llevó al reconocimiento de que esta capacidad tecnológica en particular no se prestaba a un alto grado de DevOps desde una perspectiva de trabajo en equipo. “Incluso el estándar de automatización y herramientas se consideró inapropiado, dada la arquitectura y el cronograma del eventual reemplazo en solo uno o dos años”, dice Chowning.
En lugar de adoptar un modelo DevOps único para todos, ISG recomienda crear modelos de “DevOps completo” y “DevOps mínimo”. “A partir de estos dos modelos, cree una lista de requisitos mínimos que se apliquen a ambos modelos y de los que todos los equipos podrían beneficiarse, y estos se convertirán en sus prácticas y principios centrales de DevOps”, dice Chowning. “Lo que terminas son esencialmente múltiples niveles de DevOps que difieren efectivamente de un equipo a otro, e 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 se realiza sin problemas. Es mejor averiguar más temprano que tarde si algo no está funcionando como debería.
“Si está realizando pruebas automatizadas en una nueva línea de implementación, las alertas tempranas pueden salvarlo de desastres posteriores”, dice Ehsan. “Desafortunadamente, nadie se da cuenta de los incendios que nunca ocurrieron o celebra al electricista que no quemó la casa”.
Con el tiempo, las organizaciones que recopilan 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 el dinero gastados en DevOps sin mostrar el impacto, dice Ehsan. “Si desea que los equipos de ventas agreguen tiempo de entrega, desea que el director financiero apruebe el presupuesto y desea escalar el ejercicio al resto de su organización, necesitará datos y resultados para mostrarlos”, dice.
No crear una cultura DevOps
Para que DevOps tenga mucho éxito, los equipos deben sentir pasión por él, y eso proviene de la construcción de la cultura adecuada.
“La cultura es clave. El equipo debe ser un equipo que quiera trabajar en métodos DevOps ”, dice Brian Balzer, vicepresidente de tecnología digital y transformación comercial de la embotelladora G&J Pepsi.
Tienen sus roles, pero quieren trabajar juntos para completar el objetivo”, dice Balzer. “Necesitan tener habilidades interdisciplinarias y un buen conocimiento empresarial. Si los miembros del equipo solo quieren trabajar en su disciplina o cuál es su descripción de trabajo definida, tendrá dificultades “.
G&J Pepsi ha estado operando en el marco de DevOps desde 2009 y adoptó oficialmente DevOps como una disciplina definida en 2018. “Debido a que hemos sido un equipo pequeño y esbelto, esta forma de trabajar no fue necesariamente la elección de encontrar una definición formal de cómo trabajar. , pero más una necesidad para ofrecer valor a la organización, sobrevivir a la tecnología en constante cambio [y] completar proyectos ”, declara Balzer.
Ha llevado mucho tiempo crear un entorno y un equipo de DevOps, incluida una educación y formación rigurosas. En otoño de 2020, la compañía trajo un entrenador ágil para evaluar sus procesos y cómo estaba trabajando el equipo. “Esto fue muy valioso y, después de unos meses, reestructuramos la forma en que organizamos nuestro equipo”, dice Balzer. El equipo ha progresado y ahora funciona sin problemas en el método DevOps.
“El equipo ha adoptado esta nueva forma de operar, sus cadencias, y ahora está comenzando a cumplir”, añade Balzer. “Medimos nuestro rendimiento, nuestra capacidad para crear guiones gráficos y el valor que ofrecemos a la empresa. Y lo más importante, estamos generando 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 “.
Bob Violino, CIO.com
