Primeros pasos con DevOps: el viaje de tu empresa

Tribuna de Opinión de Jaime Balañá, director técnico de NetApp Iberia

Las definiciones de DevOps aceptadas tienden por tanto a centrarse en los aspectos culturales del despliegue de IT: acabar con los silos de equipos y fomentar la colaboración en toda la organización para alcanzar fines comunes. También enfatizan la inversión en automatización para mejorar la fiabilidad, y en la recopilación de métricas para mejorar la concienciación sobre el flujo de despliegue.

¿DevOps, Agile o Site Reliability Engineering?

Otros nuevos términos que han surgido en las últimas dos décadas, a menudo relacionados con DevOps, son el desarrollo de Software Agile y de Site Reliability Engineering (SRE). La metodología ágil es un conjunto de prácticas de gestión de proyectos que se han desarrollado desde la publicación en 2001 del Manifiesto Ágil. Estas prácticas enfatizan la autoorganización y los ajustes continuos a las tareas de los equipos de despliegue de aplicaciones. Por el contrario, SRE es una disciplina de ingeniería que se centra en aplicar competencias y prácticas de desarrollo de software para reducir el continuado coste de la operación de las aplicaciones. Aunque las prácticas Agile y SRE están íntimamente relacionadas con organizaciones de DevOps altamente funcionales, ninguna de ellas es necesaria para realizar una transición a un modo de trabajo de DevOps.

La transición a DevOps

¿Qué es entonces necesario para realizar la transición a un equipo de DevOps? ¿Merece la pena el esfuerzo? En esta sección describiré algunos de los factores y prácticas recomendadas que deberemos tener en cuenta al realizar el cambio.

Determinar nuestras motivaciones

El mejor modo de comenzar es determinar los aspectos motivadores. Pueden existir muchas razones para cambiar a una metodología de DevOps, como acelerar la incorporación de nuevas funcionalidades, reducir el coste de despliegue y mantenimiento, mejorar la calidad, o tomar decisiones aplicando métricas. Decidir al principio cuál es el más importante ayudará durante el proceso.

Comunicar nuestros objetivos

Tras determinar los aspectos motivadores, es importante permanecer centrado en esos objetivos a medida que buscamos cómo cambiar los métodos de trabajo de nuestros equipos. «DevOps» es un término amplio y vagamente utilizado, por lo que resulta fácil distraerse ante las distintas rutas disponibles. La comunicación es la clave, porque en muchos puntos, los cambios que queremos hacer pueden no entenderse o incluso cuestionarse. Inevitablemente, cambiar el modo en que los equipos operan y entregan cualquier producto incurrirá en costes al principio (y probablemente en cambios en las funciones de los empleados), así que es fundamental que entiendan el panorama completo.

Gestionar el cambio

Uno de los mantras comunes de la comunidad DevOps es: «tú lo creas, tú lo ejecutas». Esta frase puede significar que un único equipo es responsable tanto del desarrollo como de las operaciones, y los métodos de trabajo actuales pueden verse alterados. Por ejemplo, los desarrolladores pueden cambiar a una rotación por turnos. Otra modificación habitual es reemplazar los procesos y operaciones de control de cambios manuales a procesos automatizados, exponiendo los interfaces a través de APIs. Implementar estos cambios conlleva ajustes en los métodos y tareas de trabajo. A medida que pasa el tiempo y el cambio cobra impulso, se puede descubrir que es necesario ejercitar nuestras habilidades de gestión, o involucrar al equipo de Recursos Humanos, para suavizar estas transiciones.

Prepararse para afrontar los obstáculos técnicos

Aunque la introducción de DevOps es principalmente un cambio cultural, ciertas habilidades técnicas específicas pueden ayudar a facilitar la transición. Las más destacadas de estas habilidades son tener conocimientos en Git, herramientas de integración continua como Jenkins, y herramientas de automatización de la infraestructura como Chef y Ansible.

Normalmente es preferible, si es posible, formar a nuestro personal en estas nuevas herramientas. Además de ser más rentable que contratar nuevo personal, enseñar nuevas habilidades puede aumentar el nivel de compromiso de las personas que mejor entienden el negocio.

Para lograr los objetivos de DevOps de automatización y mejorar la colaboración entre equipos que antes se encontraban aislados, es posible que también tengamos que hacer cambios técnicos en los procesos de gestión. Por ejemplo, muchos sistemas de control de cambios y documentación no son adecuados para un modo de trabajo colaborativo y es posible que necesitemos reemplazar o renovar los sistemas existentes para hacer posible este objetivo.

En el equipo de Cloud Analytics de NetApp, por ejemplo, utilizamos los productos JIRA y Confluence de Atlassian, porque hemos descubiertos que nos aportan la colaboración en tiempo real y cultura de comunicación abierta que requiere DevOps.

Acabar con los cuellos de botella gracias a APIs y servicios

Otra forma de ayudar a la automatización es usar unas API más formales y definidas en vez de sistemas de petición bajo demanda para servicios dentro de nuestra empresa. Ejemplos habituales de estos servicios son los cambios en el cortafuegos de la red o peticiones para instalar una versión específica de software en un servidor. Por ejemplo, las APIs pueden implementarse con interfaces REST si el servicio al que accedemos a través de la API necesita automatizarse y crecer a escala. Por otra parte, la automatización puede basarse en web si los procesos están aún madurando o no son a gran escala. Tomemos el camino que tomemos, para un enfoque realmente DevOps es importante depender menos de que las personas realicen pasos manuales y moverse hacia un modelo basado en servicios que reduzca los cuellos de botella.

En NetApp sacamos todo el partido posible a la automatización en las herramientas que utilizamos, y llevamos este enfoque a las herramientas que creamos. Nuestro portfolio de servicios cloud ofrece distintas APIs de integración que nos ayudarán en la transición.

La tecnología es el medio, no el fin

Como mencioné al comienzo de este artículo, DevOps se beneficia de las herramientas, no se define por ellas. Un error común en la búsqueda de esta transición es creer que las herramientas por sí solas cambiarán los hábitos, comportamientos y prácticas incorrectas. Importa poco si usa Ansible o Chef, Confluence o SharePoint. El mejor modo de lograr sus objetivos es mejorando la comunicación y la automatización donde sea posible, en vez de adoptar una tecnología que no tenga en cuenta el contexto en el que se realiza el trabajo.

Tener en cuenta las barreras culturales

¿Cómo inculcar la mentalidad adecuada dentro de una organización que aún no ha adoptado DevOps, y cuáles serán los obstáculos de dichos cambios?

La principal barrera es la inercia institucional. El cambio dentro de la organización puede crear inquietud o inestabilidad entre los miembros del personal. Los cambios que DevOps puede suponer para los distintos roles, como habilidades técnicas específicas, estructura del equipo o relaciones entre equipos, pueden resultar problemáticos para algunos. La resistencia tanto abierta como encubierta al cambio puede suponer un impedimento para dichos cambios.

Por desgracia no todos querrán unirse al viaje. Pero podemos aumentar el compromiso y velocidad presentando los cambios de una forma abierta, como oportunidades de crecimiento profesional. Involucrar a los miembros del equipo en la toma de decisiones también es de gran ayuda. Deberemos descubrir a los miembros clave entre el personal que abanderarán la transición, y apoyarlos siempre que sea posible. Ello ayudará a acelerar la velocidad del cambio, tanto técnico como cultural.

Incluso contando con el apoyo del personal y del equipo directivo, cambiar el modo en que trabaja un equipo no es gratuito, así que deberemos estar atentos a otro posible cambio: invertir recursos en cambios mucho antes de ver la rentabilidad. Si no estamos preparados para esto se puede perder el rumbo, porque la presión de revertir a modos más familiares de trabajar puede sobrepasarnos. Desgraciadamente, DevOps a menudo se percibe como una panacea que reduce los costes y mejora la calidad sin dolor. Pero por supuesto, ningún negocio cuenta con esa varita mágica.

Para terminar...

Cuando se adopta una metodología de DevOps, las opciones son innumerables. Estas opciones pueden ser abrumadoras, por lo que es vital recordar qué nos llevó a realizar el cambio en primer lugar. Puesto que los retos técnicos y culturales provocarán circunstancias adversas difíciles de superar, es imprescindible conseguir el compromiso de las partes interesadas dentro de la empresa, a todos los niveles. La transición a DevOps es un proceso de mejora continua, así que cuando nuestros cambios comiencen a dar sus frutos mediante las métricas que definamos hay que asegurarse de hacer públicos estos éxitos en toda la empresa para que se mantenga el impulso.

Dado que nuestros cambios se construirán uno sobre otro, los beneficios de un aumento en el control operativo y previsibilidad de los resultados empresariales se percibirán de forma inmediata. Dormiremos mejor sabiendo que los procesos establecidos ayudarán a gestionar cualquier problema y que nuestros ingenieros tendrán la información necesaria para resolver cualquier asunto rápidamente. Y el equipo directivo estará más contento, porque un ciclo de desarrollo más rápido reduce el plazo de comercialización.

Entre muchas de las opciones que existen en el mercado, NetApp ofrece una gama de servicios cloud creados por y para DevOps. Tanto para crear aplicaciones como para gestionarlas, merece la pena echar un vistazo a nuestro portfolio de servicios cloud.

Jaime Balañá, director técnico de NetApp Iberia