carátula modelo de decisión por factores técnicos, para
TRANSCRIPT
1
Carátula
Modelo de decisión por factores técnicos, para arquitecturas de microservicios
Caiza Soria, Luis Homero y Guaigua Albarracín, Humberto Gustavo
Vicerrectorado de Investigación, Innovación y Transferencia de Tecnología
Centro de Posgrados
Maestría en Ingeniería de software
Trabajo de titulación, previo a la obtención del título de Magíster en Ingeniería de software
Ing. Chamorro Sánchez, Luis Orlando. MBA
15 de julio del 2021
2
VICERRECTORADO DE INVESTIGACIÓN, INNOVACIÓN Y TRANSFERENCIA DE
TECNOLOGÍA
CENTRO DE POSGRADOS
CERTIFICACIÓN
Certifico que el trabajo de titulación, “Modelo de decisión por factores técnicos, para
arquitecturas de microservicios” fue realizado por los señores Caiza Soria, Luis
Homero y Guaigua Albarracín, Humberto Gustavo el mismo que ha sido revisado y
analizado en su totalidad, por la herramienta de verificación de similitud de contenido; por
lo tanto cumple con los requisitos legales, teóricos, científicos, técnicos y metodológicos
establecidos por la Universidad de las Fuerzas Armadas ESPE, razón por la cual me
permito acreditar y autorizar para que lo sustente públicamente.
Latacunga, 15 de julio de 2021
……………………………….……………
Ing. Chamorro Sánchez, Luis Orlando MBA.
Director
C.C.: 0401056619
3
REPORTE URKUND
4
……………………………..……………
Ing. Chamorro Sánchez, Luis Orlando MBA.
DIRECTOR
5
VICERRECTORADO DE INVESTIGACIÓN, INNOVACIÓN Y TRANSFERENCIA DE
TECNOLOGÍA
CENTRO DE POSGRADOS
RESPONSABILIDAD DE AUTORÍA
Nosotros Caiza Soria, Luis Homero y Guaigua Albarracín, Humberto Gustavo, con
cédulas de ciudadanía n° 1719103820 y 1711034122, declaramos que el contenido, ideas
y criterios del trabajo de titulación: Modelo de decisión por factores técnicos, para
arquitecturas de microservicios es de nuestra autoría y responsabilidad, cumpliendo
con los requisitos legales, teóricos, científicos, técnicos y metodológicos establecidos por
la Universidad de las Fuerzas Armadas ESPE, respetando los derechos intelectuales de
terceros y referenciando las citas bibliográficas.
Latacunga, 15 de julio de 2021
…..……………………..…………. ………..…………………….………………
Caiza Soria, Luis Homero Guaigua Albarracín, Humberto Gustavo
C.C.: 1719103820 C.C.: 1711034122
6
VICERRECTORADO DE INVESTIGACIÓN, INNOVACIÓN Y TRANSFERENCIA DE
TECNOLOGÍA
CENTRO DE POSGRADOS
AUTORIZACIÓN DE PUBLICACIÓN
Nosotros, Caiza Soria, Luis Homero y Guaigua Albarracín, Humberto Gustavo, con
cédulas de ciudadanía n° 1719103820 y 1711034122, autorizamos a la Universidad de
las Fuerzas Armadas ESPE publicar el trabajo de titulación: Modelo de decisión por
factores técnicos, para arquitecturas de microservicios en el Repositorio Institucional,
cuyo contenido, ideas y criterios son de mi/nuestra responsabilidad.
Latacunga, 15 de julio de 2021
…..……………………..…………. ………..…………………….………………
Caiza Soria, Luis Homero Guaigua Albarracín, Humberto Gustavo
C.C.: 1719103820 C.C.: 1711034122
7
Agradecimiento
Como miembros del colectivo académico al que, con orgullo nos debemos y
pertenecemos, y en el que los logros alcanzados son fruto del trabajo de muchas
personas involucradas, al culminar esta etapa de tanto esfuerzo académico,
logístico, familiar y económico, queremos agradecer profundamente a nuestros
padres por su eterno amor y aporte en nuestra formación de valores y virtudes que
podamos haber alcanzado; a nuestras esposas e hijos, fuente constante de
inspiración y objetivo de todos nuestros esfuerzos; al señor Ing. Orlando Chamorro
Sánchez, por su invaluable apoyo académico y personal, sin el cual hubiese sido
muy difícil culminar el presente trabajo; y como no podía ser de otra manera, a todo
el personal directivo y académico del programa de Maestría en ingeniería de
Software de la UFA – ESPE, sede Latacunga, quienes siempre nos apoyaron y
estuvieron prestos con su contingente, para poder alcanzar este logro profesional.
Luis Caiza Soria.
Gustavo Guaigua Albarracín.
8
Dedicatoria
A mis padres que siempre confiaron en mí y nunca dejaron de apoyarme tanto en
buenos como en malos momentos, a mi hija como muestra de que para alcanzar
nuestros sueños cualesquiera que estos sean se debe luchar sin importar el
obstáculo con constancia y dignidad. Por último, a mi gatita Mylu que siempre estuvo
a mi lado mirándome desvelar, reír, llorar en este proceso.
Viva la vida, viva la libertad, viva el amor.
Luis Caiza Soria.
9
Dedicatoria
A mis adorados hijos, Gustavo Adolfo Guaigua Martínez y Mathías Nicolás Guaigua
Andrade, por ser mi fuente inagotable de amor y ternura, energía que necesito para
que mi vida y todos mis esfuerzos tengan sentido, me esforzaré por compensar este
tiempo que tomé de ustedes.
Gustavo Guaigua Albarracín.
10
Tabla de contenidos
Carátula .......................................................................................................................... 1
Certificación ................................................................................................................... 2
Reporte Urkund ............................................................................................................. 3
Responsabilidad de Autoría ......................................................................................... 5
Autorización de Publicación ......................................................................................... 6
Agradecimiento ............................................................................................................. 7
Dedicatoria ..................................................................................................................... 8
Tabla de Contenidos ................................................................................................... 10
Índice de Tablas .......................................................................................................... 13
Índice de Figuras ......................................................................................................... 15
Índice de Anexos ......................................................................................................... 17
Resumen ...................................................................................................................... 18
Introducción ..................................................................................................... 20
Planteamiento del Problema ........................................................................... 21
Formulación del Problema .............................................................................. 22
Antecedentes ................................................................................................... 22
Justificación ..................................................................................................... 24
Importancia ...................................................................................................... 24
Objetivos .......................................................................................................... 25
Objetivo General ................................................................................... 25
Objetivos Específicos .......................................................................... 25
Metodología de Investigación ......................................................................... 26
11
Marco Teórico .................................................................................................. 28
Antecedentes Referenciales ........................................................................... 28
Teorías de la Decisión e Incertidumbre .............................................. 29
Fundamentos de la Arquitectura de Software .................................... 33
Antecedentes Históricos ................................................................................. 35
Modelos de Decisión Empresariales ................................................... 36
Modelos de Evaluación de Arquitectura de Software ........................ 37
Modelos de Decisión de Arquitectura de Software ............................ 41
Antecedentes Conceptuales ........................................................................... 46
Antecedentes Contextuales ............................................................................ 78
Diseño del Modelo de Decisión ...................................................................... 81
Determinación de Factores. ................................................................. 81
Diseño Detallado del Modelo y sus Métricas ............................................... 103
Proceso de Implementación y Presentación de Resultados del Modelo de
Decisión .......................................................................................................... 126
Paso 1: Presentación del Modelo. ..................................................... 127
Paso 2: Presentar los Impulsores Comerciales ............................... 127
Paso 3: Implementación del Modelo ................................................. 128
Resultado Final ................................................................................... 128
Construcción de la Herramienta Tecnológica.............................................. 130
Levantamiento de Requisitos. ........................................................... 130
Diseño de la Arquitectura. ................................................................. 131
Desarrollo. .......................................................................................... 132
Pruebas. .............................................................................................. 134
Implementación. ................................................................................. 137
12
Implementación del Modelo de Decisión DMTF en el Caso de Estudio ..... 138
Introducción. ...................................................................................... 138
Aplicación del Modelo en el Caso de Estudio. ................................. 138
Análisis de Resultados. ..................................................................... 143
Criterio de los Involucrados. ............................................................. 145
Conclusiones y Recomendaciones .............................................................. 146
Conclusiones. ..................................................................................... 147
Recomendaciones y Líneas Futuras. ................................................ 149
Bibliografía................................................................................................................. 151
Anexos ....................................................................................................................... 165
13
Índice de tablas
Tabla 1. Decisión arquitectural de Escalabilidad.......................................… 50
Tabla 2. Matriz de facetas para caracterizar la investigación de los modelos
de decisión de microservicios, de acuerdo al framework FDC de
ReSiste-CHS………………………………………………………...…. 87
Tabla 3. Aplicación de la matriz de facetas para la investigación de los
Modelos de Decisión de Microservicios…………………..………….. 88
Tabla 4. Listado de los dos primeros cuartiles del BPR final…………..…….. 95
Tabla 5. Catálogo final de factores técnicos encontrados, con su frecuencia
absoluta (f¡)……………………………..………………………….…… 98
Tabla 6. Factores técnicos escogidos para el modelo de decisión
propuesto………………..……………………..……………..………… 101
Tabla 7. Evaluación de los 5 patrones, respecto de 4 atributos de
calidad……………………………………………………….………..… 106
Tabla 8. Reglas de las alarmas………………………………………………… 108
Tabla 9. Valor porcentual (%) de los 4 Factores técnicos, de acuerdo a la
opción elegida…..…………………….………………………….…….. 111
Tabla 10. Ejemplo de valores ingresados en el cuestionario.……….…….….. 111
Tabla 11. Umbral de valores considerados ALTOS y BAJOS…………..……. 112
Tabla 12. Valores resultantes y verificación de alarmas……………..…..……. 112
Tabla 13. Valoración de las respuestas desde la escala de Likert………...… 118
Tabla 14. Métricas utilizadas para medir la modularidad…............................ 120
Tabla 15. Valores de las métricas y modularidad de cada componente……. 122
Tabla 16. Valor de Modularización ponderado, de cada componente………. 123
14
Tabla 17. Comparación de Factores Técnicos determinados vs factores
técnicos utilizados en el modelo……………………………………… 126
Tabla 18. Resumen de la distribución de las preguntas con que cuenta el
modelo DMTF…………………………….……………………..……… 128
Tabla 19. Product Backlog del proyecto Desarrollo del DMTF……….………. 133
Tabla 20. Planificación de las tareas, con responsables, divididas en 5
Sprints………………………………………………………….……….. 134
Tabla 21. Matriz de Casos de Uso del módulo de “Ascensos” del sistema
SITHU………………………………………………………………….... 140
15
Índice de figuras
Figura 1. Composición de relación entre los factores y el modelo…………..... 26
Figura 2. Clasificación de las teorías de tomas de decisión……………….…. 30
Figura 3. Propuesta integradora de los modelos prescriptivos y descriptivos. 32
Figura 4. Contexto de la descripción de la arquitectura………………….…… 35
Figura 5. Estructura 3 niveles de TAR……………………………..…….……… 43
Figura 6. Áreas de diseño de microservicios…………………….…………….. 44
Figura 7. Contexto de la descripción de la arquitectura…………….…………. 47
Figura 8. MSA de un sitio web de comercio electrónico…………………...….. 50
Figura 9. Correspondencia, reglas de correspondencia y detalles
adicionales sobre la justificación de la arquitectura………..…..…… 54
Figura 10. Entorno de comunicación de las APIs….…………….……………… 68
Figura 11. Comunicación por API-gateway……….………………..……………. 69
Figura 12. Ejemplo de una consulta general en GraphQl……………………….. 73
Figura 13. Fases del framework SALSA……………………………………..…… 82
Figura 14. Búsqueda de artículos en la base de datos de Google Scholar……. 89
Figura 15. Valores de las medidas descriptivas de los factores técnicos
resultantes....................................................................................... 99
Figura 16. Diagrama de cajas con los cuartiles de la frecuencia de los factores
– herramienta RStudio………….……………………………….…….. 100
Figura 17. Factores técnicos finales por cuartil………………………..………… 100
Figura 18. Esquema general del proceso de determinación de los 10 Factores
Técnico finales, mediante el método ReSiste-CHS…………………. 102
Figura 19. Arquitectura de la herramienta del DMTF…………………..….……. 131
16
Figura 20. Pantalla principal de la herramienta JMeter con una prueba de
carga de la aplicación del DMTF…………………………………..…. 136
Figura 21. Reporte del rendimiento de la aplicación DMTF (herramienta
JMeter)………………………………………………………….………. 136
Figura 22. Reunión de presentación del modelo de decisión DMTF…………. 139
Figura 23. Llenado del cuestionario por parte del arquitecto de software……. 141
Figura 24. Herramienta informática para implementar el modelo de decisión
DMTF……………………………………………………………………. 142
Figura 25. Resultado final presentada por la herramienta DMTF…………...... 143
Figura 26. Gráfico radial generado por la herramienta DMTF………………… 144
17
Índice de anexos
Anexo A. BPR (Bibliographic Portfolio of Research) inicial con 106 artículos
científicos…………………………………………………….………… 166
Anexo B. BPR (Bibliographic Portfolio of Research) de 106 artículos
científicos, con factor inOrdinatio………………...…………….……. 169
Anexo C. Matriz inicial de catalogación de 69 Factores Técnicos del BPR
(Bibliographic Portfolio of Research) con factor inOrdinatio….…... 172
Anexo D. Matriz depurada con 40 Factores Técnicos del BPR (Bibliographic
Portfolio of Research) con factor inOrdinatio……………….………. 192
Anexo E. Ejemplo de un caso de medición de “Escalabilidad”………….…… 204
Anexo F. Patrones de despliegue de PaaS y sus métricas……………….….. 207
Anexo G. Detalle de las operaciones realizadas en el ejemplo de la tabla 12. 211
Anexo H. Detalle de las operaciones realizadas en el ejemplo de la tabla 16. 215
Anexo I. Instrumento de predicción del modelo de decisión DMTF………... 219
Anexo J. Plantilla de Historia de usuario y Criterio de aceptación – DMTF.. 225
Anexo K. Presentación ejecutiva del modelo de decisión DMTF para el caso
de estudio………………………………………………………………. 226
Anexo L. Aplicación de la herramienta (cuestionario) en el Dpto. de
Desarrollo de Sistemas de la Fuerza Aérea……………….……….. 237
Anexo M. Métricas utilizadas para medir la modularidad, con el peso de las
que se utilizan en la herramienta……………………………….……. 242
18
Resumen
Una de las primeras actividades en el desarrollo de software, y una de las de mayor
impacto, es la elección de la arquitectura de la nueva aplicación. En la presente
investigación se ha pretendido proporcionar una herramienta técnica al arquitecto,
encargado de tomar esta decisión, proporcionándole de un fundamento técnico al
momento de decidir la arquitectura, en este caso, microservicios. Para este propósito, se
propone un modelo de decisión basado en los factores técnicos más utilizados, y que
han sido publicados en trabajos de investigaciones científicas, con ranking Q1, Q2 y Q3
del SCImago Journal Rank, factores recolectados mediante una revisión sistematizada
utilizando el framework RESiste-CHS, y que luego fueron posicionados mediante el
factor inOrdinatio, una técnica fundamentada en el factor de impacto y número de citas,
entre otros aspectos, para crear el modelo que se fundamenta en 14 factores que
predicen el futuro escenario, en el que se piensa implementar la Arquitectura de
Microservicios (MicroServices Architecture, MSA). Una primera aplicación de este
modelo denominado: Modelo de Decisión por Factores Técnicos (Decision Model by
Technical Factors, DMTF), fue realizada en un caso de estudio, el desarrollo del sistema
de Talento Humano de la Fuerza Aérea Ecuatoriana (SITHU), en donde se implementa
a través de una herramienta informática, desarrollada para facilitar la aplicación del
modelo y la obtención del reporte y recomendación. Con base en esta experiencia, se
marca el camino para que, en futuros trabajos, se implemente el modelo en otros
proyectos para ir validando y popularizando su empleo.
Palabras clave:
MODELO DE DECISIÓN
ARQUITECTURA
MICROSERVICIOS
FACTORES TÉCNICOS.
19
Abstract
One of the first activities at the beginning of a software development project, and maybe
one of the most trascendental, corresponds at choosing the new application’s
architecture. On this research the intention was offer a technical tool to the architect in
charge to take the decision, providing him with a technical foundation for the moment
that an architecture has to be decided, in this case microservices. For this purpose a
decision model based on the technical factors more used is suggested, and which have
been published in scientific investigations, with Q1, Q2 and Q3 rank in the SCImago
Journal Rank, data recollected by a systematized review using the framework RESiste-
CHS, then it was positioned by the InOrdinatio fact, a technique based on the impact fact
and number of citations, among other aspects, for create the model based on 14 factors
that predict the future scenario, in which it is planned to implement the (Microservices
Architecture, MSA). A first application of the model called: Decision Model by Technical
Factors, DMTF, was realized in a study case, the system development of human talent
on FAE, SITHU, across to a computer tool, developed to make easier the model
application and with which you get report and recommendation. Based on this
experience, the way is marked for future works, to be developed in another projects for
validate and popularize it.
Keywords:
DECISION MODEL
ARCHITECTURE
MICROSERVICES
TECHNICAL FACTORS
20
Capítulo 1
1.1. Introducción
“La inversión en infraestructura y la innovación son motores fundamentales del
crecimiento y el desarrollo económico. Con más de la mitad de la población
mundial viviendo en ciudades, el transporte masivo y la energía renovable son
cada vez más importantes, así como también el crecimiento de nuevas industrias
y de las tecnologías de la información y las comunicaciones” (Programa de las
Naciones Unidas para el Desarrollo [PNUD], 2019).
Conforme a los lineamientos expresados en el objetivo 9: Industria, innovación e
infraestructura del Programa de las Naciones Unidas para el Desarrollo (PNUD), y en
pleno desarrollo de la industria 4.0, fundamentada en el uso de nuevas tecnologías
como Internet de las Cosas (Internet of Things IoT), Computación y Servicios en la Nube
(Cloud Computing), Macrodatos (Big Data) e Inteligencia de Negocios (Business
Intelligence, BI), el desarrollo de las actividades de empresas de todo tipo, se ha visto
involucrado en este nuevo entorno mundial, entre ellas, por supuesto, las pertenecientes
a la industria del software, las que siempre se han caracterizado por adoptar de forma
permanente, nuevos paradigmas, metodologías y herramientas para asegurar la calidad
de sus productos.
En esta industria del desarrollo de software, específicamente en el campo de la
arquitectura, el enfoque de los microservicios (Microservices, MS) ha despertado el
interés de los arquitectos, analistas y desarrolladores de software quienes
aparentemente estarían adoptando este nuevo estándar arquitectónico, impulsados,
entre otras causas, por el auge y prestaciones del software en la nube. Esta arquitectura
pretende entonces, ser la evolución de aquellas presentes en “aplicaciones de software
cuyos módulos no se pueden ejecutar de forma independiente, denominados Monolitos”
21
(Dragoni et al., 2017, p.2), y que son los que generalmente encontramos en los actuales
sistemas en producción.
Es así que, los microservicios, están siendo, constantemente objeto de estudio a
través de trabajos de investigación, precisamente uno de ellos, el de Granchelli et al.
(2017b), quienes en su trabajo denominado “Towards Recovering the Software
Architecture of Microservice-based Systems”, indican:
Hoy, el estilo arquitectónico de microservicios está siendo adoptado por muchos
actores tecnológicos clave como Netflix, Amazon, The Guardian. (p.1)
Se percibe el impacto que está teniendo esta arquitectura, al ser referencia en
este tipo de empresas. En este contexto empezamos a revisar y analizar las
características que han potencializado la Arquitectura de Microservicios (MicroService
Architecture, MSA), para poder determinar, los factores técnicos que con mayor
frecuencia están siendo utilizados en estas plataformas que soportan alto tráfico de
usuarios y millones de transacciones por segundo. A priori se puede percibir un primer
gran factor determinante, la infraestructura en la que se despliega esta arquitectura,
infraestructura que no es la misma para otro tipo de sistemas como por ejemplo, los de
tipo Administrativo-Financieros, Sistemas Planificadores de Recursos Empresariales
(Enterprise Resource Planning, ERP), Sistemas Web, entre otros, que se despliegan en
infraestructuras más modestas. Es ahí donde el líder de un proyecto de software debe
decidir si se adopta o no, una arquitectura de microservicios.
1.2. Planteamiento del problema
La definición de una arquitectura de software, es una gran decisión que a veces
corre el riesgo de tomarse sin mayores fundamentos que la experiencia, una moda, por
decisión discrecional del líder, por costo de oportunidad o a veces por utilizar un
presupuesto asignado, pudiendo caer eventualmente, en un análisis bajo criterios
subjetivos. Esta deficiencia hace que las empresas deban gestionar una diversidad de
22
arquitecturas, producto de esas decisiones, con impacto directo en los costos, por la
contratación de personal técnico y adquisición de herramientas adicionales.
Este hecho, sumado al constante aparecimiento de nuevas técnicas y
tecnologías, propias del avance continuo en el campo de la informática, podría estar
provocando una migración hacia arquitecturas nuevas como la de microservicios, con el
propósito válido de mejorar sus capacidades, eficiencia, seguridad, adaptabilidad, entre
otras características, en algunos casos, sin tomar en cuenta factores técnicos
determinantes que fundamenten esta decisión, provocando consecuencias a las áreas
de tecnología como: la obligación de mejorar sustancialmente sus capacidades
tecnológicas y técnicas, así como aumentar la inversión de esfuerzo y tiempo en una
migración que posiblemente no traiga los resultados esperados y generando
incertidumbre en el equipo de desarrollo.
En este contexto, se hace necesario contar con herramientas, metodologías,
modelos y/o aplicativos, fundamentados en procesos de análisis e investigación
científica, basados en las experiencias y estudios que se estén realizando en el área,
con el fin de aportar significativamente y solventar una necesidad práctica, que permita
a los gestores de proyectos de software, tomar una decisión profesional y
fundamentada, al momento de tener que escoger la arquitectura del producto software.
1.3. Formulación del problema
Con base en lo expuesto, se plantea el problema con la siguiente pregunta:
¿Cuáles son los factores técnicos predominantes, que ayudan a la toma de decisión
para la adopción de una arquitectura de microservicios?
1.4. Antecedentes
Con base en la cantidad de estudios referenciados, los modelos de decisión,
constituyen un campo de estudio aun emergente, estrechamente relacionados con los
23
modelos de evaluación de arquitecturas, pero con aplicabilidad pre-proyecto, es decir
antes del desarrollo de un nuevo software.
Con esta premisa, y encaminados a diseñar una propuesta de modelo de
decisión que sustente la elección de la arquitectura de microservicios, como primer paso
se revisó modelos de evaluación de arquitecturas enfocados en sus características,
tales como el de Kazman et al. (1994) “SAAM: A method for analyzing the properties of
software architectures”; el ATAM de Kazman et al. (1998) en su trabajo “The architecture
tradeoff analysis method” y el de Dullmann et al. (2017) “CASPA: A platform for
comparability of architecture-based software performance engineering approaches”, que
nos contextualizan en la evolución de los modelos de evaluación, y que sirve de base
conceptual a los modelos de decisión.
Ya en el ámbito de estos modelos de decisión, encontramos trabajos como:
“Decision Guidance Models for Microservice Monitoring” (Haselbock & Weinreich, 2017)
y “A Dashboard for Microservice Monitoring and Management” (Mayer & Weinreich,
2017), que aunque se orientan al monitoreo de la arquitectura, permiten entender sus
principios y funcionamiento, y sirven de contexto para llegar a modelos de decisión
como los analizados en: “Decision Models for Microservices: Design Areas,
Stakeholders, Use Cases, and Requirements”, Haselböck et al. (2017b), en cuyo trabajo
ya se identifica, algunos factores técnicos tales como: integración, modularización,
descubrimiento, tolerancia a fallos, entre otros, y que en concordancia con sus líneas
futuras, constituye el fundamento y línea base de la propuesta de modelo de decisión a
desarrollar, el que pretende coadyuvar, al líder de proyectos de Tecnologías de
Información (Information Technology, IT), al momento de tener que decidir la adopción
de una arquitectura, en este caso, microservicios.
24
1.5. Justificación
El presente trabajo, pretende diseñar, construir e implementar un modelo de
decisión para la adopción de una arquitectura de microservicios, aspira incrementar el
vínculo entre la academia y la industria, aportando con un nuevo enfoque, al desarrollar
un modelo de decisión, complementando los estudios y trabajos realizados en esta área.
Este trabajo pretende entonces, contribuir a resolver la falta de opciones de
modelos y herramientas en el incipiente campo de los modelos de decisión de las
aplicaciones informáticas, en este caso, enfocadas únicamente a la elección de la
arquitectura, por ser una de las primeras tareas factores que se realizan al empezar el
desarrollo o migración de un producto software, y que tiene gran repercusión durante el
ciclo de vida del sistema informático.
Se espera además contribuir a aumentar la visibilidad de los modelos de
decisión, abriendo una nueva arista para que otros autores, puedan continuar, corregir y
mejorar el presente camino recorrido.
1.6. Importancia
El grado de penetración que tiene la MSA en el mercado del desarrollo de
software está en pleno ascenso, medido por la cantidad de artículos y publicaciones
científicas y comerciales que referencian sus características y aplicaciones, a pesar de
aquello, no existe aún, muchas opciones de modelos de decisión, y mucho menos, que
proporcionen alguna herramienta de software para su aplicación, y las que han sido
compartidas y publicadas, carecen de detalles técnicos suficientes de implementación
para poder realizar una reproducción de estos modelos. Es así que, en el presente
trabajo de investigación, se propone un modelo de decisión, práctico, funcional,
detallado y lo más sencillo posible, para facilitar su utilización, además en una primera
utilización del modelo, se lo aplicará en un caso práctico real, al evaluar la factibilidad de
adoptar la arquitectura de microservicios en el desarrollo del nuevo Sistema Integral de
25
Talento Humano de la Fuerza Aérea Ecuatoriana (SITHU), para finalmente presentar los
resultados de su aplicación, así como conclusiones, recomendaciones y trabajos
futuros.
1.7. Objetivos
1.7.1. Objetivo general
Diseñar, construir e implementar un modelo de decisión, basado en el estudio de
los factores técnicos predominantes, para fundamentar técnicamente, la adopción de
una arquitectura de microservicios. Caso de estudio: Proyecto de desarrollo del Sistema
de Talento Humano SITHU de la Fuerza Aérea Ecuatoriana en el año 2021.
1.7.2. Objetivos específicos
a) Construir el marco de referencia, mediante una revisión bibliográfica sistematizada de
artículos y revistas científicas con factor de impacto Q1, Q2 y Q3, y extraer los
factores técnicos más referenciados en el estudio y desarrollo de sistemas bajo la
arquitectura de microservicios.
b) Diseñar y construir un modelo de decisión fundamentado en los factores técnicos
relevantes, que sustente la adopción de una arquitectura de micro-servicios.
c) Crear la herramienta informática del modelo de decisión.
d) Implementar el modelo de decisión en el proyecto, desarrollo del sistema Integral de
Talento Humano SITHU de la Fuerza Aérea
En la Figura 1, se aprecia la correlación general que tiene cada uno de los
factores técnicos con el modelo de decisión, como un ente integrador.
26
Figura 1
Composición de relación entre los factores y el modelo.
1.8. Metodología de investigación
1.8.1. Tipo de investigación
Dentro del marco de la Investigación + Desarrollo + innovación + difusión
(I+D+i+d), que se ha pretendido seguir, el presente trabajo es una investigación de
diseño Documental / Literaria, de propósito Aplicada, enmarcada en los niveles
exploratorio y descriptivo:
Investigación Documental / Literaria. Para la determinación de los
factores técnicos que intervienen en la arquitectura de microservicios, se revisaron y
examinaron proyectos relacionados, publicaciones, libros y artículos científicos, con
27
factores de impacto Q1, Q2 y Q3, en donde se analizan tanto revisiones sistemáticas,
como casos de estudio para la sustentación de los problemas encontrados y su solución
en el campo de las experiencias al implementar la arquitectura de microservicios,
también se usaron fuentes secundarias (bibliográficas) para la determinación de los
factores técnicos determinantes, eje central de modelo de decisión propuesto.
Investigación de propósito Aplicada. En sus niveles básicos, tiene
como finalidad aportar a la solución ante la falta de herramientas prácticas para la
fundamentación técnica al momento de decidir adoptar la arquitectura de microservicios,
para lo cual se diseña y construye el modelo de decisión, y se lo aplica en un primer
caso de estudio, con el propósito de coadyuvar al sector productivo del desarrollo de
software y que se constituya un aporte significativo de la teoría hacia la práctica.
1.8.2. Niveles de investigación
Exploratoria. Como primer nivel, se realiza una revisión y
esquematización de varios trabajos de investigación realizados acerca del tema, con el
fin de clarificar los conceptos y definir el alcance del modelo que se propone.
Descriptiva. Describe una parte de la realidad en la que se desarrolla la
industria del software en donde se ha adoptado la MSA, como un nuevo estándar, y se
revisan sus factores y características más representativas, para construir una
herramienta para predecir su aplicabilidad en un nuevo proyecto software.
1.8.3. Métodos y técnicas de investigación
Método de Análisis-Síntesis. Para realizar juicios críticos
fundamentados, y poder evaluar y decidir cuáles factores de una arquitectura de
microservicios son los más determinantes.
Método Sistémico. Utilizado para el diseño tanto del modelo de
decisión, como para la construcción de la herramienta tecnológica que lo
operacionalizará en forma práctica de la manera más adecuada posible.
28
Capítulo 2
2.1. Marco Teórico
La toma de decisiones es un proceso continuo que se aplica en todos los
ámbitos de la vida, consiste en la elección de una, entre varias alternativas. Para tomar
una decisión se necesita conocer el contexto, antecedentes que originaron la necesidad
y consecuencias que producirán su aplicación, toda decisión trae repercusiones,
personales, técnicas o económicas, que se deben evaluar con suficiente criterio para
poder dar una solución. Así pues, existen decisiones simples sin mayor trascendencia,
pero otras pueden ser más complejas y pueden afectar varios aspectos de la vida. Un
modelo de decisión para aplicar una arquitectura de software tiene como objetivo guiar
de manera correcta la toma de una decisión técnica, decisión que puede verse influida
por varios factores como los técnicos, psicológicos, de entorno, entre otros. Esta
investigación se enfoca en los factores técnicos para generar un modelo de decisión
para la adopción de una arquitectura de microservicios.
Para el efecto, a continuación se realiza un resumen histórico y se revisa los
conceptos y definiciones de los aspectos que intervienen en la presente investigación,
tales como: arquitectura, modelos de evaluación de arquitecturas, microservicios,
características de los microservicios, y modelos de orientación, para finalmente llegar a
los modelos de decisión, de tal manera que su compresión nos ayude, como base
teórica para sustentar los fundamentos expuestos en el modelo de decisión propuesto.
2.2. Antecedentes referenciales
¿Qué hubiese pasado, si Jesús decidía ceder a la tentación después de ayunar
por 40 días en el desierto, o si Cristóbal Colón decidía no hacerse a la mar en 1492?,
las decisiones cambian el rumbo de la historia e intervienen en el destino de muchos
seres involucrados en el evento.
29
2.2.1. Teorías de la decisión e incertidumbre
Desde hace ya algún tiempo el ser humano se ha preocupado en entender cómo
funciona este proceso de la toma de decisiones, encontrando en el tiempo
investigaciones que revisan las teorías tales como:
Teoría de La Decisión e Incertidumbre: Modelos Normativos y
Descriptivos - Aguiar. Aguiar (2004), en su trabajo denominado “Teoría de la decisión
e incertidumbre: modelos normativos y descriptivos”, habla acerca del paradigma
canónico de la teoría de la decisión y manifiesta que la decisión se caracteriza por tener
2 elementos centrales: Un individuo quien va a tomar la decisión y la teoría formal de la
decisión (French et al., 1990, como se citó en Aguiar, 2004).
Además, hace una revisión de los criterios básicos de consistencia lógica, tales
como: Transitividad, Completud, Asimetría y Simetría de la indiferencia, conceptos
fundamentales que cimientan las bases de la teoría de la decisión y que son revisados
por otros autores en tratados posteriores.
En este trabajo se definen ya los Modelos Normativos, Prescriptivos y
Descriptivos propuestos por French et al. (1990),
Modelos Normativos: se estudia qué decisiones debe tomar un agente idealizado
(que no sufre nunca incoherencias lógicas y que es capaz de optimizar la búsqueda
de información).
Modelos Prescriptivos: se ocupan, en cambio, de cómo pueden elegir bien individuos
reales, dadas sus limitaciones cognitivas e informativas.
Modelos Descriptivos: estudian cómo deciden, de hecho, las personas.
Se revisa la Teoría de juegos y la Teoría de la elección social:
Teoría de juegos: que analiza las decisiones individuales que se ven influidas no sólo
por la información contextual disponible, sino por las decisiones de otros. Se trata,
pues, del estudio formal de decisiones estratégicas, en las cuales lo que una persona
30
decide depende de la información que tenga sobre lo que hacen los demás (Binmore,
1994, como se citó en Aguiar, 2004).
Teoría de la elección social: estudia y propone criterios para agregar funciones
individuales de decisión en una sola función social de decisión o función de elección
social. Dadas las preferencias de un conjunto de personas, por ejemplo, las
preferencias por distintos candidatos en una elección, se trata de saber cuál sería la
preferencia colectiva (Aguiar, 2004).
En la Figura 2, se observa un esquema acerca de esta distribución:
Figura 2
Clasificación de las teorías de tomas de decisión.
Nota. Recuperado de Aguiar, 2004.
Así mismo afirma que una decisión puede ser paramétrica o estratégica:
Paramétrica: si el contexto se considera dado, es decir, un parámetro, se puede
entender como elementos de convicción para la decisión.
31
Estratégica: si las decisiones de los actores son interdependientes, de forma que
nuestra decisión dependa de lo que hagan los demás.
Por otra parte, acerca de la incertidumbre, define dos polos afirmando que, si la
información sobre los resultados de las distintas opciones es completa (se conoce con
toda seguridad las consecuencias de nuestras decisiones) el individuo se hallará ante
una situación de Certidumbre; pero si, por el contrario, la información es incompleta (se
desconoce qué consecuencias tendrán nuestras acciones) la situación será bien de
riesgo o bien de incertidumbre.
Como se puede apreciar, el autor hace referencia al término “riesgo”, para hacer
énfasis en el hecho de tener que tomar una decisión sin tener los elementos de
convicción, es decir sin sustento de ninguna clase, lo que puede suceder cuando se
decide la adopción de la arquitectura que tendrá una aplicación de software en
condiciones de certidumbre o incertidumbre.
Teorías normativas y descriptivas de la toma de decisiones: un
modelo integrador - de Páez. Continuando en el tiempo, otro tratado acerca de las
teorías de la decisión, se encuentra en el trabajo denominado: “Teorías normativas y
descriptivas de la toma de decisiones: un modelo integrador”, en el que Páez (2015),
revisa en primera instancia, los 3 modelos teóricos que explican la toma de decisión
revisados y descritos por (Aguiar, 2004):
Modelos normativos: que muestra, cuál es la mejor forma de decidir.
Modelos prescriptivos: definen, cómo en realidad deciden las personas.
Modelos descriptivos: también definen, cómo en realidad deciden las personas.
Sin embargo, luego manifiesta que la tarea decisoria no se entiende de manera
radical, es decir que, en la realidad, no siempre se utiliza uno de los 3 modelos en forma
exacta, y propone un modelo integrador con la mezcla de los principios teóricos de los 3
modelos nombrados, explica, además la efectividad de la tarea decisoria con un
32
elemento innovador, la comprensión e incorporación de los sesgos que, de hecho, se
emplean en el acontecer diario.
Esta propuesta integradora se la observa en la Figura 3
Figura 3
Propuesta integradora de los modelos prescriptivos y descriptivos.
Nota. Recuperado de Leon, 1987.
La interpretación la hace el autor, siguiendo la Figura 3, de izquierda a derecha.
En un primer bloque se encuentra el contenido conductual de la decisión, que se
compone por todas aquellas disciplinas que participan de la explicación teórica de la
toma de decisiones como matemáticas, economía y psicología.
De esta interacción surgen los 2 modelos teóricos (óptimos y heurísticos).
Los modelos óptimos. Que son aquellos que abundan en explicaciones
probabilísticas puras y que buscan maximizar la utilidad con métodos ideales de
decisión, en cambio,
Los modelos heurísticos. Son aquellos que destacan por explicaciones
basadas en las limitaciones impuestas por los sesgos de decisión y sólo pretenden
explicar cómo sucede la conducta decisoria.
33
Finalmente, ambos resultados pueden ser integrados en el diseño de programas
de ayuda a la toma de decisión personalizados teniendo en cuenta la idiosincrasia
particular de cada sujeto y los sesgos que le definen como la relación hombre-máquina
(Páez Gallego, 2015).
2.2.2. Fundamentos de la arquitectura de software
Algunos investigadores coinciden en afirmar que la fase de diseño de la
Arquitectura del Software (Software Architecture, SA), se considera una de las fases
más críticas en el ciclo de vida del desarrollo de software, debido a que la SA se decide
al inicio de un proyecto de desarrollo, por lo que tiene un impacto considerable en la
calidad del producto final y en las repercusiones en varios aspectos relacionados (Bass
et al., 2004).
El término “arquitectura” llegó al software a través de Fred Brooks mientras
estaba en IBM, quien un día en la década de 1960 preguntó a Jerry Weinberg, si
pensaba que lo que hacían los arquitectos era una metáfora adecuada para lo que
hacemos en software, y Jerry estuvo de acuerdo (Coplien & Bjornvig, 2011).
El término completo como SA se afianzó y popularizó oficialmente a partir de
1969 en una conferencia sobre técnicas de ingeniería de software organizada por la
OTAN. Algunos de los pioneros más prestigiosos de este campo como: Tony Hoare,
Edsger Dijkstra, Alan Perlis, Per Brinch Hansen, Friedrich Bauer y Niklaus Wirth,
estuvieron presentes en esta reunión (Kruchten et al., 2006).
Muchos autores han realizado definiciones de la Arquitectura de Software, por un
lado, se afirma que es "la descomposición estructural del software". (Lüders, 2003,
como se citó en Haoues et al., 2017), Por otro lado se menciona que se trata de un
medio para proporcionar "abstracciones de alto nivel en la representación de la
estructura, el comportamiento y las propiedades clave del software complejo" (Garlan,
2003, como se citó en Haoues et al., 2017), la IEEE la define como ''la organización
34
fundamental de un sistema incorporado en sus componentes, sus relaciones entre sí y
con el medio ambiente, y los principios que guían su diseño y evolución'' (ISO/IEC/IEEE
42010, 2011), esta última es la más adoptada. Con base en estas definiciones, se
puede decir que la SA se crea a través de un conjunto de decisiones que:
representan la estructura, el comportamiento y los atributos globales de un
sistema en un alto nivel de abstracción (fase de diseño);
definen todos los requisitos funcionales; y
definen los requisitos no funcionales (atributos de calidad).
(Haoues et al., 2017)
En la ingeniería de software, se han utilizado varias arquitecturas, una de las
clasificaciones más generales, la describe Haoues et al. (2017) en su trabajo
denominado “A guideline for software architecture selection based on ISO 25010 quality
related characteristics”, en donde reconoce las siguientes arquitecturas de software:
Arquitectura basada en modelos (Model Driven Architecture, MDA).
Arquitectura basada en componentes (Component Based Architecture, CBA).
Arquitectura orientada a servicios (Service Oriented Architecture, SOA).
Arquitectura Orientada a Objetos (Object Oriented Architecture, OOA).
Arquitectura Conducida por Eventos (Event Driven Architectur, EDA).
Arquitectura Orientada a Aspectos (Aspect Oriented Architecture, AOA).
Respecto de la arquitectura de microservicios (Microservices Architecture, MSA),
surgió ante el inconveniente más grave que tiene SOA, su integración centralizada.
Algunos investigadores prefieren referirse a los microservicios como un enfoque para
construir SOA. Otros afirman que se puede hacer referencia a la arquitectura SOA como
la representación monolítica de una aplicación o como una vista comprimida de
microservicios (Salah et al., 2016).
35
En todo caso la MSA, como evolución o especialización de SOA, se aprecia en
la Figura 4.
Figura 4
Evolución de la taxonomía de sistemas distribuidos que representan la evolución de las
arquitecturas.
Nota. Recuperado de (Salah et al., 2016).
2.3. Antecedentes históricos
El siglo XVII marcó el comienzo del estudio sobre la toma de decisión. Los
primeros autores fueron de origen francés. Estos estudiosos fueron pioneros en
la elaboración de modelos matemáticos que trataban de encontrar regularidades
en la conducta óptima durante la realización de tareas de decisión en el juego de
azar. El primer trabajo documentado del que se tiene constancia es de 1738
(Páez Gallego, 2015, p.1).
Los modelos de decisión de arquitectura de software, finalmente constituyen la
implementación de una herramienta predictora que se deriva de los modelos de
evaluación de software, estos últimos han tenido ya un recorrido en el tiempo y
actualmente se encuentran bastante maduros y tratados en trabajos de investigación,
contando con herramientas de monitoreo con las que actualmente son utilizados en el
mercado.
36
La génesis, tanto de los modelos de decisión empresariales, como de los
modelos de evaluación hasta llegar a los modelos de evaluación de arquitectura de
software en este caso de microservicios, se los resume en las siguientes líneas.
2.3.1. Modelos de decisión empresariales
En toda actividad humana, desde siempre, se puede afirmar que se debieron
haber utilizado modelos de decisión, seguramente empíricos e incipientes, pero
utilizados para escoger entre las opciones del entorno. En el campo profesional, los
modelos de decisión, debieron haber sido utilizados en los grandes acontecimientos
mundiales como la Revolución Industrial de finales del siglo XVIII en Inglaterra, o
durante la gran depresión estadounidense del año 1929. En la literatura, desde hace
años atrás, grandes autores del ámbito empresarial, inclusive creadores de best sellers1
de la administración como Chiavenato (2002), ya afirmaban que una organización es un
sistema de decisiones, en donde cada persona participa consciente y racionalmente, y
decide entre las alternativas que se le presentan, de acuerdo con su personalidad,
motivaciones y actitudes. Por la misma época, otros autores como Hellriegel et al.
(2002), complementando, aumentaban otro factor, indicando que cuando los individuos
pueden identificar eventos y su impacto potencial, toman decisiones bajo una condición
de certidumbre, pero cuando la información disminuye y se vuelve ambigua, la condición
de riesgo entra en el proceso, y la decisión se basa en intuición y juicio.
Actualmente, los modelos de decisión son utilizados profesionalmente en el
ámbito de la administración de las organizaciones y negocios, con modelos tradicionales
que se han hecho populares, tales como los revisados por Barreto (2017).
1 RAE – Libro o disco de gran éxito comercial – Idalberto Chiavenato, escritor brasileño, autor de más de
30 libros que han sido destacados en el área de la Administración y Relaciones Humanas, dos de ellos best
sellers en el área de la administración “Teoría General de la Administración” y “Administración de
Recursos Humanos”. Biografía Idalberto Chiavenato (Salinas, 2011).
37
Modelo racional.
Modelo de racionalidad limitada.
Modelo político.
Modelo intuitivo.
Modelo del proceso creativo.
2.3.2. Modelos de evaluación de arquitectura de software
En el campo del desarrollo de software, el antecedente más cercano a los
modelos de decisión, son los modelos de evaluación, en este caso de arquitectura de
software, tales como SAAM y ATAM entre los más populares y que han servido de base
tanto para otros modelos de evaluación como para los modelos de decisión, por ello se
revisa la evolución de los métodos y técnicas de evaluación dentro de la arquitectura de
software con el fin de entender sus bases teóricas y fundamentos.
Primera Etapa Cronológica (1992-2000). En esta primera etapa el
nombre “Arquitectura de software“ hace su primera aparición de la mano de Perry &
Wolf (1992), lo que marca el primer hito de referencia del uso de arquitecturas en el
desarrollo de software, luego Maranzano (1993) se planteaba ya la necesidad de definir
una correcta Evaluación de Arquitectura de Software (Software Architecture Evaluation,
SAE) en el proceso de construcción de software ya que el éxito de las nuevas
tecnologías desde su perspectiva sólo serían posibles con una arquitectura sostenible,
dando con esto pie a la publicación de propuestas de varios autores, sin embargo cada
uno de ellos proponían un enfoque basado en su punto de vista y experiencia para
recomendar el uso de una arquitectura u otra, no es hasta 1994 en que aparece una de
las primeras propuestas de métodos de evaluación reconocido en la industria.
SAAM (1994). La primera propuesta de un modelo de evaluación de
arquitecturas de software se denominó: Método de análisis de arquitectura de software
(Software Architecture Analysis Method, SAAM), modelo que consta de 5 pasos,
38
fundamentado en la modificabilidad y basado en el análisis de un conjunto de
escenarios donde se analizan atributos de calidad como: mantenibilidad, portabilidad,
modularidad, reutilización, escalabilidad, integrabilidad (Kazman et al., 1994).
AQA (1997). Es el primer método de evaluación reconocido como tal, y fue
llamado: Evaluación de la calidad de la arquitectura (MITRE's Architecture Quality
Assessment, AQA), desarrollado por la empresa estadounidense MITRE, y del cual,
Hilliard II et al. (1997) mencionan que su fin fue crear una técnica objetiva y repetible
para la evaluación de arquitecturas de sistemas, cuyo enfoque se centra en la
evaluación de los riesgos de la implementación de una arquitectura con el fin de
minimizar los mismos.
SARM (1998). Es el método de reingeniería de la arquitectura de software
(Software Architecture Reengineering Method, SARM), que según Bengtsson & Bosch
(1998), se basa en la evaluación de los atributos de calidad esperados con la
implementación de una arquitectura, para lo cual usa prototipos e interacciones para
medir y evolucionar la arquitectura.
Segunda Etapa Cronológica (2000-2002). El auge de los métodos de
evaluación de las arquitecturas aparece a partir del año 2000 donde no solo se evaluaba
una arquitectura en forma general, sino que esta se fue especializando en varios
enfoques; encontramos así, modelos como:
ARID (2000). El modelo de Revisiones activas para diseños intermedios (Active
Reviews for Intermediate Designs, ARID), combina un método de evaluación de
arquitectura centrado en las partes interesadas y basado en escenarios, como el
Método de análisis de compensación de arquitectura ATAM, y una revisión de diseño
activa (Active Design Review, ADR) de especificaciones de diseño, además evalúa
diseños detallados de unidades de software coherentes tales como módulos o
componentes (Kazman et al., 2000).
39
ABD (2000-2003). El método de Diseño basado en la arquitectura (The
Architecture Based Design, ABD) que, según Bachmann et al. (2000), se basa en el
cumplimiento de los requisitos funcionales, de calidad y comerciales basados en la
capacidad de abstracción de estos requisitos pasando por una etapa extremadamente
detallada de su diseño.
Bosch (2000). En el trabajo denominado “Design and use of software
architectures: adopting and evolving a product-line approach”, Bosch (2000),
fundamentalmente plantea la necesidad de un diseño para construir sistemas de alta
calidad, confiables y fáciles de mantener, dando algunas pautas para resolver cada uno
de estos aspectos aplicando por ejemplo patrones de diseño y técnicas de evaluación
de calidad.
ATAM (2002-2003). El Método de análisis de compensación de arquitectura
(Architecture Tradeoff Analysis Method, ATAM) que según Clements et al. (2002), es la
biblia de la arquitectura de software ya que es el método más conocido y acogido por la
comunidad, aborda diversas perspectivas para la aplicación de una arquitectura
pasando por los aspectos de software hasta el hardware necesario para una
implementación, este es el modelo del cual partirán varios métodos especializados
futuros.
PASA (2002). Del método de Evaluación de desempeño de arquitecturas de
software (Performance Assessment of Software Architectures, PASA), Williams & Smith
(2002), manifiestan que permite evaluar la decisión de aplicar una arquitectura utilizando
técnicas y principios de ingeniería de rendimiento de software claramente enfocándose
en el rendimiento como el factor determinante para aplicar una arquitectura.
PROTEUS (2002). Al método Proteus, Chung et al. (2003), lo define como, aquel
que se basa en el uso de patrones para apoyar el uso de cualquier arquitectura como
una forma de unificar los criterios de aplicación. Un framework que está destinado a
40
apoyar el desarrollo de arquitecturas de software adaptables utilizando patrones de
diseño.
Tercera Etapa (2002-Actualidad). Etapa cronológica donde disminuye
el número de métodos de evaluación creados, sin embargo, los ya existentes son
mejorados y especializados.
QAW (2003-Actualidad). Acerca de los Talleres de atributos de calidad (Quality
Attribute Workshops, QAW), Barbacci et al. (2003), nos indican que es un método que
evolucionó de ATAM para complementarlo al agregar atributos de calidad y aclaración
de requisitos como fase previa a una implementación.
ADD (2003-Actualidad). Del método de Diseño basado en atributos (Attribute-
Driven Design, ADD), Bass et al. (2004), mencionan que es la evolución del método
ABD cuyo propósito se enfoca en mejorar la arquitectura basados en la idea de la
aplicación de interacciones, donde en cada iteración la arquitectura se va rediseñando y
adaptando a la necesidad de quien lo aplica.
ALMA (2004-Actualidad). El método de Análisis de modificabilidad a nivel de
arquitectura (Architecture Level Modifiability Analysis, ALMA), según Bengtsson et al.
(2004), es considerado como una de las más robustas técnicas de evaluación para la
migración de arquitecturas hasta la actualidad que se caracteriza por tomar en cuenta
tres factores fundamentales para su evaluación el costo, la calidad y el tiempo de
entrega.
QUADRAD (2005-Actualidad). El método de Desarrollo de arquitectura
impulsado por la calidad QUADRAD (Quality-Driven Architecture Development) es un
método planteado en una tesis de doctorado, en la que Thiel (2005), describe que se
fundamenta en la evaluación de los atributos de calidad, seguridad, confiabilidad y
modificabilidad de un sistema para evaluar la correcta aplicación de una arquitectura.
41
Como complemento, los patrones de diseño arquitectónico, también han tenido
su evolución, sin embargo, el uso de cada uno de ellos depende del tipo de sistema que
el arquitecto pretende crear, en este caso de estudio se analizará algunos de ellos para
determinar los factores que son medidos por estos métodos y su impacto en el uso de la
arquitectura de microservicios.
2.3.3. Modelos de decisión de arquitectura de software
En el desarrollo de software en general, existen estudios acerca de varios tipos
de modelos, empezando por los modelos de calidad, tradicionales o adaptados a algún
escenario específico, como por ejemplo “Quality models: an experience in the software
industry” (Gallardo-Cueva et al., 2020); modelos de evaluación de arquitectura de
software, como: “Comparative Analysis of Software Architecture Evaluation Methods”
(Athar et al., 2016); modelos de decisión para mantenimiento de software, como: “A
decision model for software maintenance” (Krishnan et al., 2004), entre otros, pero el
campo de los modelos de decisión en arquitectura de software, mucho más orientado
específicamente a microservicios, es un campo aun emergente y no existen muchas
referencias acerca de su historia, en tal virtud, el presente trabajo, se fundamenta en la
revisión de tres artículos científicos acerca de los modelos de decisión de arquitectura
de software, que se han desarrollado en los últimos años:
Modelo de decisión (según Sabry, 2015). En el año 2015, tenemos
una propuesta de modelo de decisión, que la encontramos en el trabajo denominado
“Decision model for software architectural tactics selection based on quality attributes
requirements”, en donde, Sabry (2015) menciona a los atributos de calidad como
fundamento de los modelos de decisión, indicando que:
Los atributos de calidad no se cumplen simplemente, sino que la satisfacción es
una escala permitida que se puede ver en un escenario (Bass et al., 2004; Bachmann et
al., 2005, como se citó en Sabry, 2015). Teniendo en cuenta el hecho de que los
42
atributos de calidad tienden a ser características de todo el sistema, se necesitan
enfoques de todo el sistema para lograrlos. La satisfacción debe alcanzarse a nivel de
arquitectura del sistema, no a nivel de componente. Los sistemas tienen múltiples
atributos de calidad importantes y las decisiones que se tomen para satisfacer un
atributo de calidad particular afectarán a otros atributos de calidad. (p.3)
Con base en esta interpretación, el modelo de Sabry (2015), describe un modelo
de decisiones de arquitectura que, aunque no se alinea en todas sus partes, al objetivo
del presente trabajo, si es un aporte al presentar un primer modelo de decisiones para
referencia y contextualización del que se pretende proponer.
Modelo de decisión (según Haselbok et al., 2017). Dos años
después, encontramos una conceptualización más alineada a lo que son los modelos de
decisión de arquitectura de software, en los trabajos denominados: “Decision guidance
models for microservices: service discovery and fault tolerance” (Haselböck et al.,
2017a) y “Decision Models for Microservices: Design Areas, Stakeholders, Use Cases,
and Requirements” (Haselböck et al., 2017b), en donde los autores describen un modelo
de decisión de arquitectura de software orientado ya a los microservicios.
Así pues, (Haselböck et al., 2017a) en el primer trabajo nombrado en el párrafo
anterior, “Decision guidance models for microservices: service discovery and fault
tolerance”, presentan modelos de orientación para la toma de decisiones para
microservicios, centrados en un aspecto particular, pero central, de dicha arquitectura,
que es el descubrimiento y el registro de servicios y áreas relacionadas como el
almacenamiento en caché, el control de versiones y el equilibrio de carga.
En esta propuesta los autores hacen énfasis en las características del
Descubrimiento y Registro de servicios, distintivos propios de una arquitectura de
microservicios, basando su modelo de decisión en estos dos pilares y en un continuo
ciclo de creación y validación de un metamodelo de guía de decisiones, y de los
43
modelos de guía de decisiones específicos para las diferentes áreas del diseño, hasta
alcanzar el mayor grado posible de completitud del modelo.
Una particularidad digna de mencionar es que, en este trabajo se hace
referencia a un interesante concepto, para trasladar el campo de la investigación a la
práctica, llamada, Investigación de Acción Técnica (Technical Action Research, TAR),
cuya trayectoria en general se aprecia en la Figura 5, y consiste en diseñar artefactos y
validarlos en condiciones del mundo real (Wieringa, 2014b).
Figura 5
Estructura 3 niveles de TAR.
Nota. Recuperado de Haselböck et al., 2017b
Para complementar, Haselböck et al., (2017b), en su segundo trabajo
denominado “Decision Models for Microservices: Design Areas, Stakeholders, Use
Cases, and Requirements”, expresan:
Los modelos de decisión son un enfoque bien conocido para explorar el espacio
del diseño, tomar decisiones, documentar y reutilizar en la arquitectura del software
(Capilla et al., 2016; Weinreich & Groher, 2016, como se citó en Haselböck et al.,
2017b).
44
En este segundo concepto, los autores nos describen, modelos de decisión,
fundamentados en decisiones arquitectónicas, encontradas en las Áreas del Diseño,
Partes Interesadas, Casos de uso y Requerimientos, como escenarios en donde se
hallaron y describen atributos de calidad como: integración, modularización,
descubrimiento, tolerancia a fallos, seguridad y privacidad, escalabilidad, entre otros, de
esta investigación se puede ver su resumen en la Figura 6.
Figura 6
Áreas de diseño de microservicios.
Nota. Recuperado de Haselböck et al., 2017b
45
Nuevamente en este trabajo se hace referencia a la utilización del método de la
Investigación de Acción Técnica (TAR), para validar los artefactos diseñados, en
condiciones del mundo real (Wieringa, 2014b).
Modelo de decisión (según Zdun et al., 2018). Un estudio ya más
detallado, en el que además de los conceptos e impulsores de decisiones revisados y
utilizados en los estudios anteriores, se añadió una perspectiva más operativa y
práctica, está fundamentado en los principales problemas en el diseño de Interfaces de
Programación de Aplicaciones (Application Programming Interfaces, APIs2), en donde
se busca analizar, cómo estos aspectos de calidad se relacionan con las prácticas en el
diseño de las API y cuáles son los principales impulsores de decisiones.
Este modelo denominado: Decisión de Diseño Arquitectónico (Architectural
Design Decision, ADD), revisa la incertidumbre que las API producen desde la
perspectiva del cliente sobre el diseño de la MSA.
En el artículo denominado “Guiding Architectural Decision Making on Quality
Aspects in Microservice APIs”, sus autores, Zdun et al. (2018), una vez más, basados en
el concepto de decisiones arquitectónicas, indican que:
La mayoría de las decisiones sobre la calidad de API deben tomarse para
combinaciones de clientes API y la API a la que acceden esos clientes. Se pueden
tomar muchas de estas decisiones para grandes grupos de esas combinaciones, como
todos los clientes con acceso freemium3 o todos los clientes que acceden a una API
específica. Se debe tomar una decisión a nivel de operaciones en la API. (p.5)
2 Una API es un conjunto de definiciones y protocolos que se utiliza para desarrollar e integrar el software
de las aplicaciones. API significa interfaz de programación de aplicaciones.
(https://www.redhat.com/es/topics/api/what-are-application-programming-interfaces) 3 Una forma de cobrar por un producto o servicio en el que el producto o servicio básico es gratuito, pero el
cliente paga por características adicionales.
(https://dictionary.cambridge.org/es/diccionario/ingles/freemium)
46
2.4. Antecedentes conceptuales
2.4.1. Arquitectura de software
Desde el tiempo en que estuvo vigente el estándar del Instituto de Ingenieros
Eléctricos y Electrónicos (Institute of Electrical and Electronics Engineers, IEEE) IEEE
1471-2000 - IEEE Recommended Practice for Architectural Description for Software-
Intensive Systems, ya se conceptualizaba a la arquitectura como: “la organización
fundamental de un sistema representado por componentes, las relaciones que existen
entre estos, el entorno que la define y los principios que guían su diseño y evolución”
(Institute of Electrical and Electronics Engineers [IEEE]-SA Standards Board, 2000, p.3).
En la norma conjunta entre la Organización Internacional de Estandarización
(International Organization for Standardization, ISO), la Comisión Electrotécnica
Internacional (International Electrotechnical Commission, IEC), y el IEEE, norma
ISO/IEC/IEEE 42010:2011 - Systems and software engineering - Architecture
description, se define también a la arquitectura de un sistema como “conceptos o
propiedades fundamentales de un sistema en su entorno incorporados en sus
elementos, relaciones y en los principios de su diseño y evolución” (International
Organization Of Standardization [ISO], 2011, p.2).
Según lo revisado en estos conceptos, se aprecia que, en 10 años transcurridos
entre las publicaciones de estas 2 normas, y hasta la actualidad, la esencia de su
definición no ha cambiado, con lo que se puede concluir que, el diseño arquitectónico es
un proceso que define cada uno de los componentes y relaciones de un sistema sin
perder de vista su entorno y evolución, los mismos que permiten que una arquitectura
de software esté preparada para soportar tanto sus actuales como sus futuras
exigencias.
47
2.4.2. Contexto de la descripción de la arquitectura.
Una visión gráfica, acerca del concepto de arquitectura y sus componentes, se la
extrae de la norma ISO/IEC/IEEE 42010:2011 - Systems and software engineering -
Architecture description, y como se aprecia en la Figura 7, describe una visión a alto
nivel de su contexto en general, donde a través de notación de diagramas de clases,
explica la relación entre sus diferentes conceptos clave, esta notación describe a la
arquitectura de un sistema de información, como un flujo que empieza con un
disparador, que son los requerimientos de la parte interesada, expresada como
propósitos y preocupaciones del sistema, con sus respectivos intereses por hacerse de
un sistema para atender y dar atención a las necesidades de un entorno, este sistema a
su vez exhibe la arquitectura expresada mediante la descripción de arquitectura.
Figura 7
Contexto de la descripción de la arquitectura.
Nota. Recuperado de ISO/IEC/IEEE 42010:2011.
48
2.4.3. Descripción de arquitectura (AD - Architecture Description)
La norma ISO/IEC/IEEE 42010:2011 - Systems and software engineering -
Architecture description, indica que: “Las descripciones de arquitectura son el resultado
del trabajo de los sistemas y la elaboración de la arquitectura del software” (ISO, 2011,
p.4). Es decir que si, por un lado, la arquitectura tiene que ver con los principios y
conceptos fundamentales de un sistema; la descripción de arquitectura es el resultado y
la forma en que es expresada esta arquitectura.
Garlan & Shaw (1993), complementan el concepto, al afirmar que el diseño
arquitectónico:
Permite identificar los problemas estructurales que involucra la organización
general y estructura de control global; determinar los protocolos de
comunicación, sincronización, acceso a datos, asignación de funcionalidad a
elementos de diseño, distribución física, composición de elementos de diseño,
escalabilidad, selección entre alternativas de diseño y asegura la calidad del
producto final. (p.1)
La arquitectura entonces, es la base en la construcción de software y saberla
elegir correctamente determinará el éxito o fracaso del sistema a construir, una correcta
arquitectura debe traducir las necesidades tanto técnicas como del negocio y dar un
soporte óptimo, pero también debe visionar a futuro y saber cómo soportará nuevas
exigencias, de no ser así, el sistema podría quedar obsoleto y sin posibilidad de
evolución en corto tiempo.
2.4.4. Decisiones arquitecturales
Para abonar en la comprensión de la arquitectura, se revisa el concepto de las
decisiones de arquitectura, que tiene directa relación con los atributos de calidad.
Al respecto, Jansen & Bosch (2005), indican que:
49
Definimos la arquitectura de software como la composición de un conjunto de
decisiones de diseño arquitectónico. Esto reduce la vaporización del
conocimiento de la información de decisiones de diseño, ya que las decisiones
de diseño se han convertido en una parte explícita de la arquitectura. (p.1)
Se debe entender entonces, que la arquitectura termina siendo un conjunto de
“decisiones” explícitas de diseño arquitectónico de la forma causa – efecto. En vista que
el término “decisiones de arquitectura”, pudiera confundirse con la de “modelo de
decisión”, que es el tema general del presente trabajo, se ejemplifica a continuación este
concepto, con un atributo de calidad, en este caso, la escalabilidad.
En la Tabla 1 entonces, se presenta una descripción de decisión arquitectural del
atributo de calidad o decisión arquitectónica “escalabilidad”.
50
Tabla 1
Decisión arquitectural de Escalabilidad.
Nota: Recuperado de Niu, Liu & Li, 2018.
Decisión de arquitectura
Atributo de
calidad
Escalabilidad
Necesidad Se requiere que el sistema sea capaz de soportar un
incremento considerable de usuarios concurrentes sin afectar
su tiempo de respuesta.
Solución Usando tecnología DOCKER, crearemos varios contenedores
con el mismo servicio con DOCKER-SWARM, para
“distribuirse” de forma transparente y proporcional entre varios
hosts, configurando varios contenedores de uno o de
diferentes servicios (balanceo de carga), sin tener que instalar
elementos adicionales y con algoritmo de selección round-
robin, comportamiento de SWARM por defecto.
Justificación Docker Swarm permite configurar una infraestructura con
balanceadores de carga, los mismos que son utilizados para
gestionar solicitudes cuando existe gran concurrencia de
usuarios simultáneos.
Se decidió implementar este mecanismo coreográfico de
Docker Swarm, pues permite equilibrar las peticiones que
llegan de los clientes a los servidores y contribuye a mantener
un tiempo de respuesta adecuado, cuando existe gran
cantidad de solicitudes queriendo acceder a la información al
mismo tiempo.
Se utilizará el algoritmo Round Robin , para determinar el
orden de atención que se les dará a las peticiones gestionadas
por los servicios.
Modelo Figura 8
MSA de un sitio web de comercio electrónico.
Nota: Recuperado de Niu, Liu & Li, 2018
51
La interpretación de la Tabla 1, indica entonces un ejemplo de una decisión
arquitectónica en la que se observa sus partes constitutivas, y en donde se describe la
necesidad y la solución, además de la justificación, punto importante en el sustento de la
decisión, además en su Figura 8 interna, se observa el diagrama del funcionamiento e
interacción de las API del tipo de Transferencia de Estado Representacional
(Representational State Transfer, REST), dentro de un sistema de comercio electrónico,
orquestadas a través de un API Gateway y donde cada microservicio gestiona una
funcionalidad bien definida del sistema, tal como: productos, órdenes de pagos,
mercadotecnia y clientes.
2.4.5. Partes interesadas (stakeholders)
La norma ISO/IEC/IEEE 42010:2011 - Systems and software engineering -
Architecture description, conceptualiza a las partes interesadas como: “individuo,
equipo, organización o clases de los mismos, que tienen interés en un sistema” (ISO,
2011, p.2).
Entendemos entonces, que todo lo que interactúa, que afecta o es afectado por
el software, es una parte interesada o stakeholder como, por ejemplo: accionistas,
clientes, usuarios, por un lado, al igual que ingenieros, programadores, Administrador de
Base de datos (Data Base Administrator, DBA), por el otro.
2.4.6. Vistas (views)
Júnior et al. (2019), en su trabajo “A Systematic Mapping Study on Software
Architectures Description Based on ISO/IEC/IEEE 42010:2011” indican que las vistas
son: “producto de trabajo que expresa la arquitectura de un sistema desde la
perspectiva de las preocupaciones específicas del sistema” (p.2).
Es decir que son las descripciones de la arquitectura desde los intereses y/o
atributos de calidad que hayan sido elegidas para ser tratadas en la arquitectura.
52
2.4.7. Puntos de vista (viewpoints)
De la misma forma Júnior et al., (2019), en el mismo trabajo “A Systematic
Mapping Study on Software Architectures Description Based on ISO/IEC/IEEE
42010:2011” definen a los puntos de vista como: “producto de trabajo que establece las
convenciones o la construcción, interpretación y uso de vistas de arquitectura para
enmarcar preocupaciones específicas del sistema” (p.3).
Un punto de vista es entonces una forma de ver los sistemas; dicho de otra
manera, una vista es el resultado de aplicar un punto de vista a un sistema de interés
particular.
Para un mejor entendimiento de los términos algo confusos del párrafo anterior,
una analogía muy ilustrativa que indica la misma norma ISO/IEC/IEEE 42010:2011
Systems and software engineering - Architecture description, dice que: “una vista es a
un punto de vista, como un programa es a un lenguaje de programación” (ISO, 2011,
p.21).
2.4.8. Preocupaciones de arquitectura (concerns)
Una vez más, la norma ISO/IEC/IEEE 42010:2011, define esta vez el concepto
de preocupación (concern), indicando que es el: “interés en un sistema relevante para
una o más de sus partes interesadas” (ISO, 2011, p.2).
Además, añade que una preocupación es cualquier influencia sobre un sistema
en su entorno, incluidas las influencias de desarrollo, tecnológicas, comerciales,
operativas, organizativas, políticas, económicas, legales, regulatorias, ecológicas y
sociales (ISO, 2011, p.2).
2.4.9. Tipo de modelo (Model kind)
La norma ISO/IEC/IEEE 42010:2011 - Systems and software engineering -
Architecture description, indica que el tipo de modelo son: “convenciones para un tipo de
modelado. Ejemplos de tipos de modelos incluyen diagramas de flujo de datos,
53
diagramas de clases, redes de Petri, hojas de balance, organigramas y modelos de
transición de estados.” (ISO, 2011, p.3).
Es decir que, los tipos de modelos, constituyen ayudas gráficas para describir de
mejor manera la arquitectura.
2.4.10. Entorno (environment)
El entorno, de acuerdo a la norma ISO/IEC/IEEE 42010:2011 - Systems and
software engineering - Architecture description, es el: “contexto que determina el entorno
y las circunstancias de todas las influencias sobre un sistema. El entorno de un sistema
incluye influencias de desarrollo, tecnológicas, comerciales, operativas, organizativas,
políticas, económicas, legales, reglamentarias, ecológicas y sociales” (ISO, 2011, p.2).
El entorno se torna determinante en una arquitectura, porque no es un factor que
siempre puede aplicarse a todo fenómeno, factor o atributo, pues estas características y
sus repercusiones siempre dependerán del entorno en el que se presentan.
2.4.11. Arquitectura y descripciones de la arquitectura
En la figura 9 se aprecia en forma más detallada la correspondencia entre los
distintos componentes y relaciones que conforman la arquitectura, es decir lo que
corresponde a descripción de arquitectura.
Entre las principales relaciones que nos describe, se observa que las partes
interesadas, tienen intereses en un sistema, el cual exhibe una arquitectura, expresada
en una descripción de arquitectura, en una relación de composición, como partes de la
arquitectura tenemos una justificación de arquitectura, correspondencia, regla de
correspondencia, vista de arquitectura y punto de vista de arquitectura como visión
general, además de otras lecturas que se pudiesen interpretar.
54
Figura 9
Correspondencia, reglas de correspondencia y detalles adicionales sobre la justificación
de la arquitectura.
Nota. Recuperado de ISO/IEC/IEEE 42010:2011.
2.4.12. Etapas del diseño arquitectónico.
Según Losavio de Ordáz & Guillen-Drija (2006), El diseño arquitectónico es un
conjunto de etapas por las cuales pasa la arquitectura de software antes de ser definida
como tal, el objetivo de cada una de estas etapas es analizar e ir refinando los
elementos que intervienen en la creación de una arquitectura tomando como base los
requerimientos del cliente. Cada etapa del diseño arquitectónico es secuencial lo que
permite que la arquitectura sea creada de forma sistematizada y validada, ya que solo
55
se pasa a la siguiente etapa de diseño si la actual ha cumplido con todos sus requisitos,
estas etapas son:
1. Etapa de Preparación.
2. Etapa de Derivación Arquitectónica.
3. Etapa de Refinamiento Arquitectónico.
4. Etapa de Resolución de Resonancia Arquitectónica.
Etapa de preparación. La etapa de preparación fundamentalmente consiste en
la recopilación de los requerimientos funcionales y no funcionales de la aplicación, a
pesar que se da por hecho que estos requerimientos ya deberían estar definidos, estos
pasan a ser analizados exhaustivamente con el fin de encontrar las características que
deben ser soportadas por la arquitectura, para ello, Losavio de Ordáz & Guillen-Drija
(2006), indican que esta etapa es: “En la que se deben organizar los requerimientos ya
levantados. Se supone que, como etapa previa al diseño arquitectónico, un proceso de
levantamiento de requerimientos se ha llevado a cabo, generando como mínimo una
lista de requerimientos funcionales” (p.133).
Etapa de derivación arquitectónica. Esta etapa se caracteriza por ser
altamente analítica ya que usa los requerimientos previamente obtenidos para definir la
arquitectura base que se usará, así como su estructura, los patrones de diseño, técnicas
de diseño y elecciones tecnológicas de la misma. Según Losavio de Ordáz & Guillen-
Drija (2006), esta etapa: “persigue generar una arquitectura base o inicial sobre la cual
poder realizar transformaciones para así lograr una arquitectura que responda a los
requerimientos tanto funcionales como no funcionales” (p.134).
Etapa de refinamiento arquitectónico. Una vez definida la arquitectura base es
necesario refinar la misma y esta etapa se especializa en ello, para lograrlo se realiza un
análisis técnico específico de los requerimientos a resolver y se usa la arquitectura base
para encontrar las tecnologías que sean compatibles con la misma y de esta manera
56
resolver dichos requerimientos, según Losavio de Ordáz & Guillen-Drija (2006), esta
etapa consiste en la: “Identificación de subsistemas, estilos y patrones: a partir de los
escenarios identificados como artefactos S (artefactos que describen características que
involucran a todo a una amplia sección de componentes del sistema) o SP (artefactos
relacionados con propiedades del sistema)” (p.135).
Etapa de resolución de resonancia arquitectónica. Está etapa consiste
esencialmente en la validación de la arquitectura y sus componentes por medio de la
identificación de los problemas o riesgos de manera temprana, esta etapa define si la
arquitectura seleccionada cumple con las necesidades de la aplicación y si no es así, es
la etapa pertinente para realizar el proceso nuevamente, Según Losavio de Ordáz &
Guillen-Drija (2006), esta etapa está compuesta por las siguientes actividades:
“Evaluación de la arquitectura: Que consiste en validar la arquitectura lograda
en la etapa anterior según ATAM (Kazman et al., 2000, como se citó en Losavio
de Ordáz & Guillen-Drija, 2006).
Transformación arquitectónica: Si el conjunto de riesgos es notable, entonces
se deben aplicar los enfoques y mecanismos arquitectónicos que permitan
solucionar o al menos minimizarlos, lo que conduciría a una nueva
transformación de la arquitectura” (p.136).
Esta es la última etapa arquitectónica y esencialmente es aquella que determina
si la arquitectura definida hasta aquí, está correctamente planteada, si es así, esta
arquitectura está lista para ser implementada ya que demuestra tener las características
necesarias para resolver las necesidades del sistema.
2.4.13. Microservicio
De acuerdo a Le (2018), en su trabajo denominado “Microservice-Based System
for Environmental Science Software Applications”:, el término microservicios se refiere al
concepto de servicios web granulares que permanecen independientes entre sí como
57
"Micro-Web-Services" (Rodgers, 2005, como se citó en Le, 2018), La idea entonces es
que estos servicios pequeños, tengan roles simples y singulares y que permanezcan
independientes entre sí.
Todos estos servicios web, para ser independientes y granulares, pueden tener
diferentes bases de código en lenguajes de programación diferentes y además contra
diferentes bases de datos. Esto permite que cada equipo de desarrollo a cargo de un
servicio, pueda elegir el mejor lenguaje o base de datos para el trabajo. Aunque la base
del código y la base de datos pueden ser diferentes, cada servicio aún se comunica a
través de una API REST, por lo que hay muy pocos cambios entre los microservicios.
Características de los microservicios (factores técnicos)
En la arquitectura de los microservicios intervienen algunas características que
tienen que ver con atributos de calidad, pero también con requerimientos funcionales del
sistema. Un aspecto importante que se pretende introducir en este trabajo, es lo
relacionado con los que se denominará Factores Técnicos, que son la base conductora
que fundamentan el diseño de la propuesta de modelo de decisión a desarrollarse, en
este aspecto se ha decidido definirles así, para no referirnos específicamente a los
atributos de calidad, es decir requisitos no funcionales, o por otro lado a los
requerimientos funcionales, no se pretende encasillarse en ninguno de los dos grupos,
porque nuestros hallazgos pueden encontrar conductores de ambos, hemos llamado a
estos Factores Técnicos en general, tales como: Usabilidad, Tiempo de respuesta o
Tolerancia a fallos pero también, cohesión o acoplamiento de las API, por ejemplo.
Algunos de estos Factores Técnicos correspondientes a atributos de calidad, los
encontramos conceptualizados en la norma ISO/IEC 25010:2011 - Systems and
software engineering - Systems and software Quality Requirements and Evaluation
(SQuaRE) — System and software quality models., atributos de calidad que están
58
presentes en la arquitectura de microservicios, aunque no son exclusivos de esta, y que
a continuación se describe algunos de ellos.
2.4.14. Accesibilidad
Definida como el: “Grado en el que un producto o sistema puede ser utilizado por
personas con la más amplia gama de características y capacidades para lograr un
objetivo específico en un contexto de uso específico” (ISO/IEC - 25010, 2011).
Muchas veces tiene que ver con la accesibilidad de los sistemas de información
para personas con algún tipo de discapacidad física.
2.4.15. Acoplamiento
El acoplamiento se define como “La medida de la fuerza de asociación
establecida por una conexión de un módulo a otro” (Stevens, Myers & Constantine,
1974, como se citó en Tiwari & Rathore, 2018, p.2). Se añade que, por ejemplo, en la
programación orientada a objetos, el acoplamiento se define como el grado con el cual,
una clase se conecta a otra. El acoplamiento muestra también la dependencia que tiene
con respecto de las otras clases. Un alto valor de acoplamiento reduce la reutilización y
aumenta el esfuerzo de mantenimiento de clase y, por lo tanto, del sistema de software
(Tiwari & Rathore, 2018).
Se entiende entonces que es el grado de dependencia que tiene una clase o
componente, con otra, en este sentido está directamente relacionado con el concepto de
cohesión, con el cual casi forman un solo factor técnico presente por supuesto, en las
MSA.
2.4.16. Adaptabilidad
Es el “Grado en el que un producto o sistema puede adaptarse de manera eficaz
y eficiente para hardware, software u otros entornos operativos o de uso diferentes o en
evolución” (ISO/IEC - 25010, 2011).
59
Tiene que ver directamente con la capacidad de reutilizar componentes
altamente desacoplados para poder crear una nueva funcionalidad de acuerdo a un
nuevo requerimiento del usuario, inclusive desarrolladas en herramientas diferentes
para cada servicio.
2.4.17. Cohesión
La cohesión se define como “el grado de conectividad entre los elementos de un
módulo (Stevens, Myers & Constantine, 1974, como se citó en Eder, Kappel & Schrefl,
1994). Una clase es cohesiva si la asociación de elementos declarados en la clase se
centra en realizar una única tarea. La cohesión muestra la fuerza interna de una clase.
Existe una compensación entre el acoplamiento y la cohesión por la calidad del
software. El acoplamiento se puede reducir aumentando la cohesión y viceversa” (Eder
et al., 1994, como se citó en Tiwari & Rathore, 2018, p.2).
En términos generales, una clase altamente cohesionada es aquella que
implementa una funcionalidad, lo más completa posible de forma altamente
especializada, haciendo únicamente el trabajo para el que fue creada, con lo que se
espera que no dependa de otras clases para realizar su trabajo.
2.4.18. Confiabilidad
Es el: “Grado en el que un usuario u otra parte interesada tiene confianza en que
un producto o sistema se comportará según lo previsto” (ISO/IEC - 25010, 2011).
2.4.19. Contenerización
Relativa al uso de contenedores, donde un contenedor es una unidad estándar
de software que empaqueta el código y todas sus dependencias para que la aplicación
se ejecute de forma rápida y confiable de un entorno informático a otro. Una imagen de
contenedor de Docker, por ejemplo, es un paquete de software ligero, independiente y
ejecutable que incluye todo lo necesario para ejecutar una aplicación: código, tiempo de
60
ejecución, herramientas del sistema, bibliotecas del sistema y configuraciones (Docker
Inc., 2020).
2.4.20. Coreografía
Es un sistema de comunicación entre los microservicios, la coreografía es más
colaborativa que su contraparte la orquestación, y
permite que cada parte involucrada describa su parte en la interacción. La
coreografía rastrea las secuencias de mensajes entre múltiples partes y fuentes,
generalmente los intercambios de mensajes públicos que ocurren entre servicios
web, en lugar de un proceso comercial específico que ejecuta una sola parte.
(Peltz, 2003, p.1).
2.4.21. Descubrimiento
Dado que los microservicios generalmente se distribuyen en diferentes hosts, se
necesitan mecanismos para el registro y el descubrimiento de servicios para garantizar
que los servicios puedan encontrarse entre sí. Esto también incluye mecanismos para
encontrar versiones específicas de servicios. (Haselböck et al., 2017b, p.7)
Respecto del descubrimiento o también llamado Registro, Rotter et al. (2017),
indican que:
El tema del descubrimiento de servicios no es nuevo, pero ha evolucionado
rápidamente en los últimos años debido a la explosión de servicios y nuevos
patrones arquitectónicos emergentes como los microservicios.
El ejemplo más simple / antiguo de un sistema de descubrimiento de
servicios es el Sistema de Nombres de Dominio (Domain Name System, DNS),
donde cada servicio tiene un nombre y el sistema DNS convierte estos nombres
en un conjunto de direcciones IP. Sin embargo, las arquitecturas complejas
orientadas a servicios requieren formas avanzadas de descubrimiento de
61
servicios que incluyen características como almacenar metadatos sobre el
servicio o el estado de las instancias del servicio (p.01).
2.4.22. Disponibilidad
“Grado en el que un sistema, producto o componente es operativo y accesible
cuando se requiere para su uso” (ISO/IEC - 25010, 2011). Este factor tiene mucho que
ver con la infraestructura tanto física como lógica en la que se despliegan los
microservicios, quienes dentro de su potencialidad está precisamente el de utilizar
infraestructura en la nube para aumentar, en este caso, su disponibilidad.
2.4.23. Efectividad
“Precisión e integridad con la que los usuarios logran objetivos específicos”
(ISO/IEC - 25010, 2011).
Cuando se decide desarrollar un nuevo sistema en microservicios o se desea
migrar hacia esta arquitectura, se espera que los resultados en función de rendimiento,
velocidad, seguridad, adaptabilidad, escalabilidad, entre otros, sean mejores que los
obtenidos con una arquitectura monolítica, en este caso la efectividad representa
entonces, el grado en que estos objetivos son alcanzados.
2.4.24. Eficiencia
“Recursos gastados en relación con la precisión e integridad con la que los
usuarios logran los objetivos” (ISO/IEC - 25010, 2011).
En el caso de los microservicios, se espera que, con su implementación, y
manteniendo la base de la infraestructura, se obtenga mejor performance con el mínimo
consumo de recursos, de tal manera que se obtenga un mejor aprovechamiento
costo/beneficio de esta.
2.4.25. Escalabilidad
La escalabilidad es a menudo una razón fundamental para que las empresas
migren hacia una arquitectura de microservicio, ya que permite el escalado
62
independiente y selectivo de servicios individuales. La escalabilidad se puede
lograr en diferentes niveles, por ejemplo, replicando servicios, dividiendo la
funcionalidad de la que es responsable un servicio o dividiendo los datos de los
que es responsable un servicio. Para hacer frente a los servicios de escalado
independiente, también se deben considerar los mecanismos de
almacenamiento en caché y equilibrio de carga. (Haselböck et al., 2017b, p.7)
Se debe considerar entonces la infraestructura sobre la cual se pretende
implementar la arquitectura de microservicios, y sus diferentes configuraciones, ya sea a
través de escalamiento vertical u horizontal, en donde las prestaciones de XaaS4 y de
infraestructuras convergentes5 e hiperconvergentes6, definitivamente, son las mejores
aliadas para sacarle un verdadero partido a la MSA.
2.4.26. Fiabilidad
“Grado en el que un sistema, producto o componente realiza funciones
específicas en condiciones específicas durante un período de tiempo específico”
(ISO/IEC - 25010, 2011).
Uno de los avances y promesas de la MSA es precisamente producir sistemas
más confiables y fiables, y esto pretende conseguirse con el hecho de dividir las
funcionalidades en varias más pequeñas lo más independientes posible, de tal forma
4 Es una abstracción que se conoce colectivamente como XaaS o Everything as a Service , y puede crear
cualquier parte de XaaS en diferentes niveles de arquitectura del sistema, tales como PaaS (Platform as a
Service), Iaas (Infraestructure as a Service).
https://www.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/cf10000_.htm 5 La tecnología de infraestructura convergente combina diversos elementos de infraestructura que potencian
la TI, como servidores, dispositivos de almacenamiento de datos, funciones de redes, virtualización,
software de administración, coordinación y aplicaciones. https://www.delltechnologies.com/es-
es/converged-infrastructure/definitions.htm. 6 La infraestructura hiperconvergente combina los mismos tipos clave de componentes de TI que la
infraestructura convergente, pero en un rack o dispositivo escalable que le permite modernizar su centro de
datos con administración simplificada, rendimiento mejorado y escalabilidad flexible.
https://www.delltechnologies.com/es-es/converged-infrastructure/definitions.htm
63
que, si un servicio sufre una caída, esta no afecte al resto de los servicios y el sistema
siga funcionando, es una de las principales diferencias con un monolito.
2.4.27. Flexibilidad
“Grado en el que un producto o sistema se puede utilizar con eficacia, eficiencia,
ausencia de riesgo y satisfacción en contextos más allá de los inicialmente
especificados en los requisitos” (ISO/IEC - 25010, 2011).
Otro gran hito alcanzado por la MSA, tiene que ver con la capacidad de que cada
microservicio pueda ser desarrollado en diferente lenguaje de programación y base de
datos, con lo que se reduce sustancialmente la dependencia tecnológica de las
capacidades tecnológicas de los programadores y herramientas con que cuente la
empresa.
2.4.28. Integración
Las arquitecturas de microservicios comprenden potencialmente miles de
servicios desarrollados y operados de forma independiente, que deben
integrarse entre sí. La integración de servicios puede ocurrir en diferentes
niveles, como el nivel de interfaz de usuario, el nivel de servicio o el nivel de
datos. (Haselböck et al., 2017b, p.6)
2.4.29. Interoperabilidad
“Grado en el que dos o más sistemas, productos o componentes pueden
intercambiar información y utilizar la información que se ha intercambiado” (ISO/IEC -
25010, 2011).
Esta característica se consigue gracias a los lenguajes comunes, a través de los
cuales, las APIs, intercambian información, entre los que destacan, el Lenguaje de
Marcado Extensible (eXtensible Markup Language, XML) y la Notación de Objetos de
JavaScript (JavaScript Object Notation, JSON).
64
2.4.30. Mantenibilidad
“Grado de efectividad y eficiencia con el que los mantenedores previstos pueden
modificar un producto o sistema” (ISO/IEC - 25010, 2011).
Si bien en el caso de los microservicios, la capacidad de realizar pequeños
trozos de un sistema, permite obtener una mejor escalabilidad y modularidad, el hecho
de tener muchos microservicios puede dificultar la mantenibilidad.
2.4.31. Modificabilidad
“Grado en el que un producto o sistema puede modificarse de manera eficaz y
eficiente sin introducir defectos o degradar la calidad del producto existente” (ISO/IEC -
25010, 2011).
2.4.32. Modularización
“Grado en el que un sistema o programa de computadora está compuesto de
componentes discretos de manera que un cambio en un componente tiene un impacto
mínimo en otros componentes” (ISO/IEC - 25010, 2011).
Tiene mucho que ver con la capacidad que tiene un sistema, de tener un bajo
acoplamiento en sus componentes, lo que le indica que mientras más independencia
tengan estos, mejor su capacidad de modularización.
2.4.33. Monitoreo y registro
Monitorear sistemas basados en microservicios es un desafío debido a la gran
cantidad de servicios independientes, que pueden estar ubicados en diferentes
hosts. Esto requiere soporte para la recopilación, distribución y combinación
automáticas de los datos de monitoreo de los diferentes servicios. El monitoreo
debe incluir el rendimiento de la aplicación, los procesos comerciales, el
seguimiento y el registro. (Haselböck et al., 2017b, p.8)
65
2.4.34. Orquestación
La orquestación se refiere a un proceso comercial ejecutable que puede
interactuar con servicios web internos y externos. Las interacciones ocurren a
nivel de mensaje. Incluyen lógica empresarial y orden de ejecución de tareas, y
pueden abarcar aplicaciones y organizaciones para definir un modelo de proceso
transaccional de varios pasos de larga duración. La orquestación siempre
representa el control desde la perspectiva de una de las partes. (Peltz, 2003, p.1)
2.4.35. Portabilidad
“Grado de efectividad y eficiencia con el que un sistema, producto o componente
se puede transferir de un hardware, software u otro entorno operativo o de uso, a otro”
(ISO/IEC - 25010, 2011).
2.4.36. Probabilidad
“Grado de efectividad y eficiencia con el que se pueden establecer criterios de
prueba para un sistema, producto o componente y se pueden realizar pruebas para
determinar si esos criterios se han cumplido” (ISO/IEC - 25010, 2011).
2.4.37. Recuperabilidad
“Grado en el que, en caso de una interrupción o falla, un producto o sistema
puede recuperar los datos directamente afectados y restablecer el estado deseado del
sistema” (ISO/IEC - 25010, 2011).
2.4.38. Reutilización
“Grado en el que un activo se puede utilizar en más de un sistema o en la
construcción de otros activos” (ISO/IEC - 25010, 2011).
2.4.39. Seguridad
“Grado en el que un producto o sistema protege la información y los datos para
que las personas u otros productos o sistemas tengan el grado de acceso a los datos
adecuado a sus tipos y niveles de autorización” (ISO/IEC - 25010, 2011).
66
2.4.40. Tiempo de respuesta
“Grado en el que los tiempos de respuesta y procesamiento y las tasas de
rendimiento de un producto o sistema, al realizar sus funciones, cumplen” (ISO/IEC -
25010, 2011).
2.4.41. Tolerancia a fallos
“Grado en el que un sistema, producto o componente funciona según lo previsto
a pesar de la presencia de fallas de hardware o software” (ISO/IEC - 25010, 2011).
2.4.42. Usabilidad
“Grado en el que un producto o sistema puede ser utilizado por usuarios
específicos para lograr objetivos específicos con efectividad, eficiencia y satisfacción en
un contexto de uso específico” (ISO/IEC - 25010, 2011).
Otros conceptos relacionados
2.4.43. ADL (Architecture Description Language)
Los lenguajes de descripción de arquitectura son, según Rico (2015): “La
definición concreta de arquitecturas de software mediante una notación que permite la
descripción de la configuración de sistemas de software de acuerdo a sus elementos y
propiedades arquitecturales (componentes, conectores y restricciones)” (p.09).
Características que debe tener un ADL según Allen (1997):
Descripción de configuraciones de arquitecturas. Debe permitir la definición de
los componentes y las interacciones que ocurren dentro del sistema.
Descripción de estilos arquitecturales. La herramienta debe permitir la
identificación de familias de sistemas haciendo uso de características
comunes que facilitan los esfuerzos de análisis e implementación.
Capacidad de análisis sobre propiedades de interés. La descripción debe
permitir la identificación y análisis de las propiedades del sistema con el
objetivo de establecer si el sistema cumple con los requerimientos definidos.
67
Aplicación a problemas prácticos de la vida real. La utilidad del lenguaje no
solo debe enfocarse en el análisis de propiedades valiosas para el sistema,
también debe ofrecer una notación que pueda aplicarse en cualquiera de los
escenarios de problemas reales y no solo en circunstancias con ciertas
características.
(p.09).
2.4.44. API (Application Programming Interface)
En el mundo de los microservicios, la forma de comunicarse es a través de APIs,
que son las interfaces que dan la cara en la entrega y recepción de información, al
respecto en Red Hat Inc. (2019) se indica que:
Una API es un conjunto de definiciones y protocolos que se utiliza para
desarrollar e integrar el software de las aplicaciones. API significa interfaz de
programación de aplicaciones.
Las API permiten que sus productos y servicios se comuniquen con otros,
sin necesidad de saber cómo están implementados. Esto simplifica el desarrollo
de las aplicaciones y permite ahorrar tiempo y dinero. Las API le otorgan
flexibilidad; simplifican el diseño, la administración y el uso de las aplicaciones, y
proporcionan oportunidades de innovación, lo cual es ideal al momento de
diseñar herramientas y productos nuevos (o de gestionar los actuales) […] Las
API son un medio simplificado para conectar su propia infraestructura a través
del desarrollo de aplicaciones nativas de la nube, pero también le permiten
compartir sus datos con clientes y otros usuarios externos. Las API públicas
representan un valor comercial único porque simplifican y amplían la forma en
que se conecta con sus partners y, además, pueden rentabilizar sus datos (un
ejemplo conocido es la API de Google Maps).
68
En la Figura 10, se observa a las APIs, como una capa intermedia entre los
dispositivos y los sistemas, y que debido a su importancia y número necesitan de un
mecanismo de gestión como es el caso de la coreografía.
Figura 10
Entorno de comunicación de las APIs.
Nota. Recuperado de Red Hat Inc., 2019.
2.4.45. API gateway
Respecto de la gateway, la página oficial de Red Hat Inc. (2019), indica que:
Una puerta de enlace de API es una herramienta de gestión de API que se
encuentra entre el cliente y un conjunto de servicios de backend.
Funciona como un proxy inverso que acepta todas las llamadas a
la interfaz de programación de la aplicación, agrega los servicios necesarios para
cumplir con las solicitudes y devuelve el resultado adecuado. […] La función
exacta de una puerta de enlace de API varía de una implementación a otra.
Algunas funciones comunes incluyen la autenticación, el enrutamiento, la
limitación de la frecuencia, la facturación, la supervisión, el análisis, las políticas,
las alertas y la seguridad.
En la Figura 11, el esquema de comunicación de un API Gateway.
69
Figura 11
Comunicación por API-gateway.
Nota. Recuperado de Song, Zhang & Haihong, 2019.
2.4.46. Contrato (de servicios SOA)
Característica propia de la arquitectura SOA, heredada a los microservicos, y de
la cual Pisani, Miraballes & García (2016) indican:
Contratos de servicios estandarizados: Este es el principio fundamental que
establece que tiene que existir un contrato estandarizado para cada servicio. Los
servicios expresan su propósito y funcionalidades a través de su contrato (p.09).
Es decir que el contrato es una capa adicional que provee información, del
formato y los datos, que es publicada por el proveedor del servicio para ser entregada y
que sea consumida por otra API, existen en el mercado herramientas que posibilitan su
utilización, tales como YAML, SOAPUI, JSON, SWAGGER, entre otras.
2.4.47. DevOps (DEVelopment & OPerationS)
Un término que, aunque no es parte de la arquitectura de microservicios como
tal, ni de su aplicación exclusiva, sí tiene mucho que ver, por las repercusiones que ha
tenido en el desarrollo de aplicaciones en este nuevo escenario, donde el desarrollo ágil
70
y el proceso de integración y entrega continua junto al aseguramiento de la calidad han
venido a mejorar los procesos de trabajo. En este contexto aparece la cultura de
Desarrollo y Operaciones, DevOps.
Al respecto, Ebert et al. (2016), en su trabajo denominado “DevOps”, nos da su
conceptualización e indica:
DevOps integra los dos mundos del desarrollo y las operaciones, utilizando el
desarrollo, la implementación y el monitoreo de la infraestructura automatizados.
Es un cambio organizacional en el que, en lugar de grupos aislados que realizan
funciones por separado, los equipos multifuncionales trabajan en la entrega
continua de funciones operativas. Este enfoque ayuda a entregar valor de forma
más rápida y continua, reduciendo los problemas debidos a la falta de
comunicación entre los miembros del equipo y acelerando la resolución de
problemas (Virmani, 2015, como se citó en Ebert et al., 2016). DevOps significa
un cambio de cultura hacia la colaboración entre el desarrollo, la garantía de
calidad y las operaciones. (p.2)
DevOps se puede definir entonces como un conjunto de prácticas o una filosofía
que combina las actividades de desarrollo y operaciones de Tecnologías de Información
(Information Technology, IT) , es decir las tareas de un profesional en programación de
sistemas con las de un profesional en ingeniería de sistemas, que en conjunto con las
metodologías de desarrollo ágiles, el aseguramiento de la calidad, integración y entrega
continuas, sumadas a las características propias de la MSA, potencializan a todo el ciclo
de vida del desarrollo y la operación de un sistema de información.
2.4.48. Endpoint
Los puntos finales (endpoints) son las direcciones por las cuales se ejecuta y
envía parámetros vía Localizador de Recursos Uniforme (Uniform Resource Locator,
URL), al respecto Brito & Valente (2020) manifiestan que:
71
Son la abstracción clave proporcionada por REST. En REST, un endpoint (punto
final) se define mediante una URL y una lista de parámetros. Por ejemplo, en la
API REST de GitHub
GET / search / repositories?q= stars:> 100
Es un punto final que devuelve datos sobre los repositorios de GitHub
con más de 100 estrellas. Dado que los puntos finales (endpoints) REST se
basan en recursos del Protocolo de transferencia de hipertexto (Hypertext
Transfer Protocol, HTTP) para admitir consultas (URL, parámetros GET / PUT,
etc.), pueden considerarse abstracciones de bajo nivel.
Por el contrario …. la consulta REST anterior se implementa en GraphQL
de la siguiente manera:
1 query searchRepos {
2 search(query:“stars:>100”, first:100, type:REPOSITORY){
3 nodes {
4 ... on Repository{ nameWithOwner }
5 }
6 }
7 }
(p.01).
Por lo anterior expuesto se concluye entonces que en GraphQL se elimina el
concepto de endpoints de API REST y se implementan las APIs a través de funciones
en una estructura más acoplada a un lenguaje de consulta.
2.4.49. Entrega Continua (CD – Continuous Delivery)
En el trabajo “Evaluation of a qualitative model for a company's technical maturity
within Continuous Integration, Continuous Delivery and DevOps”, Hagsten (2018) indica
que:
72
La Entrega Continua (Continuous Delivery, CD) es una extensión de la
Integración Continua (Continuous Integration, CI), con el objetivo de hacer que
cada cambio registrado en el control de versiones sea un Candidato de
Lanzamiento (Release Candidate, RC) potencial, por lo que las
implementaciones de software pueden automatizarse completamente desde el
registro hasta la implementación en el entorno de producción. El CD ha ido en
aumento después de la adopción generalizada de CI en la industria del
desarrollo de software; en la actualidad, algunas de las mayores empresas de TI
del mundo utilizan CD, (Humble et al., 2020, como se citó en Hagsten, 2018,
p.17).
El concepto de CD despegó después de la publicación del libro Continuous
Delivery: Reliable Software Releases through Build, Test, and Deployment
Automation que fue lanzado en 2010 (Humble & Farley, 2010). Dado que la
técnica promueve ciclos más cortos, supuestamente reduce los costos, la
inversión de tiempo y los riesgos de realizar cambios en la producción. (p.17).
En resumen, la Entrega Continua (CD), “Es un enfoque de ingeniería de software
en el que los equipos producen software valioso en ciclos cortos y se aseguran de que
el software se pueda lanzar de forma fiable en cualquier momento” (Chen, 2015, p.1), La
entrega continua, despliegue continuo o implementación continua, implica la
automatización de la construcción, prueba y despliegue (Humble & Farley, 2010).
En la arquitectura de microservicios esta entrega continua (CD), está muy ligada
al concepto de integración continua (CI), casi convirtiéndose en un solo factor y que
acompañadas por prácticas de desarrollo ágil de aplicaciones son la base conceptual de
nuevos enfoques como DevOps.
73
2.4.50. GraphQL
El lenguaje GraphQL se puede considerar como un tipo o una evolución de las
API REST, y se trata principalmente de un lenguaje de consulta para API y un tiempo de
ejecución para completar esas consultas con sus datos existentes. GraphQL
proporciona una descripción completa y comprensible de los datos en su API, brinda a
los clientes el poder de pedir exactamente lo que necesitan y nada más, pudiendo
personalizar los resultados, lo que no se obtiene con API REST, facilita la evolución de
las API con el tiempo y habilita poderosas herramientas de desarrollo. La principal
diferencia entre una API REST y una API GraphQL radica en que la primera necesita de
un Identificador de Recursos Uniforme (Uniform Resource Identifier, URI) por cada
servicio web, mientras que la segunda expone un solo endpoint URI (Facebook, 2016).
En la Figura 12, se observa un ejemplo del código de una consulta con código de
GraphQL en la sección de arriba, mientras que en la sección de abajo se observa el
resultado obtenido en formato de Notación de Objetos JavaScript (JavaScript Object
Notation, JSON).
Figura 12
Ejemplo de una consulta general en GraphQL.
Nota: fuente (Facebook, 2016).
74
2.4.51. Integración Contínua (CI – Continuous Integration)
Una acepción de CI la encontramos en el trabajo denominado “Evaluation of a
qualitative model for a company's technical maturity within Continuous Integration,
Continuous Delivery and DevOps”, en donde Hagsten (2018), indica que:
CI es una práctica de desarrollo de software que pone énfasis en que los
desarrolladores integren frecuentemente su código en repositorios compartidos,
preferiblemente varias veces al día (Duvall et al., 2007 & Kim et al., 2016, como
se citó en Hagsten, 2018, p.12), limitando así el alcance de cada cambio ya que
el tamaño del lote de software disminuye. Luego, cada verificación de código se
evalúa y verifica mediante pruebas automatizadas para detectar regresiones. El
propósito de esta práctica es detectar errores en una etapa temprana del
desarrollo y proporcionar información rápida a los desarrolladores sobre los
efectos de su código verificado. Los errores de integración pueden ser costosos
de resolver si se detectan más tarde. Un requisito previo para CI son amplios
entornos de prueba automatizados y automatización de compilación para facilitar
la canalización automatizada (Duvall et al., 2007 & Kim et al., 2016, como se citó
en Hagsten, 2018, p.12). La idea general es que cada compilación debe pasar
todas las etapas de prueba en la tubería (pipeline7) y si se descubre un error, la
corrección de ese error tiene prioridad. (p.12)
2.4.52. Integración y Entrega Continuas (CI/CD)
Otro término relacionado con la MSA y DevOps, tiene que ver con la Integración
Continua y la Entrega Continua, como una sola característica casi compuesta, esta
7 Expresión automatizada de su proceso para obtener software desde el control de versiones hasta sus
usuarios y clientes. (https://www.jenkins.io/doc/book/pipeline/).
75
innovación incorpora la automatización de estos procesos y permite a los equipos de
desarrollo y operaciones trabajar coordinadamente para implementar nuevos releases8
o versiones de los componentes de forma automatizada.
Se entiende entonces que CI/CD es un proceso automático de gestión de la
configuración y control del versionamiento del código para realizar entregas continuas e
incrementales del sistema y al mismo tiempo realizar el despliegue continuo, para esto
en el mercado existen herramientas que la posibilitan tales como Jenkins, Bamboo,
CircleCl, Amigo, entro otras.
2.4.53. JSON (JavaScript Object Notation)
Respecto del formato JSON, su página oficial json.org, indica:
JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un
formato ligero de intercambio de datos. Leerlo y escribirlo es simple para
humanos, mientras que para las máquinas es simple interpretarlo y generarlo.
Está basado en un subconjunto del Lenguaje de Programación
JavaScript, Standard ECMA-262 3rd Edition - diciembre 1999. JSON es un
formato de texto que es completamente independiente del lenguaje, pero utiliza
convenciones que son ampliamente conocidos por los programadores de la
familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y
muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el
intercambio de datos.
JSON está constituido por dos estructuras:
8 Una versión de software (release) es una decisión de entregar código a una organización fuera del equipo
de desarrollo, generalmente con fines operativos o de prueba
(https://ieeexplore.ieee.org/document/6681381)
76
Una colección de pares de nombre/valor. En varios lenguajes esto es
conocido como un objeto, registro, estructura, diccionario, tabla hash, lista de
claves o un arreglo asociativo.
Una lista ordenada de valores. En la mayoría de los lenguajes, esto se
implementa como arreglos, vectores, listas o secuencias.
Estas son estructuras universales; virtualmente todos los lenguajes de
programación las soportan de una forma u otra. Es razonable que un formato de
intercambio de datos que es independiente del lenguaje de programación se
base en estas estructuras. (JSON org., 2021)
2.4.54. REST (REpresentational State Transfer)
Acerca de la “Transferencia de Representación de Estado” que es el conjunto de
restricciones denominado REST, Brito & Valente (2020) indican que:
REST es un estilo arquitectónico para implementar sistemas distribuidos. El
estilo define un conjunto de restricciones destinadas a mejorar el rendimiento, la
disponibilidad y la escalabilidad y se basa en un paradigma tradicional cliente-
servidor (Fielding & Taylor, 2002 & Fielding, 2000, como se citó en Brito &
Valente, 2020). Las API basadas en REST son las que siguen las restricciones
definidas por el estilo REST.
REST también define una interfaz uniforme para los componentes del
sistema basada en la identificación de recursos y la provisión de datos
dinámicos. En las API basadas en REST, los datos se exponen mediante puntos
finales. Cada extremo devuelve datos sobre un recurso y cada recurso tiene un
conjunto de campos predefinido. Por ejemplo, la API REST de GitHub
proporciona 366 puntos finales.
Un ejemplo de un punto final (endpoint) es GET / users / torvalds / repos.
Este punto final devuelve la lista de repositorios públicos de un usuario dado, por
77
ejemplo, torvalds. La siguiente lista muestra un fragmento del JSON devuelto.
Contiene 93 campos, por ejemplo, nombre completo (línea 3), propietario (línea
5-8), creado en (línea 10), entre otros.
1 [
2 {
3 "full_name": "torvalds/libdc-for-dirk",
4 "private": false,
5 "owner": {
6 "login": "torvalds",
7 ...
8 },
9 "created_at": "2017-01-17T00:25:49Z",
10 ...
11 },
12 ...
13 ]
(p.02)
2.4.55. Web service
El fundamento de los microservicios lo encontramos en los servicios web, al
respecto, Brito & Valente (2020) indican que:
Los servicios web son colecciones de protocolos y estándares que se utilizan
para intercambiar datos entre sistemas web. Las aplicaciones de software
escritas en varios lenguajes de programación y que se ejecutan en varias
plataformas pueden utilizar servicios web para intercambiar datos en redes
informáticas, como Internet. Estos servicios proporcionan interoperabilidad entre
sistemas de comunicación. (Mizouni, Serhani, Dssouli, Benharref & Taleb, 2011,
como se citó en Brito & Valente, 2020). Ha habido varias implementaciones que
78
brindan soluciones para este concepto, por ejemplo, SOAP, REST y GraphQL.
(p.2).
2.5. Antecedentes contextuales
Las Tecnologías de la Información y Comunicación (TIC), constituyen en la
actualidad, la base fundamental para el desarrollo de todas las actividades humanas, en
este contexto el desarrollo de software es el medio por el cual, las aplicaciones
informáticas ven la luz, contar con herramientas que posibiliten realizar un mejor trabajo
en la construcción del software, se hace cada vez más necesario en este competitivo
escenario tecnológico.
De acuerdo a Di Francesco, Lago & Malavolta (2018), el auge de los
microservicios se está dando en dos ámbitos, si por un lado la industria la implementa
en sus productos de software, la academia no se queda atrás y continuamente se están
realizando investigaciones y publicaciones científicas acerca de esta arquitectura.
Desafortunadamente, el proceso de avanzar hacia una arquitectura basada en
microservicios no es nada fácil, ya que existen muchos desafíos que abordar desde las
perspectivas tanto técnicas como organizativas.
Pero a pesar de los desafíos que se presentan al momento de desarrollar
productos nuevos o migrar los ya existentes, parece ser que esto no desanima a los
profesionales de las aplicaciones informáticas al momento de decidirse por la adopción
de esta nueva arquitectura.
En este sentido, y en una actitud de desafío ante este nuevo reto tecnológico, Di
Francesco et al. (2018) indican que:
El estilo MSA aporta importantes ventajas y desafíos. Si, por un lado, los
sistemas de microservicios tienen arquitecturas flexibles y cambiantes (Dragoni
et al., 2017, como se citó en Di Francesco et al., 2018), por otro lado, muchos
desafíos técnicos (por ejemplo, automatización de la infraestructura, depuración
79
distribuida) y desafíos organizacionales (por ejemplo, creación de equipos
multifuncionales) deben enfrentarse antes de poder benefiarse plenamente de
ellos. La adopción de MSA es un desafío (Newman, 2015, como se citó en Di
Francesco et al., 2018), ya sea para desarrollar un sistema nuevo o para migrar
un sistema existente que adolece de problemas que se vuelven cada vez más
difíciles de resolver. Los problemas típicos de los sistemas heredados son
técnicos (por ejemplo, el sistema se vuelve altamente acoplado, difícil de
mantener, presenta efectos secundarios) o relacionados con el negocio (por
ejemplo, mucho tiempo para lanzar nuevas funciones, baja productividad de los
desarrolladores). En algunos casos, migrar hacia MSA representa la mejor
opción para resolver problemas existentes y, al mismo tiempo, mejorar la
capacidad de mantenimiento del sistema y la frecuencia de lanzamientos de
productos. (p.1)
En este contexto, la Fuerza Aérea Ecuatoriana (FAE), a través de la Dirección de
Tecnologías de la Información y Comunicaciones (DIRTIC), y dentro de esta, el
Departamento de Desarrollo de Sistemas (DDS), que tiene como propósito: analizar,
desarrollar e implementar, sistemas de información interoperables, mediante
metodologías, estándares de calidad y herramientas de desarrollo actuales, para la
administración de la Base de Datos, así como el Desarrollo, Soporte y Mantenimiento de
Software que permitan automatizar los procesos operativos, administrativos y
financieros de la institución, ha decidido adoptar este nuevo reto.
En este departamento, ubicado en el edificio de la Comandancia General de la
Fuerza Aérea, en el complejo ministerial de la Recoleta en la ciudad de Quito, en la
actualidad, se pretende adoptar este nuevo estándar arquitectónico para desarrollar los
nuevos proyectos de desarrollo de software, así como para migrar la arquitectura de los
38 sistemas en producción, desarrollados en las arquitecturas de: Cliente / Servidor, n-
80
capas, Orientada a Servicios (SOA) y basada en componentes, es allí entonces, en
donde el modelo de decisión propuesto, pretende convertirse en un aporte importante
para el líder del equipo de desarrollo y/o arquitecto de soluciones, de manera que este,
pueda tomar una decisión técnica y fundamentada, para desarrollar o migrar hacia la
arquitectura de microservicios, todo un sistema completo o evaluar cada uno de sus
módulos.
81
Capítulo 3
3.1. Diseño del Modelo de Decisión
“En realidad, no es ni necesario ni conveniente que todas las revisiones sean
sistemáticas, en cambio, es a la vez necesario y conveniente que todas las revisiones
se conduzcan aplicando criterios sistematizadores y de calidad” (Hart, 1998, como se
citó en Codina, 2020a, p.8).
El modelo de decisión que se propone en el presente trabajo, es el producto
final, luego de haber realizado una revisión sistematizada de los factores técnicos en
publicaciones científicas y libros sobre las propiedades y características funcionales y no
funcionales de la MSA,
Para el efecto y tomando en cuenta que el presente trabajo se basa en la
determinación de los factores técnicos que más se han utilizado, sin otro juicio de valor,
se ha creído pertinente escoger una metodología de revisión sistematizada, diferente a
las utilizadas en estudios de ingeniería de software, donde son más especializadas en el
estudio de su cuerpo de conocimiento, por lo que se ha utilizado el meta-framework
ReSiste-CHS, más acorde al tipo de estudio del presente trabajo.
Lo que implica entonces, que luego de esta recopilación se somete los artículos
científicos y los libros de referencia a un proceso de análisis y selección con el fin de
determinar los factores técnicos que finalmente resultaron escogidos, a través de 3
etapas:
Determinación de factores.
Diseño detallado del modelo y sus métricas
Proceso de implementación del modelo de decisión
3.1.1. Determinación de factores.
En esta primera etapa del modelo de decisión, se adopta e implementa
entonces, el marco de trabajo o framework para llevar a cabo revisiones bibliográficas
82
denominado ReSiste-CHS, acrónimo de Revisiones Sistematizadas en Ciencias
Humanas y Sociales (Codina, 2020a), fundamentado en otro framework denominado
SALSA (Search, AppraisaL, Synthesis and Analysis) (Grant & Booth, 2009, como se citó
en Codina, 2020a, p.6), que tiene 4 fases: Búsqueda, Evaluación, Análisis y Síntesis, en
la configuración que se aprecia en la Figura 13.
Figura 13
Fases del framework SALSA.
Nota. Recuperado de Codina, 2020a.
Se ha tomado en cuenta además, el contexto o campo de acción, que tiene el
framework ReSiste-CHS y por supuesto SALSA, que son los estados de la cuestión o
estados del arte y los marcos conceptuales destinados a apoyar nuevos proyectos y en
concreto, tesis de máster (como es el presente caso), tesis doctorales y memorias para
obtener financiación para proyectos de investigación (Codina, 2020a, p.8).
La conceptualización de estas 4 fases del framework SALSA (Búsqueda,
Evaluación, Análisis y Síntesis), se revisan a continuación:
83
Búsqueda. Con base en esta metodología, la fase de búsqueda debe llevarse a
cabo con las garantías de rigor, sistematicidad y transparencia que afecta a todo
el framework. Para ello, se deben utilizar las bases de datos académicas más
importantes, concretamente, Scopus y Web of Science, eventualmente
complementadas con bases de datos académicas especializadas. Por ejemplo,
Communication Sources y Humanities Sources en el caso de investigaciones del
ámbito de la comunicación social. Para explotar estas fuentes es necesario
diseñar ecuaciones (cadenas) de búsqueda que correspondan a la lógica y a la
semántica de los objetivos de la revisión sistematizada. Otras fuentes de
información pueden (y deben) ser utilizadas en función del ámbito de estudio, por
ejemplo, informes, reports o libros blancos producidos por centros de investiga-
ción u organismos de la Administración, por lo cual sistemas de información
como Google Scholar son también necesarios. (Codina, 2020a, p.11)
Evaluación. De esta segunda fase se indica que, una vez que se dispone de
una primera colección de documentos (artículos, informes, etc.) es necesario
desarrollar un sistema de evaluación que, eventualmente, descarte los
documentos que queden por debajo de ciertos umbrales de calidad. Por ejemplo,
los autores de la revisión pueden especificar como criterio de inclusión de los
trabajos que los mismos se adapten a la estructura IMRyD (Introducción,
Metodología, Resultados y Discusión). Otros requerimientos de inclusión (o
exclusión) se pueden referir al alcance geográfico o de otro tipo, marco teórico
utilizado, etc. Por ejemplo, los autores de la revisión pueden decidir que
únicamente analizarán trabajos centrados en determinadas áreas geográficas
(Europa o Latinoamérica) o que traten determinados medios (televisiones
públicas), o tal vez determinados efectos (agenda setting, recepción), etc.
(Codina, 2020a, p.11)
84
Análisis. Para analizar el banco de documentos resultante se requiere
igualmente un procedimiento sistemático que asegure que cada artículo o
informe ha sido tratado de forma similar. Los autores del trabajo de revisión
deben especificar un formato para tal análisis que puede consistir en extraer de
todos ellos una ficha (que luego puede integrarse total o parcialmente en una o
más tablas unificadas) con apartados como: metodología utilizada, objeto de
estudio, aportaciones principales, resultados más destacados, etc. No obstante,
los anteriores son criterios de análisis generales. Cada proyecto puede requerir
criterios adicionales específicos (o en lugar de). (Codina, 2020a, p.11)
Síntesis. Una síntesis debe producir un producto nuevo como resultado de la
unión en un todo de las partes analizadas. Ahora bien, en el ámbito que nos
afecta esta unión puede adoptar diversas formas en función del objeto de estudio
y de los objetivos del trabajo, ya que, a diferencia de las revisiones sistemáticas
no hay una forma determinada de presentación al estar basada en resultados
cualitativos. La más habitual, en tesis doctorales, trabajos de final de máster y
solicitudes de proyectos, es la síntesis narrativa acompañada eventualmente de
tablas y diagramas. Idealmente, pueden identificar patrones y tendencias,
promover y apoyar recomendaciones, incluso generar explicaciones que den
soporte a teorías o hipótesis que pueden generar a su vez, nuevas
investigaciones. No obstante, es frecuente que la heterogeneidad de los estudios
analizados impida poco más que identificar y caracterizar con rigor un ámbito de
estudio y establecer de este modo sus fronteras, así como los huecos y oportu-
nidades de investigación. En cualquier caso, estas síntesis siempre deben
combinar la presentación de resultados de una forma descriptiva con la de
interpretarlos de una forma crítica. (Codina, 2020a, p.11)
Respecto de las fases de Búsqueda y Evaluación, Codina (2020b), indica que:
85
La idea básica es asegurarse de que los trabajos que formen parte del banco de
documentos, hayan sido seleccionados siguiendo criterios rigurosos y no, por ejemplo,
sesgos del autor, como, por ejemplo, aquellos documentos que confirman sus teorías, o
aquellos que, por mera casualidad, han caído en sus manos. (p.4)
Con los conceptos del framework ReSiste-CHS revisados y aprehendidos, se
procede a realizar el proceso (Búsqueda, Evaluación, Análisis y Síntesis).
Búsqueda.
Creación del Grupo Óptimo de Base de Datos. Como primer punto se debe
determinar el Grupo Óptimo para la investigación, que corresponde a la selección de las
bases de datos de las cuales vamos a consultar los trabajos.
En este caso se ha utilizado, las principales bases de datos científicas, que
cuentan con publicaciones actuales y periódicas, en forma de artículos publicados en
revistas científicas, publicaciones de conferencias, congresos, procedings, libros de
memorias, series o colecciones de libros, así como experiencias y aplicaciones en el
área de la ingeniería y arquitectura de software:
Así, el Grupo Óptimo de bases de datos científicas de este trabajo está
conformado por: ACM Digital Library, Google Scholar, Elsevier, IEEE, RACCIS,
Researchgate, Scopus, Springer y Web of Science.
Además, se revisó libros y obras de editoriales dedicadas a publicaciones en el
campo de tecnología como: Adisson – Wesley / Pearson PLC, Researchgate, Taylor and
Francis Ltd. y Wiley Online Library.
Adicional y particularizando la metodología, se utilizaron trabajos de tesis de
maestría y doctorales, de las principales universidades locales e internacionales,
mereciendo una mención especial, Carnegie-Mellon University de los Estados Unidos
(CMU), a través de su Instituto de Ingeniería de Software (Software Engineering Institute
of CMU, SEI), de la cual se utilizaron algunos de sus trabajos.
86
Por último, todos estos insumos, fueron validados con el indicador SJR
(SCImago Journal Rank) que es una puntuación métrica ponderada, independiente del
tamaño, que proporciona información sobre el prestigio promedio de las revistas
científicas, por tanto, es útil como indicador de la calidad relativa de las revistas, de
manera que fueron escogidos únicamente aquellos artículos, que se encontraron dentro
de los cuartiles Q1, Q2 y Q3.
Palabras Clave y Ecuaciones (cadenas) de Búsqueda (Framework FDC). El
Framework ReSiste-SHC, que se está utilizando, en realidad puede constituir un meta-
framework, ya que está constituido por otros frameworks para darle mayor sustento
metodológico y para describir al framework SALSA.
En este punto entonces, se utiliza también el framework FDC, para la Búsqueda.
Las siglas FDC responden a las tres fases recomendadas por este
procedimiento para planificar una búsqueda, estas son: Facetar, Derivar y Combinar.
(Codina, 2020b, p.7)
A continuación, se desarrolla entonces las 3 fases del framework FDC:
Facetar. En la tabla 2, se indica las facetas correspondientes al framework FDC
(Facetar, Derivar, Combinar) para una investigación de tipo genérica, no siempre se
utilizan todas las facetas, de hecho, para el presente trabajo, se obviarán algunas de
ellas.
87
Tabla 2
Matriz de facetas para caracterizar la investigación de los modelos de decisión de
microservicios, de acuerdo al framework FDC de ReSiste-CHS.
Faceta Explicación y ejemplos
Objeto de estudio Identifica el objeto material o conceptual
en el que centramos la investigación.
Ejemplos: Televisión, sitios web, twitter,
cibermedios, comunicación política, redes
temáticas, posicionamiento web, etc.
Tipo de acción Qué clase de actividad investigadora
identifica mejor nuestro proyecto.
Ejemplos: Análisis, Síntesis, Testeo,
Comparación, Evaluación, etc.
Marco teórico Teorías o disciplinas que informan y
aportan los constructos conceptuales
principales de nuestro enfoque. Ejemplos:
Teoría de la comunicación, Semiótica,
Sociología, Psicología, Antropología, etc.
Técnicas de obtención de
datos
Técnicas concretas con las que pensamos
obtener datos para nuestra investigación.
Ejemplos: Focus group, Delphi,
Entrevistas, Encuestas, Minería de datos,
Estudios de caso, Análisis comparativos,
Análisis experto, Análisis heurístico,
Revisiones sistemáticas, Observación
participante, Estudios de usuario, Tests,
etc.
Estrategias
metodológicas
Identifica cuál(es) de las tres grandes
estrategias metodológicas utilizaremos:
cuantitativa, cualitativa, conceptual.
Topónimos Nombre de lugares, regiones o países que
intervengan en el estudio. España,
Cataluña, Europa, Portugal, Brasil,
México, etc.
Nombres propios Nombres de autores destacados o
representantes de corrientes teóricas que
intervengan en el estudio. Nombres
propios de empresas o corporaciones que
88
Faceta Explicación y ejemplos
tengan algún relación con el estudio,
incluyendo (p.e) nombres o marcas de
grupos o de empresas de comunicación.
Software o herramientas Denominaciones de paquetes de software
o de instrumentos o herramientas que
pensamos utilizar en nuestra
investigación. Ejemplos: NVivo,
Eyetracker, Card sorting, Personas y
escenarios, wireframes, etc.
Nota. Recuperado de Codina, 2020a.
Derivar. Se puede apreciar entonces en la Tabla 3, que se obviaron las facetas
de: topónimos, nombres propios, y software o herramientas, debido a que la
investigación actual, no se circunscribe a un lugar específico, no tiene investigadores o
empresas direccionadas ni tampoco herramientas específicas.
Tabla 3
Aplicación de la matriz de facetas para la investigación de los Modelos de Decisión de
Microservicios.
Faceta Explicación y ejemplos
Objeto de
estudio
Ingeniería de software, arquitectura de software,
arquitectura de microservicios, modelos de decisión.
Tipo de acción Análisis, Muestreo, Síntesis, Evaluación.
Marco teórico Atributos de calidad, requisitos funcionales, requisitos
no funcionales, factores técnicos, características de
la arquitectura de microservicios.
Técnicas de
obtención de
datos
Estudios de caso, análisis experto, observación
participante en un caso de estudio, revisiones
sistemáticas, análisis comparativo.
Estrategias
metodológicas
Tiene un ENFOQUE MIXTO (Cualitativo y
Cuantitativo), con más sesgo al enfoque Cualitativo,
ya que se fundamenta en los factores técnicos que
más han sido utilizados, estudiados, nombrados y
referenciados en los artículos científicos, en base a
89
Faceta Explicación y ejemplos
los criterios objetivos y subjetivos de sus respectivos
autores, y que al final fueron recopilados y con base
en la estadística se determinó los de mayor moda
(Mo), aquí el enfoque cuantitativo.
Topónimos No corresponde en este caso.
Nombres
propios
No corresponde en este caso.
Software o
herramientas
No corresponde en este caso.
Nota. Recuperado de Codina, 2020a.
Combinar. En esta fase se definen las palabras y se aplica la ecuación (cadena)
de búsqueda, en el presente trabajo, la cadena de búsqueda que se aplicó en las bases
de datos para encontrar los artículos científicos correspondientes, fue:
microservices "quality attributes" characteristics
Se especificó además un intervalo de tiempo de vigencia para los documentos
consultados, correspondiente a los 5 últimos años, es decir que se filtraron los artículos
desde 2015 hasta 2020, como se puede apreciar en la Figura 14.
Figura 14
Búsqueda de artículos en la base de datos de Google Scholar.
Nota. Recuperado de Google Scholar.
90
Una vez aplicado el primer filtro, con un resultado de 796 artículos, se procede a
realizar una selección más específica, con base en una revisión manual exhaustiva de
los artículos, de acuerdo a la pertinencia de su título y los que se encuentran dentro de
los cuartiles Q1, Q2 y Q3, del SJR (Scimago Journal & Country Rank).
De la aplicación de este segundo filtro, se elabora un archivo BibTeX con el
resultado de los artículos científicos seleccionados, en este caso 106 artículos del total
inicial de 796.
El siguiente pasó consistió en la creación del archivo BibTeX9, con la
herramienta Visual Studio Code, este proceso se lo realizó con el fin de automatizar esta
parte de la gestión de las citas y referencias, para estar acorde y sobre todo cumplir con
la metodología que se está utilizando.
Uso de Gestores de Referencias Bibliográficas. Conforme a lo que estipula el
framework ReSiste-CHS, “Resulta conveniente utilizar en todo el proceso un gestor de
referencias bibliográficas. La mayoría, o todos, incluyen funciones que resultan de
enorme valor en todo el proceso” (Codina, 2020b, p.9).
En este caso se ha utilizado el gestor de referencias bibliográficas, Mendeley10,
debido a que es uno de los más conocidos y utilizados, además de tener una versión
gratuita y de combinar una versión web con una versión de escritorio.
Evaluación
El objetivo de esta fase es descartar documentos que hayan sido recuperados
en la fase anterior de búsqueda, pero que carecen en realidad de las condiciones de
9 La palabra "BibTeX" significa una herramienta y un formato de archivo que se utilizan para describir y
procesar listas de referencias, principalmente junto con documentos LaTeX. (http://www.bibtex.org/, 2006) 10 Mendeley es un administrador de referencias gratuito y una red social académica que puede ayudarlo a
organizar su investigación, colaborar con otros en línea y descubrir las últimas investigaciones.
(https://www.elsevier.com/solutions/mendeley, 2021)
91
calidad mínimas establecidas por los objetivos de la revisión. De este modo, se espera
que formen parte del banco de documentos solamente aquellos que lo merezcan con
base en estos dos aspectos:
Criterios pragmáticos, o de adecuación de los documentos encontrados a los temas y
objetivos de la revisión, ya que pueden haberse producido falsos positivos.
Criterios de calidad de la investigación, para asegurar que los documentos finalmente
seleccionados corresponden a trabajos que han sido llevados a cabo siguiendo
procedimientos generalmente admitidos de calidad de la investigación (Codina,
2020b, p.10).
Si bien es cierto que la revisión sistematizada de las referencias, se la ha
realizado bajo el framework ReSiste-CHS de Codina (2020a), por otro lado, y con el fin
de mejorar el criterio de “Evaluación” de los artículos seleccionados, se ha decidido
aumentar, en este punto, el “Methodi Ordinatio”, descrito en el paper “Methodi Ordinatio:
a proposed methodology to select and rank relevant scientific papers encompassing the
impact factor, number of citation, and year of publication” de Pagani et al. (2015), que es
una adaptación del Proceso de Desarrollo del Conocimiento-Constructivista o método
ProKnow-C de Ensslin et al., (2010).
Este “Methodi ordinatio”, comprende 9 fases que se desarrollan a continuación:
Fase 1 - Establecer la intención de la investigación
El objetivo de la investigación, en esta primera fase, es extraer los factores
técnicos, más revisados y utilizados en los estudios y aplicación de los microservicios en
la industria del software, todos los estudios relativos a la arquitectura, en los que se
haya revisado sus características y atributos.
Fase 2 - Investigación preliminar exploratoria con palabras clave en bases de
datos
Fase 3 - Definición y combinación de palabras clave y bases de datos
92
Fase 4 - Búsqueda final en las bases de datos
Fase 5 - Procedimientos de filtrado
Estas actividades de las fases 2, 3, 4 y 5, fueron ya desarrolladas en la fase
“Combinar” del framework ReSiste-SHC, y están descritos en párrafos anteriores.
Fase 6 - Identificación de factor de impacto, año de publicación y número de
citas
Una vez seleccionados los 106 artículos, que constituyen el Portafolio
Bibliográfico de Investigación (Bibliographic Portfolio of Research, BPR), se procedió a
llenar los datos correspondientes a: sitio de publicación; año de publicación; año de
investigación; número de citas; factor de impacto (del último año); e importancia para el
estudio (número arbitrario asignado por el investigador), proceso del cual se puede
apreciar su tabla completa en el Anexo “A” del presente trabajo.
Con estos datos se aplicó la fórmula respectiva para obtener el factor de Index
Ordinatio (inOrdinatio) a cada una de las 106 fuentes de consulta y referencia.
La fórmula para obtener este factor, se la describe en las siguientes líneas, así
como cada uno de sus componentes:
𝐼𝑛𝑂𝑟𝑑𝑖𝑛𝑎𝑡𝑖𝑜 = (𝐼𝐹 100⁄ ) + 𝛼 ∗ [10 − (𝑅𝑒𝑠𝑒𝑎𝑟𝑐ℎ𝑌𝑒𝑎𝑟 − 𝑃𝑢𝑏𝑙𝑖𝑠ℎ𝑌𝑒𝑎𝑟)] + (Σ𝐶𝑖)
En donde:
IF = Factor de impacto (Impact factor)
= Es el factor de ponderación (importancia para el estudio) que va de 1 a 10, que
es asignado por el investigador.
Ci = Número de veces que el paper ha sido citado.
Research year = año en que se llevó a efecto la investigación.
Publish year = año en el que fue publicado el trabajo de investigación.
93
La tabla completa del BPR con el factor inOrtinatio, se puede apreciar en el
Anexo “B”
Fase 7 - Clasificación de los trabajos mediante InOrdinatio
Con el factor inOrdinatio ya obtenido, se procedió a ordenar los artículos según
su valor resultante, para seleccionar los trabajos que formarán parte de la revisión, de
acuerdo a los de mayor relevancia.
No hay un número a priori de documentos necesarios para una revisión
sistematizada. Depende de diversos factores y uno es la producción total de
documentos que genera el ámbito de trabajo, pero otro también los recursos
disponibles para llevar a cabo la revisión, entre ellos, el tiempo.
Los trabajos de revisión para trabajos de final de máster suelen requerir
al menos unas pocas decenas, tal vez entre 20 y 30 documentos. Para tesis
doctorales, entre 50 y 100. En artículos de revistas científicas, se suelen citar
entre 10 y 20 trabajos previos. (Codina, 2020b, p.10).
Como menciona Codina (2020) y con la tabla de los 106 trabajos de
investigación, ordenada de mayor a menor, se procedió a dividirlos en cuartiles, con el
propósito de escoger los que se encuentren dentro de los rangos Q1 y Q2, que
corresponden a los de mayor valor, para proceder a revisarlos y analizarlos:
Usando la fórmula de cuartiles 𝐾(𝑁)/4, donde K = cuartil a buscar; N = Número
total de datos (N=par; N+1=impar), obtenemos:
Primer cuartil (Q1)
Q1 = 1(𝑁)/4
Q1 = 1(106) /4 = 26.50 = 27 (posición)
Q1 = X27
Q1 = 134.00
27 The Design and Architecture of Microservices 134,00
94
Segundo cuartil (Q2)
Q2 = 2(𝑁)/4
Q2 = 2(106) /4 = 53 (posición)
Q2 = X53
Q2 = 100.00
Tercer cuartil (Q3)
Q3 = 3(𝑁)/4
Q3 = 3(106) /4 = 79.5 = 80 (posición)
Q3 = X80
Q3 = 78.00
Del primer cuartil (Q1) se han obtenido entonces 27 artículos y del segundo
cuartil (Q2) se han obtenido 26 artículos, dando un total de 53 artículos científicos.
De este número, se ha decidido arbitrariamente aumentar dos artículos más:
Decision guidance models for microservices - Service discovery and fault
tolerance (Haselböck et al., 2017a), y
Decision models for microservices: Design areas, stakeholders, use cases, and
requirements (Haselböck et al., 2017b).
Que corresponden a los artículos científicos que han venido sirviendo de base y
referencia para el desarrollo del presente trabajo, con lo que el catálogo final queda
compuesto entonces por 55 artículos, como se puede apreciar en la Tabla 4.
53 Automated Microservice Identification in Legacy Systems with Functional and Non-Functional Metrics 100,00
80 Refactoring Orchestrated Web Services into Microservices Using Decomposition Pattern 78,00
95
Tabla 4
Listado de los dos primeros cuartiles del BPR final.
Nombre InOrdinarioCuartil
PBR
1 Microservices: Yesterday, Today, and Tomorrow 714,00 1er. cuartil
2 Microservices Architecture Enables DevOps Migration to a Cloud-Native Architecture 568,00 1er. cuartil
3 Microservices 396,00 1er. cuartil
4 Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud317,00 1er. cuartil
5 A Systematic Mapping Study in Microservice Architecture 303,00 1er. cuartil
6 Microservices tenets 238,00 1er. cuartil
7 Migrating to Cloud-Native Architectures Using Microservices: An Experience Report 235,00 1er. cuartil
8 Infrastructure Cost Comparison of Running Web Applications in the Cloud Using AWS Lambda and Monolithic and Microservice Architectures232,00 1er. cuartil
9 Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption228,00 1er. cuartil
10 Microservices Flexible software architectures (book) 224,00 1er. cuartil
11 Microservice Architectures for Scalability, Agility and Reliability in E-Commerce 222,00 1er. cuartil
12 The Essence of Software Engineering: The SEMAT Kernel(El paper no toco un solo tema con respecto a los microservicios trato completamente sobre el kernel)203,00 1er. cuartil
13 Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation191,00 1er. cuartil
14 Microservices Approach for the Internet of Things 187,00 1er. cuartil
15 The Pains and Gains of Microservices: A Systematic Grey Literature Review 169,00 1er. cuartil
16 Extraction of Microservices from Monolithic Software Architectures 167,00 1er. cuartil
17 Architectural Patterns for Microservices: a Systematic Mapping Study 156,00 1er. cuartil
18 Open Issues in Scheduling Microservices in the Cloud 154,00 1er. cuartil
19 Workload characterization for microservices 152,00 1er. cuartil
20 Microservices migration patterns 152,00 1er. cuartil
21 Container and Microservice Driven Design for Cloud Infrastructure DevOps 151,00 1er. cuartil
22 From Monolith to Microservices Lessons Learned on an Industrial Migration to a Web Oriented Architecture150,00 1er. cuartil
23 Challenges in Delivering Software in the Cloud as Microservices 145,00 1er. cuartil
24 Migrating Towards Microservice Architectures An Industrial Survey 144,00 1er. cuartil
25 The Economics of Microservices 141,00 1er. cuartil
26 From Monolithic to Microservices An Experience Report from the Banking Domain 137,00 1er. cuartil
27 The Design and Architecture of Microservices 134,00 1er. cuartil
28 Architecting Microservices 132,00 2do. cuartil
29 Towards Recovering the Software Architecture of Microservice-Based Systems 129,00 2do. cuartil
30 Decision Guidance Models for Microservice Monitoring 127,00 2do. cuartil
31 Container-based microservice architecture for cloud applications 126,00 2do. cuartil
32 Scalable microservice based architecture for enabling DMTF profiles 125,00 2do. cuartil
33 Overcoming Security Challenges in Microservice Architectures 122,00 2do. cuartil
34 Decision Models for Microservices: Design Areas, Stakeholders, Use Cases, and Requirements120,00 2do. cuartil
35 The Evolution of Distributed Systems Towards Microservices Architecture 117,00 2do. cuartil
36 From Monolithic Architecture to Microservices Architecture 113,00 2do. cuartil
37 From Monolith to Microservices A Dataflow-Driven Approach 113,00 2do. cuartil
38 A Systematic Literature Review on Microservices 113,00 2do. cuartil
39 Microservice Ambients An Architectural Meta-Modelling Approach for Microservice Granularity112,00 2do. cuartil
40 Decision Model for Software Architectural Tactics Selection based on Quality Attributes Requirements110,00 2do. cuartil
41 Contextual Understanding of Microservice Architecture: Current and Future Directions 108,00 2do. cuartil
42 Decision Guidance Models for Microservices – Service Discovery and Fault Tolerance 106,00 2do. cuartil
43 Towards a Taxonomy of Microservices Architectures 105,00 2do. cuartil
44 Towards an Understanding of Microservices 105,00 2do. cuartil
45 Making the move to microservice architecture 104,00 2do. cuartil
46 Microservices architecture Case on the migration of reservation-based parking system 104,00 2do. cuartil
47 Migrating from monolithic architecture to microservices A Rapid Review 104,00 2do. cuartil
48 Architecture Interoperability and Repeatability with Microservices An Industry Perspective 103,00 2do. cuartil
49 Migrating Legacy Software to Microservices Architecture 103,00 2do. cuartil
50 Challenges in Documenting Microservice-Based IT Landscape A Survey from an Enterprise Architecture Management Perspective102,00 2do. cuartil
51 The Comparison of Microservice and Monolithic Architecture 102,00 2do. cuartil
52 A Complexity Metric for Microservices Architecture Migration 101,00 2do. cuartil
53 Automated Microservice Identification in Legacy Systems with Functional and Non-Functional Metrics100,00 2do. cuartil
54 Object-Aware Identification of Microservices 100,00 2do. cuartil
55 Continuous Architecting with Microservices and DevOps: A Systematic Mapping Study 98,00 2do. cuartil
96
Estos 55 documentos, constituyen así, la base teórica, del modelo de decisión
que se propone realizar, y de los cuales se obtendrá, los factores técnicos que han sido
objeto de estudio, tratado, uso, implementación o revisión sistemática.
Fase 8 - Encontrar los artículos científicos completos
En la siguiente fase se procedió a obtener y recopilar los 55 archivos en formato
de documento portátil (.pdf), entre los que se encontraron libros, revistas y artículos
científicos.
Cabe indicar en este punto que los documentos digitales, están disponibles,
previo el pago de un valor, esto aplica tanto para los papers como para los libros ya sea
digitales o en físico, los mismos que tienen un valor aproximado de USD. 30.00 los
artículos científicos, pudiendo ser mayor en el caso de libros.
Fase 9 - Lectura final y análisis sistemático de los trabajos
En esta fase se realizó la lectura y análisis de los 55 artículos, de donde se
obtuvieron los factores técnicos, que por lo general se trataron de requerimientos no
funcionales o atributos de calidad que intervienen en el desarrollo del producto software,
sin embargo, es importante recalcar que, también se tomó en cuenta requerimientos
funcionales y características propias de la MSA, además de conceptos relacionados al
uso de microservicios como es el caso de factores como la integración continua o la
gestión y uso de contenedores, entre otros, que son conceptos que tienen estrecha
relación y están ligados con la arquitectura de microservicios.
Es en esta fase donde se pasó de la lectura de los resúmenes hacia la lectura y
análisis de la totalidad del artículo, con la finalidad de ir extrayendo cada uno de los
factores técnicos que han sido analizados o utilizados en algún caso de estudio.
No se realizó ningún juicio de valor o grado de profundidad en el estudio del
factor, es decir que se registraron todas las revisiones, tratados, ejecución o utilización
del factor.
97
Análisis
El modelo de decisión, que se está proponiendo en el presente trabajo, se
fundamenta en el análisis de los factores técnicos que cuantitativamente, han sido más
revisados, analizados o utilizados en las investigaciones y casos de estudio
referenciados.
En tal virtud, se necesita una ponderación cuantitativa relacionada a la
frecuencia con la que, tal o cual factor ha sido encontrado en la revisión sistematizada
de los 55 documentos de consulta que constituyen el BPR final.
Se ha realizado entonces una revisión, lectura y análisis de cada uno de los
documentos, de los cuales se extrajeron y contabilizaron los factores técnicos que se
iban tratando, datos con los cuales se confeccionó una matriz para su mejor contabilidad
y una correcta catalogación de los factores técnicos.
En esta primera contabilidad se determinaron entonces los 69 primeros factores
técnicos (ver Anexo “C”), los mismos que una vez determinados, fueron sometidos a un
proceso de revisión y depuración.
Así pues, en una segunda instancia y análisis de datos, se procedió a unir los
factores que se correspondieron y que estaban listados con diferente descripción, como
por ejemplo: Tolerancia a fallos y fallos, despliegue continuo y entrega continua, entre
otros, así mismo se procedió a eliminar aquellos que por alguna razón fueron
considerados en una primera instancia, pero que después de analizar su concepto, no
aplicaban, como por ejemplo: aseguramiento de la calidad, que corresponde a una
actividad, más que a un atributo o factor técnico.
Una vez que se terminó esta depuración, se obtuvo el catálogo final, con un total
de 40 Factores Técnicos finales y depurados (ver Anexo “D”).
En la tabla 5, se observa la frecuencia absoluta alcanzada por cada uno de ellos,
y en base a la cual se los ha dividido en cuartiles.
98
Tabla 5
Catálogo final de factores técnicos encontrados, con su frecuencia absoluta (f¡).
Ord fi Quartil
1 Escalabilidad dinámica dinamic scalibility 47
2 Integración continuous delivery 46
3 Modularización modularity 40
4 Organización del equipo team organization 36
5 Adaptabilidad Adaptability 29
6 Computación en la nube cloud computing 29
7 Comunicaciones livianas lightweight communications 29
8 Flexibilidad flexibility 28
9 Mantenibilidad independence 26
10 Cohesión alta, acoplamiento bajo high cohesion / low coupling 23
11 Pruebas independientes test 23
12 Seguridad y privacidad security 21
13 Tolerancia a fallos fault tolerance 20
14 Disponibilidad alta high availability 20
15 Costo de implementación cost 18
16 Monitoreo y registro monitoring and registry 17
17 Agilidad Agility 16
18 Gestión dinámica dynamic management 15
19 Descubrimiento dicovery 14
20 Rendimiento performance 14
21 Fiabilidad reliability 14
22 Resiliencia resilience 14
23 Reusabilidad reusability 14
24 Portabilidad portability 11
25 Recursos resources - means 9
26 Aseguramiento y evaluación de la Quality 8
27 Eficiencia efficiency 7
28 Tiempo de respuesta / velocidad response time 7
29 Curva de Aprendizaje learning curve 5
30 Interfaces abiertas y fijas open interface 5
31 Tiempo de comercialización (time time to market 5
32 Auditabilidad auditability 4
33 Gestión de la configuración configuration management 4
34 Documentación dificil difficult documentation 3
35 Confiabilidad reliability 3
36 Comprensibilidad del software understandability 3
37 Compatibilidad compatibility 2
38 Tiempo de no disponibilidad / downtime 2
39 Usabilidad usability 2
40 Tiempo de implementación implementation time 1
Factor
1ro.
2do.
3ro.
4to.
99
Lo siguiente, fue determinar de estos 40 factores resultantes, cuáles van a servir
de fundamento al modelo. Para esto y utilizando la herramienta RStudio, se
determinaron los valores correspondientes a cada cuartil, en la que se observa que el
cuartil más alto (Q1), tiene las frecuencias desde 23 hasta 47, así mismo la mediana con
un valor de 14.00 y la media con un valor de 15.85, como se aprecia en la Figura 15.
Figura 15
Valores de las medidas descriptivas de los factores técnicos resultantes.
Con la ayuda de la misma herramienta RStudio, se genera un diagrama de cajas
o bigotes para analizar gráficamente la dispersión de los valores, tal como se aprecia en
la Figura 16 que muestra la relación de la frecuencia de los factores técnicos
encontrados, y su distribución en cada uno de los cuartiles.
Con este diagrama es posible determinar gráficamente la distribución de los
datos, observando que existe una mayor frecuencia hacia el límite superior 47 y una
menor frecuencia hacia el límite inferior 1. Es decir que, la mayor cantidad de factores
se encuentran presentes en el primer cuartil, esta conclusión es determinante para la
confección final del modelo.
100
Figura 16
Diagrama de cajas con los cuartiles de la frecuencia de los factores – herramienta
RStudio.
En el gráfico de pastel, que se muestra en la Figura 17, se aprecia visualmente
que más de la mitad de los factores técnicos encontrados, se sitúan en el primer cuartil
(Q1), dado por la siguiente interpretación matemática.
𝑄1 = 333 𝑓𝑎𝑐𝑡𝑜𝑟𝑒𝑠 𝑡é𝑐𝑛𝑖𝑐𝑜𝑠 = 52%
𝑄2 + 𝑄3 + 𝑄4 = 178 + 94 + 29 = 301 𝐹𝑎𝑐𝑡𝑜𝑟𝑒𝑠 𝑡é𝑐𝑛𝑖𝑐𝑜𝑠 = 48%
Figura 17
Factores técnicos finales por cuartil.
101
Síntesis
Se ha seleccionado entonces, los 10 primeros factores, correspondientes al
primer cuartil (Q1), el mismo que contiene una mayor cantidad de Factores Técnicos,
que la sumatoria de los otros 3 cuartiles juntos.
52% en 1er cuartil vs 48% en los 3 cuartiles restantes.
Así, en una primera fase, se inicia el modelo de decisión, con estos 10 Factores
Técnicos del Q1 (ver Tabla 6), a los que en una segunda fase se le sumarán 4 más,
resultantes de la implementación de los instrumentos de investigación (cuestionarios),
proceso detallado en el numeral siguiente.
Tabla 6
Factores técnicos escogidos para el modelo de decisión propuesto.
Para resumir todo el proceso, en el que se ha utilizado las 4 fases del
metamodelo11 framework ReSiste-CHS, y el Methodi Ordinatio del que se ha extraído el
índice ordinatio <<inOrdinatio>> para evaluar la pertinencia y calidad de los artículos
científicos, en la Figura 18, se muestra el esquema general de todo el proceso.
11 Los modelos son instancias de sus metamodelos. Las características del mundo real capturables por un
modelo están determinadas por el metamodelo.
(https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.564.1311&rep=rep1&type=pdf)
Ord fi Quartil
1 Escalabilidad dinámica dinamic scalibility 47
2 Integración continuous delivery 46
3 Modularización modularity 40
4 Organización del equipo team organization 36
5 Adaptabilidad Adaptability 29
6 Computación en la nube cloud computing 29
7 Comunicaciones livianas lightweight communications 29
8 Flexibilidad flexibility 28
9 Mantenibilidad independence 26
10 Cohesión alta, acoplamiento bajo high cohesion / low coupling 23
Factor
1ro.
102
Figura 18
Esquema general del proceso de determinación de los 14 Factores Técnicos finales,
mediante el método ReSiste-CHS.
103
3.2. Diseño detallado del modelo y sus métricas
El siguiente paso es la confección del modelo de decisión, lo que consiste
básicamente en “operacionalizar” los 14 Factores Técnicos definidos, a través de
métricas que permitan predecir la repercusión de una eventual utilización de la
arquitectura de microservicios en el futuro proyecto de desarrollo de un producto
software.
Para el efecto se ha realizado una revisión, análisis y selección de instrumentos
de evaluación, encuestas y cuestionarios, que hayan sido aplicados en la industria del
desarrollo de software y que consten en publicaciones de artículos científicos, de
manera que se encuentren debidamente validados.
El modelo en desarrollo, al que para darle una identidad se le ha denominado
“Modelo de Decisión por Factores Técnicos” (Decision Model by Technical Factors,
DMTF), está constituido por 3 herramientas que evalúan la pertinencia de adoptar la
arquitectura.
INSTRUMENTO NRO. 1
Fundamentado en los factores técnicos de MANEJABILIDAD12, COMPUTACIÓN
EN LA NUBE, DISPONIBILIDAD, FIABILIDAD Y ESCALABILIDAD DINÁMICA
Para implementar este primer instrumento, en el que interviene la Manejabilidad,
Computación en la nube, Disponibilidad, Fiabilidad y Escalabilidad Dinámica, se ha
utilizado, el trabajo denominado “Scalability Patterns for Platform-as-a-Service”, en la
que Ardagna et al. (2012), fundamentan su estudio en la utilización de los 3 niveles de
servicios en la nube tales como: Software como un servicio (Software as a Service,
SaaS); Infraestructura como un servicio (Infraestructure as a Service, IaaS) y sobre
12 Capacidad de ser manejable con facilidad (RAE) – en MSA debido a su tamaño pequeño.
104
todo; Plataforma como Servicio (Platform as a Service, PaaS), con lo que proponen 05
patrones para evaluar (en este caso, predecir) ambientes escalables, tomando en
cuenta especificaciones como la escalabilidad vertical (Scale Up), es decir recursos
adicionales para un solo nodo, por ejemplo, aumentar CPU, memoria, RAM, ancho de
banda, estos recursos pueden ser tanto físicos como virtualizados; y la escalabilidad
horizontal (scale out), que constituye el aumento de nodos completos en paralelo con lo
que se provee mayores recursos de hardware y software, por ejemplo aumentar
servidores a una plataforma cluster.
Esta predicción se la realiza con base en los siguientes 5 escenarios posibles:
SPP (Single Platform Pattern),
ShPP (Shared Platform Pattern),
CPP (Clustered Platform Pattern),
MShPP (Multiple Shared Platform Pattern),
MCPP (Multiple Clustered Platform Pattern).
SPP (Single Platform Pattern):
El Patrón de Plataforma Única, considera un escenario de un solo inquilino. Se
lanza una máquina virtual única, aislada y completa con una plataforma instalada para
cada cliente en la nube.
ShPP (Shared Platform Pattern)
El Patrón de Plataforma Compartida, considera un escenario de múltiples
inquilinos en el que se instala una única plataforma en una (conjunto de) máquina
virtual. En este caso, la plataforma es compartida por varios inquilinos, todos con
derecho a administrar una parte de ella e implementar sus servicios de forma
independiente.
105
CPP (Clustered Platform Pattern)
El Patrón de Plataforma Agrupada, es la solución adoptada por casi todos los
principales proveedores de PaaS, implementa una única plataforma que admite la
agrupación en clústeres y es compartida por todos los inquilinos. Se pueden
implementar varias instancias de los componentes de la plataforma en diferentes
máquinas del clúster. Por lo tanto, CPP admite una solución de escalabilidad que
garantiza los niveles de rendimiento de la plataforma al escalar / reducir dinámicamente
los recursos asignados al clúster.
MShPP (Multiple Shared Platform Pattern)
El Patrón de Plataforma Compartida Múltiple, es una extensión de ShPP y
mezcla escalamiento vertical y horizontal. En el momento de la inicialización, se
implementa una plataforma única, compartida y de múltiples inquilinos.
Tras un aumento en la carga, se asignan recursos adicionales (por ejemplo,
CPU, RAM, ancho de banda) para mantener las métricas de rendimiento. En caso de
que los recursos adicionales no sean suficientes, se implementa una nueva plataforma y
una parte de los inquilinos existentes se migran a la nueva plataforma junto con los
servicios que poseen.
MCPP (Multiple Clustered Platform Pattern).
El Patrón de Plataforma Agrupada Múltiple, es una extensión de CPP y
proporciona escalado horizontal en dos niveles de abstracción. En el momento de la
inicialización, se implementa una plataforma única, compartida y multiinquilino que
admite la agrupación en clústeres. Tras un aumento en la carga, se agregan recursos
adicionales (es decir, máquinas en el clúster) para mantener el nivel de rendimiento.
En la Tabla 7, Ardagna et al. (2012), presentan un resumen del análisis de los 5
factores técnicos: Manejabilidad, computación en la nube (Utilización de recursos),
106
Escalabilidad, Fiabilidad y Disponibilidad13, con respecto a los 5 escenarios
correspondientes a los patrones de PaaS.
Tabla 7
Evaluación de los 5 patrones, respecto de 5 atributos de calidad.
Patrón Manejabilidad Utilización de Recursos
Escalabilidad Disponibilidad / Fiabilidad
SPP Alta Baja Baja Media SHPP Media / Alta Alta Media Baja CPP Media Alta Media Alta
MSHPP Baja Alta Alta Media MCPP Baja Alta Alta Alta
Nota. Recuperado de Ardagna et al. (2012).
Métricas
Para efectos de la predicción, se han utilizado las siguientes 07 métricas (03 a
nivel de plataforma y 04 a nivel de host)
A nivel plataforma
Conteo total (Total Count, TC):
Número de mensajes enviados a un punto final (endpoint) determinado. Si la
métrica excede un umbral conocido, el rendimiento podría verse afectado y se generará
una alarma.
Conteo de fallos (Fault Count, FC):
Número de mensajes que resultaron en un error mientras se reenviaban al punto
final (endpoint). Estrictamente relacionado con TC, ofrece una evaluación sobre cómo
está funcionando el servicio y si aún puede cumplir con todas las solicitudes.
13 La Fiabilidad es la Disponibilidad de la API, (https://www.redhat.com/es/topics/api/what-is-api-
management)
107
Tiempo mínimo (Minimum Time, MinT), Tiempo máximo (Maximum Time,
MaxT) y Tiempo medio (Average Time, AveT):
El tiempo mínimo, máximo y medio que se tarda en enviar una solicitud al punto
final (endpoint) y recibir una respuesta. Una gran variación en MinT y MaxT indica que el
servicio puede no responder a cargas elevadas.
A nivel host
Carga de CPU (CPU Load, CL):
Utilización de la CPU en sistemas host e invitados. Los valores altos de CL en
una máquina virtual identifican un problema en el cumplimiento de la acumulación de
mensajes de solicitud.
Ocupación de memoria (Memory Occupancy, MO):
Utilización de Memoria en sistemas host e invitados. Los servicios que
administran una gran cantidad de datos (por ejemplo, archivos XML de gran tamaño)
pueden requerir porciones sustanciales de memoria en detrimento de otros servicios.
Utilización de la red (Network Utilization, NU):
Utilización del Ancho de banda de la red. Los valores altos de NU pueden sugerir
la reasignación de recursos externos para gestionar un pico de solicitudes.
Disponibilidad de host (Host Availability, HA):
Número de máquinas virtuales disponibles y accesibles a través de la red. La
caída del HA por debajo de un umbral predefinido indica la necesidad de nuevas
máquinas.
La evaluación tiene dos categorías de alarmas: de Mensaje y de Procesamiento,
de acuerdo a lo que se expone en la Tabla 8.
108
Tabla 8
Reglas de las alarmas.
ID Regla de alarma Alarma provocada
1 si FC/TC es ALTA Alarma de mensaje
2 si MaxT − MinT es ALTA
3 si AveTi − AveTj es ALTA
4 si TC es BAJA y MO es ALTA
5 si TC es ALTA y CL es BAJA y HA es BAJA
6 si CL es ALTA y TC es BAJA Alarma de procesamiento
7 si NU es ALTA
8 si TC es BAJA y CL es ALTA y HA es BAJA
Nota: Recuperado de Ardagna et al. (2012).
Entonces se genera la Alarma de Mensaje cuando:
El sistema no puede administrar la cola de mensajes eficientemente; El tiempo
promedio de entrega de mensajes, o la diferencia entre los tiempos de mensaje máximo
y mínimo está por encima de un umbral preestablecido.
Una Alarma de Procesamiento se utiliza:
Para escenarios en los que las ejecuciones de servicios pueden implicar un
tiempo de ejecución elevado o muchos recursos.
Una vez que se tiene definido el escenario y se han revisado las métricas,
finalmente se procede a aplicar las mediciones en el escenario en donde se pretende
implementar la aplicación.
Para mejor comprensión, los autores presentan un ejemplo en el que se detallan:
la PaaS, un número de solicitudes concurrentes de clientes (Request per second, RPS),
un número de pruebas, tiempo de demanda en transacciones por segundo
(Transactions per second, TPS) y el promedio de tiempo de respuesta en (Response
Time, RT), (ver Anexo “E”). Estas mediciones (post implementación) y simulaciones (pre
implementación), se las puede realizar con herramientas disponibles en plataformas de
pruebas de esfuerzo en la nube como:
109
Blazemeter (plan 50user gratuito - https://www.blazemeter.com/),
Dotcom (30días gratis - https://www.dotcom -monitor.com/es/),
Dynatrace (15días gratis - https://www.dynatrace.com/),
FloodIO (plan gratuito - https://www.flood.io/),
K6 (plan 50 pruebas gratuitas - https://k6.io/cloud),
Loader (plan 1000user gratuito - https://loader.io/),
LoadFocus (plan 20pruebas gratuitas - https://loadfocus.com/),
LoadStorm (plan 10user gratuito - https://loadstorm.com/),
LoadView (de pago - https://www.loadview-testing.com/),
OctoPerf (plan 50user gratuito - https://octoperf.com/pricing/),
O siempre se puede recurrir a JConsole y JMeter.
El cuestionario entonces, consta de 02 preguntas de selección y
completamiento, y son las siguientes:
===============================================================
CUESTIONARIO Nro. 01 (02 preguntas)
Lea detenidamente, y escoja la respuesta que más se acerque a su realidad, se
sugiere que estas preguntas sean respondidas por el encargado de la infraestructura o
del área de operaciones.
--- o ---
1. Marque con una “X”, el patrón de despliegue de infraestructura/plataforma/software,
en donde se pretende implementar el sistema; en este caso el término “en la nube”
puede ser equitativo a “en la infraestructura convergente o hiperconvergente”.
(descripción de los 5 patrones, ver Anexo “F”).
110
Opción 1 Opción 2 Opción 3 Opción 4 Opción 5
SPP ShPP CPP MShPP MCPP
2. De su infraestructura y con la ayuda de una herramienta de evaluación o simulación,
ingrese los valores de rendimiento, requeridos en la tabla siguiente: (7 métricas, ver
Anexo “F”).
Ord Indicador Valor unidad
1
Pla
tafo
rm
a
TC = Conteo Total rps
2 FC = Conteo de Fallos rps
3 MinT = Tiempo Mínimo MaxT = Tiempo Máximo AveT = Tiempo Promedio
ms. ms. ms.
4
Ho
st
CL = Carga de CPU tps
5 MO = Ocupación de Memoria %
6 NU = Utilización de la Red %
7 HA = Disponibilidad de Host %
===================================================================
Una vez receptado el cuestionario, se procede a computar los resultados para el
modelo de decisión, de la siguiente manera:
En la pregunta 1, y de acuerdo a lo que se muestra en la Tabla 7, donde los
autores indican la pertinencia de cada patrón de despliegue para que soporte
escalabilidad, se registrará una valoración porcentual de acuerdo a la siguiente
correspondencia:
Baja = 10%
Media = 50%
Alta = 100%
Por lo que en la Tabla 9, se aprecia la información completa:
111
Tabla 9
Valor porcentual (%) de los 5 Factores técnicos, de acuerdo a la opción elegida.
Manejabilidad
Computación en la nube
Escalabilidad
Disponibilidad / fiabilidad
Opción 1 100 10 10 50 Opción 2 75 100 50 10 Opción 3 50 100 50 100 Opción 4 10 100 100 50 Opción 5 10 100 100 100
Nota. Recuperado de Ardagna et al. (2012).
Esta primera parte de la respuesta, indicará el porcentaje de soporte para
adoptar MSA, de acuerdo a cada uno de los 5 factores técnicos indicados
(manejabilidad, computación en la nube, escalabilidad, disponibilidad y fiabilidad).
En la pregunta 2, y como se aprecia en la Tabla 10, el valor dependerá de las
alarmas que son disparadas de acuerdo a los valores ingresados en el cuestionario:
Tabla 10
Ejemplo de valores ingresados en el cuestionario (columna “valor”).
Ord Indicador capacidad Valor unidad
1
Pla
tfo
rm
TC = Conteo Total 1000 rps 2 FC = Conteo de Fallos 10 rps
3
MinT = Tiempo Mínimo MaxT = Tiempo Máximo AveT = Tiempo Promedio
25 30 27.5
ms. ms. ms.
4
Ho
st
CL = Carga de CPU 2 84 % 5 MO = Ocupación de Memoria 8GB 3 % 6 NU = Utilización de la Red 100/1000 Mbps 47 % 7 HA = Disponibilidad de Host 2 5 %
Nota. Basado en el trabajo de Ardagna et al. (2012).
En este punto los autores, Ardagna et al. (2012), indican que, los umbrales
ALTO y BAJO para las métricas y resultados, se pueden definir sobre la base de
pruebas experimentales previas y/o conocimientos de expertos. Los valores utilizados
para el presente modelo, con base en conocimientos de expertos, se indican en la tabla
11.
112
Tabla 11
Umbral de valores considerados ALTOS y BAJOS
ID Regla de alarma Unidad ALTO BAJO
1 FC/TC Mensajes >= 5% (3) <5%
2 MaxT − MinT Tiempo >=750ms(1) <750ms
3 AveTi − AveTj Tiempo >=25%(1) <25%
4 MO Memoria >=80%(2) <80%
5 TC Mensajes >=1200 (3) <1200
6 HA Host >=2 (3) <2
7 NU Red >=40%(2) <40%
8 CL CPU >=62%(1) <62%
Nota. Fuentes: (1) - (Muñoz-Escoí & Bernabéu-Aubán, 2017); (2) - (Celorio &
Fajardo, 2011); (3) Criterio de experto – Luis Caiza S, 2020.
Con los valores de la Tabla 10 ingresados, se procede a realizar las operaciones
descritas en la columna “Regla de alarma” de la Tabla 12, con lo que se obtiene los
valores y las alarmas disparadas que se aprecian en la columna “D” (Disparada) de la
Tabla 12. Una explicación detallada de este ejemplo se lo describe en el Anexo “G”.
Tabla 12
Valores resultantes y verificación de alarmas.
ID Regla de alarma D Alarma
1 si FC/TC es ALTA Alarma de mensaje
2 si MaxT − MinT es ALTA
3 si AveTi − AveTj es ALTA
4 si TC es BAJA y MO es ALTA
5 si TC es ALTA y CL es BAJA y HA es BAJA
6 si CL es ALTA y TC es BAJA X Alarma de procesamiento
7 si NU es ALTA X
8 si TC es BAJA y CL es ALTA y HA es BAJA
Nota: Basado en el trabajo de Ardagna et al. (2012).
113
Como se puede apreciar en la columna “D” de la Tabla 12, el instrumento arroja
2 eventos de disparos de alarmas (02 de procesamiento), equivalente al 25% del total
de las 8 alarmas posibles, entonces sacando un promedio entre los porcentajes de las 2
preguntas se tendría:
En el caso de que se haya escogido, por ejemplo, en la pregunta nro. 01, la
opción nro. 3 (CPP), los porcentajes serían los siguientes:
PATRÓN MANEJABILIDAD
UTILIZACIÓN DE RECURSOS
ESCALABILIDAD
DISPONIBILIDAD
FIABILIDAD
Opción 3 50 100 50 100 100
Se debe sumar cada factor al porcentaje de la segunda pregunta
MANEJABILIDAD
UTILIZACIÓN DE RECURSOS
ESCALABILIDAD
DISPONIBILIDAD
FIABILIDAD
25 25 25 25 25
En conclusión, si la institución en donde se va a implementar el sistema, tiene
una infraestructura que permita escalabilidad, la recomendación será positiva, por lo que
la respuesta en este factor será el promedio del porcentaje de las 2 preguntas del
instrumento, de cada uno de estos 5 factores técnicos:
MANEJABILIDAD
UTILIZACIÓN DE RECURSOS
ESCALABILIDAD
DISPONIBILIDAD
FIABILIDAD
37.5 62.5 37.5 62.5 62.5
INSTRUMENTO NRO. 2
Fundamentado en el factor técnico de INTEGRACIÓN CONTÍNUA
También encontrada por su acepción inglesa, (Continuous Integration, CI) y para
su operacionalización en el modelo de decisión, se ha utilizado el trabajo denominado
“Una Plataforma de Integración Continua Especializada en Desarrollo de Videojuegos”,
en la que Martínez-Mateu y Peinado (2018), realizan el proyecto de construcción de una
114
plataforma de integración continua orientada hacia el desarrollo, las pruebas y la
publicación de videojuegos. Como resultado se obtiene la primera versión funcional de
una herramienta basada en microservicios web que se presenta como libre, gratuita y de
fácil manejo para los desarrolladores, que la denominan GameCraft, desarrollada
específicamente para videojuegos, sin embargo, en el mismo estudio indican y
recomiendan como la plataforma más utilizada, igual de código abierto, a Jenkins, para
todo tipo de proyectos.
El cuestionario entonces, consta de 08 preguntas (de la 01 a la 04, cerradas con
respuestas en escala de Likert; y de la 05 a la 08, de selección múltiple), y son las
siguientes:
===================================================================
CUESTIONARIO Nro. 02 (08 preguntas)
Lea detenidamente, y escoja la respuesta que más se acerque a su realidad, se
sugiere que estas preguntas sean respondidas por el encargado de la arquitectura de
software.
En las preguntas de selección por favor marque con una “X” en la opción que
más se acerque a su opinión, en las preguntas abiertas debe detallar su respuesta.
1. Tengo experiencia usando herramientas de integración continua en el trabajo.
Totalmente en desacuerdo
En desacuerdo
Ni de acuerdo, ni en desacuerdo
De acuerdo
Totalmente de acuerdo
2. Considero que la integración continua no es un asunto exclusivo de los
programadores.
Totalmente en desacuerdo
En desacuerdo
Ni de acuerdo, ni en desacuerdo
De acuerdo
Totalmente de acuerdo
115
3. Considero que mi empresa actual da importancia a la integración continua.
Totalmente en desacuerdo
En desacuerdo
Ni de acuerdo, ni en desacuerdo
De acuerdo
Totalmente de acuerdo
4. Considero que la integración continúa debería ser más importante en mi empresa
actual.
Totalmente en desacuerdo
En desacuerdo
Ni de acuerdo, ni en desacuerdo
De acuerdo
Totalmente de acuerdo
5. ¿Qué herramientas de integración continua ha utilizado?
Ord. Herramienta
1 Anypoint Platform
2 AWS CodePipeline
3 Azure DevOps Server
4 Azure pipelines
5 Bamboo
6 Bitbucket Pipelines
7 Bitrise
8 Buddy
9 CircleCI
10 CodeShip
11 CruiseControl
12 GitLab CI
13 GameCraft
14 GoCD
15 Jenkins
16 Nevercode
17 Octopus Deploy
18 TeamCity
19 Travis CI
20 Otra (excepto herramientas de control de versiones como: AccuRev, Basaar, CVS, Dropbox, GDrive, Git, GitLab, Mercurial, Perforce, IBM Rational Clear Case, SVN, VSS, etc. )
116
6. En el uso profesional de las herramientas de integración continua, ¿cuáles son los
principales obstáculos y dificultades?
Ord. Obstáculo
1 Archivos binarios y/o planos.
2 Dificultad para excluir archivos a sincronizar.
3 Difícil configuración.
4 Difícil instalación (cuestionables ventajas).
5 Difícil utilización.
6 El uso de lenguajes script sin compilador causa muchas iteraciones hasta que el script funciona.
7 Elevada curva de aprendizaje.
8 Entender la filosofía y aplicarlo de forma continua.
9 Falta de disciplina y adaptación de un usuario primerizo al uso de herramientas como estas.
10 Herramientas poco intuitivas.
11 La comunicación.
12 Mentalizar a TODO el equipo de que cualquier cosa que se suba al repositorio debe ser probada, aún si no hay herramientas de integración continua.
13 Merging y branching.
14 No querer aprender por parte de mis superiores.
15 My Spanish is not good, but I can read. The main difficulties is that developers do not understand the importance of CI, and not willing to write unit tests.
16 Que no cuente con un buen analizador de calidad de código.
17 Que no se adapte al proyecto en desarrollo.
18 Que no tenga buena documentación.
19 Se requiere de un equipo potente y dedicado exclusivamente a esta tarea.
20 Setup (configuración) para múltiples plataformas "no estándar".
21 Otro.
117
7. ¿Qué características y facilidades valorarías más en una hipotética herramienta de
integración continua?
Ord. Característica más deseable
1 Que sea gratis.
2 Que sea de código abierto.
3 Que se integre fácilmente con Unity o Unreal.
4 Que esté bien documentado.
5 Que sea fácil de instalar y configurar.
6 Que sea fácilmente escalable.
7 Que esté tanto en español como en inglés.
8 Que ofrezca servicios adicionales para la mejora de productividad como analizador de calidad de código.
9 Que su funcionalidad pueda ampliarse mediante plug-ins.
10 Otro.
8. ¿Qué aspectos y funcionalidades valoras más en las herramientas de integración
continua que ya has utilizado?
Ord. Aspecto con más valor
1 Soporte para macOS.
2 Soporte para GNU/Linux.
3 Soporte para Windows.
4 Que sea gratuito.
5 Que sea de código abierto.
6 Que esté traducido en varios idiomas.
7 Que pueda integrarse con plug-ins de terceros.
8 Que tenga soporte nativo al motor Unity.
9 Que tenga soporte nativo al motor Unreal.
10 Que tenga soporte nativo al motor Monogame.
11 Que tenga soporte nativo al motor Libgdx.
12 Que cuente con un buen analizador de calidad de código.
13 Que tenga buena documentación.
14 Que sea fácil de instalar.
15 Que sea fácil de configurar.
16 Que sean muy adaptables al proyecto en desarrollo.
17 Poder excluir fácilmente archivos a sincronizar.
18 Que sea fácil de usar.
19 Otro.
===================================================================
118
De las respuestas recolectadas, y de acuerdo a la metodología utilizada por los
autores del estudio, podemos evaluar el grado de comprensión de la integración
continua, tomando en cuenta que es un factor que interviene y es deseable en el
desarrollo de un software en la arquitectura de microservicios, ya que potencializa en
gran medida a la arquitectura, sobre todo en ambientes DevOps y desarrollo
compartido. En Tal virtud, la interpretación de los resultados, los autores la realizan de
forma cualitativa, para propósitos del modelo de decisión en desarrollo, se la adapta y
se la cuantifica de la siguiente manera:
En las preguntas 01, 02, 03 y 04 se sumará las respuestas de acuerdo a la
valoración de la Tabla 13:
Tabla 13
Valoración de las respuestas desde la escala de Likert.
Opción Valoración
Totalmente en desacuerdo 0 En desacuerdo 0 Ni de acuerdo, ni en desacuerdo 1 De acuerdo 2 Totalmente de acuerdo 3
Por lo que, en el mejor de los casos, en estas 4 preguntas, se puede sumar 12
puntos.
En la pregunta 05, se debe evaluar que no exista confusión con otras
herramientas y cuidar de que no se confunda la integración continua con el “mero hecho
de usar sistemas de control de versiones como SVN o Git.” (Martínez-Mateu y Peinado,
2018). En tal virtud en caso de seleccionar alguna de las herramientas del listado, se le
dará el valor de 1, caso contario 0.
En la pregunta 06, 07 y 08 en caso de seleccionar por lo menos un (01) ítem, se
dará el valor de 1, y en caso de no seleccionar, significará que no se tiene un
entendimiento ni experiencia en CI, por lo que se le asigna el valor de 0.
119
En conclusión, si el equipo de desarrollo tiene una experiencia media, en la
utilización de técnicas y herramientas de CI, el modelo de decisión sugerirá implementar
microservicios, de acuerdo a la siguiente valoración:
<8 = No se recomienda.
>= 8 SI se recomienda.
16 puntos = altamente recomendable (se tiene experiencia)
INSTRUMENTO NRO. 3
Fundamentado en los factores técnicos de MODULARIDAD, MANTENIBILIDAD,
REUSABILIDAD, PORTABILIDAD, FLEXIBILIDAD, INTEROPERABILIDAD, COHESIÓN
Y ACOPLAMIENTO.
La modularidad, es el factor técnico en el que se fundamenta la arquitectura de
microservicios, al dividir una gran funcionalidad en varias más pequeñas, y como
consecuencia se crea dependencia e interrelación entre la modularidad y otros factores
técnicos como mantenibilidad, reusabilidad, portabilidad, flexibilidad e interoperabilidad,
con los que se pretende conseguir la deseable alta cohesión y el bajo acoplamiento.
En este escenario, para medir el impacto que la Modularización tendría en el
desarrollo de un futuro sistema de información bajo la arquitectura de microservicios, el
modelo de decisión propuesto, utiliza el método de “Deng y Mercado” que se lo
desarrolla en el trabajo de investigación denominado: “Towards an Analytical Approach
to Measure Modularity in Software Architecture Design”, en el que Ghasemi, Sharafi &
Arman (2015), proponen su herramienta matemática, fundamentada en componentes y
sistemas, para determinar el grado en el que la modularidad interviene en el producto
software.
Para esto, los autores proponen los 3 siguientes pasos:
1) Se implementan las métricas y sus respectivos pesos (únicamente los de nivel
Componente, debido a que se espera medir modularidad por Componente o módulos
120
del sistema), medidas determinadas por el método “Deng y Mercado” que se indican
en la Tabla 14.
Tabla 14
Métricas utilizadas para medir la modularidad, con el peso.
Grupo Nivel Métrica Descripción Peso
Acoplamiento Sistema CBN Coupling Between Nodes
El número de dependencias de un nodo físico a otros nodos físicos.
0
Acoplamiento Componente CBCOM Coupling Between Components
El número de todas las dependencias de un componente a otros componentes.
0.1
Acoplamiento Componente AC Afferent Coupling Between Components
La cantidad de componentes que requieren servicio del componente evaluado.
0.1
Acoplamiento Componente EC Efferent Coupling Between Components
El número de componentes de los que el componente evaluado requiere servicio de ellos.
0.15
Cohesión Componente NUCPCOM Number of Use Case per Component
El número de casos de uso en los que participa un componente.
0.1
Acoplamiento Componente NumCycles El número de ciclos de dependencia de un componente.
0.3
Acoplamiento Componente InDepned El número de rutas indirectas de un componente a otros componentes.
0.25
Granularidad Sistema NCOMPUC Number of Components per Use Case
El número de componentes correspondientes a un caso de uso.
0
Granularidad Componente NCPCOM Number of Classes per Component
El número de clases por módulo.
0
Nota. Recuperado de Ghasemi et al., 2015.
121
2) Se procede a determinar los componentes o módulos que intervienen en el sistema a
desarrollar. Para esto se hace referencia al trabajo “A logical architecture design
method for microservices architectures” en el que Santos, Salgado, Morais, Melo,
Silva, Martins, Pereira, Rodíguez, Machado, Ferreira y Pereira (2019), proponen los
componentes (unidades modulares) de la Tabla 15, pertenecientes a un sistema ERP
bajo la arquitectura de microservicios, que será la plantilla de ejemplo en el modelo
de decisión, pudiendo ser personalizada en caso de requerirse para otro tipo de
sistema, o realizar del módulo más grande en sistemas extensos, valores que deben
ser determinados por el arquitecto del sistema y registrados en el campo “OValue”
(Valor Original). Por otra parte, en el campo “NValue” (Valor Normalizado), se deberá
registrar el valor de cada componente, normalizado de acuerdo a la fórmula (1).
𝑥 =𝑑 − 𝑑𝑚𝑖𝑛
𝑑𝑚𝑎𝑥−𝑑𝑚𝑖𝑛𝑖𝑓 𝑑! = 𝑑𝑚𝑖𝑛 ∧ 𝑑𝑚𝑎𝑥
𝑥 = 0 𝑖𝑓 𝑑 = 𝑑𝑚𝑖𝑛 𝐴𝑁𝐷 𝑥 = 1 𝑖𝑓 𝑑 = 𝑑𝑚𝑎𝑥
En donde:
d = valor a normalizar; dmax = límite máximo; dmin = límite mínimo
Por ejemplo, en la columna CBCOM de la Tabla 15, los valores van desde el 1
hasta el 12; entonces dmin = 1 y dmax = 12, por lo tanto, el OValue de 1 es 0, y el
OValue de 15 es 1; ahora para encontrar el OValue de los números intermedios,
aplicamos la fórmula (1), por ejemplo, para el caso del 5:
𝑥 =5 − 1
12 − 1=
4
11= 0.36
Una vez que se tenga llena la tabla con los valores OValue y NValue, para
encontrar el valor de Modularidad en cada componente se aplica la fórmula (2), con los
valores existentes normalizados y con los pesos registrados en la Tabla 15.
𝑀𝑜𝑑𝑢𝑙𝑎𝑟𝑖𝑡𝑦𝑐𝑜𝑚 𝑖 = 𝑁𝑈𝐶𝑃𝐶𝑂𝑀 ∗ 𝑊1 + (1 − 𝐶𝐵𝐶𝑂𝑀) ∗ 𝑊2 + (1 − 𝐴𝐶) ∗ 𝑊3 + (1 − 𝐸𝐶) ∗
𝑊4 + (1 − 𝑁𝑢𝑚𝐶𝑦𝑐𝑙𝑒𝑠) ∗ 𝑊5 + (1 − 𝐼𝑛𝐷𝑒𝑝𝑛𝑒𝑑) ∗ 𝑊6 + (1 − 𝑁𝐶𝑃𝐶𝑂𝑀) ∗ 𝑊7
(2)
122
===================================================================
CUESTIONARIO Nro. 03 (01 pregunta)
Por favor ingrese los valores de modularidad esperada en la columna OValue en
cada una de las métricas.
Tabla 15
Valores de las métricas y modularidad de cada componente.
Nota. Basado en el trabajo de Ghasemi et al., 2015.
OValueNValueOValueNValueOValueNValueOValueNValueOValueNValue
p1 Inventario 0 0 12 1 6 1 5 0,5 7 1
p2 Compras 0 0 4 0,27 4 0,67 5 0,5 2 0,17
p3 Ventas 0 0 7 0,55 5 0,83 6 0,6 5 0,67
p4 Producción 0 0 8 0,64 1 0,17 7 0,7 3 0,33
p5 Subcontratación 0 0 8 0,64 4 0,67 4 0,4 1 0
p6 Control de calidad 0 0 6 0,45 2 0,33 3 0,3 1 0
p7 Planificación 0 0 12 1 5 0,83 9 0,9 2 0,17
p8 Empaquetamiento 0 0 7 0,55 3 0,5 4 0,4 1 0
p9 Operaciones financieras 0 0 8 0,64 5 0,83 10 1 6 0,83
p10 Gestión de interesados 0 0 7 0,55 2 0,33 5 0,5 3 0,33
p11 Seguridades 0 0 1 0 1 0,17 3 0,3 1 0
p12 Aplicaciones web 0 0 5 0,36 4 0,67 5 0,5 3 0,33
p13 Servidor de aplicaciones 0 0 1 0 2 0,33 2 0,2 4 0,5
p14 Servidores contenedores 0 0 2 0,09 2 0,33 1 0,1 3 0,33
p15 Servidores Base de datos 0 0 1 0 0 0 0 0 3 0,33
p16 Gestión de APIs 0 0 1 0 0 0 0 0 2 0,17
OValueNValueOValueNValueOValueNValueOValueNValue
p1 Inventario 3 0,25 3 0,75 0 0 0 0
p2 Compras 2 0,17 4 1 0 0 0 0
p3 Ventas 3 0,25 3 0,75 0 0 0 0
p4 Producción 2 0,17 0 0 0 0 0 0
p5 Subcontratación 1 0,08 1 0,25 0 0 0 0
p6 Control de calidad 1 0,08 1 0,25 0 0 0 0
p7 Planificación 0 0 0 0 0 0 0 0
p8 Empaquetamiento 0 0 0 0 0 0 0 0
p9 Operaciones financieras 0 0 1 0,25 0 0 0 0
p10 Gestión de interesados 0 0 2 0,5 0 0 0 0
p11 Seguridades 0 0 0 0 0 0 0 0
p12 Aplicaciones web 4 0,33 2 0,5 0 0 0 0
p13 Servidor de aplicaciones 1 0,08 0 0 0 0 0 0
p14 Servidores contenedores 1 0,08 0 0 0 0 0 0
p15 Servidores Base de datos 0 0 0 0 0 0 0 0
p16 Gestión de APIs 12 1 0 0 0 0 0 0
TOTAL
CBN CBCOM AC
0,696
0,6225
EC NUCPCOM
NumCycles InDepned NCOMPUC NCPCOM
0,531
0,4625
0,852
Modularidad
COMPONENTE
COMPONENTE
0,599
0,735
0,6235
0,645
0,838
0,447
0,4765
0,863
0,6905
0,933
0,617
10,63
123
3) Ahora el arquitecto de software asigna un peso a cada uno de los componentes del
sistema a desarrollar, en base a su importancia para la Modularidad, para lo cual, se
procede a multiplicar cada valor de la modularidad de cada componente por el valor
del peso asignado, con lo que se obtiene el porcentaje de modularidad por cada
componente, según se aprecia en la Tabla 16. Una explicación detallada de este
ejemplo se lo describe en el Anexo “H”
Tabla 16
Valor de Modularización ponderado, de cada componente.
Nota. Basado en el trabajo de Ghasemi et al., 2015.
===================================================================
Finalmente se obtiene el valor de modularidad final, como se aprecia en la Tabla
16 el sistema tiene un 54% de factor de modularidad, lo que indica, que existe una
correlación entre este factor y el modelo de decisión propuesto, en ese porcentaje.
COMPONENTE peso
p1 Inventario 0,2
p2 Compras 0,1
p3 Ventas 0,3
p4 Producción 0,05
p5 Subcontratación 0,01
p6 Control de calidad 0,03
p7 Planificación 0,04
p8 Empaquetamiento 0,01
p9 Operaciones financieras 0,04
p10 Gestión de interesados 0,04
p11 Seguridades 0,04
p12 Aplicaciones web 0,1
p13 Servidor de aplicaciones 0,01
p14 Servidores contenedores 0,01
p15 Servidores Base de datos 0,01
p16 Gestión de APIs 0,01
1 0,54321
Mod*peso
0,0531
0,00863
0,00852
0,00933
0,00617
0,02396
0,00735
0,02494
0,0258
0,03352
0,0447
0,14295
0,0348
0,006225
0,020715
0,531
0,863
0,852
0,933
0,617
0,599
0,735
0,6235
0,645
0,838
0,447
0,4765
0,696
0,6225
0,6905
Modularidad
0,4625 0,0925
124
Respecto del umbral desde el cual, se considera un porcentaje aceptable de
modularidad para que sea considerada la sugerencia positiva hacia la adopción de
MSA, Ghasemi et al. (2015), indican que “la conveniencia del nivel de modularidad
medido depende completamente del arquitecto” (p.11), un criterio similar tienen Vural &
Koyuncu (2021), en su trabajo denominado “Does Domain-Driven Design Lead to
Finding the Optimal Modularity of a Microservice?”, en donde manifiestan que “No hay
una respuesta fácil para encontrar el tamaño correcto de un microservicio donde hay
tantos factores diferentes, como la complejidad del dominio, el método de medición, el
lenguaje que se usa, etc.” (p.12). En este sentido entonces nos referiremos al trabajo
“Decoupling Level: A New Metric for Architectural Maintenance Complexity”, donde Mo
et al. (2016), realizan mediciones en más de 120 proyectos de software, con un nueva
métrica que la llaman “nivel de desacoplamiento” (Decoupling Level - DL), que mide el
grado de modularidad de las aplicaciones, y en donde manifiestan que “el DL promedio
de todos los proyectos de código abierto y proyectos industriales es del 60% y 54%
respectivamente” (p.5), coincidiendo con el porcentaje que se obtuvo en el caso de
prueba que se realizó para la demostración del presente cuestionario, que fue del 54%,
así mismo determinan el valor mínimo como 14% y el máximo como 94%, por lo tanto,
el umbral desde el que se toma como recomendación positiva, para el presente modelo
de decisión, será del 14%.
Con las métricas de modularidad, también se obtienen otras lecturas,
concernientes a otros factores técnicos como es el caso de la mantenibilidad, usabilidad,
cohesión, acoplamiento, granularidad y reusabilidad, por ejemplo, un valor alto de la
métrica NCPCOM (Número de clases por componente) significa que el sistema tendrá
un buen factor de reutilización, pero de la misma forma requerirá de una alta
mantenibilidad. De la misma forma un alto porcentaje en AC y en EC, significa un bajo
acoplamiento debido al número aceptablemente alto de componentes.
125
Otras lecturas indican que un valor NCCOMP > 50 %, revela una aceptable
reusabilidad y mantenibilidad, así mismo los valores de AC y EC demuestran el
acoplamiento, NUCPCOM Cohesión-portabilidad y la modularidad indica a su vez
flexibilidad e interporatibilidad.
Finalmente, el resultado se lo obtiene en forma de recomendación positiva o
negativa, para todo el proyecto, y también la recomendación alcanzada por cada uno de
sus factores, se presenta un ejemplo en el numeral 3.3.4.
Como conclusión en esta parte del diseño del modelo, y como se aprecia en la
Tabla 17, de los 10 factores técnicos iniciales que fueron determinados en la revisión
sistematizada, se pudieron utilizar 7 con la aplicación de los 3 instrumentos de
predicción, pero así mismo, se aumentaron otros 7, que fueron utilizados en los
instrumentos por parte de los autores y que están estrechamente relacionados entres si,
por lo que se los adoptó. Con esta particularidad, el modelo DMTF, queda conformado
finalmente por 14 factores técnicos, quedando excluidos 3 de los iniciales 10, de
acuerdo al siguiente detalle:
126
Tabla 17
Comparación de Factores Técnicos determinados vs factores técnicos utilizados en el
modelo.
F.T. Determinados F.T. Utilizados
1 Escalabilidad dinámica 1 Escalabilidad dinámica 2 Integración 2 Integración continua 3 Modularización 3 Modularidad 4 Organización del
equipo
5 Adaptabilidad 6 Computación en la
nube 4 Computación en la nube
7 Comunicaciones livianas
8 Flexibilidad 5 Flexibilidad 9 Mantenibilidad 6 Mantenibilidad 10 Cohesión y
acoplamiento 7 Cohesión
8 Acoplamiento 9 Manejabilidad 10 Disponibilidad 11 Fiabilidad 12 Reusabilidad 13 Portabilidad 14 Interoperabilidad
El cuestionario final resultante, implementado en un solo instrumento con las 11
preguntas, se lo puede observar en el Anexo “I”.
3.3. Proceso de implementación y presentación de resultados del modelo de
decisión
MODELO DE DECISIÓN POR FACTORES TÉCNICOS
Decision Model by Technical Factors (DMTF)
MÉTODO
La implementación del modelo DMTF, básicamente se fundamenta en la
implementación de los 3 instrumentos de predicción, cuyas respuestas dan valor a sus
correspondientes métricas, que miden el nivel de impacto de la presencia o ausencia de
determinado factor, con lo cual se confecciona la recomendación final en términos de
127
porcentajes de recomendación, de adoptar la arquitectura de microservicios en un
módulo o sistema completo.
El modelo de decisión, además adapta la estructura del modelo de evaluación
ATAM, en la caracterización de los Atributos de Calidad, en nuestro caso de los
Factores Técnicos, en la que se ha establecido una metodología que consta de 03
pasos, apoyada en principios de metodologías ágiles.
3.3.1. Paso 1: Presentación del modelo.
El primer paso, consiste en realizar una presentación del modelo de decisión, por
parte del encargado de la implementación, a las partes interesadas. Es importante que
todos los involucrados sepan los fundamentos, la información que se recopilará, cómo
se analizará y a quién se informará sus resultados, para esto, la presentación abarca 8
puntos:
Un resumen del modelo DMTF.
Conceptualización de los 14 factores técnicos que lo fundamentan.
Las técnicas utilizadas para la definición de los factores técnicos.
Tipo de información que se requerirá.
Un resumen de los 03 pasos para la implementación del modelo DMTF.
Explicación del proceso de implementación y análisis del modelo (en la herramienta
informática DMTF)
Interpretación de resultados y reportes posibles.
Destino de los resultados.
3.3.2. Paso 2: Presentar los impulsores comerciales
En este paso, el Product Owner, presenta una descripción general del sistema
desde una perspectiva empresarial, con un alto nivel de abstracción, describiendo:
128
Requisitos funcionales más importantes.
Requisitos no funcionales más importantes.
Restricciones técnicas, administrativas, económicas o políticas.
Objetivos comerciales y contexto.
Principales partes interesadas.
3.3.3. Paso 3: Implementación del modelo
El tercer y último paso tiene que ver con la aplicación de la herramienta unificada
que operacionaliza el modelo de decisión, en este paso se procede a responder la
matriz de preguntas, constituida por los 3 cuestionarios con las 11 preguntas del
modelo, y con la ayuda de la herramienta informática, distribuidas como muestra la
Tabla 18:
Tabla 18
Resumen de la distribución de las preguntas con que cuenta el modelo DMTF.
Cuestionario Nro. 1
Fundamentada en los factores de: Manejabilidad, Computación en la nube, Disponibilidad, Fiabilidad, Escalabilidad dinámica 02 preguntas
Cuestionario Nro. 2
Fundamentada en el factor de: Integración continua 08 preguntas
Cuestionario Nro. 3
Fundamentada en los factores de: Modularidad, Mantenibilidad, Reusabilidad, Portabilidad, Flexibilidad, Interoperabilidad, Cohesión y Acoplamiento. 01 pregunta
TOTAL 11 preguntas 14 Factores técnicos
3.3.4. Resultado final
Luego de haber contestado las 11 preguntas, los valores totales obtenidos, se
comparan con los umbrales del modelo, luego de lo cual, se emite la recomendación
final que está compuesta de dos aspectos:
129
Primer aspecto. Es la expresión booleana en forma de texto que indica: “SI o
No” se recomienda, la adopción de una arquitectura de Microservicios, en forma general
y es obtenida en base al porcentaje conseguido en cada una de las preguntas y de
acuerdo a los umbrales determinados en cada uno de los 3 instrumentos.
Segundo aspecto. Constituye el indicador booleano por cada uno de los
factores en donde indica si ese factor alcanzó el umbral para que su Recomendación,
pudiendo ser esta, positiva o negativa.
El resultado final del modelo se expresa de la siguiente manera:
Con base en las respuestas proporcionadas al cuestionario del modelo de decisión
DMTF, (SI o NO) se recomienda la adopción de la arquitectura de microservicios según
el siguiente detalle de conveniencia por cada uno de los 14 Factores Técnicos:
1. Manejabilidad (SI/NO)
2. Computación en la nube (SI/NO)
3. Disponibilidad (SI/NO)
4. Fiabilidad (SI/NO)
5. Escalabilidad dinámica (SI/NO)
6. Integración continua (SI/NO)
7. Modularidad (SI/NO)
8. Mantenibilidad (SI/NO)
9. Reusabilidad (SI/NO)
10. Portabilidad (SI/NO)
11. Flexibilidad (SI/NO)
12. Interoperabilidad (SI/NO)
13. Cohesión (SI/NO)
14. Acoplamiento (SI/NO)
130
Capítulo 4
4.1. Construcción de la herramienta tecnológica
En este punto se detallan los pasos que se realizaron para la construcción de la
herramienta informática, para implementar el DMTF de forma más amigable, que
permita ingresar las respuestas a las preguntas de los 3 cuestionarios base del DMTF, y
que después de calcular su aplicabilidad, nos presente un informe cuantitativo y un
reporte gráfico que permita tener un documento de sustento para el arquitecto de
software responsable de la implementación de la arquitectura de un sistema.
A pesar de que la herramienta como tal, no constituye el centro mismo del
presente trabajo de investigación, se ha pretendido darle un valor agregado al modelo
DMTF con el fin de potenciar su utilización, investigación y manipulación, la que se
espera aumente con el desarrollo de esta aplicación.
Se describe entonces de forma general los pasos que se siguieron, los cuales se
fundamentaron en metodologías ágiles de desarrollo, herramientas, lenguajes de
programación y base de datos actuales y por supuesto se adoptó la arquitectura de
microservicios.
4.1.1. Levantamiento de requisitos.
En este punto se levantaron las Historias de Usuario (HU), para lo cual se
implementó una matriz en una hoja de cálculo, con el formato general de una historia de
usuario de acuerdo a un formato de metodologías ágiles:
Como un < >
Necesito < >
Con la finalidad de < >
Esta tabla se la puede apreciar en el Anexo “J”.
131
4.1.2. Diseño de la arquitectura.
La arquitectura en la que se realizó la herramienta, congruentemente fue
microservicios, en primer lugar, para que los conceptos de los factores técnicos sean,
vivencialmente mejor aprehendidos, y en segundo lugar porque se trata de una
herramienta liviana con microservicios independientes y cuyo alcance permite la
comprensión y detalle muy alto de lo que se espera que realice la aplicación, fácil de
ampliar, desplegar y mantener.
Como se aprecia en la Figura 19, la comunicación se realiza mediante API –
REST a través de paquetes JSON y los clientes de la aplicación consumirán
microservicios mediante URI de la red.
Figura 19
Arquitectura de la herramienta del DMTF.
132
4.1.3. Desarrollo.
Herramientas y técnicas. Para el desarrollo de la aplicación, se utilizaron las
siguientes herramientas, técnicas y métodos:
Lenguaje de programación de servidor : Java
Lenguaje de Front End : TypeScript
Base de datos : MySQL
Servidor : GlassFish
Método de intercambio con el servidor : Ajax
IDE de desarrollo : Eclipse
Versionador : GitHub
Metodología de desarrollo. A pesar del tamaño pequeño de la aplicación, con
el propósito de generar una cultura y una filosofía integral de trabajo, en el contexto
actual, en la que la adopción de los microservicios está estrechamente ligada con
términos como computación en la nube, comunicaciones seguras, contenedores, entre
otros, además con la implementación de metodologías ágiles de desarrollo como Scrum
y especialmente DevOps, el desarrollo de la herramienta se la realizó siguiendo los
principios de metodologías ágiles, adoptando las buenas prácticas de algunas de ellas
como Scrum, Extreme programming y Metodologías escalables e incrementales.
Proceso. Se adoptó el Product Backlog (PB) de Scrum, para la gestión y
supervisión de las tareas en función de sus tiempos y plazos programados, además
para esta tarea se utilizó la herramienta de gestión de proyectos Jira, en su versión web
gratuita, con lo que el Product Backlog, quedó de la manera que se observa en la Tabla
19.
133
Tabla 19
Product Backlog del proyecto Desarrollo del DMTF.
Ord Tareas
1 Elaboración del Product Backlog
2 Definición de Sprints
3 Levantamiento de requisitos
4 Diseño de la arquitectura
5 Desarrollo del formulario de ingreso de usuarios
6 Desarrollo del formulario de factores técnicos y preguntas
7 Desarrollo del reporte escrito
8 Desarrollo del reporte gráfico
9 Pruebas
10 Implementación
Sprints. Se adoptó también el concepto de sprints de Scrum para ir realizando
entregas parciales y funcionales del sistema, así entonces se determinó 5 entregas
parciales divididas en 5 Sprints con una duración de 1 semana cada uno, como se
indica en la Tabla 20.
En el primer sprint se determinó la entrega del Product Backlog, con su
asignación de responsables y tiempos, también se determinó la entrega de la
planificación de todos los sprints.
En el segundo sprint, se estableció el levantamiento de requisitos y el diseño de
la arquitectura del sistema.
En el tercer sprint se determinó la realización del formulario de ingreso de
usuarios a la aplicación y el desarrollo del formulario de los factores técnicos y el
cuestionario para poder contestar la matriz de preguntas del modelo.
En el cuarto sprint se determinó el desarrollo del reporte escrito y el reporte
gráfico.
Por último, en el quinto sprint, se estableció la realización de las pruebas y la
implementación de la aplicación informática en el servidor y su publicación al internet.
134
Tabla 20
Planificación de las tareas, con responsables, divididas en 5 Sprints.
Ord. Tareas Encargado
1 Sprint planning 1 GG
2 Elaboración del product backlog GG
3 Definición de sprints GG
4 Sprint planning 2 LC
5 Levantamiento de requisitos LC
6 Diseño de la arquitectura LC
7 Sprint retrospective 2 LC
8 Sprint planning 3 GG
9 Desarrollo del formulario de ingreso de usuarios GG
10 Desarrollo del formulario de factores técnicos y preguntas GG
11 Sprint retrospective 3 GG
12 Sprint planning 4 LC
13 Desarrollo del reporte escrito LC
14 Desarrollo del reporte gráfico LC
15 Sprint retrospective 4 LC
16 Sprint planning 5 GG
17 Pruebas GG
18 Implementación GG
19 Sprint retrospective 5 GG
Nota: LC: Luis Caiza; GG: Gustavo Guaigua.
Reuniones. Únicamente se realizaron 2 tipos de reuniones, una vez más de la
metodología Scrum: la reunión de Sprint Planning y la Sprint Retrospective, (no se
realizaron las reuniones Daily Scrums), estas se llevaron a efecto vía videoconferencia,
para lo cual se aprovechó además herramientas de trabajo colaborativo y para control
de versionamiento como la plataforma GitHub. Cabe indicar que en todas las ocasiones
se terminó uniendo estas dos reuniones en una sola, ya que se empezaba a evaluar el
trabajo de la semana que terminaba e inmediatamente se planificaba el trabajo de la
siguiente en la misma reunión (Sprint retrospective + sprint planning).
4.1.4. Pruebas.
En el desarrollo de la aplicación se pudo experimentar la necesidad de asegurar
su funcionalidad óptima, con base en dos motivos principales: el primero, para tratar de
135
popularizar la utilización del modelo; y el segundo debido a que la aplicación se
desarrolló en la arquitectura de microservicios, precisamente para obtener una
experiencia vivencial de primera mano que permita mejorar la comprensión de la
arquitectura.
En este escenario se hizo necesario probar el funcionamiento y la codificación, a
través de pruebas unitarias, durante el desarrollo, pero también de pruebas de
rendimiento y funcionalidad de las APIs, finalmente se realizaron también pruebas de
estrés para medir el rendimiento de la aplicación con varios usuarios concurrentes.
Por tratarse de una aplicación relativamente pequeña, se pudo realizar estas
pruebas con relativa comodidad, aunque no se tomaron en cuenta otro tipo de pruebas
más completas que se realizan para sistemas muchos más grandes, tales como
pruebas de componentes, de integración, o de aceptación, entre otras.
Para las pruebas de carga, rendimiento y stress se utilizó la herramienta Apache
JMeter y básicamente consistió en realizar una simulación de carga de varios usuarios
concurrentes a la aplicación, con un grupo de usuarios, donde se realizaron llamadas al
servidor que tiene la aplicación mediante su URL y a través del método HTTP (GET).
En la Figura 20, se puede apreciar una vista previa de las pruebas de carga
realizadas a la aplicación DMTF y de la cual se obtuvo el reporte que se observa en la
Figura 21, que indica en resumen, que el rendimiento de la aplicación DMTF es de
1.491.193 por minuto. Lo que significa que los servidores pueden atender 1,491,193
solicitudes / minuto.
136
Figura 20
Pantalla principal de la herramienta JMeter con una prueba de carga de la aplicación del
DMTF.
Figura 21
Reporte del rendimiento de la aplicación DMTF (herramienta JMeter).
137
Para las pruebas de rendimiento y funcionalidad de las APIs se utilizó Postman.
El proceso de pruebas de las API, básicamente consistió en realizar llamadas al
servidor que hospeda la API y recuperar su respuesta. Con este procedimiento se
esperó confirmar su correcta ejecución, así como validar los métodos HTTP que se
utilizan en un formulario CRUD habitual, tales como: Create (POST), Read (GET),
Update (PUT), Delete (DELETE), entre los principales.
4.1.5. Implementación.
La implementación de la herramienta se la realizó a través de un servidor
publicado en el internet, de manera que se tenga acceso a la misma, desde cualquier
lugar, en este caso desde la institución donde se realizó el caso de estudio y desde la
institución académica patrocinadora del proyecto.
En este sentido la aplicación se encuentra disponible en la URL:
http://bit.ly/dmtf-espe
138
Capítulo 5
5.1. Implementación del modelo de decisión DMTF en el caso de estudio
En este capítulo se detalla la experiencia al haber implementado el modelo de
decisión propuesto (DMTF) en el caso de estudio, el desarrollo del sistema denominado
“Sistema Integral de Talento Humano - SITHU”, sistema a desarrollarse en la Fuerza
Aérea Ecuatoriana en el año 2021.
Se ha considerado pertinente la aplicación en un caso práctico, con el afán de
unir la línea de la investigación con el campo profesional, que permita avanzar en la
política de vinculación con la sociedad, que persigue la Universidad de Fuerzas
Armadas UFA-ESPE, patrocinadora del presente proyecto.
5.1.1. Introducción.
La Fuerza Aérea Ecuatoriana, se encuentra desarrollando, desde el mes de
octubre de 2020, el nuevo Sistema Integral de Talento Humano - SITHU, el mismo que
posee alrededor de 48 módulos principales, tales como: Seguridades, Catálogo,
Graduaciones, Pases, Ascensos, Plan de carrera, Separación institucional,
Condecoraciones, Rol de pagos, entre los principales.
En este contexto, el modelo DMTF propuesto, se aplicó al proceso de
“Ascensos”, por ser uno de los más representativos, y que se encuentra previsto de
realizarse a mediados del año 2021 pues al momento ya se encuentra en desarrollo el
primer módulo del SITHU, el de “Seguridades”, que se lo está realizando en la
arquitectura de microservicios, por decisión del Jefe del Departamento.
5.1.2. Aplicación del modelo en el caso de estudio.
Se implementó entonces el modelo DMTF, en el “Módulo Ascensos” del sistema
SITHU, para lo cual se desarrollaron los 3 pasos que constituyen la metodología de
implementación del modelo de decisión propuesto.
139
Paso 1 - Presentar el modelo. En este primer paso, se realizó una reunión con
el Jefe del Dpto. de Desarrollo de Sistemas de la DIRTIC y 2 supervisores técnicos,
donde se expuso el concepto y la metodología del modelo de decisión DMTF, en 8
puntos:
Un resumen del modelo DMTF.
Conceptualización de los 14 factores técnicos que lo fundamentan.
Las técnicas utilizadas para la definición de los factores técnicos.
Tipo de información que se requerirá.
Un resumen de los 03 pasos que constituyen el modelo DMTF.
Explicación del proceso de implementación y análisis del modelo (en la herramienta
informática DMTF)
Interpretación de resultados y reportes posibles.
Destino de los resultados.
El documento completo de la presentación ejecutiva, se adjunta en el Anexo “K”,
y en la Figura 22, se observa el instante de la exposición.
Figura 22
Reunión de presentación del modelo de decisión DMTF
140
Paso 2 - Presentar los impulsores comerciales. En este punto el product
owner procedió a dar un resumen de los requerimientos funcionales y no funcionales del
módulo de “Ascensos” del personal militar de la Fuerza Aérea, mediante la plantilla del
caso de uso correspondiente y que se observa en la Tabla 21.
Tabla 21
Matriz de Casos de Uso del módulo de “Ascensos” del sistema SITHU.
Nota: formato de caso de uso institucional FAE.
141
Paso 3 - Implementación del modelo. En este paso se procedió a la aplicación
del cuestionario, que constituye la operacionalización del DMTF, en el proceso de
desarrollo del módulo de Ascensos del sistema SITHU de la FAE.
El cuestionario fue respondido por los 2 supervisores del equipo de desarrollo,
encargados de las funciones de arquitectura de software e ingeniería de sistemas.
Las 11 preguntas, fueron contestadas esta vez en forma de un cuestionario
físico, para poder evidenciar el registro, al que se le adjuntó el detalle y explicación de
cada una de las métricas y los distintos ítems a ser evaluados.
Este cuestionario físico, se adjunta en el Anexo “L”, luego los datos fueron
ingresados a la herramienta informática, para el cálculo y presentación automática de
resultados.
En la Figura 23, se observa el momento en que es contestado el cuestionario.
Figura 23
Llenado del cuestionario por parte del arquitecto de software (Sgop. Richard Salazar).
142
En la Figura 24, se observan 2 pantallas de la herramienta el momento del
llenado de datos.
Figura 24
Herramienta informática para implementar el modelo de decisión DMTF
Nota: herramienta DMTF.
143
5.1.3. Análisis de resultados.
Una vez que el modelo procesó los datos ingresados y realizó la comparación
con los umbrales de las métricas, el modelo a través de la herramienta, generó el
resultado, en este caso para el módulo de Ascensos del sistema SITHU, el cual se
puede apreciar en la Figura 25.
Figura 25
Resultado final presentada por la herramienta DMTF.
Nota: herramienta DMTF.
144
Como se puede apreciar en este caso de estudio, la recomendación es
NEGATIVA, lo que quiere decir que no se recomienda la adopción de MSA para el
desarrollo del módulo de “Ascensos” del sistema SITHU.
De acuerdo a los resultados que se obtuvieron en cada uno de los factores
técnicos, se observa que la recomendación negativa se debe principalmente a que la
predicción arrojó que de acuerdo a la MODULARIDAD alta prevista que va a tener el
módulo de Ascensos, representaría problemas con la mantenibilidad debido a que se
crearían componentes a través de microservicios que ocuparían recursos de la
infraestructura y aumentarían el esfuerzo en los programadores al desarrollar
microservicios especializados, teniendo que brindar mantenimiento posterior.
En este punto, la herramienta también muestra un reporte radial gráfico, en
donde se puede analizar de manera visual el grado de pertinencia que tuvo cada factor,
tal como se aprecia en la Figura 26.
Figura 26
Gráfico radial generado por la herramienta DMTF.
Nota: herramienta DMTF.
145
5.1.4. Criterio de los involucrados.
En esta sección revisamos las apreciaciones, críticas y sugerencias, realizadas
al modelo, por parte de los involucrados en el caso de estudio:
Jefe del Dpto. Desarrollo de Sistemas (Capt. Luis Egas R.)
El principal aspecto manifestado por el jefe del proyecto, tiene que ver con el
aporte tangible de contar con un insumo técnico (reporte del modelo) para poder
sustentar de forma técnica, la decisión de adoptar, o no, la arquitectura de
microservicios, en tal o cual módulo o componente del sistema.
Arquitecto de software (Sgop. Richard Salazar G.)
El arquitecto de software manifiesta por su parte, que hay algunos campos en el
cuestionario que no se manejan o que el Dpto. de Desarrollo de Sistemas, no toma en
cuenta al momento de empezar el desarrollo de un Proyecto, tales como los requeridos
en la pregunta nro. 2 del cuestionario.
146
Capítulo 6
6.1. Conclusiones y recomendaciones
El desarrollo del presente modelo, ha significado un reto por demás interesante,
especialmente porque a pesar de la evidente necesidad y utilidad que puede significar la
utilización de un modelo de decisión, este campo no está muy popularizado todavía,
especialmente en el desarrollo del software en el que prácticamente es un campo aun
emergente, ya que no existe mayor bibliografía y/o investigaciones. En esta situación, el
presente trabajo se basó, principalmente en la experiencia de los trabajos de
exploración realizados en la “Johannes Kepler University Linz”, de Linz, Austria, por los
investigadores Stefan Haselböck, Rainer Weinreich & Georg Buchgeher (2017b), en su
trabajo denominado “Decision models for microservices: Design areas, stakeholders,
use cases, and requirements”, en el que describen unos modelos de decisión aplicados
a algunas áreas en el desarrollo de software, trabajo que lo realizan con una
metodología denominada Investigación de Acción Técnica (TAR), que también se
adoptó en la realización del presente trabajo, y que básicamente consistió en “el uso de
un artefacto experimental para ayudar a un cliente y aprender sobre sus efectos en la
práctica. El artefacto es experimental, lo que significa que aún está en desarrollo y aún
no se ha transferido al contexto del problema original” (Wieringa, 2014a).
En esta etapa se puede verificar entonces que el objetivo principal de diseñar un
modelo de decisión fundamentado en los factores técnicos relevantes, ha sido
alcanzado, pero también sus objetivos específicos tales como:
Construir el marco de referencia, mediante una revisión bibliográfica sistematizada
de artículos y revistas científicas con factor de impacto Q1, Q2 y Q3, y extraer los
factores técnicos más referenciados en el estudio y desarrollo de sistemas bajo la
arquitectura de microservicios.
147
Diseñar y construir un modelo de decisión fundamentado en los factores técnicos
relevantes, que sustente la adopción de una arquitectura de micro-servicios.
Crear la herramienta informática del modelo de decisión.
Implementar el modelo de decisión en el proyecto, desarrollo del sistema Integral de
Talento Humano SITHU de la Fuerza Aérea
Hitos que permitieron contar al final con un producto tangible, que aportó con
una recomendación verificable, al líder de un proyecto software, para que pueda tomar
una decisión fundamentada en un análisis técnico-científico, culminando el presente
trabajo de investigación con la propuesta del modelo de decisión que hemos
denominado DMTF (Decision Model by Technical Factors), con base en lo cual, se
expresa las siguientes conclusiones y recomendaciones:
6.1.1. Conclusiones.
6.1.1.1. Este trabajo está fundamentado en documentos de revistas científicas
dentro del cuartil Q1, Q2 y Q3, utilizando un proceso científico riguroso de selección y
clasificación.
6.1.1.2. Es importante contar con información relevante o insumos técnico-
científicos, al momento de tener que decidir la adopción de una arquitectura de software
orientada a microservicios, con el propósito de reducir la incertidumbre.
6.1.1.3. La arquitectura de microservicios, se está convirtiendo cada día, en el
nuevo estándar para el desarrollo de sistemas, especialmente cuando se ha sabido que
grandes empresas comerciales multinacionales la han adoptado para sus plataformas
informáticas comerciales, como es el caso de Netflix, Amazon, The Guardian, entre
otros (Granchelli et al., 2017) .
6.1.1.4. Existen muchos estudios y experiencias, descritos en trabajos de
investigación científica, que comparten la experiencia de haber implementado la
arquitectura de microservicios en la industria y en la academia.
148
6.1.1.5. Los modelos de evaluación de arquitecturas, constituyen la génesis
para los modelos de decisión de arquitecturas, pues comparten sus fundamentos,
especialmente lo referente a la utilización de los atributos de calidad, así como su
estructura y herramientas.
6.1.1.6. El campo de los modelos de decisión para arquitecturas basadas en
microservicios, aún no está muy difundido, y no existen muchos trabajos de
investigación como sus pares los modelos de evaluación o los modelos de calidad, por
mencionar un par de ejemplos.
6.1.1.7. La mayor parte de los modelos de evaluación y de decisión de
arquitectura, de microservicios en este caso, están fundamentados y enfocados
únicamente en atributos de calidad o requerimientos no funcionales, sin tomar en cuenta
los requisitos funcionales o características de la MSA. En este trabajo se consideran los
requerimientos funcionales, no funcionales y atributos de calidad, a los que se les ha
denominado “Factores Técnicos”.
6.1.1.8. En la mayor parte de los trabajos de investigación revisados, y de los
que se extrajeron los factores técnicos, se observa que las características de la MSA
están estrechamente ligadas y casi integradas a conceptos y filosofías tales como:
Scrum, Extreme programming y principalmente DevOps, entre otros.
6.1.1.9. De acuerdo a la lectura de las experiencias de los trabajos de
investigación, se observa que para adoptar una arquitectura de microservicios, la
organización debe contar con equipos multidisciplinarios, en la que cada miembro debe
tener competencias especializadas en un ambiente de trabajo de competencia-
cooperación.
6.1.1.10. Con base en las respuestas receptadas en el cuestionario del modelo
DMTF, en su primera implementación en el caso de estudio, se pudo evidenciar, que a
pesar de estar trabajando ya con la arquitectura de microservicios, existen algunos
149
conceptos que todavía no están muy claros o que no se utilizan.
6.1.1.11. Al implementar el modelo en el caso de estudio, los involucrados
indicaron que el modelo si permite tener un fundamento técnico para la toma de una
decisión al momento de tener adoptar la arquitectura de microservicios.
6.1.1.12. De la implementación del modelo DMTF en el caso de estudio, se
obtuvo como resultado que, el módulo de Ascensos del sistema SITHU de la Fuerza
Aérea Ecuatoriana, NO necesita desarrollarse en la arquitectura de microservicios,
contradiciéndose con las decisiones que la entidad había tomado al respecto.
6.1.2. Recomendaciones y líneas futuras.
Si bien, ha sido arduo el trabajo realizado hasta llegar a la entrega del modelo de
decisión DMTF, es más el camino que, a partir de aquí, queda por recorrer y que se
espera continúe en el tiempo, con el fin de que, el modelo propuesto continúe
evaluándose y mejorándose, hasta que efectivamente se pueda contribuir a la
popularización de los modelos de decisión de arquitecturas.
En tal virtud, se deja trazado el camino para futuros trabajos en base a las
siguientes recomendaciones:
6.1.2.1. Establecer el modelo confirmatorio, en base al modelo DMTF
exploratorio planteado.
6.1.2.2. Continuar con el estudio de modelos de decisión para la adopción de
arquitectura de microservicios, tomando como línea base el presente modelo, que
constituye un primer intento por divulgar y popularizar su utilización.
6.1.2.3. Utilizar estudios e instrumentos técnicos-científicos, como el presente
modelo y herramienta, para que la decisión de adoptar una arquitectura de
microservicios, esté mejor argumentada y sustentada.
6.1.2.4. Antes de decidir la adopción de una arquitectura de microservicios, se
deberían considerar otros conceptos y prácticas en el equipo de desarrollo, que
150
fortalezcan su eventual elección, tales como: prácticas ágiles y herramientas de
integración y despliegue continuos.
151
Bibliografía
Aguiar, F. (2004). Revista de Metodología de Ciencias Sociales. In EMPIRIA (Vol. 8).
Allen, R. J. (1997). A Formal Approach to Software Architecture. [Carnegie Mellon
University]. https://apps.dtic.mil/sti/citations/ADA333575
Ardagna, C. A., Damiani, E., Frati, F., Rebeccani, D., & Ughetti, M. (2012). Scalability
patterns for platform-as-a-service. Proceedings - 2012 IEEE 5th International
Conference on Cloud Computing, CLOUD 2012, 718–725.
https://doi.org/10.1109/CLOUD.2012.41
Athar, A., Azam, F., & Liaqat, R. M. (2016). A Comparative Analysis of Software
Architecture Evaluation Methods. Article in Journal of Software.
https://doi.org/10.17706/jsw.11.9.934-942
Bachmann, F., Bass, L., Klein, M., & Shelton, C. (2005). Designing software
architectures to achieve quality attribute requirements. IEE Proceedings -
Software, 152(4), 153. https://doi.org/10.1049/ip-sen:20045037
Bachmann, Felix, Bass, L., Chastek, G., Donohoe, P., & Peruzzi, F. (2000). The
Architecture Based Design Method. https://apps.dtic.mil/sti/citations/ADA375851
Barbacci, M., Ellison, R., Lattanze, A., Stafford, J., Weinstock, C., & Wood, W. (2003).
Quality Attribute Workshops (QAWs), Third Edition.
https://doi.org/10.1184/R1/6582656.v1
Barreto, C. (2017). Universidad Nacional De Huancavelica “Información Contable Y
Toma De Decisiones De Las Micro Y Pequeñas Empresas De La Localidad De
Huancavelica, Periodo-2014.” In Universidad Nacional de Huancavelica.
Universidad Nacional de Huancavelica.
http://repositorio.unh.edu.pe/handle/UNH/1173
Bass, L., Clements, P., & Kazman, R. (2004). Software Architecture in Practice
(Addison-Wesley (ed.); Second edi). Carnegie Mellon University - Software
152
Engineering Institute.
https://books.google.com.ec/books?hl=es&lr=&id=mdiIu8Kk1WMC&oi=fnd&pg=P
A1&ots=UfJ5R9hbOR&sig=BpvFljDjB3Bfne0ExQgewsgHJ40&redir_esc=y#v=on
epage&q&f=false
Bengtsson, P. O., & Bosch, J. (1998). Scenario-based software architecture
reengineering. International Conference on Software Reuse, 308–317.
https://doi.org/10.1109/icsr.1998.685756
Bengtsson, P. O., Lassing, N., Bosch, J., & Van Vliet, H. (2004). Architecture-level
modifiability analysis (ALMA). Journal of Systems and Software, 69(1–2), 129–
147. https://doi.org/10.1016/S0164-1212(03)00080-3
Binmore, G. (1994). Game Theory and the Social Contract: Just playing.
https://books.google.com.ec/books?hl=es&lr=&id=HZ1hC1MLPeoC&oi=fnd&pg=
PR7&ots=GhiCG18ypu&sig=0j8-d7IN-
OC0NyJ2r9u2q9ttjhA&redir_esc=y#v=onepage&q&f=false
Bosch, J. (2000). Design and use of software architectures: adopting and evolving a
product-line approach. ACM Press/Addison-Wesley Publishing Co.
Brito, G., & Valente, M. T. (2020). REST vs GraphQL: A controlled experiment.
Proceedings - IEEE 17th International Conference on Software Architecture,
ICSA 2020, 81–91. https://doi.org/10.1109/ICSA47634.2020.00016
Capilla, R., Jansen, A., Tang, A., Avgeriou, P., & Babar, M. A. (2016). 10 years of
software architecture knowledge management: Practice and future. Journal of
Systems and Software, 116, 191–205. https://doi.org/10.1016/j.jss.2015.08.054
Celorio, G., & Fajardo, P. (2011). Evaluación del desempeño de los servidores FTP y
bases de datos de la empresa “La Internacional” S.A. [Escuela Politécnica
Nacional]. https://bibdigital.epn.edu.ec/bitstream/15000/3923/1/CD-3650.pdf
153
Chen, L. (2015). Continuous delivery: Huge benefits, but challenges too. IEEE Software,
32(2), 50–54. https://doi.org/10.1109/MS.2015.27
Chiavenato, I. (2002). Administración en los nuevos tiempos (McGraw-Hill (ed.)).
https://www.urbe.edu/UDWLibrary/InfoBook.do?id=8895
Chung, L., Cooper, K., & Yi, A. (2003). Developing adaptable software architectures
using design patterns: An NFR approach. Computer Standards and Interfaces,
25(3), 253–260. https://doi.org/10.1016/S0920-5489(02)00096-X
Clements, P., Kazman, R., & Klein, M. (2002). Evaluating software architectures:
methods and case studies. http://newsrank.adelaidenow.com.au/t0ri/26-dr-itzel-
thiel-dds/evaluating-software-architectures-methods-and-ca-OHzMzZx7tx4.pdf
Codina, L. (2020a). Revisiones bibliográficas sistematizadas en Ciencias Humanas y
Sociales. 1: Fundamentos. In Methodos Anuario de Métodos de Investigación en
Comunicación Social, 1 (pp. 50–60). Universitat Pompeu Fabra.
https://doi.org/10.31009/methodos.2020.i01.05
Codina, L. (2020b). Revisiones sistematizadas en Ciencias Humanas y Sociales. 2:
Búsqueda y Evaluación. In Methodos Anuario de Métodos de Investigación en
Comunicación Social, 1 (pp. 61–72). Universitat Pompeu Fabra.
https://doi.org/10.31009/methodos.2020.i01.06
Coplien, J., & Bjornvig, G. (2011). Lean Architecture for Agile Software Development
(Wiley (ed.)).
https://books.google.com.ec/books?id=lpvY36MPMUwC&pg=PA80&lpg=PA80&d
q=Jerry+Weinberg+y+Fred+Brooks+architecture&source=bl&ots=4313rh88jY&si
g=ACfU3U23597dSU9Z-COi3d5PdyJNZcr-hw&hl=es-
419&sa=X&ved=2ahUKEwiuyJb4v9HvAhUsqlkKHSz_DecQ6AEwDnoECA8QAw
#v=onepage&q=
154
Di Francesco, P., Lago, P., & Malavolta, I. (2018). Migrating towards microservice
architectures: an industrial survey. 2018 IEEE International Conference on
Software Architecture (ICSA), 29–2909.
Docker Inc. (2020). What is a Container? | App Containerization | Docker. Docker.com.
https://www.docker.com/resources/what-container
Dragoni, N., Giallorenzo, S., Lluch, A., Mazzara, M., Montesi, F., Mustafin, R., & Safina,
L. (2017). Microservices: yesterday, today, and tomorrow. In Present and ulterior
software engineering (pp. 195–216). Springer.
Dullmann, T. F., Heinrich, R., Hoorn, A. Van, Pitakrat, T., Walter, J., & Willnecker, F.
(2017). CASPA: A platform for comparability of architecture-based software
performance engineering approaches. Proceedings - 2017 IEEE International
Conference on Software Architecture Workshops, ICSAW 2017: Side Track
Proceedings, 294–297. https://doi.org/10.1109/ICSAW.2017.26
Duvall, P. M., Matyas, S., & Glover, A. (2007). Continuous Integration: Improving
Software Quality and Reducing Risk (2007 Pearson Education (ed.); Addison-
We). Martin Fowler.
Ebert, C., Gallardo, G., Hernantes, J., & Serrano, N. (2016). DevOps. IEEE Software,
33(3), 94–100. https://doi.org/10.1109/MS.2016.68
Eder, J., Kappel, G., & Schree, M. (1994). Coupling and Cohesion in Object-Oriented
Systems.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.5819&rep=rep1&typ
e=pdf
Ensslin, L., Ensslin, S. R., Lacerda, R., & Tasca, J. (2010). ProKnow-C, knowledge
development process-constructivist.
https://scholar.google.com/scholar?hl=es&as_sdt=0%2C5&q=Ensslin%2C+L.%2
C+Ensslin%2C+S.+R.%2C+Lacerda%2C+R.+T.+O.%2C+%26+Tasca%2C+J.+E
155
.+%282010a%29.+ProKnow-
C%2C+Knowledge+Development+ProcessConstructivist.+Processo+técnico+co
m+patente+de+registro+pendente
Facebook, I. (2016). GraphQL | A query language for your API. GraphQL Homepage.
https://graphql.org/
Fielding, R. T., & Taylor, R. N. (2002). Principled Design of the Modern Web
Architecture. ACM Transactions on Internet Technology, 2(2), 115–150.
https://doi.org/10.1145/514183.514185
Fielding, Roy Thomas. (2000). Architectural Styles and the Design of Network-based
Software Architectures [University of California,].
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
French, S., Bell, D. E., Raiffa, H., & Tversky, A. (1990). Decision Making: Descriptive,
Normative, and Prescriptive Interactions. The Journal of the Operational
Research Society, 41(3), 263. https://doi.org/10.2307/2583822
Gallardo-Cueva, S., Guaigua-Albarracín, G., & Reyes-Chicango, R. (2020). Quality
Models: An Experience in the Software Industry. Communications in Computer
and Information Science, 1193 CCIS, 125–138. https://doi.org/10.1007/978-3-
030-42517-3_10
Garlan, D. (2003). Formal modeling and analysis of software architecture: Components,
connectors, and events. Lecture Notes in Computer Science (Including Subseries
Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2804,
1–24. https://doi.org/10.1007/978-3-540-39800-4_1
Garlan, D., & Shaw, M. (1993). An Introduction to Software Architecture (pp. 1–39).
https://doi.org/10.1142/9789812798039_0001
Ghasemi, M., Mehran Sharafi, S., & Arman, A. (2015). Towards an Analytical Approach
to Measure Modularity in Software Architecture Design. Journal of Software,
156
10(4). https://doi.org/10.17706/jsw.10.4.465-479
Granchelli, G., Cardarelli, M., Di Francesco, P., Malavolta, I., Iovino, L., & Di Salle, A.
(2017). Towards recovering the software architecture of microservice-based
systems. 2017 IEEE International Conference on Software Architecture
Workshops (ICSAW), 46–53.
Grant, M. J., & Booth, A. (2009). A typology of reviews: An analysis of 14 review types
and associated methodologies. In Health Information and Libraries Journal (Vol.
26, Issue 2, pp. 91–108). John Wiley & Sons, Ltd. https://doi.org/10.1111/j.1471-
1842.2009.00848.x
Hagsten, P. (2018). Evaluation of a qualitative model for a company’s technical maturity
within Continuous Integration, Continuous Delivery and DevOps [KTH Royal
Institute of Technology]. https://www.diva-
portal.org/smash/get/diva2:1241606/FULLTEXT01.pdf
Haoues, M., Sellami, A., Ben-Abdallah, H., & Cheikhi, L. (2017). A guideline for software
architecture selection based on ISO 25010 quality related characteristics.
International Journal of Systems Assurance Engineering and Management, 8(2),
886–909. https://doi.org/10.1007/s13198-016-0546-8
Hart, C. (1998). Doing a Literature Review: Releasing the Social Science Research
Imagination. In SAGE Publications Ltd (SAGE Study, Vol. 1).
https://doi.org/10.1177/1350507600312009
Haselbock, S., & Weinreich, R. (2017). Decision guidance models for microservice
monitoring. Proceedings - 2017 IEEE International Conference on Software
Architecture Workshops, ICSAW 2017: Side Track Proceedings, 54–61.
https://doi.org/10.1109/ICSAW.2017.31
Haselböck, S., Weinreich, R., & Buchgeher, G. (2017a). Decision guidance models for
microservices - Service discovery and fault tolerance. ACM International
157
Conference Proceeding Series, Part F1305, 1–10.
https://doi.org/10.1145/3123779.3123804
Haselböck, S., Weinreich, R., & Buchgeher, G. (2017b). Decision models for
microservices: Design areas, stakeholders, use cases, and requirements. Lecture
Notes in Computer Science (Including Subseries Lecture Notes in Artificial
Intelligence and Lecture Notes in Bioinformatics), 10475 LNCS, 155–170.
https://doi.org/10.1007/978-3-319-65831-5_11
Hellriegel, D., Hellriegel, S., & Hellriegel, J. W. (2002). Administración: Un enfoque
basado en competencias (C. Learning (ed.); 9na. ed).
https://www.urbe.edu/UDWLibrary/InfoBook.do?id=11058
Hilliard II, R., Kurland, M., & Litvintchouk, S. (1997). MITREs Architecture Quality
Assessment. Software Engineering & Economics Conference. Software
Engineering & Economics Conference, 9.
http://web.mit.edu/richh/www/writings/aqa-swee.pdf
Humble, J., & Farley, D. (2010). Continuous delivery: reliable software releases through
build, test, and deployment automation. Martin Fowler.
https://books.google.com.ec/books?hl=es&lr=&id=6ADDuzere-
YC&oi=fnd&pg=PT30&ots=-wowRKHcl5&sig=KXa1ewjMm5RSy1r-
VmoBG4cFn48&redir_esc=y#v=onepage&q&f=false
Humble, J., Molesky, J., & O’Reilly, B. (2020). Lean Enterprise (I. O’Reilly Media (ed.);
reimpresa). Google books.
https://books.google.com.ec/books?hl=es&lr=&id=CmbyDwAAQBAJ&oi=fnd&pg=
PT22&ots=Binjs26MxE&sig=nysQKOD17qo-
WR2PrVWdMRmbYmY&redir_esc=y#v=onepage&q&f=false
IEEE-SA Standards Board. (2000). IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems. IEEE Std.
158
https://doi.org/10.1109/IEEESTD.2000.91944
International Organization Of Standardization. (2011). ISO/IEC/IEEE 42010:2011 -
Systems and software engineering -- Architecture description. ISOIECIEEE
420102011E Revision of ISOIEC 420102007 and IEEE Std 14712000,
2011(March), 1–46. https://doi.org/10.1109/IEEESTD.2011.6129467
ISO/IEC - 25010. (2011). ISO/IEC 25010:2011 - Systems and software engineering --
Systems and software Quality Requirements and Evaluation (SQuaRE) -- System
and software quality models. https://www.iso.org/standard/35733.html
Jansen, A., & Bosch, J. (2005). Software architecture as a set of architectural design
decisions. Proceedings - 5th Working IEEE/IFIP Conference on Software
Architecture, WICSA 2005, 2005, 109–120.
https://doi.org/10.1109/WICSA.2005.61
JSON org. (2021). Introducing JSON. https://www.json.org/json-en.html
Júnior, A. A. C., Misra, S., & Soares, M. S. (2019). A Systematic Mapping Study on
Software Architectures Description Based on ISO/IEC/IEEE 42010:2011. Lecture
Notes in Computer Science (Including Subseries Lecture Notes in Artificial
Intelligence and Lecture Notes in Bioinformatics), 11623 LNCS, 17–30.
https://doi.org/10.1007/978-3-030-24308-1_2
Kazman, R., Bass, L., Abowd, G., & Webb, M. (1994). SAAM: a method for analyzing the
properties of software architectures. Proceedings - International Conference on
Software Engineering, 81–90. https://doi.org/10.1109/icse.1994.296768
Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Howard, L., & Carriere, J. (1998). The
architecture tradeoff analysis method. Proceedings. Fourth IEEE International
Conference on Engineering of Complex Computer Systems (Cat. No.98EX193),
68–78. https://doi.org/10.1109/ICECCS.1998.706657
159
Kazman, R., Klein, M., & Clements, P. (2000). ATAM: SM Method for Architecture
Evaluation. http://www.sei.cmu.edu/publications/pubweb.html
Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to
Create World-Class Agility, Reliability, and Security in Technology Organizations
(2016 IT Revolution (ed.); ITpro coll). Digital Bindery.
Krishnan, M. S., Mukhopadhyay, T., & Kriebel, C. H. (2004). A decision model for
software maintenance. In Information Systems Research (Vol. 15, Issue 4, pp.
396–412). INFORMS Inst.for Operations Res.and the Management Sciences.
https://doi.org/10.1287/isre.1040.0037
Kruchten, P., Obbink, H., & Stafford, J. (2006). The past, present, and future for software
architecture. In IEEE Software (Vol. 23, Issue 2, p. 22). IEEE Computer Society.
https://doi.org/10.1109/MS.2006.59
Le, V. D. (2018). Microservice-based System for Environmental Science Software
Applications. ProQuest Dissertations and Theses, 107.
https://scholarworks.unr.edu//handle/11714/4559
Leon, O. G. (1987). La toma de decisiones individuales con riesgo desde la psicología.
Estudios de Psicología, 8(29–30), 79–94.
https://doi.org/10.1080/02109395.1987.10821482
Losavio de Ordáz, F., & Guillen-Drija, C. (2006). Marco conceptual para un diseño
arquitectónico basado en aspectos de calidad. Sapiens: Revista Universitaria de
Investigación, 7(2), 119–138. http://www.redalyc.org/articulo.oa?id=41070209
Lüders, F. (2003). Use of Component-Based Software Architectures in Industrial Control
Systems.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.9757&rep=rep1&ty
pe=pdf
160
Maranzano, J. (1993). Best Current Practices: Software Architecture Validation. AT and
T.
Martínez-Mateu, I., & Peinado, F. (2018). Una Plataforma de Integración Continua
Especializada en Desarrollo de Videojuegos. V Congreso de La Sociedad
Española Para Las Ciencias Del Videojuego, 1033–1038.
https://dialnet.unirioja.es/servlet/articulo?codigo=7373948
Mayer, B., & Weinreich, R. (2017). A dashboard for microservice monitoring and
management. Proceedings - 2017 IEEE International Conference on Software
Architecture Workshops, ICSAW 2017: Side Track Proceedings, 66–69.
https://doi.org/10.1109/ICSAW.2017.44
Mizouni, R., Serhani, M. A., Dssouli, R., Benharref, A., & Taleb, I. (2011). Performance
evaluation of mobile web services. Proceedings - 9th IEEE European Conference
on Web Services, ECOWS 2011, 184–191.
https://doi.org/10.1109/ECOWS.2011.12
Mo, R., Cai, Y., Kazman, R., Xiao, L., & Feng, Q. (2016). Decoupling level: A new metric
for architectural maintenance complexity. Proceedings - International Conference
on Software Engineering, 14-22-May-2016, 499–510.
https://doi.org/10.1145/2884781.2884825
Muñoz-Escoí, F. D., & Bernabéu-Aubán, J. M. (2017). A survey on elasticity
management in PaaS systems. Computing, 99(7), 617–656.
https://doi.org/10.1007/s00607-016-0507-8
Newman, S. (2015). Building Microservices: Designing Fine-Grained Systems (M.
Loukides & B. MacDonald (eds.); First Edit). O’Reilly Media, Inc.
http://ce.sharif.edu/courses/96-97/1/ce924-1/resources/root/Books/building-
microservices-designing-fine-grained-systems.pdf
161
Niu, Y., Liu, F., & Li, Z. (2018). Load Balancing Across Microservices. Proceedings -
IEEE INFOCOM, 2018-April, 198–206.
https://doi.org/10.1109/INFOCOM.2018.8486300
Páez Gallego, J. (2015). Teorías normativas y descriptivas de la toma de decisiones: Un
modelo integrador. Opcion, 31(Special Issue 2), 854–865.
https://dialnet.unirioja.es/servlet/articulo?codigo=5834785
Pagani, R. N., Kovaleski, J. L., & Resende, L. M. (2015). Methodi Ordinatio: a proposed
methodology to select and rank relevant scientific papers encompassing the
impact factor, number of citation, and year of publication. Scientometrics, 105(3),
2109–2135. https://doi.org/10.1007/s11192-015-1744-x
Peltz, C. (2003). Web services orchestration and choreography. Computer, 36(10), 46–
52. https://doi.org/10.1109/MC.2003.1236471
Perry, D. E., & Wolf, A. L. (1992). Foundations for the study of software architecture.
ACM SIGSOFT Software Engineering Notes, 17(4), 40–52.
https://doi.org/10.1145/141874.141884
Pisani, M., Miraballes, R., & García, N. (2016). Aplicación de Microservicios sobre una
arquitectura SOA con restricciones de calidad de servicio [Universidad de la
República - Montevideo, Uruguay].
https://www.researchgate.net/publication/324681050_Aplicacion_de_Microservici
os_sobre_una_arquitectura_SOA_con_restricciones_de_calidad_de_servicio
Programa de las Naciones Unidas para el Desarrollo. (2019). Objetivo 9: Industria,
innovación e infraestructura | PNUD. Objetivos de Desarrollo Sostenible.
https://www.undp.org/content/undp/es/home/sustainable-development-
goals/goal-9-industry-innovation-and-infrastructure.html
Red Hat Inc. (2019). ¿Qué es una API? Documentación Proporcionada Por Red Hat
Sobre El Concepto de API (Application Programming Interface).
162
https://www.redhat.com/es/topics/api/what-are-application-programming-
interfaces
Rico, J. A. (2015). Representación visual de la ejecución de una arquitectura de
software basada en componentes con especificación formal en cálculo ρarq
[Universidad Distrital Francisco José De Caldas].
http://repository.udistrital.edu.co/handle/11349/2778
Rodgers, P. (2005). Service-oriented development on netkernel- patterns, processes
products to reduce system complexity. SYS-CON Media.
Rotter, C., Illes, J., Nyiri, G., Farkas, L., Csatari, G., & Huszty, G. (2017). Telecom
strategies for service discovery in microservice environments. Proceedings of the
2017 20th Conference on Innovations in Clouds, Internet and Networks, ICIN
2017, 214–218. https://doi.org/10.1109/ICIN.2017.7899414
Sabry, A. E. (2015). Decision model for software architectural tactics selection based on
quality attributes requirements. Procedia Computer Science, 65, 422–431.
Salah, T., Zemerly, M. J., Yeun, C. Y., Al-Qutayri, M., & Al-Hammadi, Y. (2016). The
evolution of distributed systems towards microservices architecture. 2016 11th
International Conference for Internet Technology and Secured Transactions
(ICITST), 318–325.
Santos, N., Salgado, C. E., Morais, F., Melo, M., Silva, S., Martins, R., Pereira, M.,
Rodrigues, H., Machado, R. J., Ferreira, N., & Pereira, M. (2019). A logical
architecture design method for microservices architectures. ACM International
Conference Proceeding Series, 2, 145–151.
https://doi.org/10.1145/3344948.3344991
Song, M., Zhang, C., & Haihong, E. (2019). An Auto Scaling System for API Gateway
Based on Kubernetes. Proceedings of the IEEE International Conference on
Software Engineering and Service Sciences, ICSESS, 2018-November, 109–
163
112. https://doi.org/10.1109/ICSESS.2018.8663784
Stevens, W. P., Myers, G. J., & Constantine, L. L. (1974). Structured Design. Ibm
Systems Journal, 13(2), 115–139. https://doi.org/10.1147/sj.132.0115
Thiel, S. (2005). A Framework to Improve the Architecture Quality of Software-Intensive
Systems. Universität Duisburg-Essen.
Tiwari, S., & Rathore, S. S. (2018, February 9). Coupling and cohesion metrics for
object-oriented software: A systematic mapping study. ACM International
Conference Proceeding Series. https://doi.org/10.1145/3172871.3172878
Virmani, M. (2015). Understanding DevOps & bridging the gap from continuous
integration to continuous delivery. 5th International Conference on Innovative
Computing Technology, INTECH 2015, 78–82.
https://doi.org/10.1109/INTECH.2015.7173368
Vural, H., & Koyuncu, M. (2021). Does Domain-Driven Design Lead to Finding the
Optimal Modularity of a Microservice? IEEE Access.
https://doi.org/10.1109/ACCESS.2021.3060895
Weinreich, R., & Groher, I. (2016). Software architecture knowledge management
approaches and their support for knowledge management activities: A systematic
literature review. In Information and Software Technology (Vol. 80, pp. 265–286).
Elsevier B.V. https://doi.org/10.1016/j.infsof.2016.09.007
Wieringa, R. J. (2014a). Technical Action Research. In Design Science Methodology for
Information Systems and Software Engineering (pp. 269–293). Springer Berlin
Heidelberg. https://doi.org/10.1007/978-3-662-43839-8_19
Wieringa, R. J. (2014b). Design science methodology: For information systems and
software engineering. In Design Science Methodology: For Information Systems
and Software Engineering. Springer Berlin Heidelberg.
https://doi.org/10.1007/978-3-662-43839-8
164
Williams, L. G., & Smith, C. U. (2002). PASA SM. Proceedings of the Third International
Workshop on Software and Performance - WOSP ’02, 179.
https://doi.org/10.1145/584369.584397
Zdun, U., Stocker, M., Zimmermann, O., Pautasso, C., & Lübke, D. (2018). Guiding
architectural decision making on quality aspects in microservice APIs.
International Conference on Service-Oriented Computing, 73–89.
165
Anexos