Introducción a Devops y la automatización de la instalación y gestión de sistemas

julio 7, 2016 — por David Mataró4

main

ConsultoríaCPDDevOpsMetodología

Introducción a Devops y la automatización de la instalación y gestión de sistemas

julio 7, 2016 — por David Mataró4

Primero de todo, me gustaría agradecer a Josep Mª y a todo su equipo la posibilidad de colaborar en este espacio de divulgación tecnológica.

Ya hace tiempo que vengo colaborando con Orbal y en las extensas y divertidas conversaciones con Josep Mª  siempre hemos comentado de la posibilidad de participar en el Blog. Y aprovechando este nuevo re-lanzamiento del blog, hemos creído que ahora era el momento. Pues eso, a partir de ahora voy a escribir sobre temas de automatización de la gestión de sistemas y aplicaciones y otros temas que puedan ser de interés.

Hoy vamos a introducir una de estas palabras de moda, Devops. Existen un sin fin de definiciones de Devops, pero a mi me gusta definir Devops como un conjunto de prácticas, principios y herramientas que una empresa puede utilizar para mejorar la velocidad de despliegue y calidad de sus aplicaciones.

Los principios en que se basa Devops están alineados con el concepto conocido como CAMS (culture, automation, measurement and sharing).

Cultura: los fallos no deben comportar la búsqueda de un culpable, sino que los fallos son el camino que un equipo debe utilizar para pensar que practicas utilizar para responder ante estos fallos.

Automatización: las acciones manuales inducen al fallo. Automatizar la instalación y configuración de sistemas y aplicaciones permite reducir fallos.

Medir: la monitorización y análisis son esenciales para la gestión de cualquier sistema y aplicación. Sin monitorizar es imposible conocer las causas de los fallos y poder tomar acciones correctoras para que estos no se vuelvas a producir.

Compartir: compartir el conocimiento por todo el equipo de trabajo nos permite ser más ágiles y eliminar dependencias.

Estos principios deben ser compartidos por los equipos de desarrollo y de operaciones con el fin de alinear los objetivos de ambos equipos, a los objetivos de la organización. A menudo, los objetivos del equipo de desarrollo y del equipo de operaciones no son los mismos, lo que conlleva situaciones que no favorecen alcanzar los objetivos de la empresa.

Introduccion a DevopsCuantas veces hemos oído afirmaciones como “El servidor funciona bien, es tu código” o “En mi pc funciona, es tu servidor”. Seguro que demasiadas veces. Para entender la problemática debemos ver cuales son los objetivos principales de los equipos de desarrollo y de operaciones. El equipo de desarrollo se ve presionado por los sponsors del proyecto o equipo de marketing para sacar nuevas funcionalidades o solucionar bugs. Hecho que provoca que estos deban realizar cambios en las aplicaciones y desplegar estos cambios a producción frecuentemente. Por lo contrario, el objetivo principal del equipo de operaciones es mantener los sistemas en funcionamiento y estables, con lo que lo último que desean es hacer cambios frecuentes en los sistemas que ponen en riesgo dicha estabilidad.

Tenemos que tener en cuenta que las funcionalidades desarrolladas por el equipo de desarrollo tienen un impacto directo sobre los sistemas. Por ejemplo, una nueva funcionalidad puede consumir mucho espacio de disco guardando ficheros que suben los usuarios. En este ejemplo, si se despliega esta nueva funcionalidad y el equipo de operaciones desconoce el impacto de esta nueva funcionalidad, puede llegar a provocar una incidencia por falta de espacio, lo cual  conllevará a una actuación reactiva del equipo de operaciones i seguramente al descontento de este (sobre todo si salta una alerta de espacio a las 5 de la mañana). No sería mejor que el alguien del equipo de operaciones esté en las sesiones periódicas de planificación del equipo de desarrollo para evaluar conjuntamente con el equipo de desarrollo el impacto que las nuevas funcionalidades tienen sobre los sistemas. Así el equipo de operaciones podría tomar medidas y ampliar disco antes de realizar el despliegue de esta nueva funcionalidad.

Si volvemos a “El servidor funciona bien, es tu código” o “En mi pc funciona, es tu servidor” veremos que en muchos casos, los sistemas de desarrollo no son los mismos que los sistemas de producción: sistemas operativos diferentes, versiones de software diferentes, falta de aplicaciones de parches de seguridad, etc….Herramientas como Vagrant o herramientas de gestión de la configuración como Chef o Puppet permiten que los sistemas de desarrollo sean iguales a los sistemas de producción. Estas herramientas permiten que todos los entornos del ciclo de despliegue de una aplicación sean iguales e eliminar las incompatibilidades entre entornos así como incidencias en el entorno de producción.

Sin duda, aplicar estas practicas i principios requieren de un cambios en la forma de pensar y de trabajar  de todos los equipos  (desarrollo, calidad, seguridad, operaciones, etc.) que forman parte del ciclo de despliegue de cualquier aplicación.

4 comentarios

  • Lluís Aunós

    julio 21, 2016 en 9:34 am

    Buen artículo, muy bien explicado.
    ¿teneis alguna recomendación de recurso de Internet para poder profundizar sobre el tema?

    Contestar

  • Josep Mª Gris

    julio 21, 2016 en 10:09 am

    Gracias Lluis, celebro que te guste. Lo cierto es que David domina el tema como pocos he visto.

    David te facilitará recursos sobre ello.

    Gracias por tu comentario.

    Contestar

  • David Mataró

    julio 21, 2016 en 10:59 am

    Hola Luís, gracias por tus comentarios. De hecho, estamos preparando nuevos artículos con recursos sobre DevOps y automatización de sistemas para profundizar en el tema.

    Contestar

  • Lluís Aunós

    julio 26, 2016 en 9:51 am

    ok, gracias, estaré atento.

    Contestar

Dejar comentario

Tu dirección de correo no será publicada Los campos requeridos están marcados con *

catorce + 9 =