DevOps de Vampiros y Licántropos

DevOps de Vampiros y Licántropos

DevOps es uno de los términos más mencionados en el actual entorno de IT, normalmente se asocia a estrategias de transformación digital, y a metodologías como Continuous Delivery o desarrollo ágil (SCRUM, Kaban, Lean IT u otros).

Gran parte de la confusión viene de mezclar lo que es DevOps con los requisitos necesarios o los beneficios obtenidos al implementar DevOps. Sin querer ser excesivamente dogmáticos acerca de un término cuyas líneas de contorno aún no han acabado de asentarse del todo, vamos a intentar al menos arrojar algo de luz sobre el concepto.

Comenzamos con lo más próximo que hoy en día podemos tener a una definición canónica. ¿Qué dice Wikipedia de DevOps?:

“DevOps es un acrónimo inglés de development (desarrollo) y operations (operaciones), que se refiere a una metodología de desarrollo de software que se centra en la comunicación, colaboración e integración entre desarrolladores de software y los profesionales de sistemas en las tecnologías de la información (IT)”.DevOps es una respuesta a la interdependencia del desarrollo de software y las operaciones IT. Su objetivo es ayudar a una organización a producir productos y servicios software más rápidamente, de mejor calidad y a un costo menor. 

Las empresas con entregas (releases) muy frecuentes podrían requerir conocimientos de DevOps. Flickr desarrolló un sistema DevOps para cumplir un requisito de negocio de diez despliegues diarios. A este tipo de sistemas se les conoce como despliegue continuo (continuous deployment) o entrega continua (continuous delivery), y suelen estar asociados a metodologías ágiles.

Tres ideas clave:

  • DevOps es una metodología para creación de software.
  • DevOps se basa en la integración entre desarrolladores software y administradores de sistemas.
  • DevOps permite fabricar software más rápidamente, con mayor calidad, menor costo y una altísima frecuencia de releas

A pesar de que DevOps es una de las "Palabras de Moda" que hoy no puede faltar en cualquier evento respetable de IT, pocos conocen el origen de su historia, que resulta muy ilustrativa como contexto para entender mejor el significado del término.

Para los más curiosos, cuenta la leyenda que fue en 2008 en una convención informal de agilismo cuando un belga presentó y argumentó el concepto por primera vez, aún sin bautizarlo.

El término “DevOps” como tal se popularizó en 2009, a partir de los “DevOps Days” celebrados primero en Gante (Bélgica) y luego replicados en varias ciudades del mundo.

Resulta muy revelador comprobar cómo el movimiento DevOps está fuertemente ligado desde su origen a las metodologías ágiles de desarrollo software. Todo comenzó de hecho en la conferencia Agile’08 celebrada en agosto de ese año en Toronto (Canadá).

Andrew Clay Shafer (creador de Puppet Labs y ahora en Pivotal, la empresa de VMware y EMC2 que liberó la base de datos NoSQL Redis), tenía una conferencia asignada, pero a su charla sólo había acudido una persona, un belga llamado Patrick Debois, así que decidió no realizarla. Asaltado en los pasillos por ese mismo joven, que había viajado para contar su caso de no-éxito (“Infraestructura Agile y operaciones: ¿cómo de infra-ágil eres?”), y ante su insistencia, comenzaron a discutir cómo se podría llevar el agilismo al mundo de la infraestructura y la administración de sistemas.

Patrick había vivido una experiencia muy frustrante en un proyecto para el ministerio belga de finanzas que ni desarrolladores de software ni administradores de sistemas habían logrado sacar adelante. Animados por este intercambio de ideas, acordaron crear un grupo en Google para abrir la discusión a la comunidad, el Agile System Administrators Group.

Un año después, O’Reilly organizaba en junio en San José (California) el evento Velocity’09, transmitido en streaming. Tras la exposición de la ahora muy citada “10+ Deploys a Day: Dev and Ops Cooperation at Flickr” por John Allspaw y Paul Hammond, Patrick se lamentaba en Twitter de no haber podido asistir en persona.

Entonces Paul Nasrat, responsable del CMS del periódico británico The Guardian y desde 2010 en Google, respondió a su tuit proponiéndole que organizara un evento similar en Europa.

Patrick recogió el guante y sólo cuatro meses después estaba convocado su primer DevOps Day. La repercusión fue enorme, y el hashtag creado para la ocasión, #DevOps, triunfó en las redes sociales de forma viral, dando nombre a todo un movimiento.

El objetivo principal de la raza que podríamos llamar “sistemas” u “operaciones”, siempre ha sido el de mantener estables los sistemas en producción y garantizar su correcto funcionamiento, y para ello establecen férreos controles sobre el proceso de despliegue en producción (ventanas de despliegue, fuertes fases de prueba, complejos protocolos para solicitarlo, etc.). Viven bajo el yugo de garantías contractuales y acuerdos SLA, y su religión es la calidad del servicio y el evitar penalizaciones. 

El anhelo de los desarrolladores (programadores), por el contrario, es facilitar y acelerar el cambio, y conseguir hacer llegar al usuario lo antes posible las nuevas funcionalidades del código que tanto les ha costado desarrollar. No hay cosa más desesperante para ellos que ver cómo después de días y días de máximo esfuerzo y horas extras para cumplir un plazo, su código se queda parado durante días o semanas en el limbo del proceso de despliegue. Pero el problema es que lo que funciona en local en su máquina no siempre se comporta de la misma manera en el ambiente de “Producción”.

Ambas corrientes se sienten poseedoras de la razón. los desarrolladores son como vampiros, apenas les da la luz del sol y con frecuencia suelen pensar que su código es infalible e inmortal.

Mientras que los operadores de sistemas se semejan a licántropos, pues aunque puedan parecer normales, son inmunes a cosas que matarían a la gente común pero propensos a extrañas mutaciones, en especial cuando hay un corte de luz imprevisto o alguien ha estado tocando la versión en producción. “Normalmente a devs les gusta acceder a producción y a ops no le gusta que lo hagan.

Razones como las prisas por terminar un parche, en ocasiones evitar burocracia, poder probar en un entorno real, etc., hacen que a desarrollo le atraiga acceder a los sistemas sin permiso.

Y razones como la caída de un sistema en producción, que el software a instalar no sea del todo fiable, que no se sigan todos los procedimientos (como los script de marcha atrás en caso de fallo, o guardar las fuentes del código instalado en el repositorio de versiones de desarrollo, etc.) hacen que sistemas tampoco se fie demasiado“.

El área de desarrollo empuja el cambio, quiere facilidades para introducir nuevas funcionalidades en los productos. Y operaciones sin embargo quiere estabilidad en su servicio y que nada se mueva. Ambos encuentran la solución a sus desvelos en la virtualización de los entornos vía contenedores y en la automatización de las pruebas de control y estrés.

De esta manera ambas partes confían más en los entregables y en los entornos de ejecución, reduciéndose las tasas de fallos y el tiempo de despliegue. 

Los sysadmins encuentran en herramientas como Puppet o Chef una forma de hacer “Infraestructura como código” en apenas un cuarto de hora. Hay organizaciones que aseguran que mediante este modelo son capaces de desplegar código con una frecuencia hasta 30 veces superior a sus competidores, de una manera hasta 200 veces más rápido que antes y, además, con un porcentaje de errores hasta un 60% menor.

Unos aportes de mi biblioteca personal, primero comparto “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” es una novela escrita de 2013 por Gene Kim, Kevin Behr y George Spafford, que, además de haber sido un “best seller” en el área de tecnología, debe ser en estos últimos años el libro más citado cuando se habla de DevOps.

La novela cuenta la historia de un manager de TI, llamado Bill, que trabaja para una empresa llamada Parts Unlimited, que se dedica al área de retail y al que le dan noventa días para rescatar a un proyecto que va muy retrasado y por encima de presupuesto, cuyo nombre es el proyecto Phoenix. Espero que la disfruten.


Segundo, Si desea entender cómo conducir una entrega continua o DevOps en su empresa, no hay libro mejor que “Leading the Transformation: Applying Agile and DevOps Principles at Scale “, práctico y basado en experiencia ejecutiva duramente ganada, este libro es lectura esencial para cada ejecutivo de TI "

A continuación un resumen del futuro de DevOps


Inicia sesión para ver o añadir un comentario.

Más artículos de William Ernesto Quiñonez Corado

Otros usuarios han visto

Ver temas