DevOps: WTF?

Escribí este libro porque, al parecer, “DevOps” está creando mucha ansiedad entre los profesionales de TI del mundo. También está causando un poco de auge para la gente de marketing tecnológico, que a su vez está haciendo que todo el concepto sea confuso para las empresas y los profesionales por igual. He respondido a tantas preguntas sobre DevOps en conferencias, en foros online y en los comentarios de los blogs que me he encontrado reescribiendo casi las mismas cosas una y otra vez… lo que me ha hecho sentir que un pequeño libro podría estar en orden.

Este es un esfuerzo para poner las cosas en claro para alguien que pueda sentirse un poco vago o inseguro acerca de lo que es DevOps, si están o no “haciendo DevOps”, y así sucesivamente. Pretende ser útil para los líderes empresariales, los líderes tecnológicos y los tecnólogos. Lo mantendré conciso y directo. Debido a que el Colectivo DevOps es una organización sin fines de lucro, y debido a que no vendemos nada, también puedo mantener esto completamente no comercial, independiente de los proveedores, y honesto.

Espero que esto ayude.

DevOps -un portmanteau de “Desarrollo” y “Operaciones”- es una filosofía de gestión de TI. Así es: es una filosofía. No es una herramienta, aunque se pueden utilizar herramientas para aplicar la filosofía. No es un puesto de trabajo, aunque se necesitan personas para llevarlo a cabo. Como muchas filosofías, DevOps no es para todo el mundo, igual que el vegetarianismo o el budismo no son para todo el mundo.

DevOps se creó como una reacción a algo que estaba ocurriendo en algunas tiendas de TI. A medida que algunas organizaciones comenzaron a adoptar enfoques de desarrollo de software ágiles, se encontraron con que estaban produciendo un montón de nuevas construcciones de software en un período de tiempo bastante corto. Mientras que un equipo de desarrollo de software de la vieja escuela puede producir una gran versión de software cada uno o tres años, un equipo de desarrollo ágil puede sacar nuevas versiones cada día o cada semana. Probablemente, esto se ve mucho en tu teléfono móvil, con nuevas actualizaciones de aplicaciones que llegan prácticamente todos los días.

El problema es que muchas organizaciones de TI no confían siempre en sus desarrolladores. Todo el mundo se ha quemado cuando, después de trabajar duro en sus editores de código durante dos años, el equipo de desarrollo finalmente anunció que una nueva versión de software estaba lista, sólo para que el equipo de operaciones la desplegara e inmediatamente descubriera docenas de errores críticos que destruían el trabajo. “¡El cambio es malo!” se convirtió en el mantra, y Operaciones -a menudo a través de marcos de gestión como ITIL- se convirtió en el guardián del despliegue del software de forma segura, fiable y, lo que es más importante, de una forma que pudiera revertirse si todo se torcía. Como resultado, todas las técnicas de desarrollo ágil del mundo no importaban, porque Operaciones no estaba preparado para desplegar nuevas versiones de software cada quince minutos.

DevOps se creó específicamente no tanto para sacar a Ops del bucle, sino para hacer que Ops esté más automatizado. DevOps fue diseñado para confiar en los desarrolladores, y dejar que ellos, de forma más o menos autónoma, lanzaran nuevas compilaciones cuando quisieran. Los desarrolladores revisan el código, se produce un milagro, y ese código está en producción. El “milagro” es DevOps, además de todas las herramientas y procesos que apoyan la filosofía DevOps.

DevOps es, por tanto, una filosofía especialmente adecuada para resolver un tipo de problema concreto: desplegar rápidamente el código cuando los desarrolladores digan que está listo. Si ese no es un problema que usted tiene, o si ese resultado no es lo que quiere, entonces DevOps no es para usted. Es importante entender esto, porque DevOps no es para todas las organizaciones, e incluso dentro de las organizaciones que lo utilizan, DevOps no es para todos los productos de software que crean. DevOps funciona para crear ciertos resultados específicos, y sólo es útil cuando se quieren esos resultados. DevOps también crea su propio conjunto de riesgos y compromisos, y si no te gustan, entonces DevOps no es para ti. A pesar de lo que algunos expertos en marketing podrían hacerle creer, DevOps no es una nueva y brillante bala mágica para la TI; hay muchos productos y organizaciones a los que no les gustará, ni lo utilizarán, ni lo apreciarán.

Puppet Labs, un proveedor en el espacio de herramientas DevOps, produce un “Informe del Estado de DevOps” cada año. Estoy citando sus informes de 2016 y 2017, que se pueden encontrar aquí.

Recuerda: DevOps consiste en permitir el despliegue rápido de software. Cuando ese software se rompe, DevOps está destinado a apoyar igualmente un despliegue rápido de una versión de reemplazo, o de la última versión buena conocida. Así que estas cifras deben tomarse con esos objetivos en mente.

Las organizaciones que emplean un enfoque DevOps tienden a desplegar versiones de software hasta doscientas veces más frecuentemente. Despliegan hasta 2,500 veces más rápido, y su tiempo medio para recuperarse de un fallo es hasta 96 veces más rápido, aunque tienen menos de una quinta parte de probabilidades de tener un fallo en producción. Las tiendas DevOps de alto rendimiento están en la punta del iceberg, desplegando múltiples versiones de software al día, a menudo con menos de una hora de antelación. Se recuperan de los fallos en menos de una hora, con no más del 15% de sus cambios que resultan en un fallo.

Estas cifras son muy importantes.

Pero estas cifras no son sólo de DevOps. De hecho, podría decirse que estas cifras no son DevOps en absoluto; son el resultado de un equipo de desarrollo ágil y de alto rendimiento que ha sido habilitado por DevOps. En otras palabras, es el equipo de desarrollo el que realiza los nuevos despliegues, los despliega, falla o no falla, se recupera de los fallos, etc.; DevOps sólo está ahí para permitir que esos desarrolladores hagan que todo esto ocurra.

Te preguntarás: “¿cómo es posible que DevOps consiga que los fallos en los cambios estén por debajo del 15%?”. No es posible. Pero un equipo de desarrollo ágil que produce compilaciones diarias tiende a hacer pequeñas compilaciones diarias, con sólo pequeños cambios. Los pequeños cambios tienen menos probabilidades de fallar. DevOps les permite hacer esos despliegues diarios. Es cuando los desarrolladores empiezan a apilar semanas… meses… y años de cambios en un solo despliegue cuando es más probable que se produzca un fallo profundo, simplemente porque tienes más “partes móviles” en cada lanzamiento de cambios. Cuando un cambio falla, es más fácil rastrearlo si sólo se desplegó un cambio; si se desplegaron cientos de cambios, rastrear el problemático es más difícil, y lleva más tiempo recuperarse.

Por lo tanto, DevOps permite estas cifras fomentando el desarrollo y el despliegue ágil y en pequeñas iteraciones. El beneficio proviene de Agile, pero no se puede realmente “hacer” Agile sin tener DevOps allí para desplegar realmente el código Agile.

DevOps no es una metodología de desarrollo de software; es compatible con las metodologías ágiles. DevOp tampoco es una metodología de despliegue de software. Aunque DevOps se ocupa del despliegue de software, esa preocupación es básicamente “hacerlo rápido y sin problemas”; se puede utilizar cualquier metodología que cumpla ese criterio.

DevOps no es una herramienta que se pueda comprar, aunque las herramientas -a menudo muchas de ellas en una “pila tecnológica”- pueden ayudar a dar vida a DevOps.

DevOps no es un trabajo. Es una filosofía. Sin embargo, tendrá que contar con personas cuyo trabajo implique hacer que las herramientas y los procesos de DevOps funcionen a diario.

DevOps no es automatización. DevOps incluye la automatización, a menudo un montón de ella, pero la automatización por sí sola no “hace DevOps”. Si trabajas en una empresa que utiliza scripts de shell para desplegar nuevos servidores, eso no es DevOps, aunque esa actividad podría ser una de las que utiliza una tienda de DevOps. DevOps consiste en desplegar software sin problemas, rápidamente y bajo demanda. DevOps no pretende abordar los muchos otros aspectos de la gestión moderna de TI.

DevOps no es La Nube. Se puede “hacer” DevOps internamente on-prem e internamente, aunque muchos productos desplegados en la nube pueden beneficiarse de un enfoque DevOps. Muchos proveedores de la nube ofrecen servicios específicos, compatibles con DevOps, diseñados para productos que se mueven con una cadencia ágil.

DevOps no es un marco de gestión como ITIL, aunque puede existir dentro de un marco de este tipo, o existir sin ningún marco de este tipo. DevOps no le dice cómo “dirigir las TI” en su empresa; es un enfoque para resolver un problema específico, que es, “¿cómo podemos desplegar software de forma segura y consistente mucho más rápido y con mucho menos esfuerzo?”

Tiendo a evaluar DevOps mejor como una especie de organigrama. Hay ciertos organigramas que, para mí, gritan “¡estamos haciendo DevOps!” y otros igualmente gritan lo contrario.

DevOps se centra en el código, y su despliegue, lo que significa que DevOps se centra en un producto. Un producto puede ser una aplicación, o puede ser algún tipo de sistema de creación de infraestructura (“Infraestructura como código”, del que hablaré más adelante), o algo parecido. Teniendo esto en cuenta, el equipo de personas involucradas suele llamarse equipo de producto.

Un equipo de producto suele estar formado por varias funciones. Puede tener un director de proyecto, un gestor de producto, varios desarrolladores (aunque no más de los que puedan comer sólo dos pizzas, un diseñador de UX, etc. También tendrás algunas personas de Operaciones, como un administrador de la base de datos, alguien encargado del despliegue del producto, etc. Todas las personas necesarias para llevar el proyecto desde el “código” hasta la “producción” están en el equipo. No se trata simplemente de un equipo de desarrollo que codifica y luego pasa el código “por encima del muro” a otra persona. DevOps evita los silos y se centra en reunir a todos los que contribuyen a la existencia y el éxito del producto.

Es muy notable la inclusión de Operaciones en el equipo de producto. “¡Eh, vamos a utilizar esta nueva biblioteca de interfaz de usuario que parece genial!” podría ser toda la discusión que un equipo de desarrollo puro tiene antes de saltar y utilizar dicha nueva biblioteca; la presencia de una persona de Operaciones en el equipo les permite plantear preocupaciones como, “chicos, esa cosa es un oso para desplegar y requiere un reinicio completo del sistema cada vez que lo hacemos”. Este es el corazón de DevOps: todo el mundo, desarrolladores y operaciones por igual, se preocupa por el resultado del producto: llevarlo a producción. No hay un “oye, ya hemos terminado de codificar, pasémoslo a otro equipo para que lo despliegue”; el mismo equipo es responsable de todos los aspectos del ciclo de vida del producto.

Algunos miembros del equipo pueden trabajar en varios equipos de producto. Un gestor de proyectos puede gestionar más de un producto, por ejemplo, y un especialista en operaciones puede trabajar en varios equipos de productos.

Cada tipo de función suele formar un gremio entre equipos. Por ejemplo, todos los desarrolladores pueden tener su propio gremio, que se reúne regularmente y discute cosas de particular importancia para su función, como los estándares de codificación, las decisiones sobre qué bibliotecas de apoyo adoptar, etc. Estos gremios crean coherencia entre los equipos y ayudan a polinizar nuevas ideas, nuevos estándares y nuevos enfoques.

El departamento general de TI incluirá otros equipos de soporte que no forman parte del universo DevOps. Los administradores de sistemas de mensajería, algunos administradores de bases de datos, algunos administradores de servidores, etc., serán responsables de mantener la infraestructura compartida. Si no están contribuyendo a un producto, entonces no son DevOps. Una organización puede tener muchos equipos de estilo DevOps, y muchos equipos que no son de estilo DevOps, según sea necesario para apoyar cualquier función que tengan.

Tecnológicamente, DevOps funciona un poco así:

1. Los desarrolladores revisan el código.
2. Una cadena de construcción automatizada toma el código, compila el proyecto y pone en marcha un entorno de pruebas virtual.
3. Dentro de ese entorno, se ejecutan pruebas unitarias automatizadas para probar el código. Los fallos hacen que se envíe un informe a los desarrolladores, y el proceso se detiene.
4. Cuando se ejecuta con éxito, el proyecto se despliega en producción, a menudo en un sistema de despliegue de software de algún tipo.

Los desarrolladores tienen todo el control: comprueban el código y, si todas las pruebas se superan, el código pasa a producción. Y punto. Cualquier otra cosa no es “DevOps”, aunque no ser DevOps no significa “no tener valor”.

“¿Qué pasa con un error del desarrollador que las pruebas unitarias no detectan?” Ah, aquí es donde está el verdadero corazón de DevOps. En primer lugar, usted podría revertir su control de origen a la versión anterior, dejar que la tubería de construcción automatizada haga lo suyo, y desplegar esa versión. Luego (y podrías hacer esta parte primero, si crees que puedes hacerlo rápidamente), escribes una nueva prueba de unidad para detectar este nuevo error. Confirmas que el código existente falla la prueba, validando así la prueba unitaria. A continuación, se corrige el código hasta que la prueba pase, momento en el que la cadena de construcción también lo desplegará en producción.

Las pruebas automatizadas son la “memoria institucional” del desarrollo. Garantizan que un error sólo se despliegue una vez; después, las pruebas unitarias revisadas “detectarán” el error si vuelve a aparecer. Las pruebas automatizadas nunca se olvidan de probar alguna condición concreta (como hacen las personas).

DevOps es bueno para apoyar a los equipos de desarrollo ágil que producen rápidamente nuevas construcciones de software pequeñas e incrementales en una cadencia rápida y regular. Eso es todo. De hecho, se puede hacer una lista de comprobación:

• ¿Desarrollamos software con una cadencia ágil?
• ¿Producimos nuevas versiones diaria o semanalmente?
• ¿Cada nueva versión es relativamente pequeña en términos de los cambios que contiene?
• ¿Confiamos en los pipelines de construcción automatizados, incluidas las pruebas unitarias automatizadas?
• ¿Estamos dispuestos a estar tranquilos cuando se despliega un error, sabiendo que podemos volver a desplegar rápidamente la última versión buena conocida?

Si la respuesta a cualquiera de estas preguntas es “no”, es posible que DevOps no sea para usted. Todos esos beneficios numéricos de DevOps sólo se aplican si puedes responder “sí” a todo lo anterior. Sencillamente, no se pueden conseguir los beneficios sin hacer todo el trabajo.

Muchas organizaciones no deberían utilizar DevOps. Por ejemplo, una empresa que fabrica software para el funcionamiento de reactores nucleares. No se trata de un software de “movimiento rápido” en el que se pueda tolerar cierto grado de fallo; no es un producto DevOps. Lo mismo ocurre con la empresa que fabrica software de control de resonancias magnéticas para hospitales. Lo mismo ocurre con el banco que utiliza ordenadores de gama media con décadas de antigüedad, programados en COBOL, para ejecutar su back-end.

La única advertencia que ofrecería es: “bueno, nuestro negocio no puede sobrevivir o tolerar el más mínimo fallo momentáneo en nuestro software, así que no podemos usar DevOps”. Eso probablemente no es cierto, porque todo el software tiene un fallo de algún tipo en algún momento. En la mayoría de las tiendas que no son DevOps, esos errores tardan mucho tiempo en corregirse, aún más en probarse y verificarse manualmente, y aún más en desplegarse; el punto de DevOps es reconocer que fallar es humano, y fallar rápidamente, revertir rápidamente, y seguir adelante es DevOps. Nunca he visto una sola pieza de software con cero errores, y he trabajado en algunos entornos increíblemente críticos; con DevOps, simplemente se falla con más gracia. Esto supone, por supuesto, que estás “haciendo” DevOps porque tienes un equipo ágil capaz de lanzar versiones rápidas, pequeñas e iterativas de su software. Todo el DevOps del mundo no servirá de nada si apoya a un equipo de codificadores de estilo “cascada” que no pueden escribir una línea de código sin seis semanas de reuniones de planificación. Una de las razones por las que las tiendas DevOps experimentan menos errores es porque trabajan en incrementos más pequeños de cambio. “Más pequeño” significa que “los humanos pueden envolver sus cabezas más fácilmente”, lo que significa que “es menos probable que lo hagan mal”.

Personalmente, no me gusta ese término por su inexactitud sintáctica. “Como” se utiliza para introducir un símil, que es una especie de comparación. La infraestructura no es código, ni el código es infraestructura; no sirven para lo mismo, y no son comparables. Es como decir “manzanas como carretillas”. No hay comparación.

Una frase más correcta desde el punto de vista sintáctico podría ser “infraestructura desde el código”, que describe con precisión la actividad de escribir código informático que da lugar a la creación, modificación o mantenimiento de elementos de infraestructura. El código que aprovisiona nuevos servidores virtuales y despliega software en ellos es, “infraestructura desde el código”.

Cualquier organización puede beneficiarse de añadir DevOps a la “infraestructura desde el código” (IfC). El código, en este caso, es el producto, y aunque pueda ser creado y mantenido por personas distintas de los desarrolladores tradicionales, sigue siendo código. Deberían seguir registrándolo en el control de código fuente, y pueden utilizar absolutamente los conductos de construcción automatizados -incluyendo las pruebas de validación de la infraestructura automatizada en lugar de las pruebas unitarias- para validar que el código produjo los resultados deseados, y luego empujarlo a la producción.

Como medio para configurar la infraestructura, IfC tiene claras ventajas, incluida la capacidad de ejecutar potencialmente el código para recrear un entorno completo, en una nueva ubicación, como respuesta de recuperación ante un desastre. DevOps se limita a añadir la canalización automatizada de construcción-prueba-despliegue, al igual que en un producto de software de cadencia ágil más tradicional.

Aparte del equipo, del que ya he hablado aquí, las tiendas DevOps utilizan una variedad de herramientas para crear la automatización que hace que DevOps funcione.

Comenzará con un repositorio de código fuente de algún tipo, lo que podría significar algo como Git, GitHub, Microsoft Visual Studio Team Services, etc. Algunos productos son más adecuados para un entorno de estilo DevOps que otros, así que investiga.

La integración continua, o CI, es la siguiente herramienta. Las marcas incluyen Jenkins, Team City. CircleCI, TravisCI, etc. Estas coordinan la creación de entornos virtuales para las pruebas, la ejecución de pruebas unitarias, etc. CI ayuda a los desarrolladores a ser más productivos al permitirles probar rápida y continuamente su código, con la presunción de que las pruebas unitarias automatizadas sirven como una especie de “especificación funcional” contra la que se prueba el código.

Las herramientas de entorno también pueden ayudar, las herramientas como Vagrant que ayudan a gestionar entornos basados en contenedores para que el código se ejecute. Esto puede facilitar la creación de entornos de desarrollo, prueba y producción coherentes, por ejemplo.

El despliegue de software es la última parte del rompecabezas, y difiere mucho según el producto que se despliegue. Los sistemas existentes, como Microsoft System Center Configuration Manager, pueden utilizarse para el despliegue de software interno, pero si se despliega en un entorno de nube, se puede utilizar un servicio de nube adaptado específicamente a los enfoques de DevOps.

Nominalmente, no. Sin embargo, DevOps implica muchos componentes tecnológicos, procesos y conocimientos técnicos, y no es raro que un “ingeniero de DevOps” sea la persona encargada de hacer que todo eso funcione. Pero ciertamente se puede “hacer” DevOps sin un “Ingeniero DevOps”. Es totalmente posible que un equipo de Operaciones “normal” se encargue de esas tareas, ya que DevOps consiste realmente en allanar el camino entre los desarrolladores y el despliegue. Sin embargo, es seguro decir que no se puede simplemente contratar a un “ingeniero de DevOps” y legítimamente estar “haciendo” DevOps; DevOps existe para apoyar el desarrollo de software ágil, por lo que tiene que tener su equipo de desarrolladores en marcha antes de ser capaz de desplegar rápidamente su código le hará ningún bien.

DevOps puede ser un enfoque útil, y miles de empresas tienen éxito con él ahora mismo. Las ventajas son claras, pero sólo si está dispuesto a comprometerse con todo el conjunto. Eso significa que DevOps no es para todos, y lo más inteligente que puede hacer es decidir, por adelantado, si es un camino que usted y su organización deben seguir para algunos de sus productos.