Transformación Empresarial hacia un estado DevOps€¦ · nuevos procesos e implementar herramientas que habilitan un estado DevOps. Centrando las mejoras en procesos y tecnologías

Universidad Técnica Federico Santa María

Departamento de Informática

Magíster en Tecnologías de la Información –

1

Transformación Empresarial hacia un estado DevOps

Rodrigo Arnaldo Fuentes Roberts

[email protected] +56 9 7210 6400

Resumen: El propósito del presente consiste en documentar el proceso de transformación de Equifax Chile, hacia la instauración de un estado DevOps en la organización. A partir de la identificación de puntos de mejora que atienden a problemas presentes, permite definir nuevos procesos e implementar herramientas que tienen como objetivos; disminuir las horas destinadas a procesos de liberación, junto con el número de errores que se presentan es estos eventos, al igual que, definir un marco nuevo arquitectónico, con los respectivos procesos para despliegue y construcción de productos. Se cubren los aspectos técnicos necesarios tales como decisiones tecnológicas, metodologías y herramientas seleccionadas en este nuevo toolchain. Por último, se muestra que la entrega iterativa, combinada con un proceso automatizado para construir, desplegar pruebas y liberar software incorporado en un canal de despliegue, no solo es compatible con los objetivos de conformidad y rendimiento, sino que es que la forma más efectiva de alcanzar estos objetivos. Palabras Clave: Mejora Continua, evaluación e implementación

1 Introducción

Equifax es una marca registrada de Equifax Inc., Atlanta Georgia, presentes en 24 países de América del Norte, América Latina, Asia y Europa. Opera en Chile desde 1979 entregando servicios a más de 14 mil empresas de distintos sectores, principalmente financiero, comercial, retail y entre otros; que sumada a la experiencia global de Equifax agiliza las transacciones y otorga respaldo a la decisión, a los servicios de marketing e informes comerciales de personas naturales y jurídicas. Minimizando riesgos financieros y maximizando las oportunidades de crecimiento, mientras que promociona a las personas una mejor protección y gestión de su salud financiera [1]. Hoy existen muchas metodologías destinadas al desarrollo de software donde su enfoque principal es dirigido al manejo de requerimientos y medición de esfuerzos e impactos dentro del ciclo de desarrollo. Para la mayoría de los proyectos de software, es habitual que el día destinado a paso a entorno productivo suele ser bastante tenso. Esto se debe al grado de riesgo asociado con el proceso que genera esta liberación. Las liberaciones son procesos manuales intensos. Los entornos que hospedan estas soluciones de software son manipulados individualmente, por un equipo de operaciones. Estos equipos instalan productos de terceros, que son dependencia del artefacto a instalar, las configuraciones requeridas son copiadas o creadas por medio de consolas administrativas en los servidores web. Componentes e información adicional es ubicada según especificación, para luego iniciar este servicio o aplicación distribuida. Las razones para un nerviosismo generalizado son claras: Varias cosas pueden salir mal en este proceso. Si cualquiera de los pasos no es ejecutado a la perfección, el producto desplegado no funcionara correctamente. Si se llega a este punto no es simple determinar dónde está el error, o que parte del proceso presentó algún problema. A continuación, se presentan las prácticas y procesos que identifican a un anti patrón:



Magíster en Tecnologías de la Información

2

Desplegar software de forma manual: • Se genera documentación demasiado extensa y detallada describiendo los pasos a ejecutar y de qué

forma éstos pueden salir mal. • Se realizan pruebas manuales para confirmar que una aplicación quedó instalada correctamente. • Llamados permanentes al equipo de desarrollo para explicar porque la instalación está fallando el día de

instalación. • Correcciones frecuentes a la liberación durante el proceso de instalación. • Entornos que difieren en su configuración. • Liberaciones que toman más de unos minutos en ejecutarse. Desplegar en un entorno pre productivo: • El equipo de desarrollo ensambla una liberación no probada para un ambiente muy similar a producción. • Existe poca o casi nula colaboración entre el equipo de desarrollo y operaciones. Administración y configuración manual de ambientes productivos: • Haber instalado de forma exitosa y reiterada en ambientes pre-productivos, el paso productivo final

presenta problemas. • El equipo de operaciones toma demasiado tiempo en preparar un ambiente para liberación. • Los nodos dentro de un cluster responden de forma distinta. • Configuraciones de los sistemas es realizado dentro de los servidores productivos. • Un cluster de servidores existen distintas versiones de sistema operativo, librerías, parches, software de

terceros, entre otros.

1.1 Motivación

Durante los últimos años se han realizado importantes inversiones en renovaciones tecnológicas, infraestructura y personal. Dando como resultando 3 centros de desarrollo de software conocidos como CSE (Core Software Engineering) ubicados en Atlanta, Chile y el más reciente en Dublín, que tienen como objetivo generar productos transversales a la organización que luego deben ser implementados por cada departamento IT. De forma adicional se espera que cada área IT sea capaz de alinear los productos locales según los alineamientos Arquitectónicos definidos por la casa matriz, dentro de los cuales vale mencionar: • Instaurar una cultura Agile dentro del SDLC (Software Development Life Cycle) • Actualizar, unificar y reducir el stack tecnológico actual • Migrar la organización hacia un estado DevOps

Figura 1. Ciclo SDLC (Software Development Life Cycle)

La estrategia detrás de estos cambios es acelerar el Time-To-Revenue, donde la rapidez y agilidad del goto-market son requisito previo para ganar una ventaja competitiva importante en el mercado.




3

1.2 Propuesta de Solución y Objetivos

El objetivo del documento es describir la arquitectura, estrategia y metodologías definidas para implementar y/o mejorar las prácticas de desarrollo y operaciones utilizadas transversalmente. Se identifican las áreas adecuadas para la automatización y se describen posibles soluciones para cada área.

Centrándose en el proceso de construcción, despliegue, pruebas y procesos de liberación. Con el objetivo de reducir los riesgos, estrés dentro del equipo y el cómo garantizar liberaciones más confiables. Algunos tipos de procesos que buscamos evitar, conocidos también como anti patrones son tan comunes que llegan a ser aceptados como casi norma de la industria.

La propuesta de solución considera las siguientes etapas: • Entender la situación actual o Análisis y resultados de evaluación

• Definición de nueva arquitectura de negocio • Integración con una plataforma de “Integración Continua” (CI) • Integración con Gestión de Infraestructuras / Configuración • Integración con solución de monitoreo

1.2.1 Objetivos Específicos

Se establece una estrategia para abordar; cambio cultural, definición de procesos y herramientas tecnológicas. Como parte de los objetivos específicos es posible mencionar: • Selección de metodología que asiste el proceso de cambio • Definición de nuevos procesos para despliegue y construcción de productos • Controlar y disminuir las horas destinadas a procesos de liberación • Definición de marco arquitectónico para la construcción de productos

1.3 Hipótesis del Trabajo

A partir de la identificación de objetivos de mejora, que atienden a problemáticas existentes, es posible definir nuevos procesos e implementar herramientas que habilitan un estado DevOps. Centrando las mejoras en procesos y tecnologías de la organización.

Se busca mejorar la calidad de los despliegues de software, reduciendo así el número de incidentes / problemas por producto por lanzamiento. Incrementar la frecuencia de liberación de un producto a producción e incrementar la cobertura de procesos automatizados en la organización.

1.4 Validación de la Hipótesis

Esta hipótesis debe demostrarse ejecutándola frente a múltiples proyectos piloto, mostrando mejoras en los proyectos y en la cultura de la colaboración a medida que se itera con cada proyecto. Una vez que la hipótesis sea demostrada y probada como algo que puede repetirse con resultados similares, se puede armar un caso de negocio para obtener el patrocinio a nivel corporativo.

Al medir y cuantificar el comportamiento de la gente puede ser complejo, en lo que respecta a DevOps. Esto no significa que los beneficios de DevOps no se pueden medir, para ello se van a realizar una serie de encuestas a los miembros del equipo sobre la implementación de la nueva arquitectura y procesos.




4

1.5 Breve descripción de la organización del informe en secciones

El presente documento contiene la sección 2 donde se describe el estado del arte y marco teórico que hace mención de los conceptos y metodologías abordados.

Adicionalmente, en la sección 3 se describe la aplicación del trabajo indicando los objetivos de mejora que se pretenden conseguir, las etapas de proyecto y los resultados de la aplicación de estos.

En la sección 4 se realiza una conclusión sobre el trabajo realizado. Seguido de referencias y finaliza con un apartado de anexos.

2 Marco Teórico y Estado del Arte

Este trabajo de tesina pretende incorporar la cultura de DevOps en el área IT de una compañía que maneja información comercial, tanto de personas naturales como personas jurídicas. Con el objetivo de mejorar la colaboración entre las personas responsables de entregar soluciones y servicios de software. Según la definición de Jez Humble y David Farley, creadores del “Continuous Delivery”, “es la habilidad de poder llevar a producción cualquier tipo de cambio de manera rápida, segura y sostenible” [3].

Con el fin de ampliar los conceptos abordados en este trabajo, a continuación, una pequeña descripción de cada una:

• DevOps: es un acrónimo inglés de development (desarrollo) y operations (operaciones), que se refiere a una

cultura o movimiento que se centra en la comunicación, colaboración e integración entre desarrolladores de software y los profesionales de operaciones 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 rápidamente [4].

• Continuous Delivery: técnicas para poder crear un flujo continuo de versiones software listas para pasar al

entorno de producción de manera segura, sin defectos ni sustos. Las herramientas, tecnologías y organización necesaria para lograr el ideal de poder desplegar software de forma segura en producción inmediatamente después de haberlo programado. La entrega continua, el “continuous delivery”, es la evolución natural de la “integración continua” [3].

• Integración Continua: popularizada por Fowler, se basa en integrar el software (compilarlo y probarlo)

automáticamente lo más frecuentemente posible, y así poder detectar fallos cuanto antes. El proceso se basa en obtener las fuentes desde el gestor de versiones (Subversion, Git, Plastic u otros) compilarlo y lanzar las pruebas. Todo este proceso suele automatizarse con herramientas como Jenkins, que, a su vez, se basan en que la secuencia de compilación, despliegue, etc., esté “escrita” y se lance con Maven (u otros, Ant, Msbuild, Mkfile) [5].

• Despliegue Continuo: puede ser pensado como una extensión de la integración continua, con el objetivo de

reducir al mínimo el tiempo transcurrido de desarrollo en la escritura una nueva línea de código y que este nuevo código este siendo utilizado por usuarios en vivo. Para lograr un despliegue continuo, el equipo cuenta con la infraestructura que automatiza los diversos pasos que conducen a la implementación [6].

• Lean Software Development: Robert “Bob” Charette en 1993, planteó el concepto de “Lean Software

Development” como parte de su trabajo para investigar mejores formas para administrar los riesgos en proyectos de software. Womack y Jones definieron cinco pilares básicos del patrón de pensamiento Lean: valor; flujo de valor; extracción; perfección. El quinto de ellos resonó más, que se basa en identificar las actividades que generan desperdicios y su eliminación. Reinertsen en 2005, introduce el uso de los sistemas




5

kanban que restringen el trabajo en curso y “extraen” nuevo trabajo sólo cuando el sistema está listo para procesarlo. En definitiva, Lean corresponde a un conjunto de principios, no es un proceso que pueda ser implementado directamente [7].

• Metodología de aplicaciones de 12 factores: Define una metodología para desarrollar y desplegar

aplicaciones web, específicamente aplicaciones de software como servicio. Las aplicaciones web modernas son bastante complejas, por lo que se debe proporcionar todos los pasos del proceso: desde la virtualización, la implementación, la configuración de los entornos de tiempo de ejecución y de desarrollador hasta la administración de bases de datos y redes. Todo ello manteniendo el rendimiento al máximo [8].

Figura 2. Diagrama de Venn para DevOps

Parafraseando, DevOps es una estrategia y un lenguaje común que reduce la brecha existente entre desarrollo y operaciones. La estrategia se encuentra a nivel organizacional, mientras que el lenguaje son las herramientas que permiten definir los roles de una aplicación, la automatización de los sistemas y que roles juegan las personas involucradas en desarrollo y operaciones para que esta estrategia tenga éxito.

Lo que la metodología de aplicaciones de 12 factores (The Twelve-Factor App), Continuous Delivery, Integración Continua, Lean Software Development y otras recetas modernas de TI están tratando de habilitar ha sido acuñado como "DevOps". La metodología de aplicaciones de 12 factores aborda los siguientes desafíos: • ¿Cómo puedo llegar a fallar más rápido? • ¿Cómo puede obtener todo lo que necesita para que, con sólo pulsar un botón, usted y su equipo puede hacer

su trabajo? • ¿Cómo se toma ese código y luego a través del proceso lo hace disponible para la producción? • ¿Y entonces cómo puedes automatizar ese proceso con la integración continua, el despliegue continuo, e

incluso la entrega continua? • ¿Cómo lograr que la gente cambie de metodología? ¿Cuáles son los procesos que necesitan definir para

hacer el trabajo?

Como con todas las transformaciones culturales, responder a estos desafíos podría reducirse a tres partes: las personas, los procesos y la tecnología.

Aunque "Continuous Delivery" es otro término que se utiliza junto con DevOps, existen algunas diferencias. El siguiente diagrama muestra las relaciones.




6

Figura 3. DevOps vs Continuous Delivery

Algunas de las fases pueden no encajar en todo tipo de servicios o productos. Ej.: La fase de "Operación" no es relevante en el caso de un producto que se entrega a un cliente externo. El funcionamiento de ese producto cae dentro del ciclo de vida de operación del cliente.

3 Desarrollo del Proyecto

3.1 Prácticas DevOps

DevOps es más que un conjunto de prácticas y la variedad presente en la industria es amplia. La siguiente sección se listarán las prácticas más comúnmente utilizadas en una organización TI:

1. Empieza pequeño

Tratar de hacer demasiado a la vez es una receta para el desastre. Es mejor comenzar pequeños proyectos y ganar confianza del equipo. Iniciar con proyecto que tiene una probabilidad de éxito alto. Esto podría ser un proyecto piloto o prototipo o prueba de concepto.

2. Concéntrese en el proceso y no en las herramientas. Es mejor ser independiente de la herramienta y un buen proceso debe tener la capacidad de reemplazar una herramienta con otra sin demasiada interrupción.

3. Poner todo bajo control de versiones. Para implementar de forma fiable una aplicación en la producción, todos los elementos de construcción de la aplicación: código, casos de prueba, documentos de diseño, bibliotecas externas, bases de datos y cualquier cosa que pueda ser actualizada, tiene que ser puesto bajo control de versiones.

4. Mantener un entorno de pre-productivo equivalente a la producción Normalmente, un entorno de desarrollo es diferente de la producción. Así, para evitar problemas que se encuentran sólo después de entrar en producción, como el rendimiento, el acceso relacionado y tal, se aconseja tener un ambiente de puesta en escena donde todos esos problemas se pueden encontrar antes producción.

5. Despliegue frecuente a la producción Para hacer cualquier nueva característica, correcciones de errores, parches de seguridad para el cliente lo antes posible, se sugiere desplegar código con frecuencia. Podría ser una vez para cada ciclo de sprint en un desarrollo ágil, configuración, o una vez cada cierto tiempo según lo determine conveniente el equipo DevOps




7

6. Automatizar los entornos de construcción de las aplicaciones

Para una aplicación simple, esto no es una gran preocupación. Pero para las aplicaciones más complejas, configurar el entorno de ejecución, como configurar el equilibrador de carga, las bases de datos, el servidor web, la red y todas las cosas orientadas a la operación, es mejor tener una forma automática de construir el entorno para reducir el tiempo de configuración y también reducir los errores humanos. Infraestructura como un servicio (IAAS) se utiliza para este propósito.

7. Automatizar la instalación de las aplicaciones

Además de la automatización de creación de entorno anterior, también es muy beneficioso tener Automatización para instalar la aplicación en el entorno. Esto incluye la inicialización de la Bases de datos, configuración inicial de la aplicación, instalación de dependencias y otros. La construcción automatizada y el despliegue se pueden lograr a través de metodología de 'Infraestructura como un código'.

3.1.1 Herramientas DevOps

Dado que DevOps es más un proceso, no existe una sola herramienta que ayude en la implementación de la práctica DevOps en una organización. Es más, un 'toolchain', una suite de herramientas que ayuda en la implementación de una práctica de DevOps. La implementación de DevOps no significa tirar herramientas existentes a favor de otras nuevas. Implica integrar las herramientas existentes y migrar las herramientas no conformes para que se ajusten a la práctica / proceso elegido. Los pasos del proceso que debe considerar para el soporte de herramientas son: • Solicitar, capturar y procesar un cambio • Control de versiones del código fuente • Planificación Ágil • Gestión de casos de prueba • Construcción Automatizada • Despliegue continuo • Gestión de liberaciones

3.2 The Twelve-Factor App Methodology

En la era moderna, el software se entrega comúnmente como un servicio: llamadas aplicaciones web o software como servicio. La aplicación de doce factores es una metodología para crear aplicaciones de software como servicio que: • Utiliza formatos declarativos para la automatización de la instalación, con tal de minimizar el tiempo y el

costo para los nuevos desarrolladores que se unan al proyecto. • Tener un contrato limpio con el sistema operativo subyacente, ofreciendo máxima portabilidad entre

entornos de ejecución. • Son adecuados para el despliegue en plataformas modernas de nube, evitando la necesidad de administración

de servidores y sistemas. • Minimizar la divergencia entre desarrollo y producción, permitiendo un despliegue continuo para una

agilidad máxima. • Puede escalar sin cambios significativos en herramientas, arquitectura o prácticas de desarrollo.

La metodología de aplicaciones de doce factores, propone un protocolo que considera 12 pasos, estos son descritos a continuación: 1. Código base (Codebase): Un código base sobre el que hacer el control de versiones y múltiples despliegues. 2. Dependencias: Declarar y aislar explícitamente las dependencias 3. Configuración: Guardar la configuración en el entorno respectivo 4. Backing services: Tratar a los “backing services” como recursos conectables, entiéndase también como

cualquier recurso que la aplicación puede consumir a través de la red como parte de su funcionamiento.




8

5. Construir, distribuir, ejecutar: Separar completamente la etapa de construcción de la etapa de ejecución. 6. Procesos: Ejecutar la aplicación como uno o más procesos sin estado 7. Asignación de puertos: Publicar servicios mediante asignación de puertos 8. Concurrencia: Escalar mediante el modelo de procesos 9. Desechabilidad: Hacer el sistema más robusto intentando conseguir inicios rápidos y finalizaciones seguras 10. Igualdad entre desarrollo y producción: Mantener desarrollo, preproducción y producción tan parecidos

como sea posible 11. Historiales: Tratar los historiales como una transmisión de eventos 12. Administración de procesos: Ejecutar las tareas de gestión/administración como procesos que solo se

ejecutan una vez.

3.3 Implementación DevOps

La implementación de un buen proceso DevOps beneficiará a cualquier organización en gran medida. Esto incluye la planificación, desarrollo, integración y automatización. Hay algunas áreas del producto que pueden ser beneficiadas inmediatamente por la integración y automatización de tareas que reducirán el trabajo manual involucrado, aumentando la capacidad de respuesta del equipo de soporte y también optimizar los recursos utilizados.

Figura 4. Proceso DevOps y Herramientas a Implementar

3.4 Entender la situación actual

El primer paso del proyecto consiste en evaluar en qué etapa evolutiva hacia DevOps se encuentra la organización para ello se debe evaluar: • Estado de integración continua • Estado de continuous delivery • Estado de continuous deployment • Estado de DevOps

3.4.1 Estado de integración continua

Uno de los elementos que dio inicio de la búsqueda de herramientas para apoyar este desafío fue la decisión de cambiar la versión de Java 1.6 y el servidor de aplicaciones IBM WebSphere, a Java 1.8 y Apache Tomcat 8.




9

A esto se suma la renovación de servidores, cambio del sistema operativo base utilizado de AIX a CentOS 6, cambio de las herramientas de desarrollo y nuevo sistema de control de versiones GIT en reemplazo a SVN.

Esta migración, denominada como WAS2Tomcat, no debía afectar la calidad del servicio. Comprendía en total 100 aplicaciones construidas en diversos frameworks y utilizando un número importante de librerías, algunas de las cuales tienen más de 15 años de antigüedad.

El área IT actualmente posee cuatro ambientes utilizados por el SDLC (Ver Tabla 1). El objetivo es automatizar la instalación, pruebas e integraciones de las 100 aplicaciones a migrar. Vale mencionar que hoy la configuración e instalación de cada artefacto se realiza a mano, algunas de las cuales pueden tomar horas en realizarse en un único ambiente.

Tabla 1. Ambientes IT Equifax

Ambiente Descripción Desarrollo Entorno utilizado tanto por personal interno de la organización como bien proveedores para

desarrollar soluciones QA Ambiente destinado para prueba de calidad de productos UAT Ambiente utilizado para pruebas de aceptación de usuarios y pruebas de estrés Producción Entorno productivo replicado en dos datacenters con alta disponibilidad activo-pasivo

3.4.2 Estado de continuous delivery

Al momento de evaluar de este estado evolutivo se identificaron varios anti patrones, tales como: • Entornos que difieren en su configuración. • El equipo de desarrollo ensambla una liberación no probada para un ambiente muy similar a producción. • El equipo de operaciones toma demasiado tiempo en preparar un ambiente para liberación.

De forma adicional se realizó un análisis SQALE (Software Quality Assessment based on Lifecycle Expectations por sus siglas en ingles) con la ayuda de la herramienta SonarQube (ver Tabla 2) a modo de determinar las limitaciones presentes en la implementación del continuos delivery.

3.4.2.1 Análisis SQALE

SQALE, es un método para soportar la evaluación de un código fuente de una aplicación de software. Es genérico, e independiente de otras herramientas de análisis de código fuente, se encuentra licenciado bajo Creative Commons Attribution-NonCommercial-NoDerivs 3.0.

Ha sido desarrollado para responder a una necesidad general de evaluar la calidad del código fuente. Su objetivo es responder a preguntas fundamentales como: • ¿Cuál es la calidad del código fuente entregado por los desarrolladores? • ¿Es el código modificable, fácil de mantener, portátil y reutilizable? • ¿Cuál es la deuda de diseño almacenada por el proyecto?

Está particularmente dedicado a la gestión de la deuda de diseño (o deuda técnica) de Agile Software Development. Lo que permite: • Definir claramente lo que crea una deuda de diseño • Estimar correctamente la deuda de diseño • Describir esta deuda en varias partes relacionadas con la estabilidad, la fiabilidad, la variabilidad, la facilidad

de mantenimiento. Esta clasificación apoya el análisis sobre el impacto de la deuda y cómo definir las acciones prioritarias de refactorización de código.




10

En los requisitos relacionados con el código fuente (el modelo de calidad SQALE), permite incluir un umbral mínimo para alcanzar con las pruebas unitarias. En el caso de que no se alcance este umbral, el índice de fiabilidad de la aplicación se ve afectado.

3.4.2.2 Resultados de evaluación SQALE

Se evaluaron las aplicaciones afectadas por la migración del WAS2Tomcat, arrojando los siguientes resultados: • ~850.000 líneas de código efectivas analizadas (se excluyen librerías y componentes de terceros) • 41 problemas bloqueantes encontrados (según tolerancias definidas por seguridad y estándar del lenguaje

evaluado) • 462 conflictos a nivel de código fuente • 8,98% tasa de Deuda Técnica total

Figura 5. Comparación entre evaluaciones y numero de aplicaciones

Tabla 2. Notas entregadas por evaluación SQALE

Nota de evaluación SQALE Número total de aplicaciones A 77 B 20 C 1 D 1 E 1

La calidad de los productos entregados cumple con las tolerancias definidas y solo un 3% de los productos se encuentra fuera de norma. El código entregado es relativamente fácil de mantener y portable, pero presentan un bajo índice de reutilización y varias iteraciones de las mismas funciones. Esto se debe principalmente a la naturaleza de una arquitectura monolítica presente en el total de los productos.

3.4.2.3 Evaluación de Arquitectura Monolítica

Posterior a la evaluación SQALE resalta la presencia dominante de este estilo arquitectónico. El cual presenta una serie de beneficios al momento de desarrollar nuevas aplicaciones, tales como: • Simple de desarrollar - el objetivo de las herramientas de desarrollo actuales y IDEs es apoyar el desarrollo

de aplicaciones monolíticas




11

• Fácil de implementar - basta con desplegar el archivo WAR (o la jerarquía de directorios) en el tiempo de ejecución apropiado

• Fácil de escalar - puede escalar la aplicación ejecutando varias copias de la aplicación detrás de un balanceador de carga Sin embargo, si una aplicación crece en complejidad y tamaño este enfoque presenta una serie de

inconvenientes que se vuelven cada vez más significativos:

• La gran base de código monolítica intimida a los desarrolladores, especialmente los que son nuevos en el equipo. La aplicación puede ser difícil de entender y modificar. Como resultado, el desarrollo normalmente se ralentiza. Además, debido a que no hay límites de módulos duros, la modularidad se rompe con el tiempo. Además, debido a que puede ser difícil comprender cómo implementar correctamente un cambio, la calidad del código disminuye con el tiempo. Cayendo así en un espiral descendente.

• Contenedor web sobrecargado: cuanto mayor sea la aplicación, más tiempo tardará en arrancar. Esto tuvo

un enorme impacto en la productividad del desarrollador debido al tiempo perdido esperando que el contenedor se inicie.

• Daño colateral alto: si una aplicación que comparte el contenedor web con sus pares, presenta un error no

manejado a nivel de código que resulte fatal para el contenedor que lo esté alojando. Puede derivar en una baja de servicio completa. Comprometiendo tanto el rendimiento como continuidad de los servicios aledaños.

• El despliegue continuo es difícil: una gran aplicación monolítica también es un obstáculo para los

despliegues frecuentes. Para actualizar un componente es necesario volver a implementar toda la aplicación. Esto interrumpirá las tareas de fondo (por ejemplo, trabajos de Quartz en una aplicación Java), independientemente de si se ven afectadas por el cambio y posiblemente causen problemas. También existe la posibilidad de que los componentes que no se han actualizado no se inicie correctamente. Como resultado, aumenta el riesgo asociado con la redistribución, lo que desalienta las actualizaciones frecuentes. Esto es especialmente un problema para los desarrolladores de la interfaz de usuario, ya que por lo general necesitan iterar rápidamente y volver a implementar con frecuencia.

• Escalar la aplicación puede ser difícil: una arquitectura monolítica es que sólo puede escalar en una

dimensión. Por un lado, puede escalar con un volumen de transacciones cada vez mayor ejecutando más copias de la aplicación. Algunas nubes pueden incluso ajustar el número de instancias de forma dinámica en función de la carga. Pero, por otro lado, esta arquitectura no puede escalar con un volumen de datos creciente. Cada copia de la instancia de la aplicación tendrá acceso a todos los datos, lo que hace que el almacenamiento en caché sea menos efectivo y aumenta el consumo de memoria y el tráfico de E / S. Además, los diferentes componentes de la aplicación tienen diferentes requerimientos de recursos: uno puede ser intensivo de CPU, mientras que otro puede requerir mucha memoria. Con una arquitectura monolítica no podemos escalar cada componente independientemente.

• Obstáculo para el desarrollo de escala: Una aplicación monolítica es también un obstáculo para el desarrollo

de escala. Una vez que la aplicación llega a un cierto tamaño es útil dividir la organización de ingeniería en equipos que se centran en áreas funcionales específicas. Por ejemplo, podríamos querer tener el equipo de la interfaz de usuario, el equipo de contabilidad, el equipo de inventario, etc. El problema con una aplicación monolítica es que impide que los equipos trabajen independientemente. Los equipos deben coordinar sus esfuerzos de desarrollo y redistribuciones. Es mucho más difícil para un equipo hacer un cambio y actualizar la producción.

• Requiere un compromiso a largo plazo con un stack tecnológico: una arquitectura monolítica le obliga a

casarse con el stack tecnológico (y en algunos casos, con una versión particular de esa tecnología) que eligió




12

al inicio del desarrollo. Con una aplicación monolítica, puede ser difícil adoptar gradualmente una nueva tecnología. Por ejemplo, imaginemos que eligió la JVM. Usted tiene algunas opciones de idioma, así como Java, puede utilizar otros lenguajes JVM que interactúan bien con Java, como Groovy y Scala. Pero los componentes escritos en lenguajes no JVM no tienen un lugar dentro de su arquitectura monolítica. Además, si su aplicación utiliza un marco de plataforma que posteriormente se convierte en obsoleto, entonces puede ser un desafío migrar de forma incremental la aplicación a un marco nuevo y mejor. Es posible que con el fin de adoptar un nuevo marco de plataforma que tiene que volver a escribir toda la aplicación, que es un compromiso de alto riesgo.

3.5 Arquitectura propuesta para adopción de DevOps (Micro servicios)

La arquitectura de micro servicios es un patrón alternativo que aborda las limitaciones de la arquitectura monolítica y tiene como objetivo acelerar el desarrollo de software al permitir la entrega / implementación continua.

La arquitectura de micro servicios estructura una aplicación como un conjunto de servicios ligeramente acoplados que buscan acelerar los desarrollos mientras se maximiza la reutilización de diferentes componentes.

Figura 6. Como habilitar la entrega continua

La arquitectura del micro servicio logra esto de dos maneras: • Simplifica las pruebas y permite que los componentes se desplieguen independientemente • Estructura la organización de ingeniería como una colección de pequeños grupos de trabajos (6 a 10

personas), autónomos, cada uno de los cuales es responsable de uno o más servicios.

Esta solución tiene una serie de beneficios: • Cada micro servicio es relativamente pequeño

o Más fácil para un desarrollador entender o El IDE es más rápido haciendo que los desarrolladores sean más productivos o La aplicación se inicia más rápido, lo que hace que los desarrolladores sean más productivos y acelere

las implementaciones. • Cada servicio se puede desarrollar e implementar independientemente de otros servicios • Es más fácil implementar nuevas versiones de servicios con frecuencia • Más fácil de desarrollar a escala. Le permite organizar el esfuerzo de desarrollo en torno a varios equipos.

Cada equipo (dos pizzas) es propietario y es responsable de uno o más servicios individuales. Cada equipo puede desarrollar, desplegar y escalar sus servicios independientemente de todos los demás equipos.

• Mayor aislamiento de fallas. Por ejemplo, si hay una pérdida de memoria en un servicio, sólo ese servicio se verá afectado. Los otros servicios seguirán atendiendo a las solicitudes. En comparación, un componente de mala conducta de una arquitectura monolítica puede derribar todo el sistema.




13

• Elimina cualquier compromiso a largo plazo con una stack tecnológico. Al desarrollar un nuevo servicio, puede elegir nuevo stack tecnológico. De manera similar, al realizar cambios importantes en un servicio existente, puede volver a escribirlo utilizando una nuevo stack.

Los inconvenientes son: • Los desarrolladores deben lidiar con la complejidad adicional de crear un sistema distribuido

o Las herramientas de desarrollo / IDE están orientadas a la creación de aplicaciones monolíticas y no proporcionan soporte explícito para desarrollar aplicaciones distribuidas.

o La prueba es más difícil o Los desarrolladores deben implementar el mecanismo de comunicación entre servicios. o La implementación de casos de uso que abarcan múltiples servicios sin utilizar transacciones distribuidas

es difícil y requiere una cuidadosa coordinación entre los equipos • Complejidad de implementación. En la producción, también existe la complejidad operacional de desplegar

y administrar un sistema compuesto de muchos tipos de servicio diferentes. • Mayor consumo de memoria. La arquitectura de microservicios reemplaza instancias de aplicación N

monolíticas con instancias de servicios NxM. Si cada servicio se ejecuta en su propia JVM (o equivalente), que normalmente es necesario para aislar las instancias, entonces hay la sobrecarga de M veces como muchos tiempos de ejecución JVM. Además, si cada servicio se ejecuta en su propia VM (por ejemplo, instancia EC2), como es el caso en Netflix, la sobrecarga es aún mayor.

Estos beneficios no están garantizados automáticamente. En su lugar, sólo pueden lograrse mediante la cuidadosa descomposición funcional de la aplicación en los servicios.

Un servicio debe ser lo suficientemente pequeño como para ser desarrollado por un equipo pequeño y ser fácilmente probado. Una guía útil desde el diseño orientado a objetos (OOD) es el principio de responsabilidad única (SRP). El SRP define la responsabilidad de una clase como una razón para cambiar, y establece que una clase sólo debe tener una razón para cambiar. Tiene sentido aplicar el SRP al diseño del servicio y diseñar servicios que sean coherentes e implementen un pequeño conjunto de funciones fuertemente relacionadas.

La aplicación también se descompone de una manera tal que la mayoría de los requisitos nuevos y modificados sólo afectan a un único servicio. Esto se debe a que los cambios que afectan a múltiples servicios requieren coordinación entre varios equipos, lo que ralentiza el desarrollo. Otro principio útil de OOD es el Common Closure Principe (CCP), que establece que las clases que cambian por la misma razón deben estar en el mismo paquete. Tal vez, por ejemplo, dos clases implementan diferentes aspectos de la misma regla de negocio. El objetivo es que cuando esa regla de negocios cambie a los desarrolladores, sólo es necesario cambiar el código en un número pequeño - idealmente solo uno - de paquetes. Este tipo de pensamiento tiene sentido en el diseño de servicios, ya que ayudará a garantizar que cada cambio debe afectar a un solo servicio.

Otro desafío es decidir cómo dividir el sistema en micro servicios. Esto es mucho un arte, pero hay una serie de estrategias que pueden ayudar: • Descomponer por capacidad empresarial y definir servicios que correspondan a las capacidades

empresariales. • Descomponer por diseño orientado a dominios

3.5.1 Descomponer por capacidad empresarial y diseño orientado a dominios

Tabla 3. Diseño por capacidad empresarial y diseño por dominios

Capacidad empresarial Diseño orientado a dominios Definir los servicios correspondientes a las capacidades de negocio. Una capacidad empresarial es un concepto de modelado de arquitectura

Definir los servicios correspondientes a los subdominios de DDD (Domain-Driven Design). DDD se refiere al espacio del problema de la




14

empresarial. Es algo que una empresa hace con el fin de generar valor. Una capacidad de negocio a menudo corresponde a un objeto de negocio. Ejemplo: • La administración de pedidos es responsable de

los pedidos • La gestión del cliente es responsable de los

clientes Las capacidades empresariales se organizan a menudo en una jerarquía multinivel. Por ejemplo, una aplicación empresarial puede tener categorías de nivel superior, tales como desarrollo de productos / servicios, entrega de productos / servicios.

aplicación - el negocio - como el dominio. Un dominio consiste en varios subdominios. Cada subdominio corresponde a una parte diferente del negocio. Los subdominios se pueden clasificar de la siguiente manera: • Core: diferenciador clave para el negocio y la

parte más valiosa de la aplicación • Apoyo: relacionado con lo que hace la empresa,

pero no un diferenciador. Estos pueden ser implementados internamente o externalizados.

• Genérico: no es específico para el negocio y se implementan idealmente usando el software del estante

El área de arquitectura empresarial de Equifax Inc define los lineamientos informáticos que resuelven las necesidades actuales y prevén las futuras en función de la toma de decisiones. Es decir, proponen formas de generar bases de datos integradas, generando estándares de desarrollo de aplicación y servicios internos para que sean compatibles y puedan compartir información entre ellas, e incluso dando marcos de referencia para la compra y disposición de equipos informáticos, así como de disposición de recurso humano necesario para cada uno de los puntos de interacción.

La arquitectura empresarial radica en la alineación de los distintos componentes informáticos de una organización, todos en función de una visión estratégica que les dé sentido y, a la vez, que los convierta en recursos útiles para la toma de decisiones.

Para ello Equifax ha agrupado las distintas componentes de la organización en una serie de capacidades empresariales que se alinean con las estrategias del negocio.

A modo de simplificar el diseño y desarrollo de los diferentes productos estamos optando por descomponer los productos por capacidad empresarial. Esto permite mapear fácilmente las capacidades empresariales, definidas por arquitectura empresarial con las diferentes funcionalidades.

Los productos generados a partir de esta metodología deberían estar compuestos por un conjunto de capacidades. Cada capacidad deberá estar alineada con las diferentes especificaciones empresariales. Simplificando en gran medida las relaciones actuales y futuras, entre las componentes del negocio con las aplicaciones, maximizando la reutilización y cobertura de los productos generados.




15

Figura 7. Diagrama de capas y componentes de la arquitectura propuesta

Tabla 4. Descripción de capas de la arquitectura propuesta

Nombre ¿Qué es? ¿Qué hace? / ¿Para qué sirve? Internal Facing Channel Capa que agrupa todas las

componentes que son utilizadas de forma interna por la organización

Punto de entrada para todo tipo de transacciones web. Ya sean estas; páginas web, web servicies en SOAP y/o REST. Todos los servicios expuestos deben presentarse como pass-through proxies hacia el API Gateway.

External Facing Channel Capa que agrupa todas las componentes que se exponen a clientes

API Gateway Capa de micro servicios compuestos, estos conforman un producto o servicio.

Micro servicios compuestos que constituyen la lógica de negocio de el o los productos definidos. Estos deben ser construidos utilizando el patrón Observer, el patrón Iterator y la programación funcional con RxJava.

Discovery & Distribution Capa de micro servicios que manejan recursos atómicos y distribuyen carga.

En un despliegue de sistema distribuido tradicional, los servicios se ejecutan en ubicaciones fijas y bien conocidas (hosts y puertos) y así se pueden llamar fácilmente utilizando HTTP / REST o algún mecanismo RPC. Sin embargo, una aplicación moderna basada en microservicios normalmente se ejecuta en entornos virtualizados o en contenedores donde el número de instancias de un servicio y sus ubicaciones cambia dinámicamente. Para




16

resolver estos inconvenientes se implementa el stack OSS de Netflix.

Backbone

Stack de servicios atómicos que resuelven una casuística en particular.

Conjunto de micro servicios basados en funciones atómicas del negocio. Ej.: Enviar un mail, login, un reporte, entre otros

Spring Cloud Config Micro servicio de configuraciones

Provee soporte para utilizar las configuraciones de los proyectos de forma externalizada y por entrono (desarrollo, pruebas, pre productivo, productivo) para sistemas distribuidos.

Tabla 5. Netflix OSS Stack

Nombre ¿Qué es? ¿Qué hace? / ¿Para qué sirve? Eureka

Descubridor de servicios

Es un servicio basado en REST (Representational State Transfer) que se utiliza principalmente para localizar servicios de forma dinámica y presentarlos como recursos distribuidos en vez de endpoints fijos (hosts y puertos).

Zuul Proxy Permite el enrutamiento dinámico, monitoreo, resiliencia y

seguridad.

Ribbon Balanceador de carga Biblioteca de comunicaciones de proceso intermedio (IPC). Ribbon proporciona principalmente algoritmos de balanceo de carga del lado del cliente.

Ribbon proporciona también otras características:

• Integración de la detección de servicios: los balanceadores de carga proporcionan la detección de servicios en entornos dinámicos como una nube.

• Tolerancia a errores: puede determinar dinámicamente si los servidores están activos y funcionando en un entorno en vivo y puede detectar aquellos servidores que están inactivos

Reglas configurables de balanceo de carga: admite RoundRobinRule, AvailabilityFilteringRule, WeightedResponseTimeRule y también admite la definición de reglas personalizadas.

Hystrix Circuit Breaker Es una biblioteca de latencia y tolerancia a fallos diseñada para aislar puntos de acceso a sistemas remotos, servicios y bibliotecas de terceros, detener el fallo en cascada y permitir la resiliencia en sistemas distribuidos complejos donde el fallo es inevitable.

3.5.2 Despliegue de aplicaciones y servicios (patrón instancia de servicio por contenedor)

Cuando utiliza el patrón Instancia de servicio por contenedor, cada instancia de servicio se ejecuta en su propio contenedor. Los contenedores son un mecanismo de virtualización a nivel del sistema operativo. Un contenedor consiste en uno o más procesos que se ejecutan en una caja de arena. Desde la perspectiva de los procesos,




17

tienen su propio espacio de nombres de puertos y sistema de archivos raíz. Puede limitar la memoria de un contenedor y los recursos de la CPU. Para utilizar este patrón, se empaqueta el servicio dentro de una imagen de container. Una imagen de container docker, es una imagen de sistema de archivos que consiste en las aplicaciones y bibliotecas necesarias para ejecutar el servicio. Algunas imágenes de container consisten en un sistema de archivos raíz de Linux completo.

3.6 Integración con una plataforma de “Integración Continua” (CI)

CI es una componente importante dentro del proceso de DevOps. Herramientas tales como Jenkins, BuildBot, Microsoft VSTS/TDS y GitLab se encuentran dentro de las más populares. Cualquiera de estos puede ser implementado basado en los requerimientos del negocio.

Las herramientas de CI se pueden integrar con cualquier sistema de control de versiones tales como Git o Subversion, para proveer compilación de código automatizadas siempre y cuando esta tenga alguna modificación. Esto evita que alguien, ya sea del equipo de desarrollo u operaciones tenga que descargar y compilar el código de forma manual.

El siguiente diagrama demuestra un típico proceso de desarrollo. El desarrollador realiza un commit del código a un repositorio de control de versiones (ej.: Git). El equipo de operaciones responsable de compilación e instalación tomará el código fuente designado y construirá los ejecutables en el servidor de compilación. A continuación, desplegaran los artefactos resultantes (ej.: un archivo *.war) y lo instalaran en un entorno de pruebas. El equipo control de calidad hace pruebas en la aplicación, si estas resultan exitosas, el equipo de operaciones realiza una nueva instalación en un ambiente pre productivo. Si el negocio aprueba la instalación el equipo de operaciones nuevamente ejecuta el procedimiento de instalación en los servidores de producción.

Figura 8. Proceso manual dentro del ciclo de desarrollo Existen muchos pasos manuales en este proceso: 1. Descarga del código fuente al servidor de compilación 2. Ejecutar la compilación 3. Instalar la aplicación en el servidor de pruebas 4. Ejecución de pruebas por el equipo de control de calidad (si es que las pruebas no están automatizadas) 5. Instalación de aplicación en servidor de pre-productivo 6. Instalación de aplicación en servidor de producción 7. Monitores de los servidores de pruebas pre-producción y producción




18

Para efectos de esta implementación instalamos una herramienta de CI (Jenkins) y lo integramos con las siguientes herramientas: • BitBucket: Sistema de control de versiones git • SonarQube: Herramienta de evaluación SQALE • Cucumber: librería para pruebas automatizadas • Gatling.io: Herramienta para realizar pruebas de estrés

El servidor Jenkins descarga automáticamente el código desde BitBucket (siempre y cuando existan cambios en el código fuente). Ejecuta una evaluación del código SQALE con SonarQube y almacena los resultados obtenidos para posterior análisis. Posteriormente se compilan las fuentes y ejecuta las pruebas unitarias con cucumber, una vez aprobadas todas las pruebas entra en una segunda fase donde se estresa la aplicación para tal de cumplir con los tiempos de respuesta definidos por el negocio. Finalmente instala la aplicación en los servidores pre-productivos y eventualmente pasa a producción cuando se entregue la orden. Este proceso eliminó varios pasos ejecutados anteriormente de forma manual y a su vez incorporó nuevas funcionalidades. El siguiente diagrama denota el nuevo proceso.

Figura 9. Integración con herramienta de CI

El nuevo proceso automatizado elimina errores humanos, liberara recursos humanos que pueden ser reasignados a tareas más productivas e incrementa la velocidad con la que se liberan cambios.

3.7 Integración con Gestión de Infraestructuras / Configuración

Integración con despliegue continuo es otra componente importante del proceso DevOps. Para realizar despliegues de aplicaciones automáticamente, la infraestructura (CPU, almacenamiento, memoria) debe soportarlo. Esto es posible cuando el cliente utiliza una plataforma IAAS. Podría ser una nube privada / on premise como VMware, OpenStack o nube pública como Amazon AWS, Microsoft Azure, Google Cloud Platform.

La configuración de compilación de CI, la configuración de prueba y muchas otras funciones requieren hosts con cierta capacidad de CPU / memoria / almacenamiento. En esto las construcciones ocurrirían, las aplicaciones serían desplegadas para la prueba del sistema y así sucesivamente. En lugar de configurar servidores de compilación dedicados o servidores de prueba que se utilizarán sólo cuando sea necesario y que estarán inactivos para el recordatorio de la hora, es mejor desplegar estos hosts cuando sea necesario. Esto es posible con tecnologías como Infrastructure as a Service (IAAS), gestión de la configuración. Las herramientas de CI como Jenkins y otros tienen interfaces bien integradas a las plataformas IAAS como OpenStack, AWS,




19

que puede proporcionar los servidores de compilación necesarios a petición y hacer la compilación para ello. Del mismo modo, la automatización de pruebas puede utilizar las interfaces apropiadas (utilizando API) para suministrar las máquinas necesarias (máquinas virtuales) y utilizar herramientas de gestión de configuración como Kubernetes para implementar las aplicaciones en estas máquinas virtuales y luego hacer las pruebas automatizadas. La mayoría de estos se realizarán automáticamente en un proceso de DevOps.

Incluso después de automatizar el proceso de creación y lanzamiento usando una plataforma de CI (Jenkins), hay algunos pasos manuales involucrados. El equipo de Operaciones estará involucrado en configurar los hosts para los servidores de compilación, para desplegar las aplicaciones en entornos de prueba y puesta en escena. También necesitan instalar el software dependiente como bases de datos, servidores de directorio y así sucesivamente. Todos estos son procesos manuales. No sólo eso, sino que los hosts desplegados siempre estarán funcionando incluso cuando no se produzca ninguna compilación o prueba. Esto es un desperdicio de recursos de la empresa. Todo el proceso se vería como la imagen de abajo.

Figura 10. Provisionamiento manual de hosts de compilación / prueba

El uso de herramientas de gestión de configuración y orquestación como Kubernetes junto con la plataforma IAAS como Docker puede automatizar el proceso manual. El nuevo proceso eliminará la implementación manual de hosts y la instalación de software dependiente. Los servidores de compilación y los servidores de prueba se implementan sólo cuando se requiere allí utilizando los recursos de manera eficiente.

Figura 11. Integración con IaaS y CM




20

3.8 Integración con solución de monitoreo

El monitoreo continuo es otro componente importante del proceso DevOps. El monitoreo se realiza para todas las categorías en un entorno: Rendimiento, Capacidad, Rendimiento, Uptimes, KPIs, Cumplimiento, Archivos de registro. Cada una de las categorías tendrá diferentes consumidores como desarrolladores, probadores, sistemas informáticos y así sucesivamente.

Con una buena configuración, la monitorización se puede integrar con otros componentes del proceso. Por ejemplo, cada vez que hay un problema de capacidad, como el almacenamiento en cortocircuito, el equipo de operaciones podría ser notificado de tal evento. Si está integrado con la configuración de IAAS, esto podría ser automatizado para proporcionar más capacidad de disco a petición. Del mismo modo, siempre que haya un problema de rendimiento con la aplicación desplegada, el proceso puede usarse para generar automáticamente un incidente con registros apropiados que el equipo de desarrollo puede examinar para fijar en la siguiente iteración. El proceso se verá como a continuación después de agregar la supervisión al proceso.

Figura 12. Integración con Monitoreo

El monitoreo suele ser capturado por el registro. Hay herramientas como Nagios, ELK (Electricsearch, Logstash) pila que se puede implementar para realizar el registro y la supervisión. A continuación, los registros capturados se analizan para encontrar cualquier problema y luego se agregan al rastreador de peticiones para su posterior procesamiento.

3.9 Resultados obtenidos de los proyectos piloto

Los proyectos piloto seleccionados para implementar la nueva arquitectura e infraestructura, son productos existentes dentro de la compañía. Por ende, simplifica la comparación entre el historial de un producto y su nueva implementación. La tabla 6 refleja los beneficios obtenidos de forma transversal en los tres proyectos, para mayor información de los proyectos refiérase al anexo de este documento.

Tabla 6. Resultados de implementación de Arquitectura de micro servicios y despliegue continuo

Beneficio detectado Arquitectura e infraestructura antigua Arquitectura e infraestructura nueva

Despliegues más frecuentes a producción.

5 despliegues promedio al año por producto monolítico.

256 despliegues promedio al año

Tiempo promedio de instalación de un nuevo

~1.5 horas invertidas en instalación sin incluir tiempo invertido en pruebas.

~30 minutos invertidos en instalación incluidas las pruebas automatizadas.




21

producto a producción reducido. Tiempo de recuperación tras un fallo de servicio

~2.5 horas ~15 minutos, esto se logra gracias a la capacidad de auto healing de la infraestructura

Instalación de parches de seguridad en servidores

Trabajo de mantenimiento manual que toma ~8 horas en cerca de 250 servidores

Trabajo automatizado por kubernetes, tiempo ~45 minutos en 376 contenedores desplegados.

Reutilización de componentes en nuevos desarrollos

0 componentes reutilizadas 16 de 51 representando un 31% del desarrollo total

3.10 Encuesta a los involucrados en la transición hacia un estado de DevOps

Como parte del proceso de transición y con el objetivo de conocer la percepción de los miembros de los equipos de desarrollo, calidad y operaciones del impacto que pudo tener este trabajo, se realizó una encuesta orientada a identificar el valor que puede entregar cada uno de los aportes presentes en este trabajo.

Se utilizó la escala de Likert [9] para estructurar las preguntas y respuestas de la encuesta. Para realizar las encueta se utilizó la herramienta de confluence.

Las respuestas posibles fueron las siguientes: • Totalmente en desacuerdo • En desacuerdo • Ni de acuerdo ni en desacuerdo • De acuerdo • Totalmente de acuerdo

Las preguntas y los resultados conseguidos se detallan a continuación:

Pregunta 1 La integración de código con más frecuencia conduce a niveles de riesgo reducidos en cualquier proyecto.

Figura 13. Respuesta a pregunta 1




22

Pregunta 2 La incorporación de pruebas automatizadas e inspecciones de código continuas en el proceso de CI es valiosa tanto para desarrolladores como para gerentes.


Pregunta 3 La integración continua puede permitirle liberar software a producción en cualquier momento.

Figura 15. Respuesta a pregunta 3 Pregunta 4 La modularidad de la arquitectura de micro servicios tiene la ventaja de permitir realizar correcciones, mejoras, mantenimientos y actualizaciones de forma más eficiente que la arquitectura monolítica.





23

Pregunta 5 Con el nuevo proceso de despliegue continuo la instalación de cualquier artefacto de software en los ambientes de desarrollo, pruebas y pre productivo toman minutos en vez de horas.


Pregunta 6 La automatización de casos de prueba ha simplificado las pruebas regresivas.

Figura 18. Respuesta a pregunta 6 Pregunta 7 La arquitectura de micro servicios permite incorporar rápidamente nuevos requerimientos de negocio, generando tan solo leves desviaciones en la planificación de un proyecto.


3.11 Análisis de resultados de las encuestas

A partir de las encuestas realizadas a los involucrados, se percibir una disminución en el costo de desarrollo y operaciones. Otros beneficios incluyen: • Ciclo de desarrollo más corto • Mayor velocidad de liberación • Detección mejorada de defectos • Reducción de fallos de implementación y reversiones • Tiempo reducido para recuperarse después de un fallo.




24

De hecho, estos beneficios pueden convertirse en indicadores clave de rendimiento (KPI, por sus siglas en inglés) para que su empresa pueda realizar un seguimiento. Las empresas pueden rastrear el tiempo y el costo que se necesita para el proyecto que desarrollan aplicaciones de software utilizando un enfoque tradicional de no DevOps y compararlo con el uso de DevOps para apreciar mejor los beneficios cuantificables de DevOps.

Adicionalmente se puede observar una distribución más o menos pareja en la pregunta 7 relacionada a la incorporación de cambios a nuevos requerimientos del negocio. Esto se debe principalmente al tipo de solicitud recibida. Si esta se encuentra alineada con el requisito original su rápida implementación no genera mayores inconvenientes, el problema solo se presenta cuando los requerimientos escapan mucho al original.

4 Conclusiones

A modo de cierre se abordan cada uno de los temas tratados. Estos van desde las herramientas y procesos, automatización, pasos a producción y entregas iterativas. Vale destacar que uno de los aspectos más relevantes de este trabajo es la iteración continua a todos los procesos y herramientas definidas. Lo que hoy resuelva necesidades de negocio que aceleran el time to revenue puede que no apliquen en un futuro próximo.

En cuanto a las herramientas comunes tanto para Devs y Ops puede ayudar realmente a establecer una terminología y procesos comunes para requisitos, dependencias y problemas. Si, al discutir un desafío, Devs y Ops tienen las mismas herramientas y procesos en mente, lo más probable es que tendrán un tiempo más fácil de entender y trabajar unos con otros. Y si los Devs y Ops están trabajando conjuntamente en un problema y no necesitan discutir sobre quién es el responsable de ejecutar una tarea, ya sea arreglar una configuración de compilación o crear un script.

La automatización es una piedra angular de un gran flujo de trabajo de desarrollo. Cada tarea que pueda ser ejecutada por una maquina debería contar con algún grado de automatización. El desplegar de pruebas es una de esas tareas. A través de ellas, puede estar seguro de que los pasos más importantes que sus clientes tomarán a través de su sistema funcionarán, independientemente de los cambios que realice. Esto le da la confianza para experimentar, implementar nuevas características y enviar actualizaciones rápidamente.

Poner el software en producción es lento y arriesgado. La optimización de este proceso tiene el potencial de hacer el desarrollo de software en general más eficaz y eficiente. Por lo tanto, la entrega continua puede ser una de las mejores opciones para mejorar los proyectos de software. La entrega continua tiene como objetivo procesos regulares y reproducibles para entregar software, al igual que la integración continua para integrar todos los cambios. Mientras que la entrega continua parece una gran opción para disminuir el tiempo de comercialización en realidad tiene mucho más que ofrecer: Es un enfoque para minimizar el riesgo en un proyecto de desarrollo de software, ya que garantiza que el software realmente puede ser desplegado y ejecutado en la producción. Así que cualquier proyecto puede obtener alguna ventaja, incluso si no se encuentra en un mercado muy competitivo donde el tiempo de mercado no es tan importante después de todo.

Por último, espero que se demuestre que la entrega iterativa, combinada con un proceso automatizado para construir, desplegar pruebas y liberar software incorporado en un canal de despliegue, no sólo es compatible con los objetivos de conformidad y rendimiento, sino que es la forma más efectiva de alcanzar estos objetivos. Este proceso permite una mayor colaboración entre los que participan en la entrega de software, proporciona una retroalimentación rápida para que los errores y las funciones innecesarias o mal implementadas se puedan descubrir rápidamente. Esto, a su vez, significa una entrega más rápida de software valioso y de alta calidad que conduce a una mayor rentabilidad con menor riesgo.




25

Referencias

[1] “Equifax – Perfil de la empresa”, 2017, http://soluciones.equifax.cl/acerca-de-equifax/perfil-de-la-empresa [2] “Continuous Delivery”, 2010, Jez Humble & David Farley, Addison-Wesley Signature Series, Pearson Education Inc. [3] “Metodologías ágiles y desarrollo basado en conocimiento”, Loraine Gimson, 2012 [4] “Microservice Patterns, 2017”, Chris Richardson, Manning Publications Co. [5] “Patterns of Enterprise Application Architecture”, 2003, Martin Fowler, Addison-Wesley Signature Series, Pearson

Education Inc. [6] “Refactoring: Improving the Design of Existing Code”, 1999, Martin Fowler & Kent Beck, Addison Wesley Longman

Inc. [7] “Microservices”, 2014, Martin Fowler, Pearson Education Inc. [8] “The Twelve-Factor App”, 2017, https://12factor.net/ [9] “Escala Likert”, https://es.wikipedia.org/wiki/Escala_Likert




26

Anexos

Arquitectura de proyecto piloto 1– Medios de pago para facturas pendientes

El objetivo de este proyecto es cubrir la integración de medios de pago para que los clientes de Equifax puedan pagar sus facturas pendientes a través del Banco de Chile, Banco Santander, Khipu y Servipag.

Figura 20. Arquitectura Medios de pago

Tabla 7. Componentes de medios de pago para facturas

Componente ¿Qué hace? / ¿Para qué sirve? FB WEB Aplicación web cliente ~ Angular Banco Santander Canal de comunicación entre Banco Santander y Equifax, con la herramienta PEC. Banco de Chile Canal de comunicación entre Banco de Chile y Equifax Facturas Pendientes Micro Servicio que maneja las peticiones HTTP del cliente. Es la puerta de enlace

a otros micro servicios PEC Micro Servicio que maneja las peticiones del Banco de Chile y Banco Santander PendingBills Micro Servicio que se encarga de buscar en base de datos las facturas pendientes

de un cliente MotorPago Micro Servicio que maneja la comunicación con el motor de pago Mailing Micro Servicio que se encarga de enviar correos electrónicos y guardar en base de

datos al correo que se le envío el comprobante de pago PB-Trx Micro Servicio que inserta, busca y modifica la transacción realizada, sea por el

portal o por PEC. Lockbox Micro Servicio que verifica el archivo enviado a R12 PB-Rut Busca en base de datos los Ruts asociados al usuario autenticado PB-PEC Micro Servicio devuelve el monto total del Banco Santander Billing Micro Servicio que devuelve el histórico de las transacciones de un usuario

Arquitectura de proyecto piloto 2– Business Monitor El producto Business Monitor, es la evolución del producto Alerta Comercial. Este, orientado a la venta por empresas y a personas naturales, trae consigo un re diseño del concepto de Alerta Comercial, la creación de un sitio público con información del producto, sus funcionalidades y un Dashboard con una suite de estadísticas, administración de cartera, administración de contratos, gestión de bases alertadas, gestión de alertas generadas.




27

Uno de los beneficios inmediatos es la reutilización de algunos de los servicios generados en el primer proyecto (marcados en verde en la figura 21).

Figura 21. Arquitectura Business Monitor

Tabla 8. Componentes de business monitor

Componente ¿Qué hace? / ¿Para qué sirve? Business Monitor WEB Aplicación web para despliegue de planes, validación de identidad y pago web Business Monitor API que orquesta los flujos y lógica de negocio de la aplicación Web Users Administración de usuarios y clientes Suscripciones Micro Servicio para administración de suscripciones al sistema de alertas Notificaciones Micro Servicio responsable de enviar notificaciones de alerta a clientes que

contraten el servicio eID Micro Servicio de validación de identidad de personas naturales y empresas Planes Micro Servicio de gestión de planes Logging Servicio de trazabilidad

Arquitectura de proyecto piloto 3– Lease Suite

Producto que permite a personas naturales y jurídicas con o sin contrato con Equifax, firmar un contrato de arriendo. Permitiéndoles a su vez publicar las deudas morosas de sus arrendatarios en Boletín Electrónico Dicom. Permite a arrendadores y corredores verificar que los arrendatarios no tienen deudas impagas.




28

Figura 22. Arquitectura Lease Suite

Tabla 9. Componentes de Lease Suite

Componente ¿Qué hace? / ¿Para qué sirve? Lease Suite Web Aplicación web para que los clientes puedan consultar y/o reportar la deuda de sus

arrendatarios, esto previa validación de identidad y pago web Lease Suite API que orquesta los flujos y lógica de negocio de la aplicación Web Users Administración de usuarios y clientes Consultas al RUT Micro Servicio para consultar información de identidad de una persona Registro de Deudas Micro Servicio responsable de consolidar la información de deudas de un

arrendatario Registro de Morosidades

Micro Servicio responsable de consolidar la información de morosidades de un arrendatario

Planes Micro Servicio de gestión de planes Logging Servicio de trazabilidad

Documents

Transformación Empresarial hacia un estado DevOps€¦ · nuevos procesos e implementar herramientas que habilitan un estado DevOps. Centrando las mejoras en procesos y tecnologías