arquitecturas ejecutables aplicadas en el contexto de data

UNIVERSIDAD DE LOS ANDES

Facultad de Ingeniería

Departamento de Ingeniería de Sistemas y Computación

Arquitecturas ejecutables aplicadasen el contexto de Data Analytics

Trabajo de tesis presentado por

Juliana Dávila Rodríguez

Director

Darío Ernesto Correal Torres Ph.D.

Para optar por el título de

Magíster en Ingeniería de Sistemas y Computación

Noviembre del 2017

Resumen

En la ejecución de un proyecto de Big Data Analytics(BDA) intervienen múl-

tiples actores para su desarrollo, entre ellos los arquitectos de software y los cien-

tíficos de datos. Sin embargo, la comunicación entre estos actores no es sencilla

y ha generando problemas que afectan el proceso de despliegue de una solución

analítica, como son los altos costos y transición propensa a errores entre el labora-

torio de datos y el ambiente de pruebas. A través de esta investigación utilizamos

y ampliamos la definición de la estrategia “ArchOps”, la cual se basa en arqui-

tecturas ejecutables para desplegar una arquitectura por medio de la definición

de sus artefactos de diseño, facilitando la puesta en producción de una solución

Data Analitics(DA) y la validación y prueba de una arquitectura.

i

Más información

El código de implementación, documentación e instrucciones de este proyecto

se pueden encontrar las siguientes urls:

https://github.com/judaro13/arieta-api

https://github.com/judaro13/arieta-web-app

Los servicios desarrollados para la validación del proyecto pueden ser consul-

tados en: https://github.com/judaro13/arieta-services

Así mismo, los datos utilizados para la validación se pueden encontrar en:

https://github.com/judaro13/arieta-validation

ii

https://github.com/judaro13/arieta

https://github.com/judaro13/arieta-web-app

https://github.com/judaro13/arieta-services


Agradecimientos

Quiero agradecer a todos los que me apoyaron directa e indirectamente en

la elaboración de esta investigación. Le doy las gracias a Lorena Salamanca, con

quien trabaje en investigaciones previas relacionadas con esta tesis y las cuales

sirvieron de base para su ejecución. También quiero agradecer especialmente a

Cristian Camilo Castellanos, quien nos dio la base para esta investigación a partir

de su trabajo de doctorado y el cual ayudó en múltiples faces del desarrollo de

esta tesis. Finalmente agradezco a Dario Ernesto Correal, quien sin su guía no

hubiera sido posible culminar este proyecto.

iii

Índice general

Resumen i

Más información ii

Agradecimientos iii

Tabla de contenido iv

Lista de imágenes vii

Lista de tablas viii

1 Introducción 1

1.1 Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . 2

1.2 Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Objetivo general . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . 6

1.4 Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . 7

2 Contexto 9

2.1 Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Vistas y puntos de vista de una arquitectura . . . . . . . . . . . . 10

2.3 Arquitectura orientada a servicios - SOA . . . . . . . . . . . . . . 11

2.4 Micro-servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Arquitecturas ejecutables . . . . . . . . . . . . . . . . . . . . . . 14

2.7 ArchOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iv

Índice general v

2.8 Escenarios de calidad . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.9 Tácticas de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.10 Data Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.11 Representación de modelos de solución analítica - PMML . . . . 18

2.12 Contenedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.13 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.14 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Estrategia de solución 24

3.1 Conceptos fundamentales de ArchOps . . . . . . . . . . . . . . . 24

3.1.1 Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.2 Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.3 Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.4 Practicas y herramientas . . . . . . . . . . . . . . . . . . . 30

3.2 Proceso de solución . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 Estrategia de solución: Despliegue automático, una estrategia Ar-

chOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Implementación de la herramienta de validación: Arieta 38

4.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.2 Cliente Web . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.3 Servicio de notificaciones . . . . . . . . . . . . . . . . . . . 45

4.2.4 Clúster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Validación 49

5.1 Experimentación . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1 Escenario de calidad 1: Despliegue de una solución analítica 50

5.1.2 Escenario de calidad 2: Flexibilidad de los artefactos de

analítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 57

vi Índice general

5.1.4 Amenazas a la validación . . . . . . . . . . . . . . . . . . 58

6 Trabajo relacionado 59

7 Conclusiones y trabajo futuro 63

7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.2 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Apendice A: Arieta API Endpoints 66

Apéndice B: Ejemplo de archivo JSon para despliegue 68

Apéndice C: Ejemplo de archivo PMML 70

Apéndice D: Manifiesto Ágil DevOps 72

Apéndice E: Capturas de pantalla 74

Bibliografía 80

Índice de figuras

1.1 Actores principales en BDA . . . . . . . . . . . . . . . . . . . . . 4

2.1 Vistas de Rozanski y Woods . . . . . . . . . . . . . . . . . . . . 11

2.2 Interacciones en DevOps . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Modelo ArchOps . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Escenario de calidad . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Estructura de un PMML . . . . . . . . . . . . . . . . . . . . . . . 20

2.6 Maquinas virtuales y representación de contenedores [1] . . . . . 21

2.7 Diagrama de arquitectura de K8s [2] . . . . . . . . . . . . . . . . 22

2.8 K8s dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 CAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Ciclo ArchOps para un arquitecto de software . . . . . . . . . . . 31

3.3 Estrategia de solución . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Arieta: Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Flujo de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Tecnologías utilizadas . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Servicio OpenScoring . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5 Vista de despliegue del sistema . . . . . . . . . . . . . . . . . . . 45

4.6 Kafka: Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 Esquema de la validación . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Táctica de despliegue 3 a 1 . . . . . . . . . . . . . . . . . . . . . 52

5.3 Servicio de analítica . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 Resultados de la táctica 3 a 1 . . . . . . . . . . . . . . . . . . . . 54

5.5 Táctica de despliegue 1 a 1 . . . . . . . . . . . . . . . . . . . . . 55

vii

5.6 Resultados de la táctica 1 a 1 . . . . . . . . . . . . . . . . . . . . 56

5.7 Resultados de actualizar un modelo analítico . . . . . . . . . . . 57

7.1 Vista de despliegue del sistema . . . . . . . . . . . . . . . . . . . 75

7.2 Vista - Adicionar nueva tecnología al sistema . . . . . . . . . . . 76

7.3 Vista - Editar un servicio . . . . . . . . . . . . . . . . . . . . . . 77

7.4 Vista - Listado de escenarios de calidad . . . . . . . . . . . . . . 78

7.5 Vista - Crear un nuevo escenario de calidad . . . . . . . . . . . . 78

7.6 Vista - Listado de tácticas de despliegue . . . . . . . . . . . . . . 79

7.7 Vista - Crear una nueva táctica de despliegue . . . . . . . . . . . 79

Índice de cuadros

5.1 Escenario de calidad 1 . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Escenario de calidad 2 . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1 Tabla de comparación de tecnologías relacionadas . . . . . . . . . 61

viii

1Introducción

Para cualquier tipo de proyecto de software, la definición de su arquitectu-

ra es fundamental para satisfacer el conjunto de unidades arquitectónicas que

permiten alcanzar los atributos de calidad, las funcionales y las restricciones del

negocio que están ligadas directamente a los objetivos del mismo. Éstas unidades

incluyen especificaciones en elementos de software, propiedades y relaciones, así

como restricciones entre ellos [3, 4]. La arquitectura de software de un sistema

se puede ver como “el conjunto de estructuras necesarias para razonar acerca del

sistema” [3] y que a su vez permite vigilar y mantener aspectos como: disponi-

bilidad, integrabilidad, seguridad, rendimiento, usabilidad y accesibilidad, entre

otros [5].

En una arquitectura de software, también es importante integrar nuevos re-

cursos o tecnologías y permitir aplicar cambios en el sistema de forma ágil, lo

cual hace que sea un factor esencial a tener en cuenta en el diseño de la misma.

1

2 1.1. Planteamiento del problema

Este principio es primordial para alcanzar la adaptabilidad de sistema necesaria

para afrontar nuevos retos, sobretodo teniendo en cuenta los nuevos avances tec-

nológicos y tendencias en el manejo de la información. El principio de agilidad es

ampliamente aplicado en desarrollo de software y han emergido múltiples prác-

ticas y documentos para su definición, entre estos está el “Manifiesto ágil ”, que

enfatiza en valores como: “Individuos e interacciones sobre procesos y herramien-

tas. Software funcionando sobre documentación extensiva. Colaboración con el

cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un

plan”[6]. En nuestro caso, la “Respuesta ante el cambio” nos motiva a permitir

aplicar cambios sobre una arquitectura sin dejar de lado su documentación.

El diseño de arquitecturas hasta al momento ha sido trivial o inexistente en

en sistemas con cantidades de datos “pequeños” o en Datawarehouse [7], donde

la información se considera pequeña en el contexto de Big Data, y los procesos

son orientados a lotes o bloques de datos, con arquitecturas estándar que rara

vez cambian. Sin embargo, en el contexto de BDA, las arquitecturas deben tener

capacidades mayores que las tradicionales, ya que éstas deben afrontar desafíos

técnicos para soportar analítica avanzada sobre grandes volúmenes de datos.

No obstante, también es cierto que en los proyectos de BDA no es común

saber en la fase inicial las preguntas que se quieren resolver, así como las tec-

nologías que se van a utilizar [8]. Adicionalmente a esto, están los problemas de

comunicación entre los diferentes actores involucrados, especialmente entre los

científicos de datos y los arquitectos de software para mover un modelo de solu-

ción del ambiente del laboratorio, al ambiente de producción. El estado del arte

investigado y expuesto más adelante, indica que existen estrategias para facilitar

la comunicación y el despliegue de arquitecturas y soluciones, las cuales no se

están utilizando en este campo en específico.

1.1 Planteamiento del problema

La creación y consumo de datos ha crecido significativamente en los últimos

años, generados principalmente por el comercio electrónico y las aplicaciones

Capítulo 1. Introducción 3

Web. El manejo, utilización y aprovechamiento de dicha información se ha vuelto

cada vez más relevante, impulsando el mercado de BDA y generando grandes

expectativas y predicciones sobre este, como muestra Forbes en su artículo “6

Predictions For The $203 Billion Big Data Analytics Market”[9], donde estiman

que para el 2020 el mercado de BDA estara sobre los $203.000 millones de dólares,

con un crecimiento anual esperado del 11.7%. Esto ha impulsado la inversión en

hardware, software y servicios para BDA, así como en científicos de datos y su

educación. Sin embargo, en el contexto de BDA existe una brecha comunicativa

al rededor del aspecto humano.

En los proyectos de BDA, es usual encontrar tres actores de dominios dife-

rente, como se puede observar en la figura 1.1. Los expertos del negocio, per-

tenecientes al dominio del negocio, se encargan de especificar que objetivos del

negocio y procesos impulsan la solución analítica. Los científicos de datos, del do-

minio analítico del sistema, son quienes entienden los datos del proyecto y tienen

los conocimientos necesarios para manipularlos y generar una o múltiples solu-

ciones según el objetivo del proyecto. Finalmente, el arquitecto de software, del

dominio de las tecnologías de la información, se encarga de diseñar y desplegar

la arquitectura del sistema, así como seleccionar y administrar las tecnologías

necesarias para implementar una solución analítica y desplegarla en ambiente de

producción.

Sin embargo, cada uno de los actores, al ser de dominios diferentes, tienen sus

propias terminologías, intereses y objetivos, que aun cuando todos están alineados

con el objetivo principal de proyecto, son intrínsecamente diferentes. Esto genera

dificultades a la hora de comunicar y traducir los objetivos de un domino a otro

y hace necesario articular una solución que integre los dominios. Por ejemplo,

entre el dominio del negocio y el analítico, los objetivos del negocio se deben tra-

ducir a tareas analíticas y a algoritmos, dónde el resultado final de un científico

de datos serían los modelos entrenados en el laboratorio de datos, dentro de un

ambiente controlado. No obstante, en un entorno de producción, los modelos de-

ben convertirse en componentes de software empresarial con atributos de calidad

tales como escalabilidad, baja latencia y seguridad. Consecuentemente, entre el

4 1.1. Planteamiento del problema

Figura 1.1: Actores principales en BDA

domino analítico y el dominio de las tecnologías de la información, un modelo de

solución debe traducirse a una arquitectura con las tecnologías que lo soportan,

así como producirse el despliegue de dichos elementos en producción.

La falta de coordinación y los distintos conocimientos y objetivos entre los

arquitectos de software y los científicos de datos incrementa la brecha comunica-

tiva y las dificultades en mover una solución a un ambiente de producción. Estos

problemas de comunicación e interoperatibilidad entre dominios no es un mal

menor, estudios indican que más del 55% de los proyectos de DA fallan por esta

razón [10, 7]. Los cuales generan:

Alto costo y transición propensa a errores entre el laboratorio de

datos y el ambiente de pruebas [7, 8, 11]

Siendo estos errores los relacionados con requerimientos no funcionales del

proyecto como son: tiempo de ejecución, latencia, disponibilidad, escalabilidad,

entre otros. Es decir, errores arquitecturales. Por otro lado, existen problemas

relacionados con la actualización de un modelo desplegado en producción, ya


que en muchos casos es necesario reescribir la implementación de la solución a

otros lenguajes o tecnologías orientadas a entornos productivos, por ejemplo, un

científico de datos entrena y evalúa modelos usando tecnologías como R o Scikit

Learn, pero para llevarlo a producción es necesario transformar dicho código a

lenguajes como C++, Java o Spark, para mejorar el rendimiento .

Este problema, sobre el cual está enfocada esta investigación, tiene tres as-

pectos a tener en cuenta: el diseño de la arquitectura de software, el desarrollo de

la solución y su despliegue. El desarrollo y despliegue de la solución no pueden

llevarse a cabo satisfactoriamente sin un buen diseño de la arquitectura. El diseño

de la arquitectura a su vez, debe respaldar los requisitos de DA y los objetivos

del negocio, teniendo en cuenta que un diseño inadecuado es costoso, lleva mucho

tiempo en rectificarse y las malas decisión arquitecturales tienen consecuencias

a largo alcance en el sistema[7]. Por lo tanto, el diseño de la arquitectura del

sistema es de gran importancia para el despliegue de una solución, así como de-

be permitir analizarse, validarse y probarse; sin embargo con las aproximaciones

tradicionales para este tipo de proyectos, estas labores generarían más costos e

incrementarían el tiempo de ejecución del proyecto.

1.2 Contribución

Aun cuando existen diferentes forma de aproximarse a este problema, en

nuestro caso nos basamos en el uso de arquitecturas ejecutables, ya que es un

tema en el cual hemos venimos trabajando desde hace algunos años y nos interesa

saber el comportamiento de este en el entorno especifico de data analytics.

En esta tesis se tomo como base el concepto de ArchOps, el cual en este tra-

bajo se define formalmente especificando sus principios, valores, metodologías,

practicas y herramientas. Todo esto con la finalidad de entender mas profunda-

mente el concepto de ArchOps y su implementación. Adicionalmente se realizo

la prueba de concepto sobre el uso de arquitecturas ejecutables en el contexto

de data analytics, con el objetivo de desplegar modelos de analítica de forma

automática a partir de escenarios de calidad, tácticas de diseño y modelos de

6 1.3. Objetivos

analítica en formato PMML.

El uso de arquitecturas ejecutables permiten a un arquitecto de software ge-

nerar cambios en el estado actual de una arquitectura, dada la definición de sus

artefactos, permitiendo probarla y validarla, así como alinearla con los objetivos

del negocio y las restricciones, de esta forma facilitar el despliegue de una solu-

ción. Para validar esto y como parte de los resultado expuestos en este documento,

se desarrolló la herramienta de software llamada “Arieta”, donde los componen-

tes y las conexiones entre ellos son diseñados y desplegados en un ambiente de

producción. Esta herramienta fue diseñada para que a través del diseño de una

arquitectura, de sus componentes y conexiones entre ellos, se permita desplegar

una solución de DA, así como permitir modificar la arquitectura en producción

y asegurar los requerimientos del proyecto.

Arieta se desarrolló en un escenario donde un científico de datos genera un

modelo de solución, y éste junto a un arquitecto de software seleccionan las tecno-

logías necesarias para su ejecución, con estas se despliega la solución en produc-

ción, determinando si es el caso, restricciones de memoria y GPU para asegurar

los atributos de calidad requeridos. Toda esta ejecución se hace mediante la imple-

mentación de servicios que contiene las tecnologías requeridas para el despliegue

de la solución. Esta herramienta permite la orquestación de las tecnologías, así

como el despliegue de una solución de DA.

1.3 Objetivos

1.3.1. Objetivo general

Definir una solución basada en los conceptos de DevOps aplicada a modelos

de arquitectura analítica que permita mejorar el proceso de despliegue.

1.3.2. Objetivos específicos

Definir formalmente el concepto de ArchOps

Diseñar y desarrollar una herramienta que permita desplegar arquitecturas


de software mediante sus artefactos de diseño.

Permitir genera cambios en una arquitectura desplegada en ambiente de

producción.

Permitir desplegar de una solución analítica en ambiente de producción de

forma automática.

Dar a conocer con pares el resultado de esta investigación.

1.4 Estructura del Documento

El resto de este documento se muestra de la siguiente forma: El capitulo 2

muestra el contexto de esta tesis. En el capítulo 3 se describe la estrategia de

solución seguida para resolver el problema mencionado. En el capítulo 4 se define

la metodología usada para el despliegue de arquitecturas, el proceso de desarrollo

y las tecnologías usadas en la herramienta “Arieta”. En el capítulo 6 se muestra

el proceso de validación y análisis de resultados. El capítulo 7 se habla sobre los

trabajos relacionados a esta tesis y en el capítulo 8 se presentan las conclusiones

y el trabajo futuro de esta investigación.

8 1.4. Estructura del Documento

2Contexto

En este capítulo se introducen las principales definiciones utilizadas en el

documento, que son conceptos base para la realización de esta investigación.

2.1 Arquitectura de software

Bass et al. afirma que “la arquitectura de software de un programa o de un

sistema de computación, es la estructura o estructuras del sistema, las cuales

comprenden elementos de software, propiedades externamente visibles de dichos

elementos y las relaciones entre ellos”[3]. Una arquitectura es la abstracción de un

sistema que incluye relaciones entre sus componentes. Por otro lado, el diseño de

arquitectura afecta cada aspecto de sistema ya en esta es el conjunto de decisiones

de diseño que se debe hacer en etapas tempranas [12], al impactar cada aspecto

del sistema, el diseño debe ser cuidadoso, puesto que una mala elección puede

9

10 2.2. Vistas y puntos de vista de una arquitectura

restringir su aplicación en sistemas de gran escala [13, 14, 15].

Otros autores como Philippe Kruchten, reconocen el poder de una arquitectu-

ra a través de la estructuración y comportamiento, donde dice que “La arquitectu-

ra del software abarca el conjunto de decisiones importantes sobre la organización

de un sistema de software que incluye la selección de los elementos estructurales

y sus interfaces, mediante los cuales se compone el sistema; el comportamien-

to se especifica en la colaboración entre esos elementos; la composición de estos

elementos estructurales y conductuales en subsistemas más grandes; y un estilo

arquitectónico que guía a la organización”.

Por otro lado, diferentes autores afirman que “La arquitectura es el conjunto

de decisiones de diseño que se deben tomar al principio de un proyecto” en[12].En

otras palabras, una arquitectura se refiere a la estructura básica de un sistemas y

es por ende es un tema de gran atención y cuidado, ya que esta afecta de diferentes

maneras el comportamiento y las restricciones del sistema, los atributos de calidad

y los objetivos del negocio.

2.2 Vistas y puntos de vista de una arquitectura

En arquitectura de software existen dos conceptos comunes a través de las

múltiples definiciones de la misma: Vistas (View) y Puntos de vista (viewpoint),

los cuales fueron presentados en la publicación ISO/IEC/IEEE 42010:2011 Sys-

tems and software engineering architecture description [16].

Los Puntos de Vista hacen referencia a las convenciones para construir, inter-

pretar y usar las vistas de una arquitectura en un marco especifico del sistema.

Es decir, desde que punto de vista se van a interpretar dichas vistas del sistema.

Las Vistas del Sistema son la representación de todo un sistema y expresan

la arquitectura de éste desde un determinado punto de vista.

En la definición de estos artefactos, un arquitecto debe evitar condensar todas

las preguntas o definiciones de la arquitectura en un sólo modelo, con respecto

a esto Rozanski y Woods dicen que “No es posible capturar las características

funcionales y las propiedades de calidad de un sistema complejo en un solo mo-

Capítulo 2. Contexto 11

delo que sea comprensible y de valor para todos los interesados”. Por esto, ellos

presentan un catálogo de puntos de vista que se pueden usar para definir la

arquitectura, estos se pueden ver en la imagen 2.1.

Figura 2.1: Vistas de Rozanski y Woods

En el marco de esta investigación, para el desarrollo de la herramienta de

validación, se hace uso de la vista de despliegue, la cual describe el entorno en

el que se implementará el sistema, incluida la captura de las dependencias que el

sistema tiene en su entorno de tiempo de ejecución.

2.3 Arquitectura orientada a servicios - SOA

Las arquitecturas orientadas a servicios (SOA) por sus siglas en inglés Service

Oriented Architecture, se basan en servicios individuales, de funciones y procesos

del negocio específicos; como dice O’Brien et al. “Es un framework de aplicación

que toma las aplicaciones comerciales diarias y las divide en funciones y procesos

de negocios individuales, llamados servicios. SOA permite construir, desplegar

e integrar estos servicios independientemente de las aplicaciones y la platafor-

ma informática en la que se ejecutan” [17]. El propósito de SOA es simplificar

el funcionamiento y mantenimiento de aplicaciones monolíticas, dividiéndolas en

múltiples aplicaciones. SOA es una forma de diseñar, implementar y armar ser-

vicios que soportan o automatizan las funciones del negocio[18]. Por otro lado,

como ventajas de SOA, éste puede ser usado como punto de entrada único para

12 2.4. Micro-servicios

las fuentes de datos de la empresa, y donde los equipos IT sólo deben preocuparse

por la seguridad, el rendimiento y la confiabilidad de los servicios que se conectan

a la información de la empresa, en lugar de vigilar múltiples puntos de entrada

que podrían perjudicar la seguridad y generar problemas de rendimiento en el

futuro [19].

Para el desarrollo de nuestra herramienta de validación, utilizamos los con-

ceptos de SOA, ya que ésta nos permiten expresar cada funcionalidad del sistema

como un componente independiente, brindándonos una forma de estandarizar el

proceso de despliegue sin tener que afectar otros ya desplegados

2.4 Micro-servicios

“El estilo arquitectónico de micro-servicios, es un enfoque para desarrollar una

aplicación única como un conjunto de pequeños servicios, cada uno funcionando

en su propio proceso y comunicándose con mecanismos ligeros, a menudo una

API de recursos HTTP. Estos servicios se basan en las capacidades comerciales

y la maquinaria de despliegue automatizado por medios de despliegue indepen-

dientes. Existe un mínimo de gestión centralizada de estos servicios, que puede

escribirse en diferentes lenguajes de programación y utilizar diferentes tecnologías

de almacenamiento de datos” [20]. Este concepto extiende los principios de las

arquitecturas SOA y reduce la necesidad de coordinación explicita de los equipos.

Sin embargo, este tipo de arquitectura presenta mayores desafíos, ya que es ne-

cesario probar cada servicio individual y colectivamente, en donde un mal diseño

puede empeorar el desempeño, disponibilidad o mantenibilidad[21, 22].

La arquitectura de software es una construcción humana donde según Conn-

way “Cualquier organización que diseñe un sistema (definido en términos genera-

les) producirá un diseño cuya estructura es una copia de la estructura de comuni-

cación de la organización” [23]. Al igual que una organización, los microservicios

se crean según las capacidades del negocio y son tan variados como los diferentes

perfiles que se encuentran en una empresa, brindado diferentes tipos de atribu-

tos y fortalezas en la ejecución y desarrollo. En esta investigación, utilizamos el


concepto de micro-servicios para permitir el despliegue automatizo de servicios

dentro de la herramienta de validación y de la cual se hablara más adelante.

2.5 DevOps

DevOps es un acrónimo para desarrollo y operaciones, como puede verse en la

figura 2.2, Len Bas et al. define DevOps como “Un conjunto de prácticas enfocadas

a reducir el tiempo entre realizar un cambio en un sistema y que éste cambio se

aplique en producción, mientras se asegura alta calidad ”[21]. DevOps se centra

en el valor de la colaboración entre los equipos de desarrollo y operaciones en

todas las etapas del ciclo de vida de desarrollo para crear y operar un servicio,

mostrando la importancia de los dos en este proceso [24].

Figura 2.2: Interacciones en DevOps

A su vez, DevOps extiende los principios ágiles a la fase de entrega de un

software y al flujo de trabajo [25, 26], enfocándose en la colaboración e integración

de los equipos de trabajo, así como en la automatización de los procesos de entrega

y cambios en la infraestructura para facilitar o agilizar las pruebas y lanzamiento

de un producto.

Como ya hemos visto DevOps, Microservicios y SOA comprenden los mismos

principios, es decir, permitir a las empresas usar pequeñas piezas de software

en vez una gran aplicación monolítica, de modo que cada pieza sea manejable,

independiente en desarrollo, despliegue y paralelas entre sí, para permitir mayor

velocidad en desarrollo y adaptabilidad al cambio, siguiendo los principios ágiles.

14 2.6. Arquitecturas ejecutables

2.6 Arquitecturas ejecutables

“Una arquitecta ejecutable es una implementación del sistema, construida pa-

ra demostrar que la arquitectura diseñada soportará las funcionalidades claves,

y más aun, para exhibir las propiedades en términos de rendimiento, capacidad,

confiabilidad, escalabilidad y otras capacidades” [27]. Estas arquitecturas descri-

ben el sistema y permiten la generación automática o semi-automática de sus

artefactos, los cuales son usados para analizar, refinar o implementar la arquitec-

tura descrita.

Como se definió anteriormente, una arquitectura de software es el mapa del

sistema en donde se expresan las principales definiciones, relaciones, restricciones

y funcionalidades, entre otras, es la estructura en sí del sistema. En general un

arquitecto de software no puede desarrollar una arquitectura de software completa

o no tiene la experiencia para para convertir un modelo de arquitectura ejecutable

[28], sin embargo, la necesidad de evaluar las características y el comportamiento

de las descripciones de arquitectura para determinar su idoneidad en satisfacer las

necesidades de los usuarios, requiere pruebas que vayan más allá de las factibles

con sólo una representación estática [29, 30].

Dado que una arquitectura de software provee un entendimiento de diferentes

aspectos de un sistema como: estructura, comportamiento, despliegue y ambiente

de desarrollo, entre otros [31], cuando un arquitecto de software puede ejecutar

una arquitectura consigue[32, 27]:

Asegurar que las tecnologías y componentes planeados puedan ser testeados

en el escenario definido.

Hacer una identificación temprana de cuellos de botella.

Hacer pruebas de estrés para validar con los requerimientos del negocio.

Mantener actualizados los modelos de la arquitectura.


2.7 ArchOps

ArchOps es una extensión de DevOps para permitir el desarrollo de un sistema

funcional a través de sus artefactos de arquitectura. ArchOps al igual que DevOps,

siguen los principios ágiles y se enfocan en la colaboración entre las disciplinas,

mejorando las relaciones y coordinación entre actores.

ArchOps es una estrategia basada en arquitecturas orientada a servicios y

ejecutables, la cual reduce la brecha entre la arquitectura y la evolución del soft-

ware, y en nuestro caso para reducir el tiempo a producción de una arquitectura

diseñada con esta estrategia. Como se puede ver en la figura 2.3, el arquitecto

de software participa en el ciclo de vida de una aplicación y le da una completa

gobernabilidad en sus proyectos, lo que le permite validar y ajustar el modelo a

la solución real y a la necesidad del negocio [33].

Figura 2.3: Modelo ArchOps

2.8 Escenarios de calidad

Los atributos de calidad no funcionales, son aspecto de sistema que no afectan

directamente un funcionalidad y definen las características que el sistema debe

soportar. Desde la perspectiva de un arquitecto de software, las definiciones no

operacionales y las preocupaciones sobre atributos de calidad superpuestos deben

poderse validar por algún mecanismo, por lo cual se generaron los escenarios de

calidad.

Un escenario de calidad, es la especificación de los requerimientos de un atri-

16 2.8. Escenarios de calidad

buto de calidad no funcional [34]. Esta especificación se divide en seis partes como

se muestra en la figura 2.4, las cuales son:

Fuente de estímulo: Hace referencia al ente que genero el estimulo o propicia

el evento de evaluación

Estímulo: Es la condición que debe tenerse en cuanta cuando llega al siste-

ma.

Ambiente: Se refiere a las condiciones del sistema en las cuales se va a

evaluar el estimulo

Artefacto: Es el artefacto o artefactos que son afectados o estimulados. Este

puede ser el sistema completo o algunas partes del mismo.

Respuesta: Es la acción esperada o respuesta de los artefactos después de

ser afectados por el estimulo

Medida de respuesta: Se refiere a la medida con que se evalúa si el atributo

de calidad se cumple o no, cuando se produce la respuesta.

Figura 2.4: Escenario de calidad

Los escenarios de calidad se pueden dividir entre escenarios generales y especí-

ficos. Los generales son independientes de sistema y pueden aplicarse a cualquier

sistema. En contraste, los específicos se crean para para atributos de calidad con-

cretos bajo consideraciones particulares. Para el desarrollo de esta investigación

se utilizan escenarios de calidad específicos, centrados en los atributos de calidad

de tiempo de respuesta y modificabilidad.


2.9 Tácticas de diseño

Para cumplir con las especificaciones de un atributo de calidad, para este un

arquitecto de software utiliza diferentes técnicas arquitecturales, las cuales se lla-

maron “tácticas de diseño”[34]. Más concretamente, una táctica es una decisión

de diseño que especifica como lograr un atributo de calidad, estas afectan direc-

tamente la respuesta del sistema ante un estimulo y al igual que los patrones de

diseño, son técnicas de diseño que los arquitectos han estado utilizando durante

años.[34]

El uso de una táctica depende del contexto, es por esto que para esta in-

vestigación, dada la definición de un escenario de calidad, se aplican diferentes

tácticas para alcanzar los atributos de calidad requeridos.

2.10 Data Analytics

Existe una gran cantidad de datos hoy en dial almacenados en empresas,

universidades y gobiernos, entre otros, con diferentes estructuras y fuentes, pero

los datos sin un mecanismo para entenderlos y analizarlos no tienen valor, toda la

información almacenada sobre medicina, gustos, clientes, ciudadanos o desastres

es inútil sin extraer lo esencial al respecto. Por esto, se creo el concepto de Data

Analytics(DA), esta incluye una serie de metodologías, algoritmos y técnicas que

permiten analizar grandes cantidades de datos supervisados o no supervisados

para que sea comprensibles, válidos, novedosos y útiles [35]. Es una poderosa

herramienta que también permite clasificar, estimar, predecir, agrupar, describir

y perfilar datos para encontrar valor con un objetivo en particular o descubrir

estructuras, entre otras tareas [36].

DA permite tomar decisiones informadas a través de extraer conclusiones

sobre los datos, además permite a los científicos e investigadores verificar o refutar

modelos, teorías e hipótesis científicas [37].

El proceso de análisis comienza con la recopilación de datos, en la cual los

científicos de datos identifican la información que necesitan para una aplicación

18 2.11. Representación de modelos de solución analítica - PMML

de análisis en particular. Luego, trabajan solos o con los ingenieros de datos y el

personal de TI para armarla y usarla. Los datos de diferentes sistemas pueden

necesitar combinarse a través de rutinas de integración de datos, transformarse

en un formato común y cargarse en un sistema de análisis, como un clúster

Hadoop, una base de datos NoSQL o un depósito de datos. En otros casos, el

proceso de recopilación puede consistir en extraer un subconjunto relevante de

una secuencia de datos brutos que fluye, por ejemplo, en Hadoop y moverlo a una

partición separada en el sistema para que pueda analizarse sin afectar el conjunto

de datos general[37].

2.11 Representación de modelos de solución analítica -

PMML

Predictive Model Markup Language (PMML) “es el estándar líder para mo-

delos estadísticos y de minería de datos y cuenta con el respaldo de más de 20

proveedores y organizaciones. Con PMML, es fácil desarrollar un modelo en un

sistema usando una aplicación y desplegar el modelo en otro sistema usando otra

aplicación, simplemente mediante la transmisión de un archivo de configuración

XML”[38]. PMML es un estándar liderado por la industria para representar el

resultado de los algoritmos de minería de datos, con el objetivo de permitir que

una gran variedad de usuarios defina y comparta modelos predictivos utilizando

un estándar abierto como es el XML.

PMML se creó ante la necesidad de estandarizar el complejo mosaico de repre-

sentación de conocimientos producidas por la gran variedad de proveedores para

minería de datos, los cuales emplean diferentes modelos y métodos para expresar

el conocimiento adquirido o descubierto [8]. La generación de conocimiento no es

un fin en sí, y como resultado de estos diferentes enfoques para la representación

del conocimiento, los consumidores de conocimiento, como las herramientas de

puntuación en tiempo real, los motores de personalización, las herramientas de

marketing o de visualización, requieren una gran cantidad de recursos para su

integración. PMML tiene como objetivo proporcionar una representación están-


dar del conocimiento y los meta-datos asociados requeridos por un consumidor

de conocimiento. PMML proporciona los siguientes beneficios[8]:

Los problemas e incompatibilidades de propiedad ya no son una barrera

para el intercambio de modelos entre aplicaciones.

Los modelos se pueden generar utilizando cualquier proveedor de generador

de conocimiento y se pueden implementar utilizando cualquier consumidor.

La estructura de un documento PMML puede verse en la imagen 2.5, la cual

esta compuesta por una serie de etiquetas que encapsulan la representación de

un modelo de DA.

2.12 Contenedores

“Los contenedores de software son un paquete de elementos que permiten

ejecutar una aplicación determinada en cualquier sistema operativo.”[39]. El pro-

pósito de los contenedores es reducir el número de fallas de un código al cambiarlo

de un ambiente a otros, por ejemplo al pasar de ambiente de staging a producción,

siendo útiles y ágiles en el proceso de migración entre plataformas.

Los contenedores se asemejan a las tecnologías de virtualizacion, sin embargo,

la máquinas virtuales a diferencia de los contenedores, son una abstracción del

hardware físico e incluyen una copia completa de un sistema operativo, una o más

aplicaciones, binarios y bibliotecas necesarias, ocupando decenas de GB memoria

y haciendo que estas puedan tardar en arrancar una imagen[40]. En contraste,

los contenedores incluyen solo las librerías y elementos esenciales para ejecutar

el código que contienen, siendo rápidas de desplegar.

2.13 Docker

Docker es una plataforma de contenedores para ejecutar y administrar apli-

caciones junto con contenedores aislados, éste provee un capa adicional de abs-

tracción y automatización a nivel del sistema operativo en Linux. Docker utiliza

20 2.13. Docker

Figura 2.5: Estructura de un PMML

la característica de aislamiento de recursos del kernel de Linux para permitir que

contenedores independientes se ejecuten dentro de una sola instancia de Linux;

evitando la sobrecarga de arranque y el mantenimiento de máquinas virtuales.

Una imagen contenerizada es un paquete ligero, autónomo y ejecutable de una


pieza de software que incluye todo lo necesario para ejecutarlo: código, tiempo de

ejecución, herramientas del sistema, bibliotecas del sistema, configuración. Como

se ve en la figura 2.6, los contenedores son en realidad una abstracción en la capa

de aplicaciones que empaqueta código y dependencias entre sí. Este software

contenerizado siempre se ejecutará de la misma manera, independientemente del

entorno, mediante software aislado de su entorno.

Figura 2.6: Maquinas virtuales y representación de contenedores [1]

2.14 Kubernetes

Kubernetes(K8s) es un orquestador de contenedores a nivel de producción,

construido como un sistema de código abierto para aplicaciones de administración

en contenedores y que proporciona un mecanismo para automatizar la implemen-

tación, escalado y administración de aplicaciones en contenedores. Fue diseñado

por Google y donado a Cloud Native Computing Foundation (CNCF). Su objeti-

vo es proporcionar una “plataforma para automatizar la implementación, escalado

y operaciones de contenedores de aplicaciones en clusters”[41]. Es compatible con

una variedad de herramientas de contenerización, incluido Docker.

Para proporcionar el mecanismo de implementación y mantener el escala-

miento de imágenes contenerizadas, K8s define un conjunto de elementos básicos

o primitivas como:

Pods: Unidad de programación básica que agrega un alto nivel de abs-

22 2.14. Kubernetes

tracción a un componente contenerizado. Esto representa uno o más con-

tenedores ubicados conjuntamente en la misma máquina y que comparten

recursos. Cada pod tiene una dirección IP única y expone por puertos las

aplicaciones en contenedores.

Services: Conjunto de pod de trabajo compartido. Por defecto, un servicio

está expuesto dentro del clúster, pero se puede definir que esté expuesto

fuera de éste. K8s proporciona un servicio de descubrimiento, solicitud de

enrutamiento y equilibrio de carga(load balance) de tráfico para gestionar

las conexiones de red entre los pods dentro del servicio.

Como se puede ver en la figura 2.7, K8s sigue la arquitectura maestro-esclavo.

Los componentes de K8s se pueden dividir en aquellos que administran un nodo

individual y los que forman parte del plano de control. Los componentes de

administración se comunican con los componentes de los nodos y su carga de

trabajo, y dirigen la comunicación a través del sistema.

Figura 2.7: Diagrama de arquitectura de K8s [2]

Adicionalmente, K8s proporciona una interfaz web para consultar los datos

desplegados en el cluster como se muestra en la figura 2.8.


Figura 2.8: K8s dashboard

3Estrategia de solución

Teniendo en cuenta que el alto costo y transición propensa a errores entre el

laboratorio de datos y el ambiente de pruebas de un modelo de solución analítica,

en esta sección exponemos la estrategia seguida para alcanzar los objetivos pre-

sentados en el primer capítulo de este documento, así como la definición formal

de la estrategia basada en DevOps llamada ArchOps, el cual es un término acu-

ñado por profesionales de la Universidad de los Andes en previas investigaciones

[42, 43, 44] y para el cual se definen a continuación.

3.1 Conceptos fundamentales de ArchOps

En arquitecturas de software, los atributos de calidad de un sistema siempre

ha sido un tema de gran importancia para los arquitectos, es por esto que los

atributos de calidad son considerados en el momento del diseño, implementación

24

Capítulo 3. Estrategia de solución 25

y despliegue de un arquitectura y los cuales deben se evaluados a nivel de la

arquitectura. Sin embargo, el como lograrlos no siempre esta bien comprendido.

En este sentido los arquitectos utilizan diferentes tácticas para diseñar, como

dice Len Bass “Una táctica es una decisión de diseño que influye en el logro de

un atributo de calidad.”[34], estas permiten definir como configurar una arqui-

tectura de modo que se puedan alcanzar los atributos de calidad requeridos. No

obstante, cualquier diseño utiliza múltiples tácticas, donde es necesario compren-

der que atributos de calidad afectan y los efectos y riesgos que esta implican. Más

allá de esto, desde una arquitectura saber que estrategias fueron usadas para su

diseño puede ser de gran importancia para la modificación o creación de una

arquitectura.

Por otro lado, la documentación de una arquitectura es un tema que se ha

dejado de lado y el cual en muchas ocasiones se encuentra desactualizada con

respecto a la realidad de un sistema, generando toda una serie de problemas en su

comprensión [33]. Estos puntos hicieron necesaria la definición de una estrategia

que integre el aspecto arquitectónico en el proceso de desarrollo de tecnologías

en una empresa, la cual se llamo “ArchOps”.

La palabra ArchOps es una combinación de las palabras “Architecture” y

“Operational” y nace de la necesidad identificada de expandir los mismos princi-

pios que DevOps abarca hacia los arquitectos de software. Al igual que DevOps,

ArchOps es una práctica en la que se fomenta la colaboración entre las diferentes

disciplinas del desarrollo de software.

Como se mencionó brevemente en el contexto, ArchOps es una extensión

de DevOps y tiene las mismas raíces, es decir, son ramas de los principios del

desarrollo de software ágil.

En las palabras de los autores de este concepto, “ArchOps es una metodolo-

gía de desarrollo con un conjunto de prácticas destinadas a cerrar la brecha entre

arquitectura, desarrollo y operaciones, enfatizando en la comunicación y la cola-

boración, integración continua, garantía de calidad, entrega con implementación

automatizada y una actualización automática de artefactos de arquitectura de

software”[44].

26 3.1. Conceptos fundamentales de ArchOps

Al igual que en DevOps[45], ArchOps persigue los siguientes lineamientos:

Valores: ArchOps sigue los valores expresados en el “Manifiesto Ágil”[6]

enfocados tanto en la documentación como en el despliegue automático

de software y arquitectura, así como en la colaboración de los equipos de

desarrollo, operaciones y arquitectura.

Principios:ArchOps se basa en el termino definido por JohnWillis “CAMS”[46]

para DevOps . El principio de “automatización de la infraestructura” es uno

de los principios fundamentales de ArchOps donde a pesar de que existe

herramientas de gestión como Puppet o Chef que permiten la definición

de infraestructura como código y la automatización de la arquitectura; por

un lado se dejan descuidados los documentos de diseño de la arquitectura,

además no son conceptos fáciles de entender y que a través de ArchOps se

facilitan.

Metodología: El uso de metodologías ágiles como Scrum o Kanban es

esencial para seguir los principios ágiles, incluyendo en estos no solo desa-

rrollo y operaciones, sino también los arquitectos de software.

Practicas: Integración continua y despliegue continuo no solo aplicado

al desarrollo de software sino también a la arquitectura en si, así como

la utilización de administración de configuraciones, métricas y esquemas

de seguimiento, un enfoque de herramientas para herramientas aplicadas

también al contexto de los arquitectos de software.

ArchOps busca que a través de la automatización de la infraestructura se pue-

dan crear sistemas, configuraciones e implementaciones de sistemas por medio de

la definición de los artefactos de la arquitectura, permitiendo que estas defini-

ciones de la arquitectura (documentación) cambien y se mantengan actualizadas

con la evolución del sistema. Así mismo, ArchOps aplica el concepto de entrega

continua a una arquitectura, donde el crear, probar e implementar una arquitec-

tura se hace mediante la utilización del concepto de arquitecturas ejecutables y

en donde el diseño debe permitir el monitoreo y la orquestación de las tecnologías


al mismo tiempo que se mantiene del diseño de la arquitectura al día.

Para permitir automatización de la infraestructura, la entrega continua de

la misma y la actualización automática de los artefactos de la arquitectura, Ar-

chOps hace uso de tres conceptos fundamentales: Arquitecturas ejecutables, SOA

y Micro-servicios, en donde la intersección de estos conceptos nos brinda los li-

neamientos necesarios para entender y aplicar en concepto de ArchOps, siendo

necesario: Definir una arquitectura a través de una o múltiples vistas del sistema,

escenarios de calidad y tácticas de diseño, y permitir que dichas definiciones se

conviertan en ejecutable a través de las herramientas definidas para dicho pro-

pósito. Esto significa que una arquitectura se debe poder desplegar, cambiar y

monitorear a través de sus definiciones de diseño.

Siguiendo con los conceptos de ArchOps, en especial con lo referente a la

automatización, se recomienda que la orquestación de las tecnologías se deben

dejar a sistemas especializados para esto, es decir contenerizadores de aplicaciones

o tecnologías necesarias para el funcionamiento del negocio y de esta forma se

permite el aislamiento en funcionamiento y despliegue de las herramientas del

sistema.

3.1.1. Valores

ArchOps sigue los principios establecido en el manifiesto ágil[6] y con base a

esos creemos que:

Los artefactos de diseño de una arquitectura no deben ser solo documenta-

ción del sistema. Los artefactos mismo debe poder desplegar la arquitectura

que describen.

La definición de escenarios de calidad y sus tácticas de diseño deben tener

un impacto real sobre la arquitectura.

El diseño de la arquitectura debe ser fácilmente comprensible por quien lo

mire.

Una arquitectura debe ser configurable y modificable para alcanzar los atri-

butos de calidad del sistema.


Compartir del diseño de una arquitectura debe permitir la mejora de la

misma.

La comunicación entre equipos es esencial para un buen diseño de arqui-

tectura.

El uso de estándares comunes entre usuarios para compartir información

facilita el entendimiento entre las partes.

ArchOps se enfoca en mejorar la relación y la coordinación entre los tres

equipos de tecnología de una empresa: Arquitectura, desarrollo y operaciones,

facilitando el compartir información como es los escenarios de calidad y la do-

cumentación documentación del sistema(artefactos de diseño), permitiendo la

actualización del diseño de una arquitectura al emplear los conceptos de arqui-

tecturas ejecutables y micro-servicios. Por otro lado, ArchOps facilita la respuesta

al cambio, permitiendo crear, desplegar, modificar y eliminar servicios a deman-

da, al proponer el uso de aplicaciones contenerizadas y despliegues a través de

los artefactos de diseño de la misma.

3.1.2. Principios

Partiendo del principio de DevOps “Infraestructura como código”, en ArchOps

planteamos que es desde los artefactos de diseño de donde se debería definir,

desplegar y modificar una arquitectura, por lo cual adaptamos este principio,

siendo el siguiente la base misma de ArchOps:

Artefactos de diseño como infraestructura

Con esto queremos decir que la documentación misma de la arquitectura es

la estructura real del sistema y que a través de la cual se debe poder realizar

cambios que afectan el estado actual del sistema.

ArchOps se rige igualmente por los siguientes principios, como se muestra en

la imagen 3.1[46], en donde:

La Cultura en una organización debe poner a los individuos e iteraciones

entre estos, sobre los procesos y las herramientas del sistema, ya que es


así como se habilita la automatización de tareas y en especial la de una

arquitectura.

La Automatización se refiere a entrelazar procesos y herramientas, facili-

tando realizar acciones complejas o repetitivas. Las herramientas de manejo

de versiones, configuraciones, integración, monitoreo, control y orquestación

son piezas importantes en este contexto, no solo en desarrollo u operaciones,

sino también en el ámbito de la arquitectura.

La Medición es fundamentar para mejorar en múltiples sentidos. En una ar-

quitectura, tener métricas, entre otras, permiten ajustarla a las necesidades

reales del negocio y alcanzar los atributos de calidad definidos.

Compartir es inherente a la cultura y se promueve el compartir ideas, pro-

blemas, diseños, formas de realizar una tarea, solucionar un problema o dar

retroalimentación de un proceso, esto promueve la creación de conocimiento

y el mejoramiento continuo en diferentes aspectos.

Figura 3.1: CAMS

Consecuentemente con lo anterior, ArchOps sigue los principios ágiles adap-

tados para incluir en el proceso los arquitectos de software (ver apéndice 7.2), los

cuales incluyen los cuatro principios dados.


3.1.3. Metodología

Existen múltiples metodologías ágiles que pueden ser usadas con ArchOps

como Scrum, Kanban, XP, entre otras, siempre extendiendo la comunicación ente

desarrollo, operación y arquitectos. Los arquitectos en el proceso de planeación

y despliegue de soluciones, deben tener un papel activo, ya que es necesario que

estos tenga en cuenta los requerimientos funcionales y los no funcionales para el

diseño de la arquitectura y los cambios que sean necesarios aplicar para así lograr

que los atributos de calidad se cumpla en el sistema.

En este sentido, como se ve en la figura 3.2, un arquitecto debe entender los

atributos de calidad que requiere el sistema. Seguido a esto, debe diseñar las rela-

ciones y restricciones entre diferentes tecnologías requeridas. Dado que ArchOps

propone el uso de arquitecturas ejecutables y el uso de micro-servicios, el diseño

e interacciones de dichas tecnologías, al momento de desplegar el sistema, se vol-

verán ejecutables, teniendo siempre actualizado el diseño de la arquitectura; en

este aspecto, las tecnologías desarrolladas deberán estar contenerizadas para po-

derse ejecutar a través de los artefactos de diseño de la arquitectura. Finalmente,

deberá poderse probar la arquitectura, realizar mediciones, monitoreo o cambios

para garantizar los atributos de calidad. Puesto que ArchOps define el diseño de

la arquitectura como la misma solución que se despliega en el sistema, compartir

es inherente al sistema, ya que se facilita el acceso al diseño de la misma por

parte de cualquier actor del sistema, según las restricciones del mismo.

3.1.4. Practicas y herramientas

ArchOps al igual que DevOps comparten las siguientes practicas:

Configuración de autoservicio al permitir seleccionar, configurar y desplegar

tecnologías en el sistema sin la intervención de terceros o configuraciones

complejas.

Aprovisionamiento automatizado al delegar la asignación de recursos, ba-

lanceo de carga y escalabilidad, entre otros, a sistemas expertos.


Figura 3.2: Ciclo ArchOps para un arquitecto de software

Integración continua al contenerizar las tecnologías, puesto que permite al

arquitecto, a través de una interfaz del sistema, puede desplegar tecnologías,

relacionarlas y generar restricciones entre ellas al hacer uso de arquitecturas

tipo micro-servicios.

Entrega continua al facilitar el despliegue no solo de tecnologías, sino tam-

bién de la misma arquitectura.

Despliegue basado en escenarios de calidad brinda mayor control sobre la

arquitectura y facilita el cumplimiento de los atributos de calidad del sis-

tema.

ArchOps no especifica que herramientas se deben utilizar para su implemen-

tación, sin embargo dado que propone el uso de los artefactos de diseño como la

representación y ejecución de la arquitectura, es deseable disponer de una interfaz

que muestre vista de despliegue, asignación o funcional según sea definido. Por

otro lado, se debe permitir el monitoreo continuo de las tecnologías desplegadas

en el sistema, por lo que el uso de colas de mensajes para esto es ideal para su

implementación. Así mismo, el uso de diferentes roles para acceder a la configura-

ción de la arquitectura facilita compartir la información existente, la realización

de pruebas y tener control y seguridad sobre la arquitectura.

32 3.2. Proceso de solución

3.2 Proceso de solución

Para resolver el problema presentado y alcanzar los objetivos establecidos en

el primer capítulo, seguimos los pasos que se explicara a continuación.

Estrategia de despliegue automatizado:

Para solucionar nuestros problema expuesto, estudiamos las diferentes for-

mas de facilitar el proceso de implementación de una arquitectura y el

despliegue de una solución analítica. En este contexto, estamos de acuerdo

con Anand eat al. [8] que enfatiza que la representación de conocimiento

estandarizada y la implementación automatizada reduce el costo de inte-

gración con otras aplicaciones de TI las cuales constituyen el entorno de

TI de una empresa. Por esto, para poder implementar un despliegue auto-

matizado de una solución de DA, definimos que el uso del estándar PMML

como forma de comunicar una solución de DA a un arquitecto de software

era la mejor opción, ya que al ser un formato basado en XML, permite

ser consumido por gran variedad de aplicaciones [47] y reduce no solo los

problemas comunicativos, sino también el tiempo en aplicar un cambio a

un modelo desplegado en el sistema.

Para el despliegue de una solución analítica en formato PMML, estudiamos

diferentes metodologías de software y nos dimos cuenta de que las contri-

buciones de DevOps en términos de reducir el tiempo de salida al mercado

de una solución o sus cambios, tienen que ser teniendo en cuenta el dise-

ño de la arquitectura para evitar propensión a errores y menor eficiencia

para implementar una solución y cambios. Además, la arquitectura debe

permitir alcanzar los atributos de calidad y los requisitos para una solución

implementada, esto implica que la arquitectura debe estar en capacidad de

modificarse una vez desplegada en el ambiente de producción. Para resolver

esto, utilizamos la estrategia ArchOps, que facilita el despliegue de tecno-

logías al basarse en el uso de arquitecturas ejecutables y micro-servicios.

Estas características se aplican a la solución de nuestro problema, dándonos


flexibilidad y adaptabilidad, así como también nos permite automatizar la

implementación y generar cambios sobre la arquitectura en un entorno de

producción tiempo cercano al real.

Para el despliegue de la solución analítica, seguimos los lineamientos de

ArchOps con respecto al uso de micro-servicios. Este estilo de arquitectura

se adapta para automatizar la implementación de una solución de DA,

generando un servicio con dicha solución.

Alcance y definición de requerimientos funcionales: Para la estrategia de

validación, decidimos implementar una herramienta que nos permita la im-

plementación de una arquitectura mediante sus artefactos, así como per-

mitir el despliegue de un modelo de solución de DA. En esto, notamos que

en la industria en general hay tres conceptos bien conocidos: aplicaciones

web, API REST y micro-servicios. Todo esto relacionado con la capacidad

de aplicar cambios ágilmente, permitir la comunicación entre los servicios

y los cuales están alineados con la filosofía ArchOps para reducir el tiempo

de los costos de producción. También estudiamos las diferentes soluciones

propuestas en Archinotes [43] y ArchinotesX [33] que aportan una base para

nuestra solución.

En nuestro desarrollo de la herramienta participaron tres roles: Arquitecto

de software, desarrollador de software y científico de datos. Sin embargo,

los roles de arquitecto desarrollador fueron asumidos por la misma persona

debido a la restricción de tiempo y recursos. El papel del científico de datos

fue asumido por un experto en el modelado de soluciones de DA. Para

automatizar la implementación de una solución, decidimos utilizar servicios

como base, estos tienen una estructura de código que recibe parámetros para

instanciar una solución en el entorno de producción. Por otro lado, aun

cuando se habla del rol de un desarrollado, nuestro trabajo no se enfoca

en desarrollo de software, sino en el rol del arquitecto de software en el

contexto de DA con respecto al despliegue de una arquitectura a través de

sus artefactos de diseño.

34 3.2. Proceso de solución

Además, consideramos qué funciones más acordes con nuestro propósito

dadas las restricciones de tiempo y recursos. Esto nos da como resultado

que las operaciones relacionadas con la gestión del centro de datos y las

tecnologías implementadas, incluyendo las relacionadas con la asignación de

recursos y la administración de la implementación de la solución, aportan

valor a la solución y facilitan la gestión y el ajuste de las tecnologías por

parte del arquitecto de software a demanda del científico de datos.

Diseño de la arquitectura y tecnologías utilizadas:

En el capítulo 4 describimos todas las tecnologías utilizadas para implemen-

tar la herramienta de validación “Arieta”. Las tecnologías seleccionadas se

usaron previamente en otros proyectos, esto con el fin de evitar una curva

de aprendizaje en el proceso de desarrollo de la misma. Además, el propó-

sito de la implementación no es aprender nuevas tecnologías, sino generar

una herramienta para validar el uso de la estrategia de ArchOps para des-

plegar una arquitectura de software aplicada al contexto de DA y permitir

el despliegue automatizado de una solución de DA.

Desarrollo de la herramienta de validación Arieta:

Para el desarrollo de la herramienta de validación Arieta, se utilizó una

metodología ágil en compañía de un científico de datos en el proceso de

implementación de una solución. Además, la arquitectura Arieta sigue el

patrón de micro-servicios como se plantea en la metodología ArchOps; el

desarrollo de la misma inicio en julio de 2017. Como estrategia para su

desarrollo se utilizó GitHub para la gestión de versiones y compartir re-

sultados, también se utilizó una plataforma de orquestación en la cual se

tienen conocimientos previos para facilitar su ejecución.

Validación: El Capítulo 5 describe el proceso seguido para verificar la ido-

neidad de la solución planteada para la hipótesis y los problemas menciona-

dos, los cuales se realizaron en base a la definición de escenarios de calidad

y tácticas de despliegue.


Resultados y análisis: Finalmente recolectamos los resultados obtenidos del

proceso de validación y los analizamos. El Capítulo 5 también contiene

parte de este análisis.

La herramienta Arieta, tiene como objetivo principal implementar y probar

el concepto de arquitectura ejecutable y aplicar la estrategia de ArchOps en el

contexto de DA para facilitar la implementación de la arquitectura y la solución.

3.3 Estrategia de solución: Despliegue automático, una

estrategia ArchOps

Para la solución de nuestro problema, seguimos las estrategia que muestra al

figura 3.3, en la cual tomamos como base tres artefactos de diseño:

Escenarios de calidad

Tácticas de despliegue

Solución Analítica - PMML

Figura 3.3: Estrategia de solución

Teniendo una solución analítica en formato PMML, los escenarios de cali-

dad nos proporcionan las medidas de calidad para evaluar el despliegue de una

solución en el sistema, por otro lado las tácticas de diseño nos brinda las especifi-

caciones de como desplegar dicha solución de modo que se cumplan los atributos

36 3.3. Estrategia de solución: Despliegue automático, una estrategia ArchOps

de calidad especificados en los escenarios de calidad. Estos tres componentes son

utilizados por la herramienta de validación Arieta, la cual se comunica con un

clúster para desplegar mediante servicios la solución analítica, y para la cual se

especifica su diseño e implementación más adelante.

Más concretamente, cuando un científico de datos genera una solución DA,

esta debe implementarse en un entorno de producción, lo cual genera una serie de

interacción entre el arquitecto de software y el científico de datos para diseñar la

arquitectura de software necesaria para el despliegue exitoso de la solución. Por

otro lado, para hacer cambios rápidamente en la arquitectura, es necesario crear

un flujo de trabajo continuo entre estos actores. Haciendo uso de la estrategia

ArchOps, se genero un servicio que consume una solución PMML y a través de

las herramientas provistas por Arieta, se despliega dicho servicio mediante la

definición de sus artefactos de diseño. Este proceso de despliegue automatizado

reduce el tiempo de salida a producción de una solución de DA.

Al aplicar la estrategia ArchOps y las tácticas de diseño, se proporcionar un

entorno en el que el arquitecto de software puede modificar la arquitectura de

modo que cumpla con los escenarios de calidad. El uso de esta estrategia da dos

valores adicionales: Primero, el modelo y las definiciones de la arquitectura de

software evolucionarán con el ciclo de vida del proyecto, esto es debido a que

el modelo de arquitectura de software no es solo una abstracción, sino que es,

de hecho, la solución. Segundo, el definir y asociar las tácticas a un escenario

de calidad, nos permite aproximarnos mejor a los requerimientos del sistema,

generando cambios en la misma arquitectura para satisfacer las necesidades del

del negocio.

Dado que nuestra meta es cumplir con los objetivos planteados en el primer

capitulo y validar nuestras afirmaciones mediante el desarrollo de la herramienta

de validación Arieta, seguimos principios fundamentales de ArchOps y se diseñó la

solución con base en las arquitecturas de micro-servicios. En este sentido, Arieta

se compone de los siguientes cuatro componentes:

Interfaz web - cliente web: Expone gráficamente el estado del sistema y


permite realizar cambios en la arquitectura actual del sistema. A través

de esta, se pueden definir las tácticas a emplear para alcanzar lo atributos

de calidad y modificar el sistema a través de la vista de despliegue. Todo

ajuste hecho a través del cliente web, alterará realmente el estado actual de

la arquitectura y sus artefactos desplegados. Este cliente se comunica con

la API de Arieta para generar los cambios requeridos en la arquitectura.

API REST: Es responsable de crear, actualizar y eliminar servicios, así

como generar la conexión entre ellos. Esto tiene una relación profunda con

el clúster para realizar dichas acciones.

Clúster: Está diseñado para automatizar la implementación, escalado y ope-

ración de la tecnologías contenerizadas. Además, permita destinar recursos

a cada contenedor según sea necesario. Este es el centro de datos en sí

mismo.

Servicio de notificaciones: Brinda la capacidad de monitorear el estado del

sistema y de cada servicio desplegado.

Finalmente, todo esto para alcanzar nuestro objetivo principal: implementar

y actualizar una arquitectura a través de sus definiciones de artefactos.

4Implementación de la herramienta de

validación: Arieta

Para la implementación de la herramienta, investigamos enfoques anterior co-

mo son Achinotes [42] y ArchinotesX [33], que también se centran en arquitecturas

ejecutables y arquitectura colaborativas. Estas tienen como objetivo facilitar el

proceso de diseño de arquitectura de software para metodologías de desarrollo

de software ágil y distribuido. Estas investigaciones nos dieron una base para

enfrentar los problemas descritos en este documento.

Con esta herramienta, buscamos implementar una arquitectura ejecutable

usando sus definiciones de artefactos y generar cambios en sistema en tiempo

cercano al real, así como facilitar el despliegue de una solución de DA para reducir

el tiempo a producción.

38

Capítulo 4. Implementación de la herramienta de validación: Arieta 39

4.1 Arquitectura

Nuestra implementación sigue el patrón de la arquitectura de micro-servicio,

como se muestra en la figura 4.1, donde cada servicio implementa una funcio-

nalidad completa, ejecuta su propio proceso y se despliega independientemente.

Con esta premisa, Arieta está compuesta por cuatro módulos principales: Interfaz

Web o cliente web, API REST, clúster y Servicio de notificaciones.

Figura 4.1: Arieta: Arquitectura

El API REST es una Interfaz de programación de aplicaciones (API) de

transferencia de estado representacional (REST) que contiene el conjunto de fun-

ciones o métodos disponibles para interactuar con el clúster, este es utilizado por

el Cliente Web para comunicarse con el clúster. El API expone puntos finales(end-

points) de acceso que permiten crear, actualizar o destruir servicios en el clúster,

así como obtener información del sistema o de los servicios desplegados. Cada vez

que se llama un end-point, este envía una instrucción al clúster para completar

una acción. Por ejemplo, el end-point GET /v1/services envía una instrucción al

clúster para recuperar la información todos los servicios desplegados, el clúster

responde a el API con la información de los servicios actuales. El API también

genera una conexión entre los estados de los servicios en el clúster con el servicio

de notificaciones para comunicar el estado de los servicios; esto nos permite hacer

un seguimiento de cada servicio y de del clúster en sí.

40 4.2. Implementación

El Cliente Web es responsable de mostrar el estado actual de la arquitectura y

los servicios desplegados con sus estados. Esta comunica a través del API REST

las acciones necesaria para aplicar el clúster como crear, editar o eliminar un

servicio. La interfaz web expone dos perspectivas del sistema: Las tácticas de

un escenario de calidad y la vista de despliegue. A través de un escenario de

calidad se definen los criterio mismo de un determinado atributo de calidad y

asociado a este se definen las tácticas relacionadas para alcanzar dicho atributo de

calidad. Con estas definiciones es posible configurar el sistema para que siga dicha

táctica. A través de la vista de despliegue se permite crear recursos(imágenes de

servicios o tecnologías dockerizadas), generar diversas configuraciones entre estos

y conexiones, para luego desplegarlos en el sistema.

El clúster utiliza Kubernetes (K8s) para automatizar despliegue, escalar y

manejar contenedores. Este se encarga de manejar todo el hardware de la in-

fraestructura de la compañía y gestionará la asignación de recursos. El clúster

realmente contiene las aplicaciones implementadas y permite asignar recursos se-

gún se soliciten. En nuestra implementación, se utilizan aplicaciones dockerizada

(servicios) para permitir realizar el despliegue de tecnologías.

El servicio de notificación utilizan el servicio de colas de apache Kafka para

exponer todo el estado de los servicios y del clúster. En este servicio se crean un

tema o cola de mensajes global, en el cual se envían todas las actividad y estados

del clúster y servicios desplegados.

4.2 Implementación

4.2.1. API

Este es el núcleo de nuestra herramienta de validación, el API es un servicio

que hace de puente entre el cliente web y el clúster. Para este servicio, nos cen-

tramos en las actividades principales de crear, editar y destruir un servicio. Una

especificación completa del API se puede ver en el apéndice 7.2.

Las acciones de crear y actualizar, recibe como parámetro un archivo Json con

las especificaciones de un servicio. Este archivo está compuesto como un array de


hashes, en donde cada hash contiene la especificación del servicio; en el apéndice

7.2 se puede ver un ejemplo de la configuración de un servicio en formato JSon.

Cada una de estas especificaciones de servicio debe incluir el nombre de la

imagen de la tecnología o aplicación dockerizada, así como la tecnología utilizada

por otro lado, si hay una conexión con otro servicio, debe indicar el nombre o

la ruta del servicio. A través de esta configuración, también se puede definir las

características del contenedor, que determina las propiedades del contenedor que

ejecuta el servicio, esto incluye el uso mínimo y máximo de memoria y CPU,

entre otros.

El API, también expone la lista de servicios desplegados y los end-points para

crear, editar y eliminar servicios. Cada registro de un servicio contiene el nombre

que se muestra, el nombre de la imagen dockerizada y la versión de la imagen.

Estas imágenes se utilizan para desplegar los servicios en el clúster.

Otra función importante para Arieta son los estados de servicios. La API

a través de comandos se comunica con el servidor de notificaciones. Cuando el

API se inicializa, crea si es necesario, un tema o tópico principal en el servicio

de notificaciones y comunica cada acción realizada en el clúster a este. Además,

cuando se implementa un servicio, la API crea un hilo conectado con el clúster

para recuperar cada estado generado por la ejecución del servicio y se envían al

servicio de notificación. Con la información enviada al servidor de notificaciones,

el cliente web puede consumir el estado actual del sistema. Una representación

del flujo de trabajo de este proceso puede verse en la figura 4.2

Para el desarrollo del API se uso el legunage de programacion Ruby y las

siguientes gemas para facilitar el desarrollo

Rake: Es una herramienta de administración de tareas de software y auto-

matización de compilación. Permite al usuario especificar tareas y describir

dependencias, así como agrupar tareas en un espacio de nombres.

Sryro: Es un enrutador para desarrollo web, este ofrece una API muy simple

y escalable que fomenta la modularidad y hace que sea fácil crear aplica-

ciones grandes y pequeñas sin sacrificar la capacidad de mantenimiento.


Figura 4.2: Flujo de despliegue

Ruby-kafka: Es una librería de Ruby para Apache Kafka. El enfoque de

esta librería es la simplicidad operacional, con buen registro y métricas que

pueden facilitar los problemas de depuración.

Además, se utilizó git como sistema de control de versiones para el seguimiento

de cambios; todo esto fue almacenado en el servicio provisto por Github. En la

imagen 4.3 se presenta una vista completa de las tecnologías utilizadas.

Servicios dockerizados

Todos las tecnologías utilizadas son imágenes dockerizadas de las mismas, las

cuales se almacenan en el servicio en la nube de DockerHub. Los servicios usados

para la validación se muestran a continuación.

Servicio de OpenScoring: Aplicación desarrollada por un tercero que faci-

litar la evaluación de una solución de DA, el cual es una aplicación REST para

ejecutar modelos PMML usando JPMML-Evaluator de java para la evaluación de

modelos [48]. En la imagen 4.4 se pueden ver las tecnologías que usa este servicio.

OpenScoring recibe y almacena un modelo en disco y a través de su API se

envían los datos al modelo para evaluar, ya sean individuales, por bloques o en

formato csv. Puesto que el objetivo de Arieta es permitir el despliegue de una

solución de DA, se eligió esta aplicación por su diseño y la facilidad para evaluar


Figura 4.3: Tecnologías utilizadas

datos a través de un archivo PMML.

send-pmml-service: Servicio tipo Web Server desarrollado en Ruby para

la validación de la solución, el cual mediante parámetros recibe un modelo de

analítica y se lo envía a un servicio tipo OpenScoring para ser almacenado y

posteriormente usado para el análisis de datos.

kafka-to-analytic-service: Servicio desarrollado en Ruby para la validación

de la solución, el cual mediante variables de entorno se consume un tópico de una

cola de kafka y envía los datos a un servicio definido, los cuales pueden ser un

servicio tipo OpenScoring o un servicio para base de datos

mongodb-service: Servicio tipo Web Server desarrollado en Ruby para la

validación de la solución, el cual mediante parámetros recibe datos en formato

JSon para posteriormente ser almacenados en una base de datos MongoDB defini-

da mediante variables de entorno. Este servicio almacena en la colección definida

mediante parámetros, los datos recibidos. Por ejemplo al realizar un POST sobre

/collectionName, el sistema almacena en la colección “collectionName” dos datos


Figura 4.4: Servicio OpenScoring

suministrados.

4.2.2. Cliente Web

A través del cliente web, los arquitectos de software y los científicos de da-

tos pueden interactuar con el clúster y los servicios desplegados. El cliente web

muestra los artefactos de la arquitectura existentes, permite actualizarlo, agregar

nuevos servicios dockerizados y desplegarlos en el clúster. Adicionalmente, a tra-

vés de cliente web se pueden crear escenarios de calidad y las tácticas relacionadas

con estos. En la figura 4.5 se puede ver la vista de despliegue del sistema, adi-

cionalmente en el apéndice 7.2 se pueden observar todas las capturas de pantalla

del sistema.

El cliente web se conecta con la API a través de sus end-points para realizar

actividades como crear, actualizar o destruir servicios. También el cliente web se

conecta con los servicios de notificación para consumir los diferentes estados del

clúster y los servicios.

Al visualizar los estados de los servicios desplegados, los arquitectos de softwa-

re y los científicos de datos pueden actualizar los atributos de los contenedores de

servicios para mejorar el rendimiento de una solución asociados con los escenarios

de calidad y las tácticas definidas.

El cliente web permite adicionar un recurso para el sistema a partir de una

imagen docker, marcar un servicio para deplegarlo en producción y configurar di-

cho recurso con diferentes aspectos como variables de entorno, relaciones o punto

salida de datos. Una vez configurado un recurso, este se puede desplegar en pro-

ducción. Adicionalmente, el cliente web permite visualizar lo que está ocurriendo


Figura 4.5: Vista de despliegue del sistema

en cada instante en el clúster, los logs de los servicios y el estado actual de estos.

El proceso de visualización hace uso de web sockets para tener una comunica-

ción constante con el servidor de notificaciones, y haciendo uso de JQuery, se

despliegan dichas notificaciones en la interfaz web.

El cliente web fue implementado usando el framework de desarrollo ágil Ruby

on Rails, así como JQuery para manejar javascript, Boostrap para el estilo de la

aplicación y múltiples gemas que manejan el sistema de logueo o la conexión al

servicio de notificaciones, entre otras. La información de estos recursos y servicios

se almacena en una base de datos SQLite.

4.2.3. Servicio de notificaciones

Nuestro servicio de notificación usa la plataforma de transmisión distribuida

Kafka. Esta se trata de una plataforma de código abierto desarrollada por la


Fundación Apache, escrita en Scala y Java, y se utiliza para crear y canalizar

datos en tiempo real. La imagen 4.6 muestra el funcionamiento de un servicio

de Kafka, donde aplicaciones llamadas productores, producen y envían datos a

una cola o tópico especifico, los cuales son consumidos posteriormente por otras

aplicaciones llamadas consumidores. Kafka también almacena flujos de datos de

manera segura en un clúster [49] de forma distribuida, replicada y tolerante a

fallas.

Figura 4.6: Kafka: Arquitectura

Como mencionamos anteriormente, nuestro API se conecta con el sistema

de notificaciones, donde están almacenados todos los estados de las aplicaciones

dockerizadas, así como del estado mismo del clúster.

El tópico general de proyecto incluye información de cuando se crean, editan

o eliminan servicios, así como los proceso que se corren dentro de ellos. Por otro

lado, en el API crea un hilo individual por cada servicio desplegado, donde este

envía la información un tópico general para tener un continuo seguimiento del

proceso de ejecución de los servicios.

En terminología de Kafka, nuestro API es un productor de información y el

cliente web es el consumidor de dicha información. El uso de Kafka, nos permite

mostrar en tiempo cercano al real el estado del cluster y de los servicios.


4.2.4. Clúster

Como definimos anteriormente, K8s es un sistema para la administración de

aplicaciones en contenedores y el cual es usado como administrador del cluster.

Para comunicarse con K8s hay dos formas: a través de la API de K8s o mediante

la herramienta de línea de comandos “Kubectl”, la cual usa nuestra herramienta

de validación.

K8s contiene un API REST el cual es la estructura fundamental de este,

donde todas las operaciones y comunicaciones entre componentes y llamados

al API REST son manejados por el Servidor API, incluidos los comandos de

usuario externos. En consecuencia, todo en la plataforma K8s se trata como un

objeto API y tiene una entrada correspondiente en el API [41]. Por otro lado, las

herramientas de línea de comandos realizan casi la misma acción que la API.

Nuestra API se comunica con K8s por la línea de comandos del cliente Ku-

bectl, dada la facilidad que brindan las herramientas de línea de comando y

evitando así implementaciones adicionales para manejar el API de K8s, como

implementar las llamadas al API, solicitudes y respuestas.

El uso de K8 brinda las siguientes características, las cuales están alineadas

con el propósito de la implementación de la herramienta Arieta.

Escalamiento a nivel global: Diseñado con los mismos principios que

permiten a Google ejecutar miles de millones de contenedores a la semana,

K8s pueden escalar sin aumentar su equipo de operaciones. K8s permiten

escalar la aplicación hacia arriba y hacia abajo con un simple comando, con

una UI o automáticamente en función del uso de la CPU.

Binpacking automático: Coloca automáticamente los contenedores se-

gún sus requerimientos de recursos y otras restricciones, sin sacrificar la

disponibilidad. Mezcla cargas de trabajo críticas y mejora el esfuerzo para

aumentar la utilización y el ahorro de recursos. Cuando se especifica un Pod,

puede especificar opcionalmente la cantidad de CPU y memoria (RAM) que

necesita cada contenedor. Cuando los contenedores tienen solicitudes de re-

cursos específicos, el planificador puede tomar mejores decisiones sobre los


nodos en los que colocar los Pods. Y cuando se especifican los límites en los

Contenedores, la contención de los recursos en un nodo se puede manejar

de una manera específica.

Servicio de descubrimiento y balanceo de carga: No es necesario

modificar la aplicación para usar un mecanismo de descubrimiento de ser-

vicios. K8s da a los contenedores sus propias direcciones IP y un único

nombre DNS para un conjunto de contenedores, y puede equilibrar la carga

entre ellos.

5Validación

Con el objetivo de exponer las evidencias de que la herramienta desarrollada

puede ser utilizado para resolver problemas reales [50] y siguiendo consecuen-

temente los lineamientos planteados en Disign Science Research (DSC)[51, 52]

el artefacto de validación Arieta, fue evaluado mediante experimentación con

la participación de un arquitecto de software experto en la implementación de

soluciones para DA.

5.1 Experimentación

El objetivo de esta validación es determinar si la herramienta para la valida-

ción Arieta, permite el despliegue automático de modelos de solución analítica

en formato PMML según los objetivos definidos, se planteo la experimentación

del artefacto de validación mediante el despliegue de una solución de BDA en

49

50 5.1. Experimentación

presencia de un experto en el tema. Con la ayuda de un científico de datos, se

genero un modelo de solución de DA de un árbol de regresión en formato PMML,

el cual predice el retardo en una ruta en una ventana de tiempo especifica con

una precisión de R cuadrado de 0.71, sobre los datos del transporte público de

la ciudad de Vancouver - Canadá. Se descargaron para la pruebas un total 74959

registros, los cuales se descargaron en formato protobuffer a través del API del

servicio de datos Translink [53] y convertidos a formato CSV para su procesa-

miento. Por otro lado, el modelo y los datos usados para la validación pueden ser

consultados en https://github.com/judaro13/arieta-validation

La experimentación con la herramienta de validación se llevo a cabo en un

servidor Linux y se realizó con base a dos escenarios de calidad y tácticas de

diseño que se muestran a continuación.

5.1.1. Escenario de calidad 1: Despliegue de una solución analí-

tica

Para la prueba de este escenario se tomo el modelo de solución analítica

diseñado por un científico de datos perteneciente a la Universidad de los Andes,

y se procedió de la siguiente manera para la experimentación:

Se realizo la configuración servidor Kafka independiente de la herramienta

de validación, con retención de 5 segundos por cada tópico.

Se creo de Script para enviar datos al servidor Kafka cada 5 segundos.

Se configuro y desplegó los servicios necesarios según el escenario de calidad

a probar.

Se puso en ejecución el Script para enviar datos para iniciar la prueba del

escenario de calidad.

Con base en el atributo de calidad sobre el tiempo de ejecución, el despliegue

de una solución analítica a partir de su modelo de solución en formato PMML

debe darse en el menor tiempo posible a través de las herramientas diseñadas. El

despliegue incluye la creación de los servicios de conexión. El despliegue debe ser


Capítulo 5. Validación 51

Figura 5.1: Esquema de la validación

funcional, siguiendo el flujo de información como se muestra en la imagen 5.1, en

donde un servidor Kafka encola en uno o varios tópicos los datos de la experimen-

tación, posteriormente un servicio de analítica lee y evalúa esta información, por

ultimo los resultados generados son almacenados en una base datos MongoDB.

t

Fuente Científico de datosEstimulo Nueva solución de analítica (PMML)

AmbienteArieta tool con recursos creados, serviciodesplegado de "send-pmml-service", servidor Kafkay MongoDB disponibles

Componente Servicio de analítica

Respuesta Un servicio de analítica deberádesplegarse con el nuevo modelo de provisto

Medida dela respuesta

El despliegue no debe tomar el menor tiempo posibleen realizarse. El tiempo de procesamiento de un batchde 1000 datos debe ser inferior a 1500ms

Cuadro 5.1: Escenario de calidad 1

Para validar este escenario de calidad se aplicaron dos tácticas de despliegue

las cuales se muestran a continuación

Táctica de despliegue 3 a 1

Esta táctica especifica el despliegue de tres servicios de analítica conectados a

un servidor Kafka. El despliegue de esta táctica se puede visualizar en la imagen

5.2. Adicionalmente, en la imagen 5.3 se muestra la composición del servicio de

analítica, donde finalmente queda guardado el modelo de analítica a utilizar.

Para esta táctica, se utilizo el 13.3% de los datos descargados, los cuales fueron

enviados a tres tópicos diferentes a un servidor Kafka. Para esta táctica, se crearon

tres servicios “kafka-to-analytic”( ver sección 4.2.1 sobre “servicios dockerizados”


Figura 5.2: Táctica de despliegue 3 a 1

para más información sobre los servicios implementados) cada uno ligado a un

tópico diferente, a su vez, se crearon tres servicios de analítica conectados cada

uno con un único servicio de “kafka-to-analytic”. Cada servicio “kafka-to-analytic”

se encarga de leer un tópico especifico y enviar la información para ser analizada

con su respectivo servicio de analítica. Los resultados obtenidos del análisis, son

enviados a un servicio “mongodb-service”, el cual finalmente persiste los datos en

un servidor de base de datos MongoDB

Las pruebas realizadas con esta táctica indican que:

El tiempo promedio en configurar y desplegar la arquitectura según la tác-

tica 3 servicios de analítica a 1 un servidor Kafka, es de alrededor de 25

minutos.

El tiempo promedio de procesamiento de un batch de 1000 datos es de

1785ms. Esto se dio debido a al uso un único servicio para persistir los

datos, lo cual genero un cuello de botella en este punto. Para mejorar la


Figura 5.3: Servicio de analítica

táctica, se puede plantear escalamiento del servicio de persistencia.

El tiempo de despliegue total de la solución se incrementa linealmente según

el número de configuración que deban realizarse en los servicios.

El diseño tipo micro-servicios y ejecutable de la arquitectura, facilita el

escalamiento lineal y vertical de una estrategia.

El tiempo de procesamiento por cada test ejecutado en esta táctica se puede

visualizar en la figura 5.4. En donde muestra que la primera ejecución toma mayor

tiempo en realizarse al ser la primera vez en utilizarse el modelo, posteriormente

se puede ver que el tiempo de ejecución de las demás pruebas es relativamente

similar.

Táctica de despliegue 1 a 1

Esta táctica especifica el despliegue de un único servicio de analítica conectado

a un servidor Kafka. Dada la implementación de nuestros servicios, los servicios

necesarios para ejecutar esta táctica y el flujo de información de la misma, se

muestra en la imagen 5.5

Para realizar las pruebas de procesamiento se utilizo el 13.34% de los datos

descargados, para un total de 10000 datos, los cuales fueron enviado a un único

topico en un servidor Kafka. Nuestro servicio puente “kafka-to-analytic” consume

el tópico especifico donde se envían los datos de transporte, este envía a un servicio

de analítica provisto por OpenScoring, los datos para su análisis. Los resultados


Figura 5.4: Resultados de la táctica 3 a 1

obtenidos del servicio de analítica son tomados por el servicio “kafka-to-analytic”

y enviados a un servicio de base de datos llamado “mongodb-service”, el cual es

el encargado de enviar los resultados a un servidor de base de datos en MongoDB

para su persistencia

Las pruebas realizadas indican que:

El tiempo de despliegue de una imagen nueva (anteriormente no desplegada

en el clúster) toma un tiempo de despliegue variable ya que depende del

tamaño de la imagen a descargar y desplegar.

El tiempo de despliegue de un servicio de analítica basado en OpenScoring

ejecutado en ocasiones anteriores, toma un tiempo de despliegue promedio

de 2100ms.

El tiempo de despliegue de los servicios “kafka-to-analytics” y “mongodb-

service” son inferiores a 1 minuto cada uno.

El tiempo de configuración del servicio de analítica desplegado, es decir, la

asignación del modelo de analítica, toma en promedio 3 minuto.


Figura 5.5: Táctica de despliegue 1 a 1

El tiempo promedio en configurar y desplegar la arquitectura según la tác-

tica 1 a 1 es de 10 minutos.

El tiempo de ejecución de un batch de 1000 datos toma en promedio 1328ms,

satisfaciendo en procesar.

El tiempo de procesamiento por el test ejecutado en esta táctica se puede

visualizar en la figura 5.6. En donde similar a la táctica 3 a 1, la primera ejecución

toma mayor tiempo en realizarse y consecuentemente el tiempo de ejecución de

las demás pruebas es relativamente similar.

5.1.2. Escenario de calidad 2: Flexibilidad de los artefactos de

analítica

Para la prueba de este escenario se tomaron diferentes modelos de solución

analíticas de la pagina del DMG[38], y se realizo la experimentación según los

pasos de configuración seguidos en el primer escenario de calidad.


Figura 5.6: Resultados de la táctica 1 a 1

En este escenario, se busca permitir el cambio de un modelo de solución

analítica en un servicio de analítica previamente desplegado en el sistema. A

continuación se muestra la descripción detallada de este escenario.

Fuente Científico de datosEstimulo Cambio en una solución de analítica (PMML)

Ambiente Arieta tool, con los recursos creados, servicio desplegadosde analítica y "send-pmml-service"

Componente Servicio de analíticaRespuesta Cambio del modelo de un servicio de analítica

Medida dela respuesta

El servicio debe seguir en funcionamientoen la misma dirección asignada por el sistema.El cambio de un modelo no debe afectar elfuncionamiento del sistema y debe realizarse en menosde 10 segundos

Cuadro 5.2: Escenario de calidad 2

Para este escenario se realizaron en total 5 pruebas con diferentes modelos

analíticos sobre clustering, redes neuronales, regresiones y arboles. Estos modelos

pueden ser consultados en: https://github.com/judaro13/arieta-validation

Las pruebas realizadas para este escenario, con la configuración del sistema

como se muestra en la imagen 5.5 indican que:



Realizar un cambio de modelo a través del servicio de “send-pmml-service”

tiene una duración promedio de 9.3 segundos sin incluir los tiempos de

configuración, lo cual puede ser visualizada en la imagen 5.7.

Es necesario detener el servicio de “kafka-to-analytic” para evitar errores en

el flujo de los datos a evaluar.

Figura 5.7: Resultados de actualizar un modelo analítico

5.1.3. Resultados

Es posible desplegar un modelo de solución de DA usando el concepto

descrito en ArchOps.

El uso de escenarios de calidad y tácticas de despliegue permiten la im-

plementación de diferentes esquemas para el despliegue de una solución de

DA, así como la validación de los mismo.

El uso del cliente web de la herramienta de validación, permite visualizar

errores como son los cuellos de botella en el sistemas de forma ágil.

Dado el funcionamiento actual de los servicios del sistema, el tiempo de

configuración de los mismo es directamente proporcional al número de con-

figuraciones por realizarse.


Dado que cada servicio de analítica contiene un modelo de solución, la

actualización de dicho modelo se puede realizar en tiempos inferiores a tres

minutos sin necesidad de hacer desarrollos o implementaciones adicionales.

La comunicación entre arquitectos de software y científicos de datos mejora

en el proceso de despliegue al solo ser necesario especificar características

para el despliegue del mismo.

Adicionalmente los datos de la validación pueden ser consultados en el link

arieta-validation

5.1.4. Amenazas a la validación

El servicio encargado de hacer el análisis de datos, OpenScoring [48], es

provisto por un tercero, en este sentido, errores de código, desactualización

con el estándar PMML o abandono del software puede afectar la validación

de este proyecto.

Los datos de prueba son tomados de API publico de Translink [53], varia-

ciones en el formato de los mismo afectarían el proceso de análisis de los

datos y despliegue de soluciones analíticas.


6Trabajo relacionado

En el proceso de elaboración de este proyecto, investigamos varias tecnologías

y herramientas que podrían validar nuestros objetivos. Sin embargo, ninguna

solución satisfizo completamente los criterios que teníamos para este proyecto

como:

Vista de implementación accionable. Como parte de nuestra solución,

es necesario conocer los elementos desplegados en el sistema, siendo más

explícitos, ver los elementos desplegados y sus conexiones, y también per-

mitir la edición o creación de conexiones mediante esta, asi como el uso de

escenarios de calidad y tácticas para el despliegue de una arquitectura.

Arquitectura ejecutable. Este criterio es el punto principal de nues-

tro trabajo. Esto nos permitirá desplegar completamente una arquitectura

usando las definiciones de sus artefactos en producción en tiempo cercano

59

60

al real.

Arquitectura colaborativa. Una parte de nuestra investigación es fa-

cilitar la comunicación entre arquitectos y cientificos. Esta característica

permite trabajar en colaboración entre estos actores y también seguir los

criterios de la estrategia DevOp.

Estado de los servicios. Ver lo que sucede en cada despliegue y lo que

se ejecuta en cada servicio de desplegado es relevante para poder evaluar el

comportamiento y el estado, y para determinar si la configuración actual del

servicio es correcta o si para su desarrollo es mejor utilizar otra tecnología.

Hay múltiples herramientas en el mercado tanto de código abierto como pro-

pietarios que siguen algunos de los puntos mencionados, se exponen las más

similares y estables a nuestro proyecto; en la tabla 6.1 muestra una relación entre

los criterios y las herramientas que investigamos.

SaltStack. “Es un software de orquestación inteligente para el centro de

datos” como dice la comunidad SaltStack. Este permite la automatización

del centro de datos, automatizando el empaquetado y aprovisionamiento

de código en el entorno de TI operacional de una organización. La admi-

nistración de aplicaciones de software proporciona administración de con-

figuración para operaciones de TI, entornos DevOps y CloudOps [54]. Sin

embargo, esto no proporciona ninguna vista de arquitectura como compo-

nentes o implementaciones.

Cisco UCS Manager Cisco Unified Computing System (UCS) es una

linea de centro de datos compuesta de hardware de cómputo, soporte de

virtualización, tejido de conmutación y software de administración. La ad-

ministración de dispositivos del sistema se puede integrar mediante un nave-

gador, línea de comandos o API [55]. Este es un software exclusivo, restrin-

gido para usar con los componentes de Cisco, además de mostrar las vistas

de despliegue y las conexiones entre los elementos, pero no es accionable en

sí mismo.

Capítulo 6. Trabajo relacionado 61

VMware Cloud Foundation. Es la plataforma Software-defined data

center (SDDC) unificada, esta plataforma de infraestructura funciona en

la nube y es híbrida, proporciona una infraestructura dinámica definida

por software para ejecutar aplicaciones en entornos privados y públicos

[56]. Esto proporciona múltiples ventajas de gestión pero no incluye vistas

arquitectónicas.

AWS CloudFormation. Es un servicio que ayuda a modelar y configurar

recursos de Amazon Web Services. AWS permite la colaboración mediante

el uso de identidades y otras herramientas. Además, AWS tiene múltiples

herramientas de monitoreo para CPU, GPU y uso de disco, sin embargo,

no facilita el monitoreo individual de servicios desplegados. Por otra parte,

esto tiene un costo asociado con los recursos implementados.

SaltStack Cisco UCSManage

VMwareCloudFoundation

AWSCloudFormation

Arieta Tool

Actionabledeployment view 1/2 x x

Executablearchitecture. x x x x x

Collaborativearchitecture x x x x x

Deployedelement status 1/2 1/2 1/2 1/2 x

Cuadro 6.1: Tabla de comparación de tecnologías relacionadas

Incluso cuando AWS está cerca de nuestro enfoque, tiene la restricción de

costos y monitoreo de recursos. Resumiendo, todas las tecnologías presentadas

contienen datos sobre estado sobre un servicio desplegado, como son los logs, pero

en general son de difícil acceso y restringen el monitoreo en tiempo cercano al

real, dándonos que ninguna de estas para abarcar todos los criterios de nuestra

investigación, la combinación de esto con otra herramienta puede llenar los re-

querimientos pero agregar complejidad a la solución, sin embargo ninguna tiene

en cuenta los escenarios de calidad o tácticas de despliegue en la arquitectura. La

herramienta Arieta proporciona todos los criterios mencionados anteriormente,

62

ejecuta a través de una vista de implementación accionables. Los componentes

en el entorno de producción, permite la colaboración entre los actores, así como

el monitoreo de estado en tiempo cercano al real de los elementos desplegados.

7Conclusiones y trabajo futuro

7.1 Conclusiones

Con la finalidad de alcanzar los objetivos descritos en el primer capítulo de

esta tesis, se procedió a definir formalmente la metodología ArchOps, sus valores,

principios y practicas, para luego aplicarlos en la solución de los problemas plan-

teados. Por otro lado, el uso de esta metodología nos permitió definir y desplegar

una arquitectura a través no solo de las vistas de arquitectura, sino también a

través del diseño de escenarios de calidad y tácticas de despliegue, es decir, nos

permitió realizar la integración de estos conceptos con el despliegue mismo de

una arquitectura.

Para permitir el despliegue de un modelo analítico de forma automática, se

definió el uso del estándar PMML. Para automatizar el despliegue, se desarrolla-

ron servicios encargados en persistir datos y conectar y transferir información a

63

64 7.1. Conclusiones

servicios especializados en la ejecución de modelos PMML, los cuales permitieron

desplegar modelos de DA a través de su representación en PMML.

El desarrollo de la herramienta de validación Arieta permitió comprobar que

el uso de arquitecturas ejecutables (estrategia ArchOps) permite el editar y des-

plegar arquitecturas a través de sus artefactos de diseño, como son los escenarios

de calidad, tácticas de despliegue y vistas de despliegue. Así mismo, la visualiza-

ción del estado actual de una arquitectura desplegada permite a los arquitectos

tener una mejor comprensión del estado del sistema y detectar cuellos de botella,

entre otros problemas. El uso de escenarios de calidad y tácticas de diseño para

desplegar una arquitectura facilitan la toma de decisiones en alto nivel de un

arquitecto de software para alcanzar los atributos de calidad definidos.

A pesar que la estrategia ArchOps fue utilizada el el contexto de DA, esta

puede ser aplicada a cualquier otro contexto y brindar los beneficios que trae

consigo, como son: Actualización continua de los artefactos de diseño, diseño de

escenarios de cálida y tácticas, despliegue automatizado a través de los artefactos

de diseño, mejor compresión de la arquitectura desplegada y tácticas utilizadas

para su diseño. Adicionalmente el uso de orquestadores como K8s puede permitir

el escalamiento necesario para aplicarse en el contexto de Big Data.

En resumen tenemos que:

Se definió formalmente la estrategia ArchOps, valores, principios, metodo-

logía y practicas y herramientas.

Se diseño e implementó una herramienta capaz de permitir la orquestación

de tecnologías en producción a través de sus artefactos de diseño, en espe-

cial a través de la vista de despliegue, escenarios de calidad y tácticas de

despliegue.

Se valido que la herramienta Arieta, es capaz de desplegar y modificar

modelos de DA, permitiendo el despliegue de los mismos en producción

de forma automática y mejorando la comunicación entre arquitectos de

software y científicos de datos en este proceso.

Capítulo 7. Conclusiones y trabajo futuro 65

Dado que ArchOps utiliza el concepto de arquitecturas ejecutables, esta

permite el despliegue de cualquier tecnología en producción al conteneri-

zarlas; por otro lado puede ser aplicada en cualquier contexto, no solo en

el de DA.

El uso de PMML para la representación de modelos reduce el tiempo y erro-

res para actualizar una solución analítica desplegada, ya que evita procesos

de reescritura de la solución a otros lenguajes o tecnologías, al permitir ser

consumido por gran variedad de tecnologías.

7.2 Trabajo futuro

Dado que el propósito de nuestra herramienta de validación Arieta, esta en-

marcado en los objetivos de este proyecto, es decir el despliegue de soluciones de

DA, queda espacio para implementar otro tipo de funcionalidades como:

Desplegar más información sobre los procesos que se están ejecutando.

Implementar un sistema de monitoreo de errores.

Generar un sistema de ayudas que permitan minimizar los errores que puede

cometer un arquitecto al configurar un servicio.

Automatizar el monitoreo de las tácticas de diseño de los escenarios de

calidad para facilitar la evaluación de los escenarios de calidad

Automatizar el despliegue de las tácticas de diseño

Así mismo, seria de utilidad determinar el desempeño de la solución planteada

en el contexto de Big Data Analytics.

Apendice A: Arieta API Endpoints

To understand the actions available in the cluster, we show at next the end-

points and functions allowed.

Operations List

Deploy services

Delete services

Check cluster status

Check existing pods

Check existing services

Check memory status

Get pod description

Deploy Services

Deploy into kubernetes the specified services given in a specification file.

Action: POST /v1/

Params: services Json file with the containers specifications.The file is compo-

sed by an array of hashes, where each hash has the specifications of a container.

Delete service

Delete a service from the cluster by a its name.

Action: DESTOY /v1/pods/:podName

66

Apendice A: Arieta API Endpoints 67

Cluster status

Return the current status of the cluster in a yaml format

Action: GET /v1/

Response example

1 apiVersion: v1

2 clusters:

3 − cluster:

4 certificate−authority: /path/to/ca.crt

5 server: https://192.168.99.100:8443

6 name: minikube

7 contexts:

8 − context:

9 cluster: minikube

10 user: minikube

11 name: minikube

12 current−context: minikube

13 kind: Config

14 preferences: {}

15 users:

16 − name: minikube

17 user:

18 client−certificate: /path/to/apiserver.crt

19 client−key: /path/to/apiserver.key

Get pods

Return the current pods deployed in the cluster

Action: GET /v1/pods

Get services

Return the current pods exposed in the cluster

Action: GET /v1/services

Get memory use

Return the current memory usage of the cluster

Action: GET /v1/memoryUse

68

Get Pod description

Implemented - Return the description of a pod

Action: GET /v1/pods/:podName

Apéndice B: Ejemplo de archivo JSon para

despliegue

1 [

2 {

3 "name": "ingestor1",

4 "image": "kafka",

5 "version": "latest",

6 "properties": {

7 "topic":"CRMData",

8 "port":"9000",

9 "batch_size":"1000"

10 },

11 "enviroment":{

12 },

13 "data_source": {

14 "service": "mongodb1",

15 "type": "database",

16 "target": "model1"

17 },

18 "data_destination":{

19 "service": "",

20 "type": "file",

21 "target": "/tmp/file.csv"

22 },

23 "device_configuration": {

24 "memory":"5Mi",

25 "memory_limit":"5Mi",

26 "cpu":"100m",

27 "cpu_limit":"200m"

28 }

29 },

30 {

69

70

31 "name": "treem",

32 "image": "jpmml/openscoring",


34 "device_configuration": {

35 "memory":"5Mi",

36 "memory_limit":"5Mi",

37 "cpu":"100m",

38 "cpu_limit":"200m"

39 }

40 },

41 {

42 "name": "mongodb1",

43 "image": "mongo",


45 "mode": "READ",

46 "properties": {

47 "port":"27017"

48 }

49 },

50 {

51 "name": "mongodb2",

52 "image": "mongo",


54 "mode": "READ",

55 "properties": {

56 "port":"27017"

57 }

58 }

59 ]

Apéndice C: Ejemplo de archivo PMML

1 <?xml version="1.0" encoding="UTF−8"?>

2 <PMML version="4.2" xmlns="http://www.dmg.org/PMML−4_2">

3 <Header copyright="Vincenzo">

4 <Application name="KNIME" version="3.3.0"/>

5 </Header>

6 <DataDictionary numberOfFields="21">

7 <DataField name="VMail Message" optype="continuous" dataType="integer">

8 <Interval closure="closedClosed" leftMargin="0.0" rightMargin="51.0"/>

9 </DataField>

10 ....

11 <DataField name="State" optype="categorical" dataType="string">

12 <Value value="KS"/>

13 <Value value="OH"/>

14 <Value value="NJ"/>

15 <Value value="OK"/>

16 ...

17 <Value value="ND"/>

18 </DataField>

19 </DataDictionary>

20 <TreeModel modelName="DecisionTree" functionName="classification"

21 splitCharacteristic="binarySplit" missingValueStrategy="lastPrediction"

22 noTrueChildStrategy="returnNullPrediction">

23 <MiningSchema>

24 <MiningField name="VMail Message" invalidValueTreatment="asIs"/>

25 <MiningField name="Day Mins" invalidValueTreatment="asIs"/>

26 ...

27 <MiningField name="Churn" invalidValueTreatment="asIs"

28 usageType="target"/>

29 </MiningSchema>

30 <Node id="0" score="0" recordCount="2666.0">

31 <True/>

32 <ScoreDistribution value="0" recordCount="2280.0"/>

71

72



35 <SimplePredicate field="Day Charge" operator="lessOrEqual"

36 value="44.96"/>




40 <SimplePredicate field="CustServ Calls" operator="lessOrEqual"

41 value="3.5"/>



44 ...


46 <SimplePredicate field="Day Charge" operator="greaterThan"

47 value="38.185"/>



50 ...

51 </Node>

52 ...

53 </Node>

54 </TreeModel>

55 </PMML>

Apéndice D: Manifiesto Ágil DevOps

Nuestra máxima prioridad es satisfacer al cliente a través de la entrega

temprana y continua de una funcionalidad valiosa.

La funcionalidad del software solo puede ser realizada por cliente cuando

es entregado a ellos por los sistemas. Los requerimientos no funcionales son

tan importantes como funcionalidad deseada para el resultado del usuario.

La infraestructura es cambiante y debe poderse entender, cambiar y actua-

lizar según sea necesario sin dejar de lado la documentación de esta.

Aceptamos que los requerimientos cambien, incluso en etapas tardías del

desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar

ventaja competitiva al cliente.

Entregamos funcionalidades frecuentemente, entre dos semanas y dos me-

ses, con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio, desarrolladores, operaciones y arquitectos de-

bemos trabajamos juntos de forma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que

darles el entorno y el apoyo que necesitan, y confiarles la ejecución del

trabajo.

El método más eficiente y efectivo de comunicar información al equipo de

desarrollo y entre sus miembros es la conversación cara a cara.

El software y sistemas funcionando es la medida principal de progreso.

73

74

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores, equipo de operaciones, arquitectos y usuarios debemos ser

capaces de mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la

agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado,

es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para

a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Apéndice E: Capturas de pantalla

Figura 7.1: Vista de despliegue del sistema

75

76

Figura 7.2: Vista - Adicionar nueva tecnología al sistema


Figura 7.3: Vista - Editar un servicio

78

Figura 7.4: Vista - Listado de escenarios de calidad

Figura 7.5: Vista - Crear un nuevo escenario de calidad


Figura 7.6: Vista - Listado de tácticas de despliegue

Figura 7.7: Vista - Crear una nueva táctica de despliegue

Bibliografía

[1] “Docker - build, ship, and run any app, anywhere.” https://www.docker.

com/. (Accessed on 10/11/2017).

[2] “Kubernetes - wikipedia.” https://en.wikipedia.org/wiki/Kubernetes#

cite_note-4. (Accessed on 10/11/2017).

[3] L. Bass, P. Clements, and R. Kazman, Software architecture in practice. SEI

series in software engineering, Boston: Addison-Wesley, 2nd ed ed., 2003.

[4] R. Murch, The Software Development Lifecycle - A Complete Guide:. Ri-

chard Murch, 2008.

[5] R. Kazman and L. Bass, Toward Deriving Software Architecture from Quality

Attributes. ESC TR: Engineering and Services Center, Software Engineering

Inst., Carnegie Mellon Univ., 1994.

[6] “Manifesto for agile software development.” http://agilemanifesto.org/.

(Accessed on 10/02/2017).

[7] H.-m. Chen, R. Kazman, S. Member, and S. Haziyev, “Agile Big Data Analy-

tics for Web-Based Systems : An Architecture-Centric Approach,” IEEE

TRANSACTIONS ON BIG DATA, vol. 2, no. 3, pp. 234–248, 2016.

[8] S. S. Anand, M. Grobelnik, F. Herrmann, M. Hornick, C. Lingenfelder,

N. Rooney, and D. Wettschereck, “Knowledge discovery standards,” Arti-

ficial Intelligence Review, vol. 27, no. 1, pp. 21–56, 2007.

80

https://www.docker.com/

https://www.docker.com/

https://en.wikipedia.org/wiki/Kubernetes#cite_note-4

https://en.wikipedia.org/wiki/Kubernetes#cite_note-4

http://agilemanifesto.org/

Bibliografía 81

[9] G. Press, “6 predictions for the $203 billion big data analytics

market.” https://www.forbes.com/sites/gilpress/2017/01/20/

6-predictions-for-the-203-billion-big-data-analytics-market/,

2017. (Accessed on 09/24/2017).

[10] Infochimps, “Cios and big data: What your it team wants you to know,”

2015.

[11] L. Tuovinen, “A Conceptual Model of Actors and Interactions for the Know-

ledge Discovery Process,” vol. 1, no. Ic3k, pp. 240–248, 2016.

[12] M. Fowler, “Design - Who needs an architect?,” IEEE Software, vol. 20,

pp. 11–13, Sept. 2003.

[13] G. Fairbanks, Just enough software architecture: a risk-driven approach.

Boulder, Colo: Marshall & Brainerd, 2010.

[14] M. Fowler, “Is design dead?.” http://martinfowler.com/articles/

designDead.html. Online, Accessed: 2016-03-07.

[15] G. Miller, “Second generation agile software development.” http://blogs.

msdn.com/randymiller/archive/2006/03/23/559229.aspx. Online, Ac-

cessed: 2016-03-07.

[16] International Organization for Standardization, International Electrotech-

nical Commission, Institute of Electrical and Electronics Engineers, and

IEEE-SA Standards Board, Systems and software engineering: architectu-

re description = Ingeniérie des systèmes et des logiciels : description de

l’architecture. Geneva; New York: ISO : IEC ; Institute of Electrical and

Electronics Engineers, 2011. OCLC: 782965386.

[17] L. O’Brien, L. Bass, and P. F. Merson, “Quality attributes and service-

oriented architectures.” http://repository.cmu.edu/cgi/viewcontent.

cgi?article=1440&context=sei. Online, Accessed: 2016-03-07.

[18] D. K. Barry and D. Dick, Web services, service-oriented architectures, and

cloud computing: the savvy manager’s guide. The Savvy manager’s guides,

https://www.forbes.com/sites/gilpress/2017/01/20/6-predictions-for-the-203-billion-big-data-analytics-market/

https://www.forbes.com/sites/gilpress/2017/01/20/6-predictions-for-the-203-billion-big-data-analytics-market/

http://martinfowler.com/articles/designDead.html

http://martinfowler.com/articles/designDead.html

http://blogs.msdn.com/randymiller/archive/2006/03/23/559229.aspx

http://blogs.msdn.com/randymiller/archive/2006/03/23/559229.aspx

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1440&context=sei

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1440&context=sei

82 Bibliografía

San Francisco, Calif. : Oxford: Morgan Kaufmann ; Elsevier Science [distri-

butor], second edition ed., 2013. OCLC: ocn815363503.

[19] E. Bertino, ed., Security for Web services and service-oriented architectures.

Heidelberg [Germany] ; New York: Springer, 2010. OCLC: ocn268931371.

[20] J. Lewis and M. Fowler, “Microservices.” http://martinfowler.com/

articles/microservices.html, 2014. Online, Accessed: 2016-10-01.

[21] L. Bass, I. M. Weber, and L. Zhu, DevOps: a software architect’s perspec-

tive. The SEI series in software engineering, New York: Addison-Wesley

Professional, 2015.

[22] J. Thones, “Microservices,” Software, IEEE, vol. 32, pp. 116–116, Jan 2015.

[23] M. E. Conway, “How do committees invent?,” Journal of Systems and Soft-

ware, Jan. 1968.

[24] A. Ávram, “The benefits of microservices.” http://www.infoq.com/news/

2015/03/benefits-microservices. Online, Accessed: 2016-03-13.

[25] M. Erder and P. Pureur, Continuous Architecture Sustainable Architecture

in an Agile and Cloud-Centric World. MA,USA: Elsevier, 2016.

[26] C. Larman and B. Vodde, Scaling lean & agile development: thinking and

organizational tools for large-scale Scrum. Upper Saddle River, NJ: Addison-

Wesley, 2009. OCLC: ocn233547812.

[27] P. Kruchten, “The 4+1 view of architecture,” in The 4+1 View Model of

Software Architecture, pp. 45–50, IEEE Software, 1995.

[28] L. W. Wagenhals, S. W. Liles, and A. H. Levis, “Toward executable architec-

tures to support evaluation,” in Toward executable architectures to support

evaluation, pp. 502–511, IEEE, 2009.

[29] D. J. Delgado, R. Torres-Sáez, and R. Llamosa-Villalba, “Develop an Execu-

table Architecture for a System of Systems: A Teaching Management Model,”

Procedia Computer Science, vol. 36, pp. 80–86, 2014.

http://martinfowler.com/articles/microservices.html

http://martinfowler.com/articles/microservices.html

http://www.infoq.com/news/2015/03/benefits-microservices

http://www.infoq.com/news/2015/03/benefits-microservices

Bibliografía 83

[30] Ni Feng, Wang Ming-Zhe, Yang Cui-Rong, and Tao Zhi-Gang, “Executable

architecture modeling and validation,” in Executable architecture modeling

and validation, pp. 10–14, IEEE, Feb. 2010.

[31] P. Helle and P. Levier, “From Integrated Architecture to Integrated Execu-

table Architecture,” in From Integrated Architecture to Integrated Executable

Architecture, pp. 148–153, IEEE, 2010.

[32] T. Bagnall, “Executable architectures – do we have the time?.” http:

//download-na.telelogic.com/download/userpresentation/uk2007/

Executable_Architectures_do_we_have_the_time_TBagnall_EADS.pdf.

Online, Accessed: 2016-03-13.

[33] L. Salamanca and D. Correal, “Archinotesx : an arcops framework.” https:

//biblioteca.uniandes.edu.co/acepto201699.php?id=10643.pdf, 2016.

[34] L. Bass, P. Clements, and R. Kazman, Software architecture in practice. SEI

series in software engineering, Upper Saddle River, NJ: Addison-Wesley, 3rd

ed ed., 2013.

[35] K. J. Cios, W. Pedrycz, R. W. Swiniarski, and L. A. Kurgan, Data Mining:

A Knowledge Discover Approach. 2010.

[36] M. J. A. Berry and G. S. Linoff, Data Mining Techniques, vol. 10. 2001.

[37] C. S. Margaret Rouse, “What is data analytics (da)? - defini-

tion from whatis.com.” http://searchdatamanagement.techtarget.com/

definition/data-analytics.

[38] M. G. Grossman R, Hornick M, “Data mining standards initiatives - data

mining group.” http://dmg.org/, 2002.

[39] “Contenedores de software - wikipedia, la enciclopedia libre.” https://es.

wikipedia.org/wiki/Contenedores_de_software.

[40] D. Inc., “What is docker?.” https://www.docker.com/what-docker. Onli-

ne, Accessed: 2016-10-07.

http://download-na.telelogic.com/download/userpresentation/uk2007/Executable_Architectures_do_we_have_the_time_TBagnall_EADS.pdf



https://biblioteca.uniandes.edu.co/acepto201699.php?id=10643.pdf

https://biblioteca.uniandes.edu.co/acepto201699.php?id=10643.pdf

http://searchdatamanagement.techtarget.com/definition/data-analytics

http://searchdatamanagement.techtarget.com/definition/data-analytics

http://dmg.org/

https://es.wikipedia.org/wiki/Contenedores_de_software

https://es.wikipedia.org/wiki/Contenedores_de_software

https://www.docker.com/what-docker

84 Bibliografía

[41] “Kubernetes - production-grade container orchestration.” https://

kubernetes.io/. (Accessed on 10/11/2017).

[42] J. Urrego and D. Correal, “Archinotes: A tool for assisting software architec-

ture courses,” in Software Engineering Education and Training (CSEE T),

2013 IEEE 26th Conference on, pp. 80–88, 2013.

[43] J. Urrego, R. Munoz, M. Mercado, and D. Correal, “Archinotes: A global

agile architecture design approach,” in Agile Processes in Software Enginee-

ring and Extreme Programming (G. Cantone and M. Marchesi, eds.), vol. 179

of Lecture Notes in Business Information Processing, pp. 302–311, Springer

International Publishing, 2014.

[44] B. Connolly, “5 areas of it that are on the rise.” http://www.cio.com.au/

article/577321/5-areas-it-rise. Online, Accessed: 2016-03-13.

[45] E. Mueller, “A devops manifesto | the agile admin.” https://

theagileadmin.com/2010/10/15/a-devops-manifesto/, 2010.

[46] J. Willis, “What devops means to me - chef blog.” https://blog.chef.io/

2010/07/16/what-devops-means-to-me/, 2010.

[47] “Data mining group - pmml powered.” http://dmg.org/pmml/products.

html.

[48] V. Ruusmann, “openscoring: Rest web service for scoring pmml models.”

https://github.com/openscoring/openscoring.

[49] “Apache kafka.” https://kafka.apache.org/. (Accessed on 10/11/2017).

[50] M. C. Tremblay, A. R. Hevner, and D. J. Berndt, “Focus Groups for Artifact

Refinement and Evaluation in Design Research,” Communications of the

Association for Information Systems, vol. 26, pp. 599–618, 2010.

[51] V. Vaishnavi and B. Kuechler, “Design Science Research in Information Sys-

tems,” Ais, p. 45, 2004.

https://kubernetes.io/

https://kubernetes.io/

http://www.cio.com.au/article/577321/5-areas-it-rise

http://www.cio.com.au/article/577321/5-areas-it-rise

https://theagileadmin.com/2010/10/15/a-devops-manifesto/

https://theagileadmin.com/2010/10/15/a-devops-manifesto/

https://blog.chef.io/2010/07/16/what-devops-means-to-me/

https://blog.chef.io/2010/07/16/what-devops-means-to-me/

http://dmg.org/pmml/products.html

http://dmg.org/pmml/products.html

https://github.com/openscoring/openscoring

https://kafka.apache.org/

Bibliografía 85

[52] A. Hevner and S. Chatterjee, Design Science Research in Information Sys-

tems, vol. 22. 2010.

[53] “Translink open api.” https://developer.translink.ca/, 2017.

[54] “Saltstack intelligent orchestration for the software-defined data center.”

https://saltstack.com/. (Accessed on 10/04/2017).

[55] “Cisco ucs manager - cisco.” https://www.cisco.com/c/en/us/products/

servers-unified-computing/ucs-manager/index.html. (Accessed on

10/04/2017).

[56] “Vmware cloud foundation unified sddc platform.” https://www.vmware.

com/products/cloud-foundation.html. (Accessed on 10/04/2017).

https://developer.translink.ca/

https://saltstack.com/

https://www.cisco.com/c/en/us/products/servers-unified-computing/ucs-manager/index.html

https://www.cisco.com/c/en/us/products/servers-unified-computing/ucs-manager/index.html

https://www.vmware.com/products/cloud-foundation.html

https://www.vmware.com/products/cloud-foundation.html

arquitecturas ejecutables aplicadas en el contexto de data

Documents