Mitos y realidades sobre DevOps

El término DevOps nace en 2009 cuando Patrick Debois organiza en la ciudad belga de Gante el primer DevOpsday, un foro técnico donde reunir a desarrolladores y gente de operaciones para sentar las bases de una colaboración más estrecha entre los equipos de IT. Tras el éxito del evento comienzan a organizarse regularmente en otros países, el vocablo comienza a ganar popularidad y surgen los primeros intentos de dotarlo de un marco formal.

Aparecen libros como Toyota Kata (Mike Rother) o Continuous delivery (Jez Humble y David Farley), y grandes empresas como Flickr, Amazon o Etsy se jactan de seguir sus principios y comparten metodologías que les permiten liberar código en producción más de diez veces al día. Curiosamente uno de los textos más influyentes es la publicación a comienzos de 2013 de la novela The phoenix project. En el libro encontramos multitud de referencias a metodologías ágiles ya modelos productivos como Lean.
 
Llegamos a un punto donde hay tantas definiciones sobre “qué es DevOps” que, aun compartiendo una idea troncal común, cada una pone el foco en un área concreta y aparecen multitud de corrientes contradictorias. Es aquí donde nace la necesidad de dotar al término de una definición consensuada y en 2015 Patrick Debois, Gene Kim, John Willis y Jez Humble publican el libro DevOps Handbook, considerado por muchos como la biblia de DevOps. Grandes organizaciones como la Fundación Linux adoptan este como referencia para sus cursos.
 
En definitiva, podríamos definir DevOps como una cultura empresarial que busca alinear a todos los departamentos implicados en el ciclo de vida de un servicio/aplicación, centrando sus esfuerzos en conseguir un alto desempeño global, y no solo los departamentos de desarrollo y operaciones, sino también las áreas de negocio.
 
¿Cuáles son las influencias de DevOps?
 
Básicamente son tres: agile manifesto, lean y webscale IT. Encontraremos también referencias al método científico, el ciclo de Deming o psicología del trabajo (importancia del capital humano, luchar contra el burnout, mantener la motivación). En el lado técnico habla de un conjunto de buenas prácticas, como entrega continua, uso de Kanban o infraestructura como código, y también define algunos conceptos clave: producto mínimo viable (MVP), aprendizaje continuo, automatización, deployment pipeline, fail-fast o ganado vs. mascotas entre otros muchos.
 
“Si no puedes describir lo que haces como un proceso, entonces no sabes lo que
estás haciendo” Dr. William E. Deming
 
¿Por qué debería plantearme usar DevOps en mi empresa?
 
La mejor manera de mostrar las bondades de su implantación es señalando los beneficios obtenidos por empresas que ya lo han hecho:

• Recuperación frente a un fallo total: 96 veces más rápido.
• El tiempo entre que un cambio de código es introducido y se pone en producción es 440 veces más rápido.
• La frecuencia de los despliegues es 46 veces más común.
• Se duplica las veces que se alcanzan objetivos.
• Tasa de errores 5 veces menor: Del 38,5 % al 7,5 %.

Los datos comparan la situación antes y después de utilizar DevOps. Fuente: State of DevOps Report (Sexta encuesta anual de usuarios de DevOps).
 
¿Como puedo implantarlo?

Es común comenzar utilizando herramientas que nos habiliten la adopción de alguna de las metodologías propuestas. Todo el mundo habla de software como Puppet, Ansible, Docker, Jenkins, etc., cuando busca “perfiles DevOps” para sus equipos.
Si bien es cierto que utilizando estas herramientas conseguiremos una mejora cualitativa, centrarnos únicamente en la parte técnica hace que obviemos muchos de los beneficios.
 
Existe un modelo conocido como las 3 vías de DevOps en el que se plantea una adopción paulatina y no traumática trabajando en un objetivo concreto en cada una de sus fases. Podríamos resumir estas fases en:
 
Primera vía: Pensar en el sistema como un todo. El objetivo es obtener un conocimiento profundo del sistema poniendo foco en la creación de un flujo de trabajo ágil y mantenible.
 
Segunda vía: Mejorar el feedback. Es necesario trasladar el conocimiento a toda la cadena para hacer correcciones y mejoras, así como facilitar la toma de decisiones en base a los datos obtenidos.
 
Tercera vía: Cultura del aprendizaje y experimentación continua. Nos centraremos en poner a prueba el sistema para obtener la maestría suficiente en caso de fallos y poder evolucionar.
 
Como en otros aspectos de la vida, no hay soluciones mágicas ni atajos y es necesario conocer la empresa y sus procesos para poder adaptar DevOps a ella. Asesorarse correctamente y aprender de experiencias ajenas nos facilitará el camino enormemente.


Mitos
 
Existen algunos mitos sobre DevOps que no dejan de ser falsos. Repasemos algunos:
 
“Solo es válido para proyectos nuevos en la nube, con contenedores y/o microservicios” Es más sencillo implantar DevOps en proyectos nuevos que nazcan dentro de esta cultura, pero se puede utilizar en cualquier proyecto (como trasladar aplicaciones legacy a estos entornos [legacy in a box]).

“Habla solo de aspectos técnicos”
DevOps no busca solucionar un problema de tecnología sino de negocio y procesos. No solo habla de técnica, sino que intenta mejorar la calidad del trabajo, crear un marco de colaboración y comunicación entre equipos, utilizando aspectos de psicología laboral para romper los clásicos silos.
 
“Es rupturista”
DevOps no es un framework o metodología, sino un conjunto de buenas prácticas encaminadas a conseguir una cultura empresarial. La implementación en la empresa es evolutiva
 
“No es compatible con ITIL o SCRUM”
DevOps complementa muchas de estas metodologías, comparte muchas de sus buenas prácticas y tiene orígenes comunes. Todas persiguen el mismo fin: Mejorar los procesos. Son compatibles e incluso deseables que se apliquen juntas, aunque pueden existir algunos puntos de solapamiento.