Qué es DevOps y por qué debemos prestarle atención

¿Qué es DevOps?

Aunque a menudo las organizaciones ven el concepto Devops como un rol dentro de una organización o como un conjunto de tecnologías o herramientas, la realidad es que DevOps agrupa una serie de principios, valores, metodologías, herramientas y prácticas. El objetivo principal de DevOps es permitir a las organizaciones reaccionar a los cambios de forma más rápida, eficiente y confiable posible. Está por tanto muy relacionado con metodologías Agile [1] y con la automatización de tareas de desarrollo (Dev/Development) y de sistemas (Ops/Operations) de donde surge su nombre. Aunque se hace mucho hincapié en los beneficios para adaptarse a nuevos requisitos, cambios desde negocio, o adaptación del desarrollo según los resultados y feedback obtenido, la mayor parte de sus beneficios se obtienen también en proyectos con planificaciones en cascada tradicionales.

En un entorno de alta competitividad como lo es el del desarrollo software se hace cada vez más importante utilizar técnicas que mejoren la agilidad, adaptabilidad conservando la estabilidad y fiabilidad. Aunque está extendida la creencia de que usar integración continua es lo mismo que implantar DevOps, es necesario advertir que esto es solo un ingrediente más para acelerar la liberación de nuevas versiones. DevOps es mucho más que eso.

Aunque sigue existiendo confusión en torno al concepto de DevOps muchas de sus características se van extendiendo gracias a los claros beneficios que proporcionan muchas de sus prácticas. De la mano de la tendencia hacia desarrollo de software basándose en metodologías ágiles, DevOps trata de evitar cualquier esfuerzo o gasto innecesario a la hora de entregar código de calidad a sus clientes.

¿A nivel de negocio, por qué prestar atención a este concepto?

La adopción de la filosofía DevOps por parte de las empresas es una tendencia consolidada [2]. Es una respuesta a las necesidades cambiantes y a las oportunidades en esta etapa de despliegue tecnológico. Permite aplicar la innovación a los desarrollos siguiendo el ritmo marcado por el negocio. Si lo que hay fuera de la organización cambia más rápido que lo de dentro el final de la misma está cerca.

El crecimiento exponencial de la tecnología introduce un importante factor de presión en las compañías debido a la continua introducción de innovaciones. Para lidiar con este entorno de negocio que cambia constantemente, las compañías necesitan adaptarse de forma continua. La innovación debe convertirse cada vez más en el proceso principal de una compañía que quiere imponerse en su mercado. Esto obliga a facilitar una cultura interna de innovación que confronte los sentimientos de desconfianza o resistencia.

Las tecnologías de la información e internet democratizan el mercado, por lo que más que nunca cada cliente debe estar satisfecho. De lo contrario elegirá de forma sencilla otro proveedor y con el enfoque social de internet puede que aparte a otros potenciales clientes. Esto también contribuye a una permanente adaptación a todos los clientes.

Sin embargo DevOps no va a funcionar si personal no especializado hace pruebas aisladas que no conducen a un enfoque práctico para la organización. Tampoco lo hará si no existe una gran perseverancia, ya que se requiere disciplina y atención en los detalles para lograr una transformación exitosa. En este sentido puede ser extremadamente útil la implantación de DevOps de la mano de Gradiant ya que conoce profundamente la cultura DevOps, para que predique las ventajas, forme al personal clave y suavice la transición con el uso de herramientas adecuadas.

¿Cómo diseñar un roadmap hacia DevOps?

Aunque no todos los pasos que se introducen en las siguientes líneas son necesarios para el uso de DevOps, sí son imprescindibles para una adopción total. Por ejemplo se puede usar DevOps haciendo uso de los puntos 2-6 pero usando planificaciones en cascada, pero de ese modo no se van a aprovechar totalmente las ventajas de DevOps. Introducimos a continuación la ruta desde el enfoque de Gradiant que debe seguir una organización hacia la filosofía DevOps:

1. Uso de metodologías ágiles: Lo que persiguen las metodologías ágiles de desarrollo es satisfacer al cliente a través de la entrega temprana y continúa de software. Esto permite que lleguen requisitos cambiantes sin mucho problema en el largo plazo, es decir el paso del método tradicional de planificación Las personas del negocio y el equipo de desarrollo deben trabajar juntos de forma cotidiana con comunicación frecuente y si es posible mejor cara a cara. Actualmente los métodos agile más habituales son Extreme Programing (XP) [3], Scrum [4] y Kanban [5].

Scrum es el framework más comúnmente utilizado. Trata de entregar productos con el mayor valor posible al cliente y de gestionar problemas y situaciones complejas. Usa enfoques iterativos e incrementales para desarrollar utilizando equipos cross-funcionales. Basado en el empirismo, se enfoca en el conocimiento, experiencia y toma de decisiones basadas en lo que se sabe.
XP surgió para ayudar a pequeños equipos a desarrollar software cuando los requisitos no están muy definidos y cambian frecuentemente. Se considera una metodología ligera y se enfoca en ahorros de costes, test unitarios, integración de todo el sistema de forma frecuente, pair programming, diseño simple y entregas frecuentes de software que funciona.
Kanban surgió como una herramienta LEAN [6] para gestionar operaciones de fabricación. Se aplica también a desarrollo software y ha sido considerada una metodología orientada a la adaptabilidad, visual y ahorro de costes tratando de eliminar el malgasto de procesos de producción. Las reglas principales son visualiza el flujo de trabajo, limita el trabajo en progreso y mide el tiempo para finalizar las tareas.

Otras metodologías menos comunes son Dynamic Systems Development Method (DSDM) [7], Adaptive Software Development (ASD) [8], Crystal [9], Feature-Driven Development (FDD) [10] y Rational Unified Process (RUP) [11].

2. Uso de técnicas y metodologías de test: Las pruebas han adquirido gran protagonismo en el desarrollo de software. Dentro de las prácticas [12] que ayudan a una organización a probar con éxito y mejorar la eficiencia del desarrollo, existen técnicas para realizar pruebas (pruebas de caja blanca y de caja negra), o diferentes actividades y objetivos en la forma de aplicar las pruebas (unitarias, integración, aceptación o sistema), así como metodologías de desarrollo de software centrados en la realización de las pruebas (BDD-Behauvior Driven Development, TDD-Test Driven Development, ATDD-Acceptance Test Driven Development, STDD-Story Test Driven Development) o, incluso para dar soporte a nuevas metodologías relacionadas con los proyectos que tienen como objetivo realizar pruebas como TMAP [13].

3. Uso de microservicios en el diseño del desarrollo: Este tipo de arquitecturas surgen para dar solución a los problemas inherentes a los sistemas monolíticos. Estas son algunas de las ventajas que aportan:

Servicios pequeños e independientes, lo que mejora la asignación de responsabilidades en los equipos de desarrollo.
Unidades de despliegue pequeñas, esto facilita la encapsulación en contenedores Docker [14] aprovechando todas las ventajas ya sabidas de esa tecnología:
Portabilidad: Empaqueta tu aplicación de una manera estandarizada, permite introducir las dependencias y que se ejecute del mismo modo en cualquier infraestructura.
Ligereza: Los contenedores comparten sistema operativo por lo que se ahorran los recursos necesarios en las máquinas virtuales donde cada una ejecuta un sistema operativo completo. Sólo se consumen los recursos realmente necesarios.
Abierto: Docker está basado en estándares y permite la ejecución de contenedores en Linux, MacOS y Windows sobre cualquier infraestructura privada o en el cloud público.
Aislamiento: Los contenedores aíslan aplicaciones añadiendo una capa de protección entre ellas.
Simplifica el mantenimiento y la operación: Docker reduce el esfuerzo y riesgo de la gestión de las dependencias de la aplicación, mejora la gestión de las actualizaciones y proporciona funcionalidades como self-healing, balanceo de carga, alta disponibilidad, rollback, descubrimiento de servicios, etc.
Reducción de tiempo tanto de desarrollo como de despliegue, test y operación.
Agilidad en hot fixes (consecuencia de las anteriores).
Multitecnología, es decir, permite combinar diferentes lenguajes y tecnologías para poder implementar el desarrollo de la forma más conveniente.
Fácil escalado

4. Uso de automatización en la infraestructura, los despliegues y gestión de la configuración. Sobre esta automatización de procesos hablaremos en el siguiente apartado en el que mencionaremos ejemplos de las herramientas necesarias.

5. Uso de métodos de integración/despliegue/entrega continua: La integración continua es una práctica que establece el orden de ejecución de los componentes de un proyecto incluyendo casos de prueba. De este modo se facilita la construcción correcta del software cuando se ejecuta el proceso de integración, logrando que el mismo sea transparente para el equipo de desarrollo. Permite además al equipo de desarrollo visualizar el estado de los builds durante en el proceso de integración permitiendo la detección de posibles incidencias, y así evitando una propagación de estos errores en un futuro. A posteriori de la integración continua, la entrega continua incluye los procesos de almacenamiento de los artefactos y binarios resultado de la construcción y la validación del código pusheado al repositorio. Despliegue continuo a mayores de la integración continua y entrega continua, proporciona una fase posterior con la automatización necesaria para el despliegue de los resultados de las fases anteriores en el entorno deseado, producción, staging, etc. A la hora de elegir las herramientas adecuadas, sobre todo en organizaciones grandes o con múltiples proyectos y clientes, resulta importante gestionar de forma adecuada los permisos de los usuarios. No en vano la mayoría de herramientas no permite que un desarrollador o cliente pueda acceder al repositorio de código con sus permisos sino con los de un desarrollador del proyecto (que puede tener permisos en otros repositorios) o los de un usuario genérico para todos los repositorios. Esto genera claros problemas de seguridad.

6. Uso de buenas prácticas: Estas buenas prácticas incluyen actividades orientadas a implementar de forma correcta DevOps y refinar los problemas que puedan surgir en la adaptación a la organización. Algunas de las buenas prácticas son:

Planificar, hacer seguimiento y un buen versionado del desarrollo. Esto es importante para realizar un correcto desarrollo y una mejora continua del proceso DevOps.
Dejar constancia de toda incidencia: Cada incidencia debe quedar reflejada en alguna herramienta para su tratamiento posterior.
Garantizar repetibilidad: Se debe automatizar en la medida de lo posible cada operación, proporcionando mecanismos automáticos también para la restauración (rollback) al estado anterior de un cambio.
Probar todo: Cada cambio debe ser probado, a ser posible de un modo automático. Para automatizar están los sistemas de integración/despliegue/entrega continua que ya se han mencionado.
Monitorizar y auditar lo que sea necesario: El uso de herramientas que permitan monitorizar el comportamiento de las aplicaciones, así como de eventos en los logs es muy importante para que el equipo de desarrollo pueda arreglar problemas. Además debe haber siempre un responsable de cada cambio en el sistema, se deben evitar las cuentas genéricas, cada usuario debe realizar operaciones de una forma identificable. Cada acceso para cambios u operaciones debe quedar almacenado para determinación de responsabilidades y que los usuarios sean conscientes de ello.

¿Qué herramientas usar para transicionar a DevOps?

El uso de herramientas facilitadoras para tanto la parte Dev como para la parte Ops se hace imprescindible en el contexto de agilidad a través de la automatización. Sin embargo hay muchas alternativas y combinaciones de herramientas que deben adaptarse a la organización para poder hacer una transición hacia DevOps de la mejor manera. Para describir una pequeña agrupación de estas herramientas que se pueden utilizar para facilitar el trabajo de los equipos DevOps, se definirán 7 categorías que disponen de herramientas más o menos necesarias, pero muchas de ellas básicas para el deployment, como por ejemplo Docker o Jira. Entre paréntesis se incluyen muchas de las herramientas que Gradiant utiliza para implantar DevOps a sus clientes o dentro de su propia estrategia DevOps.

Codificar: En esta categoría están aquellas herramientas encaminadas a mejorar el rendimiento del desarrollo. También podríamos dividir en subcategorías de herramientas como IDEs para desarrollo (Eclipse, IntelliJ IDEA), los sistemas de gestión de repositorios para control de versiones (git, Gitlab, Bitbucket, FishEye), herramientas de análisis de calidad de código (Sonarqube), herramientas de revisión de código (Crucible, gerrit), seguimiento de issues y bugs (Jira, Redmine, Project, Mantis), herramientas para programación por pares (ScreenHero) o las herramientas para hacer merges (KDiff3, DiffMerge, P4Merge).
Build: En esta categoría estarían encuadradas aquellas herramientas cuya finalidad es la de preparar el código para su ejecución y prueba. El rol de estas herramientas es validar que un desarrollo se ha validado y puede pasarse a un entorno de staging o de producción. Si se utilizan de forma correcta permiten eliminan gran parte del tiempo de pruebas que tienen que emplear los desarrolladores y además asegura la detección de problemas inesperados introducidos en partes del desarrollo que antes del cambio funcionaban bien. Herramientas de integración continua (Jenkins, Bamboo, Go.CD) y automatización de los builds (Maven, Make, Gradle, Ant)
Test: El objetivo de las herramientas de test es reducir los casos de prueba manual al mismo tiempo que se incrementa la cobertura, y por tanto ahorrando tiempo de creación de la automatización y esfuerzo y tiempo de ejecución de los tests. Herramientas de test continuo web (Selenium), herramientas de test continuo móvil (Appium), herramientas de test iterativo (Lux, Expect), herramientas para test de criterios de aceptación (FitNesse, FIT, EasyAccept), o test unitarios (XUnit, JUnit, Unit.js, ATF).
Empaquetado: En esta categoría se agrupan las herramientas encaminadas a evitar tener que depender de proveedores y repositorios externos en los procesos de build y para poder mantener controladas las librerías propias de la empresa así como para poder compartir con clientes externos los resultados desarrollados. Repositorio de artefactos (Nexus 3, Artifactory), Contenedores (Docker), gestión documental (Confluence, Owncloud).
Gestión de la configuración: Esta categoría agrupa aquellas herramientas diseñadas con el propósito de usar scripts, recetas, blueprints, playbooks, charms, plantillas, etc. para la simplificación de la automatización y orquestación en los entornos de ejecución de la organización. El objetivo es proporcionar un modo estándar y consistente de realización de los despliegues y sus configuraciones. En esta categoría están las herramientas de gestión de configuración y gestión de versiones (Puppet, Salt, Chef, Ansible, Vagrant, Juju)
Despliegue: Dentro de esta categoría se incluyen las herramientas y servicios que permiten la ejecución sobre infraestructura (on premise, datacenter o cloud público) tanto de las herramientas necesarias para DevOps como de los desarrollos realizados. En esta categoría están las herramientas de orquestación de infraestructura privada (Gradiant ITBox, MaaS, Openstack, Kubernetes), herramientas de orquestación de servicios (Docker Compose, Docker Swarm), herramientas de orquestación multicloud (Gradiant ITBox, Cloudify, Apache Brooklyn), virtualización (Docker, KVM), cloud públicos (Amazon AWS, Azure, Google CE).
Monitorización: Uno de los muros que DevOps trata de romper es la falta de feedback sobre las aplicaciones puestas en producción una vez se ha realizado el despliegue por parte del departamento de operaciones. La monitorización debe ser algo transversal y debe llegar sin filtros al departamento de desarrollo que podrán detectar e interpretar los resultados del día a día de sus desarrollos. En esta categoría están las herramientas de rendimiento de aplicaciones (Zabbix, Nagios, Influxdb, Telegraf, Grafana), revisión de logs (GrayLog, Logstash, Kibana, Elasticsearch), experiencia de usuario y analíticas web (Piwik, Google Web Analytics).

Referencias:

[1] Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28-35.

[2] Mastering Digital Disruption with DevOps Design to Disrupt Report 4 of 4 https://www.capgemini.com/resource-file-access/resource/pdf/design_to_disrupt_4.pdf

[3] Beck, K. (2000). Extreme programming explained: embrace change. addison-wesley professional.

[4] Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum(Vol. 1). Upper Saddle River: Prentice Hall.

[5] Sugimori, Y., Kusunoki, K., Cho, F., & Uchikawa, S. (1977). Toyota production system and kanban system materialization of just-in-time and respect-for-human system. The International Journal of Production Research, 15(6), 553-564.

[6] Naylor, J. B., Naim, M. M., & Berry, D. (1999). Leagility: integrating the lean and agile manufacturing paradigms in the total supply chain. International Journal of production economics, 62(1), 107-118.

[7] Stapleton, J. (1997). DSDM, dynamic systems development method: the method in practice. Cambridge University Press.

[8] Highsmith, J. (2000). Adaptive software development. Dorset House.

[9] Cockburn, A. (2004). Crystal clear: a human-powered methodology for small teams. Pearson Education.

[10] Palmer, S. R., & Felsing, M. (2001). A practical guide to feature-driven development. Pearson Education.

[11] Kruchten, P. (2004). The rational unified process: an introduction. Addison-Wesley Professional.

[12] Yagüe, Agustin; Garbajosa, Juan; (2009). Comparativa práctica de las pruebas en entornos tradicionales y ágiles. REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software, Diciembre-Enero, 19-32.

[13] Koomen, T., van der Aalst, L., Broekman, B., Vroon, M.: TMap Next, for result driven testing. UTN Publishers, 2006

[14] Merkel, D. (2014). Docker: lightweight linux containers for consistent development and deployment. Linux Journal, 2014(239), 2.

Autor: José Otero-Pena, responsable técnico de Cloud Computing, Área de Servicios y Aplicaciones de Gradiant