Llegamos a ustedes gracias a:



Reportajes y análisis

Promesas y peligros en el viaje a DevOps

[15/09/2015] Al igual que muchas organizaciones de hoy en día, Nationwide debe batir regularmente nuevas aplicaciones de software para mantener su competitividad en una industria llena de gente.

Pero la compañía de seguros y servicios financieros no siempre fue capaz de mantenerse al día con la demanda. Durante años, Nationwide se basó en 23 departamentos de TI, cada uno de los cuales utilizaba su propia mezcolanza de herramientas y metodologías para crear nuevos productos y servicios. Hasta que la directora de tecnología DevOps, Carmen DeArdo, se dio cuenta de que el enfoque "monolítico" de Nationwide para el desarrollo de aplicaciones se traducía en equipos de proyectos inflados, extensos planes de diseño de software y ciclos de vida de desarrollo dolorosamente lentos.

En vez de agregar más personal al problema, DeArdo optó por migrar del mundo artificial de desarrollo en cascada, a una cultura de colaboración DevOps.

Las definiciones varían, pero DevOps es generalmente reconocido como un movimiento de desarrollo de software que fomenta la automatización, integración y una mayor colaboración entre los desarrolladores de software y el personal de operaciones. Al cerrar la brecha entre estas dos facciones que a veces están en conflicto, DevOps establece una forma consistente y repetible para que TI pueda gestionar su entorno de producción, lo que resulta en un tiempo más rápido para comercializar, niveles de productividad más altos y un despliegue de servidores y aplicaciones más fluido.

Desde que adoptó DevOps en el 2009, Nationwide ha mejorado la calidad del software en un 50% y ha reducido el tiempo de inactividad del usuario en un 70%. Hoy en día, más de 100 equipos ágiles, creciendo a un ritmo de 35% anual, manejan la friolera de 60% de los trabajos de desarrollo y los nuevos proyectos de la empresa. El código se integra continuamente y es desplegado en un entorno de desarrollo varias veces al día, lo que resulta en "mayor calidad, mayor productividad y más entrega a tiempo" de las solicitudes, de acuerdo con DeArdo.

Nationwide es una de un número creciente de empresas que abrazan DevOps para lidiar con la consumerización de software empresarial. Quedaron atrás los días de los lanzamientos trimestrales. En estos días, se espera que las organizaciones produzcan código y pongan en marcha nuevas herramientas de software con la velocidad y la agilidad de Amazon o Google. Al mismo tiempo, el impulso por liberaciones frecuentes da lugar a entornos de producción complejos y revoltosos que son difíciles de manejar. Muchos líderes de TI tienen la esperanza de encontrar una respuesta en DevOps, a pesar de algunos inconvenientes, incluyendo el riesgo de una guerra cultural y la posibilidad de la crítica por parte de sus pares.

A lo sumo, DevOps promete ayudar a que las empresas mantengan el ritmo frenético actual de la entrega de software. El objetivo es que los desarrolladores lancen software con mayor frecuencia sin la adición de capas de complejidad a la infraestructura, aligerando así la carga para las operaciones.

Los investigadores incluso están descubriendo una correlación entre la agilidad de TI y las mejoras en el rendimiento del negocio. En su reporte "Estado de DevOps 2014", que se basa en una encuesta realizada a 9.200 profesionales de TI de todo el mundo, el proveedor de software de automatización Puppet Labs afirma que "las organizaciones de TI de alto rendimiento son más ágiles y confiables: despliegan código con una frecuencia 30 veces mayor que sus pares de menor rendimiento, y obtienen un 50% menos fracasos. Y las empresas con un alto rendimiento de TI tienen el doble de probabilidades de superar su rentabilidad, cuota de mercado y metas de productividad".

La firma de investigación Gartner predice que alrededor del 25% de las compañías Global 2000 adoptará la filosofía DevOps en el 2016. Y se espera que el mercado para las herramientas DevOps crezca a 2,3 mil millones de dólares para finales de este año, impulsado en parte por las ventas de nuevos productos de proveedores como Chef, Puppet, Ansible, IBM, Microsoft y Atlassian.

No persiga cascadas

Esta no es la primera grieta de TI en la simplificación del desarrollo de software. La Information Technology Infrastructure Library (ITIL), es un enfoque de décadas para alinear los servicios de TI con las necesidades del negocio. Pero con sus mejores prácticas detalladas en cinco tomos voluminosos, rivalizando con el tamaño y el alcance de las memorias de Winston Churchill, no es de extrañar que muchas empresas abandonen las prescripciones formales de ITIL.

"DevOps es más un enfoque de sentido común, un cambio cultural que fomenta la creatividad y la colaboración", señala la analista de Gartner Laurie Wurster.

Pero convencer a los desarrolladores y a la gente de operaciones para que unan sus fuerzas con el fin de acelerar la entrega de software no es tarea fácil. Abrazar DevOps se traduce en un liderazgo fuerte, métricas confiables, incentivos convincentes, herramientas eficaces y algo parecido a una revolución cultural.

De hecho, en una encuesta de Saugatuck Research, de más de 300 operaciones de desarrollo y profesionales y directivos de TI, solo el 37% de los encuestados dijeron que tienen establecidas estrategias DevOps formales. Y más de la mitad de los encuestados dijo que "la superación de hábitos culturales dentro de mi organización/empresa" era un obstáculo para adoptar plenamente los principios DevOps.

Buitres de la cultura

Pregúntele a Ryan Kelley, un ingeniero de sistemas en el National Renewable Energy Laboratory, (NREL), él comenzó a usar DevOps para un proyecto que involucró obtener la aprobación reglamentaria para añadir nuevas capacidades en la nube para la infraestructura informática del laboratorio. "Estábamos realmente aislados", recuerda. "Hubo algunos equipos que hicieron lo suyo y sin mucha comunicación entre ellos. Lo que me gustó de DevOps era la idea de romper esos silos".

Sin embargo, la introducción de principios de entrega continua demostró ser más difícil de lo previsto por Kelley. "Cuando se tiene una cultura establecida, es difícil romper las barreras para tratar de hacer las cosas de manera diferente", anota. "Para cualquier empresa grande, es el mayor obstáculo -ir más allá del cambio cultural".

Jez Humble está de acuerdo.

"El problema es que hay un departamento -operaciones- que se mide por la estabilidad. Y otro departamento -desarrollo- que se mide por el rendimiento, como qué tan rápido podemos escribir el código", anota Humble , quien es co-autor de "Entrega Continua: Lanzamientos confiables de software a través de automatización de pruebas, construcción y despliegue, y vicepresidente de ingeniería en Cheff, un proveedor de software de automatización de TI que cuenta a NREL entre sus clientes. "Cuando esos dos departamentos se miden de esa manera, inmediatamente entran en conflicto".

En otras palabras, la gente de operaciones mantiene el barco a flote, mientras que a los desarrolladores les encanta sacudirlo. Para complicar aún más las cosas está el hecho de que los dos grupos por lo general se comunican a través de sistemas de etiquetado, en lugar de los encuentros cara a cara.

Es un obstáculo que Nationwide fue capaz de despejar mediante el establecimiento de lo que llama un centro de desarrollo de aplicaciones. Originalmente fue un "experimento" para centralizar seis equipos de desarrollo con cerca de 50 personas en total, el ADC ha crecido en 180 equipos multifuncionales, cada uno dedicado al desarrollo ágil, anota DeArdo.

Otra barrera común a la adopción de DevOps es una curva de aprendizaje empinada. "DevOps requiere diferentes habilidades, por lo que se necesita una sólida capacidad de formación si va a ponerlo en práctica", añade DeArdo. Por esa razón, Nationwide ahora tiene sesiones de "Enseñanza los jueves" dos veces al mes -reuniones informales donde la gente puede intercambiar consejos y compartir sus conocimientos en entrega continua de software.

El NREL descubrió una brecha de conocimiento similar cuando introdujo por primera vez DevOps. Kelley dice que mientras que el laboratorio estaba acostumbrado a la gestión de un centro de datos tradicional, su talento tenía una comprensión limitada de las prácticas de desarrollo de software del día a día. Como resultado, añade, "DevOps representaba una curva de aprendizaje gigante y lo sigue siendo. Todavía tenemos un largo camino por recorrer. Pasamos mucho tiempo tratando de entender lo que puede hacer Chef, las nuevas metodologías y cómo implementarlas".

Ofrecer alivio para el dolor

Desde el choque cultural al entrenamiento intenso, Wurster señala que es fundamental que las empresas le ofrezcan a sus desarrolladores y personal de operaciones algo a cambio de su angustia. "DevOps incluye el cambio de cultura, y se basa en la consideración de la responsabilidad, ser creativo y estar atentos", agrega, añadiendo que no va a funcionar a menos que a los empleados se les ofrezca un incentivo para probarlo.

Promociones, crecimiento, bonificaciones, Wurster indica esas son todas las recompensas que las empresas pueden utilizar para impulsar una mayor adopción de DevOps. Ser capaz de ver los frutos de su trabajo es también un poderoso incentivo. En el pasado, no era raro que un desarrollador pase meses creando una aplicación, solo para tirarla por encima del muro de operaciones y nunca oír hablar de ella nuevamente.

Humble sabe lo que es eso. Como ingeniero veterano, dice que una vez trabajó incansablemente en un producto de software, solo para descubrir varios años después de que, "a pesar de que llegó a tiempo, dentro del presupuesto y en la fecha prevista, la compañía para la que lo construimos en realidad tuvo que cancelarlo porque nadie lo quería. Eso fue muy aleccionador para mí y fue una de las epifanías que tuve sobre la entrega continua de DevOps".

Debido a que DevOps requiere la plena participación de los desarrolladores, desde el diseño de una aplicación hasta su despliegue, los miembros del equipo en realidad llegan a ver el valor que entregan sus creaciones en un entorno de producción en vivo.

Esto fomenta un mayor sentido de la propiedad, lo cual es especialmente gratificante con proyectos desafiantes.

Pero a medida que los desarrolladores y el personal de operaciones cosechan las recompensas de un entorno más colaborativo, los altos ejecutivos pueden estar preguntándose, "DevOps: ¿Qué hay en ellos para mí?" Y ese es un problema crucial para la adopción.

"Tienes que tener el apoyo del vicepresidente senior para hacer este tipo de transformación", señala DeArdo. "Hay una inversión y también hay cierto riesgo, por lo que necesita ese apoyo."

Medir las victorias del negocio

Por esta razón, Nicole Forsgren, director de desempeño de la organización y análisis en Chef, dice que es importante que las organizaciones establezcan métricas de rendimiento que sean específicas para DevOps a pesar de que pertenezcan a los negocios, como la rentabilidad, cuota de mercado y la productividad. Ella reconoce que "el camino a la línea de fondo puede ser un poco largo y sinuoso", pero señala que la búsqueda de una manera de medir cómo es que la entrega continúa, el mayor tiempo de actividad y un mayor impacto de colaboración del negocio, son clave para obtener altos niveles de aceptación.

¿Cómo es que DevOps ha acortado el ciclo de vida de desarrollo de software? ¿Cómo ha ayudado a acelerar el lanzamiento de nuevas versiones de productos? ¿Cómo es que la disponibilidad de red ha mejorado con DevOps? Al ver DevOps como vaticinador del desempeño de una organización, los equipos de TI pueden obtener con mayor facilidad el soporte ejecutivo que necesitan para sobrellevar los cambios culturales radicales.

Los desarrolladores y el personal de operaciones también se beneficiarán al establecer métricas. Los profesionales de TI se han acostumbrado a las funciones y responsabilidades estrictamente definidas con una mínima realimentación. En esencia, los desarrolladores puedan terminar un trabajo, entregarlo a operaciones y esperar lo mejor. DevOps les pide ampliar su alcance y hacer frente a un nuevo territorio -fuera de la caja de comportamiento que pueda abrirlos a la crítica.

"Hay mucho miedo en las organizaciones", anota Humble. "Los de operaciones están preocupados por la pérdida de sus puestos de trabajo debido a que no tienen un guión. Los evaluadores están preocupados por la pérdida de sus puestos de trabajo porque no saben cómo automatizar. Y los desarrolladores no quieren aprender acerca de cómo ejecutar el software en producción porque quieren ser codificadores". Sin embargo, mediante el establecimiento de expectativas claras y el uso de indicadores para medir el desempeño, los equipos de TI pueden protegerse contra señalamientos y, en su lugar, construir y desplegar con la seguridad de que su trabajo se medirá con las métricas establecidas.

De hecho, los adoptantes conocedores de DevOps están encontrando maneras de convertir la crítica en información valiosa. En el pasado, Kelley dice que una solicitud para, por ejemplo, un servidor llegaba, y el equipo de desarrollo lo construía y configuraba manualmente y luego lo entregaba -sin hacer preguntas.

Sin embargo, con el uso de Chef, el NREL es capaz de crear nuevas aplicaciones y entregarlas por etapas. Este enfoque poco sistemático al desarrollo y despliegue le da a operaciones el tiempo necesario para ofrecer realimentación a los desarrolladores sobre lo que está y no está funcionando.

"Es una mejora continua de flujo libre, en lugar de un gran proyecto que entrega todo a la vez", indica Kelley. "Ahora mordemos los proyectos en pequeños trozos y continuamente entregamos partes una y otra vez". El resultado, añade, es un valioso "circuito de realimentación" que puede ayudar a que las organizaciones eviten perder tiempo y dinero en proyectos condenados.

Ese es un cambio significativo de cómo los desarrolladores y el personal de operaciones solían abordar los proyectos, comenta Gary Gruver, un consultor DevOps y co-autor de "Un enfoque práctico de desarrollo ágil a gran escala, quien ayudó a guiar a los equipos de ingeniería a través de transformaciones de TI a gran escala en Macy's y Hewlett-Packard al principio de su carrera.

"Antes, un desarrollador podía construir algo y el trabajo de operaciones era trabajar en todos estos temas", agrega. "Ahora, en lugar de esperar seis semanas para que operaciones ejecute pruebas y comience la limpieza de aplicaciones, se aseguran que los desarrolladores arreglen problemas en forma permanente" -antes de que las aplicaciones entren a un entorno de producción. Lo que es más, señala el ejecutivo, DevOps ayuda a que los desarrolladores comprueben el código rápidamente y averigüen "en cuestión de horas" si un producto está listo para ser "integrado en un nuevo entorno de operaciones".

Construir un conjunto de herramientas

La selección de las herramientas adecuadas es también clave para la transición desde el modo de proyecto hacia DevOps. Es más fácil decirlo que hacerlo. El mercado DevOps es una red interconectada de gestión de proyectos, pruebas automatizadas, gestión de versiones, integración y herramientas de implementación continuas. Con el fin de dar sentido a esta "cadena de herramientas vagamente vinculadas", Wurster recomienda dividir soluciones en tres categorías principales.

En primer lugar, están las herramientas listas para DevOps, que están "diseñadas específicamente para ayudar con la automatización de configuración continua", señala Wurster. Estas ofertas "fuera de la caja" son las mejores para apoyar cambios culturales radicales a DevOps.

En segundo lugar, están las herramientas habilitadas para DevOps, que son tecnologías que se han ajustado y reposicionado para ayudar en la integración continua y actividades de calidad, así como las tareas de automatización de pruebas existentes. Si bien estas herramientas no son precisamente nuevas en el mercado, ayudan a facilitar una mayor colaboración entre los desarrolladores y el personal de operaciones.

Y, finalmente, hay herramientas con capacidad para DevOps -herramientas primarias de monitoreo, productos de pruebas de seguridad y soluciones de gestión de la vigilancia portátil principalmente para tareas importantes pero no urgentes.

En Nationwide, DeArdo ha creado un conjunto de herramientas que consta de IBM UrbanCode para agilizar la entrega, IBM Rational como una plataforma de desarrollo de software, Jenkins para la integración continua de código abierto, y Tasktop para extraer los componentes juntos.

Sin embargo, advierte que "las herramientas realmente no hacen mucho bien si no se tienen algunos procesos o prácticas estándar. Si se varía demasiado en la forma de trabajar, las herramientas no van a solucionar cualquier problema". Decidir qué herramientas se utilizarán y por qué, qué técnicas probablemente logren los mayores cambios en su entorno de TI, y cómo otras tecnologías -como la computación en la nube- podrían contribuir a una cultura DevOps, son preguntas que tiene que responder antes de abrazar la agilidad.

Solo los tontos se apresuran

Y, como suele ser el caso cuando se reacondiciona TI, quien es lento y constante gana la carrera. Después de años sumido en silos y versiones de software escalonados, la perspectiva de un suministro continuo puede causar que los líderes de TI salten sin mirar. Pero el éxito de la noche a la mañana no es posible con DevOps. Gruver advierte, "usted no va a ser capaz de hacer todo a la vez y no podrá planificar todo. Tiene que establecer metas para un período corto de tiempo, realizar un seguimiento y medir su progreso".

Tampoco debe esperar que su entorno DevOps se vea igual que todos los demás. A diferencia de ITIL, DevOps está abierto a interpretación y sigue evolucionando como una filosofía.

"La implementación de DevOps no es un proceso que se vea de la misma forma en todas partes", señala Forsgren. Pero aunque ella reconoce que el establecimiento de mejores prácticas, el tratamiento de la infraestructura como código e instigar una reforma cultural "puede ser complicado", cuando DevOps funciona", es increíblemente impactante".