¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.techbiz
José Ruiz Cristina 01/12/2015 Cargando comentarios…
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.
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".
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.
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".
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.