Síguenos:
Cloud
1 de Agosto de 2017

En el nombre de DevOps

En el nombre de DevOps

En el nombre de DevOps

Escrito por , 1/08/2017

La Biblia nos cuenta que cuando Dios creó a Adán le encargó ponerle nombre a todas las criaturas (Génesis 1:19). Y no es algo baladí. Necesitamos que todas las cosas tengan un nombre para poder comunicarnos entre nosotros y evitar confusiones.

Quienes hayáis estado involucrados en el desarrollo de algún estándar, sabéis que la primera cuestión que hay que resolver es el glosario, el diccionario de términos que se utilizan como referencia. De esta manera se simplifica la relación entre las personas que utilizarán el estándar y éste podrá avanzar en su desarrollo e implantación sin obstáculos ocasionados por las diferencias en cómo denominamos cada actividad o proceso.

En “Pequeño gran hombre” (Little big man, Arthur Penn, 1970) el protagonista, interpretado por Dustin Hoffman, de origen blanco pero educado como cheyene, juega al engaño al comportarse como blanco o como cheyene según con quien, para sacar provecho. Y, en su avanzada ancianidad (¡llega a los 121 años!), termina quejándose amargamente de que los blancos lo desprecian como cheyene y los cheyenes como blanco. Si hubiese elegido adoptar una de las dos identidades de forma clara, en lugar de sacar partido de la confusión, habría tenido una vida menos problemática, aunque también es verdad que nos habríamos quedado sin esta gran película.

A DevOps le sucede algo parecido. El término apareció en 2009, lo crearon dos trabajadores de Flickr en una conferencia titulada “10+ Deploys per day”. En aquella sesión, John Allspaw y Paul Hammond se refirieron a los beneficios de unificar las actividades de desarrollo y operaciones en un único equipo con objetivos comunes.

Pero DevOps no cuenta con una definición inmutable que provenga de un marco de referencia o esté sujeta a la propiedad intelectual. Como consecuencia, cada proveedor o usuario termina denominando como “DevOps” a su propia versión de productos, servicios u operativas en función de su propio interés y conveniencia. Y con esto se provoca y magnifica la confusión terminológica.

Pero entonces ¿qué es DevOps? O, mejor aún, ¿dónde podemos encontrar la definición que sirva mejor a nuestra organización? Me voy a permitir hacer de guía turístico con la aportación de algunas referencias:

Después de esta singladura en torno al significado de DevOps, la conclusión que intento transmitiros es que cada uno define DevOps como le parece más oportuno.

También es verdad que para las grandes organizaciones la definición de DevOps es irrelevante, ya que lo que necesitan es una estrategia con un plan de despliegue. De hecho, en mi opinión, nunca va a ser posible disponer de un estándar en torno a DevOps, dado que cuando hayamos conseguido fijar una fotografía rigurosa y detallada de lo que queremos que sea DevOps, el mercado y nuestras propias circunstancias habrán cambiado tanto que dicho estándar resultará inservible.

Por el contrario, considero que son mucho más eficaces los foros de empresas o profesionales para la compartición de experiencias y mejores prácticas. En este sentido, en España tenemos ya algunos casos de nuevos foros públicos y privados que tratan estos asuntos, e incluso de organizaciones “de toda la vida” como itSMF que aportan su esfuerzo en adaptar las buenas prácticas tradicionales a las nuevas realidades TI como DevOps.

No hace muchos meses tuve la suerte de participar en una encuesta realizada entre siete de las mayores empresas de España de sectores como energía, logística, finanzas, construcción y, por supuesto, telecomunicaciones y creo que estas cinco conclusiones merecen consideración:

  1. En primer lugar, unánimemente se identificó la necesidad de que exista un departamento de Arquitectura, externo a los equipos de proyecto, que marque el rumbo tecnológico.
  2. Las siete compañías coincidieron en que se encontraban ya trabajando con herramientas de automatización del ciclo de vida del software (entrega o integración continua).
  3. Asimismo, una cuestión fundamental para todas ellas es la automatización de pruebas. En la aplicación de este aspecto existía incluso un grado de avance mayor que en el punto anterior.
  4. Existe una mayor dispersión de criterios en los entornos tecnológicos o la preferencia por herramientas opensource o comerciales convencionales. Pero esta diversidad de criterios es positiva, ya que refleja las diferencias propias entre los departamentos de TI de las organizaciones.
  5. Y donde la disparidad es mayor es en la dependencia que puede existir entre DevOps y las metodologías de desarrollo ágiles.

Todos estos aspectos son muy relevantes, reflejan que las grandes empresas en España (y seguramente en todo el mundo) no se están quedando paradas por el hecho de que no haya una definición estandarizada de DevOps, ni están esperando a que vengan los grandes consultores del sector TI a enseñarles cuál es el “camino de baldosas amarillas”, sino que se han lanzado por sí mismas a descubrir su camino hacia la transformación de las operaciones.

Si no queremos ser como el protagonista de “Pequeño gran hombre” y preferimos que se reconozca a nuestra organización como grande pero eficaz en su implantación de DevOps, deberemos crear nuestra propia definición. Os propongo la mía, en la que DevOps se compondría de tres características principales:

  1. Ciclos cortos de desarrollo y despliegue con piezas software de tamaño pequeño.
  2. El ciclo de vida del software se automatiza y agiliza (continuous delivery) y quedan en manos del equipo los momentos y la decisión del paso de un entorno a otro.
  3. Equipo humano: menos de diez personas, que combinen las habilidades core, autoorganizado y cooperativo.

Algunos de estos aspectos ya los hemos ido tratando en este blog, aunque les sacaremos más punta, y de otros escribiré más adelante. DevOps en las grandes organizaciones debe ser tratado con el rigor que le faltó al personaje de Dustin Hoffman pero, al mismo tiempo, es necesaria su capacidad de adaptación y de reinvención por el camino.

Imagen: Thomas Fisher rare Book

Sobre el autor

Eduardo Méndez Polo

Eduardo Méndez Polo

Llevo 26 años en este mundo de las TI, con lo que me ha dado tiempo a conocer una gran variedad de tecnologías, metodologías operativas y buenas prácticas. Por suerte (y por ganas) he podido también realizar casi todo tipo de funciones: desarrollo software, gestión de la calidad, despliegues, operaciones, infraestructura, planes técnicos y estratégicos… Los temas más recientes en los que me he visto envuelto han sido cloud computing y DevOps. En mi tiempo libre formo parte del Coro Gospel de Boadilla del Monte, y he dado unos primeros pasos en el complejo mundo del modelismo espacial…
Ver todos sus artículos »