DevOps, vampiros y licántropos

Para cerrar nuestra trilogía de posts sobre DevOps (ya os contamos la génesis del movimiento DevOps y una primera aproximación a una definición de lo que entendemos por DevOps), hablamos hoy de cómo esta forma de trabajar viene a solucionar un enfrentamiento tan viejo como el que nos relata otra famosa trilogía cinematográfica, la de Underworld.

En el principio de los tiempos…

Parafraseando a Roberto Miñana, consultor y experto QSS en el área de Zaragoza, 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. devops3 star trek 200

El anhelo de los desarrolladores (programadores), por contra, 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 antena”.devops3 what-is-dev-ops-4 200

Ambas corrientes se sienten poseedoras de la razón. Hay una celebrada entrada en el blog de Jeff Atwood ‘Coding Horror’, donde ya en 2010 se comparaba a los programmers con vampiros y a los sysadmins con hombres lobos. Vamos, que los desarrolladores son como vampiros, apenas les da la luz del sol y con frecuencia suelen pensar que su código es 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.

En el fondo de la comparación están los hechos contrastados. Según Javier Garzás, profesor de la URJC en Madrid y “practitioner” en 233 Grados de Ti: “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“.

…DevOps como solución al conflicto

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.devops quote HENRY-FORD-770x300

Además, el despliegue continuo permite incorporar frecuentemente pequeños cambios, posiblemente la forma más estable de evolucionar un sistema en producción (a platos más pequeños, pérdidas más asumibles en la vajilla). Para Javier Garzás, “tanto DevOps como la entrega continua no dejan de ser nuevas palabras a la extensión de la agilidad y el Lean IT al área de operaciones. Y que refleja cómo va tomando forma lo que en un futuro será la manera de desarrollar de muchas empresas: Agile / Lean + DevOps / Continuous Delivery + Cloud“.

Sin duda, estas dos razas superhumanas están condenadas a entenderse para beneficio de nuestro “submundo”.

 

 

Si quieres saber más sobre este tema, te recomendamos:

 

Ingeniero de telecomunicación por la UPM, cuento con veinte años de experiencia en proyectos web en compañías como GMV-SGI, Germinus, Gesfor, Logica y CGI. Actualmente me ocupo de alinear y transmitir la oferta de Paradigma Digital, y ayudar a definir la mejor solución para cada cliente, aportando mis conocimientos sobre Internet y metodologías ágiles, mi capacidad de abstracción y el diseño de soluciones de negocio a partir de tecnologías cross.

Ver toda la actividad de José Ruiz Cristina

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

Comentarios

  1. Creo que es una vision muy reducida y poco realista considerar sistemas o infraestructuras como solo “operacion”.

    Las areas de sistemas, tambien hacen delivery e integracion, solo que en lugar de aplicaciones, es de tecnologias, como servidores web, de aplicaciones, gestores de colas, ldaps, buses de datos, gestores de contenidos, bases de datos, gestores documentales, caches de objetos, paquetes empresariales, etc… Y eso no lo hacen ni lo van a hacer los programadores ni sus jefes, ya sean adaptativos o predictivos.

    Saludos

Escribe un comentario