DevOps – Desarrollo y Operaciones colaborando en la entrega de valor

A lo largo de los años trabajando con equipos de operaciones y equipos de desarrollo, me he dado cuenta de una confusión recurrente con el término DevOps. Las ofertas de empleo, que aparecen en la red, tampoco ayudan demasiado a entender el concepto sino todo lo contrario.

Hemos sido espectadores de afirmaciones tales como: “es una evolución de agile” “es automatizar los despliegues”“hacer entrega continua” y hasta  hemos podido observar que algunos afirmaban “ser DevOps”, que viene a ser lo mismo que ser actor y afirmar ser “el mundo del espectáculo”.

¿Que NO es DevOps?

Algunas fuentes afirman que “DevOps es una evolución de Agile que va más allá de “una metodología de desarrollo” en la misma línea que “agile evolucionó de Waterfall” . La “metodología DevOps”, comentan estas fuentes, nació de la necesidad de aumentar la colaboración entre desarrollo y operaciones, y de esa manera, “entregar más rápidamente el software”. Estas afirmaciones están muy lejos de la realidad y basan sus conclusiones en términos malinterpretados.

A parte, y digno de mención, existen otros pocos que piensan que “los equipos DevOps son desarrolladores” que también “despliegan el software y lo mantienen”.  Algo como los hombres orquesta del software. Esta interpretación es muy conveniente para algunas empresas cuando quieren ahorrar en costes de desarrollo y mantenimiento.

Seas de desarrollo u operaciones, te recomiendo echar un vistazo a “Devops for Developers”. Aunque está orientado a que alguien con enfoque más en desarrollo entienda mejor estos conceptos, creo que es indistinto el rol que tengas para que te sea de utilidad.

¿Que SI es DevOps?

DevOps se refiere a una cultura o movimiento que se centra en comunicación, colaboración e integración entre desarrolladores de software y los profesionales de operaciones en las tecnologías de la información (IT). Se trata de una respuesta a la interdependencia del desarrollo de software y las operaciones IT con el objetivo de ayudar a una organización a producir productos y servicios software rápidamente y con calidad.

DevOps no es una evolución de agile, ni tampoco agile es una metodología. Agile explicado de una forma simplificada es un conjunto de valores y principios que son comunes a aquellos frameworks de desarrollo software que basan su desarrollo en el empirismo y la mejora continua. Se llama “ágile” (ágil) en contraposición con metodologías más “pesadas” como Waterfall.

Si te interesa conocer un poco más de detalle de por qué aquellas metodologías “pesadas” no funcionan en el mundo software, te invito a echar un vistazo a un post que escribí ya hace tiempo:  “El por qué de que muchos proyectos fracasen I: Waterfall “.

Agile y DevOps por tanto no son incompatibles, de hecho, DevOps tiene su origen como movimiento en la conferencia de 2008 de Agile Alliance. Os dejo un video que explica su historia.

Dos partes distintas de un todo

El time to market es el tiempo medio desde que se forma la idea hasta que la ponemos en producción. Desarrollo crea incrementos de producto listos para ser utilizados y operaciones se encarga de los despliegues (y del mantenimiento). En el caso del despliegue, lo más eficiente es que este sea un sistema de pull, es decir, cuando hay un incremento de producto disponible en el repositorio de binarios operaciones lo despliega.

Cuando te dedicas a mantener software puesto en producción, lo que tienes en mente es estabilidad y escalado. Piensas en como puedes dar servicio con ese software y esa infraestructura a los usuarios de forma eficiente, monitorizando la demanda, escalando cuando es necesario y resolviendo los problemas que pudieran surgir de una manera óptima.

Sin embargo, si te dedicas a desarrollar software, lo que tienes en mente es el cambio y la calidad de tu producto. Tus requisitos cambian constantemente, el código muta a lo largo de su desarrollo. Si se baja la guardia en la calidad de lo entregado impactará en errores cuyo coste es más elevado cuanto más tarde son detectados (Cost of Quality).

Ambos mundos tienen un mismo objetivo pero se ocupan de partes distintas de un todo. La forma de optimizar el cycle time de desarrollo no es exactamente la misma que la de optimizar el cycle time de despliegue.

Para mejorar el cycle time de desarrollo se tiene que pensar en herramientas que permitan automatizar la construcción y garantizar la calidad de los cambios (integración continuaanálisis estático de código, test unitarios, etc.) y se debe pensar en frameworks/técnicas que permitan adaptarse al cambio de una manera eficiente sin decrementar la calidad y el valor proporcionado del entregable al usuario final (ScrumTDDGitflow…).

Por otro lado para mejorar el cycle time de los despliegues, el equipo de operaciones debe pensar en la automatizaciónmonitorización y escalado. Hablamos de dar un servicio a varios productos, y por esto funcionan con SLAs, estandarización y procedimientos de gestión del servicio. Ellos buscan la estabilidad.

Calidad y cooperación

Conseguir que ambos equipos tengan la misma visión se convierte en uno de los grandes retos para sacar un producto al mercado con calidad de una forma rápida. El aseguramiento de la calidad, el entendimiento, la paciencia y la cooperación entre ambos equipos es vital para DevOps.

Por ese motivo, optimizar el cycle time de forma local en cada equipo no es suficiente para que tenga impacto real en el Time to Market.  Si observamos la  forma de trabajar de ambos equipos como un sistema y aplicamos los principios del pensamiento sistémico, entendemos que algunas decisiones que tome uno de los equipos podrían ser perjudiciales para el conjunto. Os pongo dos ejemplos concretos:

  • Desarrollo descuida la calidad. La garantía de que el incremento de producto cumple una serie de quality gates (y un DoD) es esencial, entre otras muchas cosas,  para que cualquier automatización en la parte de operaciones tenga garantía de éxito. No es lo mismo automatizar el despliegue de algo que tenemos confianza de que funciona correctamente que automatizar algo de lo cual no tenemos garantía.
  • Operaciones no participa en la elaboración producto. Los requisitos no funcionales del entorno son importantes tenerlos en cuenta en etapas tempranas del desarrollo y la participación de operaciones en este punto es esencial. Nos encontramos muchos productos que una vez desplegados no encajan adecuadamente con las capacidades de la infraestructura y no se puede dar el servicio adecuado.

Mi humilde opinión

Creo que lo más importante en DevOps son las personas y que todo lo demás es sentido común aplicado en el  momento de que ambos equipos colaboran. No hablar un lenguaje común, ni haber un entendimiento debido a una separación tanto física como conceptual entre ambos equipos suele llevar a tres problemas:

  • El juego de las acusaciones. Todo el mundo está equivocado y todo el mundo tiene a la vez razón.
  • El muro de la confusión. Objetivos contradictorios y dos visiones distintas que son parte de una visión más amplia llevan a una falta de entendimiento.
  • Cuellos de botella. Las entregas de incrementos cada pocas semanas en ecosistemas ágiles hacen visible más aún la falta de coordinación entre ambos equipos, así como la falta de automatización.

Nosotros para romper esta barrera de la confusión solemos hacer participar más al equipo de operaciones en el día a día de los equipos de desarrollo (y viceversa). Por ejemplo rotando a un miembro del equipo para que participe en las dailies, planificaciones y sprints reviews.

Además, si tenemos muchos equipos y productos distintos, tenemos comprobado que funciona muy bien reuniones cortas y periódicas para resolver impedimentos entre los representantes de desarrollo, calidad y operaciones.

Yo creo que las confusiones que existen en algunos casos en torno a DevOps y Agile se producen principalmente por no tener claros los conceptos que manejamos. Esto es habitual en cualquier disciplina y creo que debemos aceptar que en un mundo global, la desinformación existe y es responsabilidad nuestra profundizar en los conceptos.

Y tú, ¿qué opinas?

El origen de DevOps

Tenía pensado sacar algunos posts en relación a DevOps y pensando creo que puede ser buena idea por comenzar por los orígenes. Creo que hoy en día se confunde mucho DevOps con el uso de herramientas, lo cual es una parte importante, pero no es todo.

DevOps es un movimiento originado en 2007, cuando Patrick Debois, un consultor freelance, estuvo analizando el sector IT. Su objetivo principal era ganar experiencia en todas las perspectivas en la cadena de valor IT. Tiene un blog bastante interesante.

En 2007 mientras Debois estaba en un proyecto de consultoría para el gobierno de Bélgica para la migración de un data center se frustra debido a los conflictos que se producían entre desarrolladores y administradores de sistemas. Debido a esto él decide proponer una solución.

En Agosto del 2008, en Agile2008 conference, Andrew Clay Shafer y Patrick Debois se conocen. Shafer habló sobre la “infraestructura Agile” y sólo una persona atiende: Patrick Debois. Shafer, al ver que no había más que un asistente, piensa que no había interés en este tema salta esta sesión y Debois más tarde tiene con una larga conversación en el pasillo sobre el tema.

De esta y otras conversaciones surgieron todas las típicas frustraciones y conflictos que existen entre operaciones y desarrollo, así como sus motivos. Ambos crearon un grupo en Google denominado “Agile System Administrators” creado para continuar el debate.

devops_timeline

En 2009 John Allspaw y Paul Hammond presentan “10 deploy per Day”en la O’Relly Velocity 09 Conference. La principal premisa era enfocarse en asegurar que Dev y Ops trabajaban juntos y de forma crossfunctional a través de las herramientas y procesos ágiles.

Esto inspiró a Debois creando el evento “DevOpsDays” en Bélgica (DOD). Decide hacer exactamente lo que indica la charla y toma de aquí el concepto DevOps (Dev and Ops Cooperation at Flickr). La conferencia de puertas abiertas tiene lugar en Octubre de este año y se continua la discusión vía Twitter. El movimiento empieza a surgir.

Al mismo tiempo, la integración continua está en su momento de auge dentro del espectro Agile. Y había mucho movimiento en cuanto al continuous deployment sobre todo con la aparición del libro “Continuous delivery”.

Mientras en paralelo la industria IT empiezan a tener fuerza otras metodologías como Operation Management, Lean e IT service management.

Este movimiento formado por debates, conferencias, twitter y  lentamente tomó atención de la industria. IBM, CA Technologies, HP y BMC empiezan a aplicarlo.

En una entrevista de InfoQ en Abril del 2012, Debois admite que el nombre no fue intencional, que simplemente el título original era muy largo y escribió “DevOpsDay” para acortar. De aquí emergió el nombre DevOps.

Por otro lado, la similitud entre las palabras “Debois” y “DevOps” siempre me ha parecido un dato, al menos curioso.

Por ahora esto es todo. Espero que os haya aclarado al menos el origen.