DevOps para principiantes

¿Qué es DevOps y por qué las organizaciones están migrando a un "modelo operativo DevOps"?

Empecemos con dos definiciones, ambas de proveedores de nubes a hiperescala: Microsoft y Amazon:

Las definiciones coinciden en varios factores clave que es importante que entienda el principiante en DevOps: -

• DevOps es "algo más que herramientas": combina personas, cultura, procesos, prácticas, herramientas y tecnología.
• DevOps se centra en el cliente: se esfuerza por ofrecer valor y servir mejor a sus clientes.
• El objetivo de DevOps es mejorar el tiempo de comercialización: ofrecer valor a "alta velocidad" (o de forma continua) pero, sobre todo, sin comprometer la estabilidad, disponibilidad o seguridad de sus aplicaciones/servicios.

¿Por qué es necesario DevOps?

Antes de profundizar en estas tres áreas, es importante preguntarse "¿Por qué DevOps?"

¿Qué fallaba en las formas existentes de gestionar el Desarrollo y las Operaciones (el "Dev" + "Ops" de "DevOps") que impulsó la necesidad de cambiar?

Esta es también una pregunta importante que debe hacerse antes de iniciar su propia transformación DevOps: ¿qué necesidades de los clientes NO está satisfaciendo actualmente con su modelo de entrega actual, y puede medir (cuantificar) la brecha entre lo que está proporcionando actualmente y lo que sus clientes necesitan? Esto le ayudará a construir el "caso de negocio para DevOps" para obtener la inversión y los recursos que necesita y así alcanzar sus objetivos de transformación DevOps.

La respuesta corta a esta pregunta es que, en muchas organizaciones, las áreas de desarrollo y operaciones eran silos con objetivos diferentes, líneas jerárquicas diferentes y culturas diferentes. Esto significaba que el trabajo, en particular las nuevas versiones de aplicaciones, no fluía con rapidez y facilidad desde las estaciones de trabajo de los desarrolladores hasta los entornos de producción, pasando por el proceso de lanzamiento. Los cambios en los sistemas se consideraban de alto riesgo, ya que introducían errores y provocaban inestabilidad y escasa disponibilidad de los sistemas de producción.

Esto, a su vez, provoca la insatisfacción y las quejas de los clientes. Esto provocó un conflicto constante entre el departamento de Operaciones, cuyo objetivo era la estabilidad y la disponibilidad, y el de Desarrollo, cuyo objetivo era poner las nuevas funciones en manos de los clientes lo antes posible.

Este conflicto y desalineación se intensificaron cuando muchos equipos de desarrollo adoptaron las metodologías de desarrollo de software ágil y de entrega continua, que hacen hincapié en versiones más pequeñas y frecuentes. El equipo de Operaciones no disponía de las "filosofías culturales, prácticas y herramientas" para satisfacer esta necesidad, al menos no sin poner en riesgo la estabilidad de los sistemas de producción. Por lo tanto, DevOps evolucionó para satisfacer esta necesidad tanto de velocidad como de estabilidad.

¿Qué debe incluir su modelo DevOps?

Así pues, dado que DevOps es "algo más que herramientas", ¿cuáles son los elementos clave de un "modelo DevOps"?

Un marco popular en la comunidad DevOps es el modelo CALMS, tratado por primera vez por Jez Humble en "El manual de DevOps". Tabla 1 - El modelo CALMS desglosa los cinco elementos del modelo.

El reto de pasar a un modelo operativo DevOps, en particular para los tecnólogos del departamento de TI, es que somos excelentes en la aplicación de la automatización y las herramientas, pero tenemos mucha menos experiencia en cosas como la creación de una cultura sólida, el análisis de procesos Lean o la medición efectiva de los resultados de los clientes, en lugar de limitarse al monitoreo de las métricas del sistema. Esto destaca la necesidad de que la gente de transformación DevOps llegue más allá del departamento de TI para ayudar a fomentar el cambio. Por ejemplo, el departamento de RRHH debería contar con personas con más experiencia en el fomento del cambio cultural. Si su organización se dedica a la fabricación, es posible que encuentre una experiencia Lean profunda en otras partes del negocio. El departamento de TI no puede emprender el cambio a un modelo DevOps de forma aislada del resto de la organización.

Centrarse en el cliente y alinear a las partes interesadas

A continuación, debemos analizar qué significa estar "centrado en el cliente" como parte de una transformación DevOps.

Para cualquiera que desempeñe un rol de liderazgo, especialmente en organizaciones empresariales grandes y distribuidas, la queja de que "TI" no está "alineada" con "El Negocio" es probablemente familiar.

Muchos clientes [internos] o usuarios finales de otros departamentos sienten que TI "no les da lo que quieren o necesitan" para satisfacer las necesidades de sus clientes reales, externos. Las TI se ven como un silo separado dentro de la organización más amplia, demasiado lento, demasiado encerrado en sí mismo y demasiado centrado en "hacer cosas de nerds de TI" que en ofrecer valor al cliente.

Por injusto que esto pueda parecer a muchos dentro del departamento de TI, solo tenemos que echar un vistazo a la estructura de muchos departamentos de TI para ver la verdad de esta afirmación. La mayoría de los departamentos de TI tradicionales se organizan en torno a silos tecnológicos: los administradores de bases de datos en un equipo, las redes y comunicaciones en otro, la infraestructura de servidores en otro, etcétera. Para lograr un resultado integral para el cliente, por ejemplo, el lanzamiento de un nuevo producto o servicio, es necesario coordinar todos esos silos diferentes, lo que puede resultar costoso y llevar mucho tiempo.

¿La "alineación de productos" forma parte de la respuesta?

Como parte de su transformación DevOps, muchas organizaciones están pasando a un modelo "alineado con el producto", es decir, equipos multidisciplinares que atraviesan los silos de TI tradicionales para centrarse en ofrecer un producto/servicio que satisfaga una necesidad concreta del cliente. También se denominan "equipos alineados con el flujo de valor" porque están alineados con un flujo de valor del cliente y pueden ofrecer nuevos productos o funciones de productos "de principio a fin", desde la idea inicial hasta la fase de desarrollo, implementación y operaciones en producción. Estos equipos son "dueños" de su producto, y sus métricas de éxito deben alinearse con las métricas reales del cliente, como la satisfacción del cliente, la adopción, el crecimiento, etc.

Acelerar el cambio

Por último, cuando nos fijamos en el "tiempo de comercialización" y en cómo DevOps puede lograr "velocidad Y estabilidad".

Muchas organizaciones tradicionales de TI, agotadas por los desastrosos rollouts de productos opacados por la mala calidad del código, pruebas inadecuadas y procesos de lanzamiento manuales y propensos a errores, tienen miedo al cambio. En consecuencia, hacen lanzamientos con poca frecuencia, a veces incluso en ciclos anuales o trimestrales. Estos "grandes lanzamientos" son, paradójicamente, aún más difíciles de gestionar y coordinar, lo que aumenta el riesgo. Como ya se ha dicho, esto también provoca una gran frustración en "la empresa", que considera que las TI son demasiado lentas y engorrosas. A su vez, esto lleva a los usuarios de la empresa a intentar eludir al departamento de TI... la temida "TI en la sombra": productos y servicios de TI que no están bajo el control del departamento de TI, y esto puede plantear riesgos de seguridad y de otro tipo para la empresa y sus clientes.

Al mismo tiempo, aumenta el apetito de los usuarios por nuevas funciones y su impaciencia ante las funciones prometidas desde hace tiempo y que aún no han sido lanzadas. Las organizaciones que pueden satisfacer o anticiparse rápidamente a las necesidades de los clientes, con poca o ninguna interrupción de los servicios existentes, a menor costo y con mayor calidad, pueden ganar cuota de mercado a las que no pueden hacerlo. Las investigaciones sobre DevOps han demostrado que las organizaciones que adoptan DevOps, en particular las que se destacan en las cuatro métricas de DevOps comentadas anteriormente, pueden superar sus objetivos en crecimiento de clientes, cuota de mercado y rentabilidad.

DevOps permite a las organizaciones lanzar cambios más pequeños con mucha más frecuencia y menos riesgo al fomentar una cultura que acepta el cambio, y que aprovecha prácticas técnicas como la automatización para mejorar la calidad, reducir el error humano y proporcionar información rápida si las cosas van mal. Muchas organizaciones lanzan cientos, si no miles, de cambios a producción cada día, con una tasa de fracaso de cambios muy baja y un plazo de entrega rápido. Esto complace a los clientes internos y externos por igual, mejora la satisfacción del cliente e inicia un "círculo virtuoso" de mejora del rendimiento en cada paso del flujo de valor.

¡Buena suerte en su viaje DevOps!