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:
- Recomiendo comenzar por la Wikipedia. Es cierto que no debe usarse como la fuente de información definitiva pero es un interesante punto de partida. No en vano, desde mayo de 2010 hasta junio de 2016 la entrada correspondiente a DevOps ha tenido más de 700 revisiones, lo que nos da una muestra del esfuerzo realizado en la búsqueda de una definición rigurosa.
- En segundo lugar, no podemos dejar de visitar a algunos de los principales proveedores del sector TI. Entre otros, Oracle afirma que DevOps es una “nueva escuela de pensamiento”, para Microsoft consiste en aportar calidad en la cadena de valor del cliente aplicando técnicas lean y agile, para IBM es un acercamiento que promueve una colaboración más cercana entre el negocio, el desarrollo y las operaciones de TI y para HPE es una aproximación que enfatiza el desarrollo rápido, pequeño e interactivo de las aplicaciones.
- Por último, se puede bucear en el criterio de los medios de comunicación técnicos (Datamation, ITWorld, Techcrunch, Wired…), los analistas (Gartner, Forrester, 451 Research, Ovum…) o las principales firmas consultoras (Atos, Deloitte, CGI, Logicalis, Accenture…).
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:
- 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.
- 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).
- 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.
- 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.
- 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:
- Ciclos cortos de desarrollo y despliegue con piezas software de tamaño pequeño.
- 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.
- 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
Soluciones y Sectores
Te puede interesar
-
Edificios sostenibles para un turismo más inteligente y competitivo
El sector turístico representó el año pasado el 12,2% del PIB en España. Se trata, por tanto, de un ...
-
La capacitación en industria 4.0, condición sine qua non para su transformación
Recientemente leía un artículo sobre “Desafíos de la industria europea en la nueva coyuntura socioeconómica”. En él se apuntaba, ...
-
Hospitalización domiciliaria: un nuevo paradigma en la gestión de pacientes crónicos
Como explicaba en un post anterior, asistimos a la transformación de la atención médica para mejorar la calidad de ...
