Como es bien sabido en el mundo IT, si algo puede decirse con algún anglicismo todo suena más ‘cool’ pero no por ello es mejor, ni más novedoso. Por tanto es habitual caer en la tentación de usar anglicismos sin saber muy bien su origen o qué significan e incorporarlos a nuestro vocabulario diario por inercia, y claro, el desconcierto está servido.
Este artículo consta de dos partes; una primera parte en la que hablaremos de uno de estos términos de moda dejando claro qué es DevOps, qué no es y desmentir algunos de sus mitos y leyendas, y una segunda parte sobre los beneficios de usar Devops, cómo implementarlo, o los principios que lo cimentan.
El movimiento DevOps empezó a fraguarse entre el 2007 y el 2008 (años muy cercanos a los que dieron origen a los principios Agile con los que se encuentra muy interrelacionado) cuando en las convenciones técnicas, tanto de comunidades TI como de desarrollo de software, se empezó a hablar de forma franca de lo que, a través experiencias reales, funcionaba y de lo que no. Lo que dio lugar a un debate dentro de dichas comunidades de profesionales del sector, que además iban en aumento.
Los desarrolladores y profesionales de TI/Operaciones coincidían que la situación de partida era la de un claro aislamiento donde predominaban los silos de conocimiento o poder. Hasta entonces, las empresas solían mantener en “cajones separados” a los diferentes departamentos de una empresa. Muchas veces con objetivos distintos (y, a menudo, en clara competencia con otros), direcciones de departamento independientes, e indicadores globales del rendimiento totalmente separados por áreas. Esto repercutía en que “cada uno se preocupaba de lo suyo” y se convertía en una fuente recurrente de problemas graves (alta burocracia, problemas de competencia, etc.).
DevOps es un término surgido de la casualidad. Aparece por primera vez en 2009 cuando Patrick Debois organiza en la ciudad de Gante, Bélgica, un foro técnico donde se dieron cita profesionales del sector. Se dice que durante una de las charlas Patrick escribió en una pizarra DevOps como un acrónimo de “Develop and Operations” (Desarrollo y operaciones). El término gustó y comenzó a ser usado de forma masiva desde entonces.
La idea fundamental es entender DevOps como un ‘mindset’, o forma de pensar, con base en una serie de herramientas y que no busca solucionar un problema tecnológico concreto, sino de negocio y procesos en conjunto. Por lo que hablar de DevOps, no es solo hablar de técnica, sino también de intentar consensuar la forma en que todos los actores realizan su trabajo, creando un marco de colaboración y comunicación entre equipos, utilizando aspectos de psicología laboral para romper los clásicos silos.
Definir DevOps, es definir un conjunto de prácticas que automatizan los procesos entre los equipos de desarrollo de software y operaciones TI; para que las organizaciones puedan compilar, probar y publicar software con mayor rapidez y fiabilidad, basándose en una cultura de colaboración entre equipos que, tradicionalmente, venían trabajando en grupos aislados. Entre las ventajas que promete, se incluyen el aumento de la confianza y de la velocidad de publicación de software de calidad, la capacidad de solucionar incidencias críticas rápidamente y una mejor gestión del trabajo imprevisto.
Existen algunos mitos sobre DevOps. No pocas personas tienen falsas creencias acerca de este término. Quizá motivadas porque aunque su filosofía y bases son claras, no lo es tanto su contexto de aplicación.
Se tiende a pensar que es un término relacionado con empresas tecnológicas en exclusiva, como Netflix, Facebook, LinkedIn o Google. Si bien estas empresas fueron pioneras, los principios de DevOps son abiertos y quizá sin saberlo, tu empresa ya aplica alguna de sus premisas, como por ejemplo Agile o Lean.
Del mismo modo se tiende a pensar equivocadamente que todos los miembros de los equipos tengan que aprender de todo (desarrollo software, testing, operaciones, etc.). En realidad esto es completamente falso. DevOps no dice que los equipos de operaciones tengan que saber programar ni viceversa, si bien es cierto que ambos hacen uso de scripts para administrar entornos o realizan tareas con elementos software, en realidad lo que se pretende es que cada área tenga una noción de lo las funciones y tecnologías que usan el resto. De este modo, todos pueden entender y participar de manera activa en el desarrollo de un proyecto (control de versiones, rastreo de errores, etc.) y de esta manera contribuir al ciclo de vida del software sobre el que trabajan y aportar valor al negocio.
DevOps no es “ChatOps”. Aunque es cierto que DevOps depende de una buena comunicación entre equipos, esto no significa que todo se resuma a chatear entre sí por medio de IRC, Slack o Teams. Recuerda, una buena comunicación sin procesos adecuados tampoco es difencial.
No existe un rol de DevOps ‘per se’. Si encuentras un currículum que diga que alguien es ingeniero en DevOps desconfía. DevOps es cultura, herramientas y buenas prácticas para hacer de nuestra organización, una organización más humana entre equipos a distintos niveles.
No existe una biblia o manual DevOps, que contenga las instrucciones necesarias para realizar dicha transformación. DevOps se basa en las experiencias positivas y negativas que van acumulando los profesionales relacionados con la transformación digital, y por tanto se encuentra en constante evolución tanto tecnológicamente, a través de sus herramientas, como en cuanto al resto de elementos que lo componen. Y debe adaptarse siempre a la situación inicial de la empresa donde quiera aplicarse.
No te pierdas... DevOps: fundamentos, beneficios y cómo implantarlo (PARTE II)
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
