Llegamos a ustedes gracias a:



Reportajes y análisis

5 obstáculos para adoptar DevOps

[13/12/2017] El concepto de DevOps cumple 10 años en el 2018. A pesar de ese hito de madurez, la mayoría de las organizaciones aún no han adoptado completamente esta práctica de TI, que combina el desarrollo, las operaciones y el personal de pruebas en equipos interfuncionales destinados a mejorar la agilidad en la entrega de servicios de TI.

Según Forrester Research, solo el 13% de las organizaciones ha implementado DevOps, 50% son pruebas piloto o pruebas de concepto. Otro 27% planea implementar DevOps dentro del año, mientras que el 9% está interesado, pero no tiene planes de adoptar DevOps dentro de los próximos 12 meses.

Hay muchas razones por las que la adopción de DevOps ha sido lenta. Rob C. Guckenberger, director ejecutivo de desarrollo de aplicaciones de la Commonwealth Office of Technology de Kentucky, es un líder de TI que enfrenta estos desafíos mientras que el Estado lidia con la forma en que quiere progresar con la adopción de DevOps.

Guckenberger explica que la propiedad del desarrollo de las aplicaciones se encuentra dispersa en numerosas agencias, mientras que la Commonwealth Office of Technology posee la infraestructura. Eso creó compartimentos estancos que deben ser desagregados para que DevOps funcione. El Estado también depende de una amplia gama de sistemas, creando barreras para que la automatización y los procesos continuos funcionen en toda la empresa, dos principios clave de DevOps. Además, el Estado aún no tiene las habilidades adecuadas para brindar soporte a DevOps completamente.

"Definitivamente vamos a llegar ahí, afirma Guckenberger. "Es solo cuestión de cómo hacerlo.

Los obstáculos para adoptar y expandir DevOps en los departamentos de TI de la empresa, como las soluciones en sí, afectan a las personas, los procesos y la tecnología. Aquí observamos más de cerca los obstáculos específicos que enfrentan los CIO en esas áreas cuando implementan DevOps, y cómo eludirlos.

Los dolores de la cultura cambian

Jonathan Feldman, CIO de la ciudad de Asheville de Carolina del Norte, afirma que su equipo utiliza los principios de DevOps -como ciclos de retroalimentación más cortos, sprints más cortos y pruebas de usabilidad- aunque no identifica a su departamento como un usuario de DevOps.

Aun así, Feldman afirma que llegar a ese espacio ha requerido un cambio en la forma en que las personas piensan y operan. Ha requerido un cambio cultural, algo que no se puede forzar de la noche a la mañana.

"Decidir adoptar DevOps el día de mañana es el Big Bang de TI, y simplemente no puede funcionar. Uno introduce demasiado, de manera demasiado rápida, afirma. "Y si está tratando de usar DevOps para todo, hará que las personas se rebelen. Es el enfoque correcto para muchas cosas, pero no para todo.

Los hallazgos de una encuesta de otoño del 2017, realizada por la empresa de software Pensa, identificaron los problemas relacionados con las personas como las principales barreras para la adopción de DevOps. Pensa encuestó a más de 200 responsables de la toma de decisiones de TI en septiembre, preguntando sobre los mayores desafíos que enfrentan al adoptar las prácticas de DevOps. Aproximadamente, el 19,7% expresó que tener presupuestos limitados es la barrera más importante, el 9,4% mencionó la cultura de la compañía, el 7,9% afirmó que lo eran las habilidades limitadas de TI, y el 7.4% mencionó la falta de aceptación por parte de los ejecutivos.

El analista de Forrester, Robert Stroud, afirma que los CIO deben abordar la cultura desde el comienzo de sus iniciativas de DevOps. Deben lograr que otros ejecutivos comprendan y respalden la estrategia de 'vender' la idea de la DevOps no como un conjunto de principios, sino como una herramienta fundamental para la transformación digital. Y deben hacer que los empleados trabajen colaborativamente en una organización más horizontal, donde haya más flexibilidad para que cada trabajador individual resuelva problemas.

"Requiere un replanteamiento fundamental. La gente se siente cómoda con la forma en que han estado trabajando, y no todos son agentes de cambio. Por lo tanto, deberá encontrarlos, presentarlos y hacer que promuevan DevOps y articulen su valor, afirma, y agrega que muchos líderes de TI subestiman "el nivel de cambio cultural y organizativo necesario.

Aconseja a los departamentos de TI a que se centren en formar equipos de DevOps fuertes, contratando o capacitando en las habilidades correctas, e identificando a los líderes orientados al negocio y no a los tecnócratas; porque los líderes "están impulsando la agenda para entregar las funciones y características con el fin de hacer su negocio más eficiente y competitivo.

Sin embargo, Chris Rollins, gerente de operaciones de plataforma para el sitio web de intercambio de boletos en línea StubHub, que ahora usa los principios de DevOps siempre que le sea posible, afirma que es desafiante lograr que todos los adopten.

"Algunos grupos en nuestra organización creen que debemos seguir con los métodos previos porque eso funcionó bien en el pasado, afirma. "A muchas personas les gusta el enfoque práctico para el desarrollo de software y la administración de sistemas, mientras que los principios de DevOps señalan que la automatización sin intervención manual es fundamental para el éxito.

Rollins usa el evangelismo para convertir a los escépticos.

"Continuamente defendí los beneficios de DevOps con la alta gerencia. Una vez que la gente se dio cuenta de los beneficios, muchos de los problemas desaparecieron, afirma, señalando que compra y distribuye muchas copias del popular libro de DevOps, "El Proyecto Phoenix: Una Novela Sobre TI, DevOps y Ayudar a su Negocio a Ganar.

Proceso: Comience en pequeño o fracasará

Además de la cultura, el proceso es otra clave para el éxito de DevOps. Con DevOps, la automatización se emplea para desarrollar una integración continua y una plataforma de producción continua que puede evaluarse y supervisarse automáticamente. La complejidad de dicho sistema deja a muchos CIO luchando por decidir dónde comenzar, afirman los expertos.

Fannie Mae, la empresa patrocinada por el gobierno que se encarga de apoyar la propiedad de una vivienda, ha existido desde la Gran Depresión. Tiene su porcentaje de tecnología monolítica heredada, pero está trabajando para aumentar la digitalización y optimizar su negocio, afirma Jason Anders, el director de tecnología responsable de la estrategia y adopción de la nube en la compañía.

Él afirma que la adopción de DevOps ha sido parte de esa modernización.

"Para nosotros, significa la capacidad de un desarrollador para obtener el ambiente de desarrollo, escribir, probar y desplegar código en producción de una manera automatizada, rápida y no exenta de riesgos, aunque menores a que si no estuviera automatizada, explica.

Fannie Mae ha estado en su travesía de DevOps desde finales del 2013; hoy, en desarrollo y producción, requiere de horas para hacer lo que antes solía tomar semanas, o incluso un mes.

Anders afirma que los líderes de Fannie Mae apoyan las iniciativas de DevOps; aun así, afirma que es difícil lograr que todos estén de acuerdo en lo que debe suceder y cómo deberían funcionar los nuevos principios dentro de la empresa.

"Mantener a todos sincronizados es un verdadero desafío. Estamos tratando de avanzar más rápido y cada equipo está muy preocupado con sus fechas límite, es muy difícil mantenerse al ritmo de la comunicación, es complicado decir: 'Esta es la forma que elijo', afirma Anders. "No tengo una solución mágica para eso. Simplemente se trata de trabajo duro, es tomarse el tiempo para hablar tanto como se pueda.

Para ayudar a que todos estén sincronizados, Anders afirma que comenzó con pequeños proyectos para desarrollar los procesos que producirían los primeros éxitos de DevOps. Estos proporcionaron la base de los procesos, principios y prácticas que podrían utilizarse en proyectos más grandes y extensos en toda la organización.

"Comenzamos DevOps con la tecnología más nueval para que pudiéramos diseñarla de la manera que pensábamos que debería ser, y así podríamos volvernos buenos para aprender a hacer las cosas bien con las herramientas, explica. "Y a medida que está desarrollando una aplicación completamente nueva, puede poner en práctica los patrones de automatización correctos que puede comenzar a aplicar en cualquier otro lugar.

Feldman tomó un rumbo similar cuando inició la travesía DevOps de Ashville hace unos cinco años, aplicando conceptos de DevOps a pequeños experimentos para que su equipo pudiera adquirir cierta experiencia en una manera nueva de desarrollo y despliegue de software.

Edward L. Haletky, CEO y analista principal de TVP Strategy, con sede en Austin, Texas, está de acuerdo con ese enfoque, y señala que muchas áreas de TI asumen más de lo que pueden manejar cuando comienzan con DevOps -y luego pierden el entusiasmo.

"Es bueno comenzar con un proyecto pequeño y donde sabes que puedes tener éxito, afirma.

Una cuestión de autoridad -y estabilidad

También existen otros obstáculos -orientados al proceso- para la práctica exitosa de DevOps.

Por ejemplo, Guckenberger afirma que DevOps puede permitir comportamientos deshonestos o atajos, a medida que la autoridad y la autonomía pasan de los ejecutivos y gerentes hacia los equipos DevOps.

"Con la autoridad viene la capacidad de hacer cosas que no se deberían hacer. Los trabajadores pueden, por ejemplo, reparar fallas inmediatas, pero ignorar los problemas subyacentes. "Harán cosas que no son seguras, muy arriesgadas, que no son sostenibles.

Por su parte, Rupen Sheth, vicepresidente ejecutivo de operaciones de Iono, una compañía de tecnología con sede en Milpitas, California, afirma que ve desafíos en la creación de procesos que permitan la flexibilidad y velocidad que los equipos DevOps requieren, pero que también respalden la necesidad de estabilidad de TI de una organización.

Sheth afirma que TI debe abordar estos problemas desde el principio al determinar qué controles tienen sentido en un mundo DevOps. "TI tiene que decir: 'Aquí están todas las cosas aprobadas que podemos proporcionar; aquí están todos los ambientes de aplicación, listos para utilizarse, que se pueden provisionar, afirma.

Guckenberger ofrece consejos similares, afirmando que los CIO pueden limitar el riesgo respaldando la plena autoridad de sus equipos y definiendo los cambios que requieren aprobación. Aunque afirma que algunos argumentarían en contra de esa táctica, diciendo que ocasionará demoras en el ciclo de DevOps, también señala que introduce un control sobre el potencial de problemas que de otra forma existirían.

La evaluación de los datos

Cuando se está provisionando código a producción de manera automática, las pruebas deben ser confiables y completas. Aquí, para muchas organizaciones, los datos pueden ser un problema.

Fannie Mae se ha topado con este obstáculo al expandir su uso de DevOps, con el fin de obtener mayores ganancias de la velocidad que DevOps le brinda a TI, afirma Anders, ya que la falta de datos para usar en las pruebas de código puede demorar drásticamente el trabajo.

"Puede tomar semanas obtener los conjuntos de datos correctos para hacer las pruebas, y si está tratando de hacer todo ágilmente como Fannie Mae, y ejecutar todo en sprints de dos semanas, se vuelve imposible si se requiere de tres semanas para obtener los datos, afirma.

Así que Fannie Mae automatizó la pieza de datos utilizando la plataforma Delphix, y adoptando la metodología DataOps para producir datos de prueba en cuestión de horas en lugar de semanas. El resultado es una mayor velocidad, pruebas más fuertes y más creatividad; los desarrolladores ahora saben que pueden acceder rápidamente a los datos necesarios para las pruebas, y no sentirán que han perdido demasiado tiempo si la innovación no ocurre.

Apostar por las herramientas correctas

"Existen, sin duda, otros obstáculos en torno a la tecnología necesaria para tener éxito con DevOps, afirma Anders. Él enfrenta los desafíos (integrar código, encontrar las fallas rápidamente y enlazar DevOps con las tecnologías previas) que él y su equipo han encontrado en la integración continua, producción continua y al trabajar en un entorno cada vez más automatizado.

También cita las herramientas como una barrera potencial. Los líderes de TI deben asegurarse de que sus equipos estén cómodos con las herramientas de DevOps, como las herramientas de administración de la configuración, las plataformas de producción continua y las pruebas automatizadas, afirma Anders. También deben saber cómo la organización decidirá qué herramientas usar, cómo serán administradas y si necesitan limitar cuántas herramientas diferentes se deben usar dentro de la organización. Además, los líderes de TI deberían estar atentos a qué herramientas tienen sentido para el futuro, y cuáles no, para no quedar rezagados.

"Es un desafío encontrar las herramientas adecuadas, y la industria está cambiando muy rápido. Hubo oportunidades en las que invertimos en algo porque pensamos que era innovador en ese momento, pero las herramientas no continuaron innovándose, así que tuvimos que reemplazarlas. Uno aprende esas lecciones a lo largo del camino, afirma Anders, explicando que él y su equipo continúan evaluando las herramientas disponibles para determinar cuáles son la mejor opción.

Stroud, de Forrester, afirma que es fundamental que los líderes inviertan adecuadamente en las tecnologías necesarias para ofrecer soporte a DevOps.

"Los ejecutivos no siempre dan a los equipos la capacidad de jugar de manera efectiva y experimentar con herramientas o productos, afirma.

Stroud y otros enfatizan que los líderes que no apoyan adecuadamente a DevOps dentro de sus organizaciones -ya sea para obtener las herramientas adecuadas, contratar el talento adecuado o respaldar nuevas formas de trabajo- encontrarán en esta era, donde DevOps puede ofrecer la velocidad y agilidad necesarias para competir, que tales decisiones ahora podrían destruir no solo sus iniciativas de DevOps, sino también a la compañía.