En un mundo en el que la digitalización avanza rápidamente, surge la siguiente pregunta: ¿cómo podemos ofrecer soluciones de software más rápidas y eficientes?
Las migraciones a la nube suelen estar en el centro de los proyectos, pero hay una visión profunda detrás de estas decisiones. Esta visión combina el potencial de la tecnología en la nube con los principios de DevOps para maximizar la velocidad de desarrollo y despliegue. En esta serie de blogs, analizamos cómo DevOps influye directamente en las decisiones y procesos de una migración a la nube y por qué es crucial comprender y adaptar este enfoque.
Este es el primer artículo de nuestra serie sobre DevOps. En las próximas semanas publicaremos más artículos en profundidad.
La visión: Con Warp 9.99 hacia el futuro
Hoy en día, la migración a la nube está en el centro de muchos proyectos. Sin embargo, cuando se pregunta a los participantes en el proyecto por la motivación que hay detrás de esta migración a la nube, rápidamente se pone de manifiesto que esta decisión se tomó «en otro lugar». Sin embargo, esta decisión tiene una base fundamentalmente importante, que se analizará en esta serie de blogs.
La influencia de DevOps, cuya visión y objetivos tienen un impacto directo en las decisiones de migración a la nube, será el centro de la descripción.
Una de las herramientas de planificación más populares sigue siendo la hoja de cálculo Excel de Microsoft (en alemán) o sus alternativas. Una de las razones por las que Excel es muy popular -y no sólo en planificación- es la rapidez con la que los departamentos pueden llevar a cabo aspectos (es decir, cálculos, análisis, manipulación de datos, etc.) de forma independiente.
Hace unos años, un departamento especializado comparaba con el desarrollo de software la posibilidad de maximizar la velocidad de implementación de funciones individuales en Excel. Una discusión sobre los retrasos en el desarrollo de funciones para un sistema existente entre el departamento especializado y el de desarrollo de software solía ser más o menos así:
Departamento: «¿Por qué siempre tardáis tanto en implantar el desarrollo de software? Simplemente creamos una nueva hoja de datos en Excel y estamos listos para trabajar. Ahora me estáis diciendo que no podré realizar la función XY en nuestro sistema hasta dentro de unos meses. No lo entiendo, por favor, explícamelo».
Desarrollo de software: «…» (A menudo explica los engorrosos y complejos procesos de desarrollo y los consiguientes retrasos).
Incluso hoy en día, la analogía de Excel anterior sigue siendo ridiculizada erróneamente como el colmo de la incomprensión de los procesos en el desarrollo de software por parte de los departamentos especializados y tachada de irrealista y utópica. Sin embargo, en el fondo, esta analogía expresa una visión fundamentalmente innovadora:
Las características o requisitos individuales de nuestros clientes, que van dirigidos a los sistemas que se van a realizar, deben ponerse en producción con la misma rapidez y eficacia que la creación de una nueva hoja de datos en Excel, idealmente controladas por el propio cliente y sin estar sujetas a engorrosos procesos (de liberación) o tiempos de inactividad (periodo en el que un sistema no está disponible).
Idealmente, esto significa que cada commit en un sistema de control de versiones constituye un lanzamiento de producción potencial (más adelante en esta serie se hablará de ello). En otra versión de esta visión, las funcionalidades ya están en producción en un punto definido en el tiempo y simplemente pueden ser activadas allí por los propios gestores especializados en una fecha (u hora) clave.
Los aspectos sustantivos de esta visión se presentarán en detalle a lo largo de esta serie de blogs. Sin embargo, su realización requiere una visión fundamentalmente diferente del proceso global de desarrollo de software, sobre todo en lo que respecta a la superación de un conflicto clásico entre el desarrollo de software y las operaciones, del que pueden extraerse algunas ideas para el diseño de la visión.
La palabra portmanteau DevOps como resultado de un conflicto clásico
En las estructuras empresariales clásicas, organizadas jerárquicamente, sigue existiendo una separación en silos de las funciones y áreas de responsabilidad que puede remontarse a el llamado principio taylorista (en alemán). El principio de control de los procesos de trabajo desarrollado por F. W. Taylor es una de las razones de la separación de estos procesos en áreas separadas y organizadas jerárquicamente:
Figura 1: Estructura jerárquica de la empresa (extracto)
La figura 1 muestra un ejemplo de separación funcional entre compras, marketing y ventas, informática, producción y personal y administración. Un peligro explícito que se deriva de una forma organizativa de este tipo es la separación o desvinculación de las distintas áreas funcionales. Un ejemplo extremo sería la externalización de toda la IT a una empresa externa, basándose en la opinión de que la IT es un «mal necesario» de una empresa. Sin embargo, hoy en día las IT impregnan todos los procesos y flujos de trabajo de una empresa, lo que, desde una perspectiva alternativa, convierte a dicha empresa en una empresa de IT (más sobre esto más adelante).
En la figura 2 se ilustra otra subdivisión ejemplar de las TI en áreas funcionales organizadas jerárquicamente:
Figura 2: TI organizada jerárquicamente en áreas funcionales
De forma análoga al riesgo de demarcación y aislamiento de las IT en una empresa mencionado anteriormente, la demarcación entre desarrollo (DEV) y operaciones (OPS) -a menudo denominada «muro de la confusión»- da lugar a un conflicto que se ha desarrollado durante décadas y cuyas dimensiones se enfrentan y manifiestan en diversos grados.
A continuación se explican cinco de estas dimensiones contrastadas:
Objetivos y prioridades:
El objetivo principal del desarrollo de software es cumplir los requisitos del cliente. El desarrollo de software es un proceso inherentemente creativo: lo ideal es que las nuevas funciones se realicen centrándose en la introducción, el uso o el cumplimiento de enfoques/lenguajes/marcos innovadores, etc. Este cumplimiento tiene lugar en el marco de iteraciones en las que los incrementos se generan/implementan en los sistemas. Esta realización tiene lugar en el marco de iteraciones en las que los incrementos se generan/implementan en los sistemas. En comparación con la realización de los objetivos mencionados, los equipos de operaciones son responsables de garantizar que los sistemas existentes sean estables, fiables y seguros. Por tanto, se centran más en la estabilidad y disponibilidad de las funciones implementadas en la aplicación.
Velocidad y estabilidad
Con demasiada frecuencia, los equipos de desarrollo de software se ven sometidos a una enorme presión para implementar y entregar los requisitos con rapidez. Las nuevas funciones, actualizaciones o correcciones de errores deben entregarse lo antes posible. Los equipos de operaciones, en cambio, prefieren un enfoque más lento y prudente para minimizar el riesgo de fallos o problemas y así mantener o aumentar la estabilidad.
Herramientas y tecnologías
Por un lado, en el desarrollo de software se suelen utilizar las herramientas y tecnologías más recientes, mientras que, por otro, los equipos de operaciones pueden decantarse por tecnologías más antiguas y probadas para garantizar la estabilidad y seguridad del sistema en su conjunto.
Responsabilidad y propiedad
Por un lado, los equipos de desarrollo de software pueden sentirse responsables del código que producen, mientras que, por otro, los equipos de operaciones pueden sentirse responsables de todo el sistema y expresar derechos de propiedad.
Comunicación y colaboración
Tanto los equipos de desarrollo de software como los de operaciones trabajan en sus respectivos silos (véase la Figura 2). Por tanto, la información no siempre se transmite de forma eficaz.
Para cumplir la visión mencionada al principio, es decir, gestionar la entrega de los requisitos implementados con la máxima rapidez, hay que superar estos conflictos. El primer enfoque para superarlos consiste en desarrollar y aplicar un modelo de colaboración entre desarrollo y operaciones.
Las dos partes del nombre (dev y ops) de la traducción inglesa de estas dos áreas de responsabilidad – development y operations – se combinan para formar una palabra anidada: DevOps.
El establecimiento y la promoción de una cultura DevOps en una empresa, que se basa en particular en las dimensiones de responsabilidad, propiedad, comunicación y colaboración, está inicialmente a la vanguardia de la introducción de la cultura subyacente, que se retomará más adelante en esta serie de blogs.
A su vez, esta cultura conduce a una comprensión compartida de los demás aspectos conflictivos que deben abordarse y resolverse conjuntamente. Las decisiones y características tecnológicas desempeñan un papel fundamental en la resolución de los conflictos de las dimensiones «velocidad y estabilidad» y «herramientas y tecnologías» en particular. A la hora de seguir estudiando las posibilidades de resolver de forma óptima el conflicto en estas dimensiones, es preciso abordar los tres flujos esenciales, de los que pueden derivarse todos los demás conceptos.
Los tres ríos o vías (flujos)
Los flujos que se resumen a continuación se explican en detalle por Gene Kim y en el manual DevOps.
La primera ruta permite que el trabajo fluya lo más rápidamente posible de izquierda a derecha (véase la Figura 3):
Figura 3: Flujo de desarrollo a operaciones
Este planteamiento hace hincapié explícitamente en el rendimiento del sistema global más que en el trabajo de silos individuales (departamentos o empleados individuales). Aquí se incluyen todos los flujos de valor empresarial que permiten las IT, desde los requisitos hasta la entrega. Por tanto, esta entrega representa valor para el cliente en forma de servicio.
Excurso: plazo de entrega
Gene Kim et. al. diferencian explícitamente entre lead time y processing time. Mientras que el lead time comienza cuando se crea o realiza una solicitud y se completa con la entrega final, el tiempo de procesamiento representa el periodo de tiempo desde el inicio real del trabajo en el ticket correspondiente en el backlog (véase la Figura 4).
Figura 4: Tiempo de procesamiento y rendimiento
En concreto, el primer flujo consiste en optimizar el tiempo de paso de una solicitud por el sistema global.
En el segundo flujo, los bucles de retroalimentación se obtienen de forma rápida y continua. Este flujo de retroalimentación se establece a lo largo de todo el primer recorrido (véase la Figura 5).
Figura 5: Circuitos de retroalimentación
En el segundo enfoque, la atención se centra en corregir y mejorar continuamente estos bucles de retroalimentación, es decir, acortar su duración y anclar el conocimiento donde sea necesario.
El tercer flujo tiene que ver con la creación de una cultura de experimentación y asunción de riesgos. El objetivo de esta vía es crear una cultura de aprendizaje que aprenda de los errores resultantes, repitiendo y practicando los pasos para fomentar la aparición de una cultura de confianza (véase la Figura 6).
Figura 6: Creación de una cultura de experimentación y aprendizaje
Dedicar tiempo a las mejoras o crear rituales (de recompensa) que puedan derivarse de la asunción de riesgos contribuye a aumentar la resistencia de la cultura frente a los factores de influencia negativos.
¿Y Cloudnative?
DevOps representa uno de los cuatro pilares, especialmente en el contexto de cloudnative (véase la Figura 7). Estos son: DevOps, microservicios, contenedores y entrega continua.
Figura 7: Los cuatro pilares de Cloudnative
Cada uno de estos cuatro principios básicos, presentados como pilares de Cloudnative, tiene una influencia significativa en la velocidad a la que los requisitos implementados pueden ponerse en producción y, por lo tanto, cada uno tiene un impacto masivo en la realización de la visión mencionada al principio.
El resto de esta serie de blogs tratará con más detalle cada uno de los pilares y las condiciones marco.
