Modelo de Evolución Arquitectónica de

Monolito a Microservicios para el Sistema de

Información ISys de la Dirección Nacional de
Admisiones de la Universidad Nacional de
Colombia

Sebastián David Moreno Bernal

Universidad Nacional de Colombia

Facultad de Ingeniería, Departamento de Ingeniería de Sistemas e Industrial
Bogotá, D. C., Colombia
2022
 Modelo de Evolución Arquitectónica de
Monolito a Microservicios para el Sistema de
Información ISys de la Dirección Nacional de
Admisiones de la Universidad Nacional de
Colombia

Sebastián David Moreno Bernal

Trabajo final presentado como requisito parcial para optar al título de:
Magíster en Ingeniería - Ingeniería de Sistemas y Computación
«Master of Engineering - Systems and Computer Science»

Dirigido por:
Jeisson Andrés Vergara Vargas, M.Sc.

Línea de investigación:
Arquitectura de Software
Grupo de Investigación:
Colectivo de Investigación en Ingeniería de Software (ColSWE)

Universidad Nacional de Colombia

Facultad de Ingeniería, Departamento de Ingeniería de Sistemas e Industrial
Bogotá, D. C., Colombia
2022
Dedicado a mi familia

”You cannot teach a man anything, you can only

help him find it within himself.”

- Galileo Galilei
Agradecimientos
En primer lugar agradezco a Dios por su guía y acompañamiento durante toda mi vida, por las
bendiciones concedidas y permitirme alcanzar un logro más en mi vida académica. A mi familia
y allegados por su apoyo incondicional y motivación continua durante el proceso de realización
de este trabajo final.

Un agradecimiento especial a la Universidad Nacional de Colombia y a todos los docentes que

contribuyeron con sus conocimientos a mi aprendizaje, crecimiento académico y profesional.
A mi director y maestro Jeisson Andrés Vergara Vargas por su guía, asesoría, dedicación y con-
tinua retroalimentación en el proceso de realización de este proyecto. A la Dirección Nacional
de Admisiones, especialmente a Nubia López por la confianza y el apoyo brindado, y al profesor
Mario Alberto Pérez por su tiempo y dedicación como evaluador de este trabajo final. A todo el
equipo técnico de admisiones que participaron directa o indirectamente en el proyecto, pues con
su colaboración y disposición aportaron para la aplicación del modelo de evolución en el sistema.

Por último agradezco a todos los autores citados en este documento, que con sus trabajos y
publicaciones proporcionaron las bases para este trabajo investigativo.
 ix

Título en español
Modelo de Evolución Arquitectónica de Monolito a Microservicios para el Sistema de Infor-
mación ISys de la Dirección Nacional de Admisiones de la Universidad Nacional de Colombia.

Title in English
Architectural Evolution Model from Monolith to Microservices for the ISys Information Sys-
tem of Dirección Nacional de Admisiones of the Universidad Nacional de Colombia.
x

Resumen
El trabajo final presenta el estudio de caso de la evolución de un sistema de información con
arquitectura monolítica hacia microservicios. El trabajo realizado se basa en la creación, imple-
mentación y validación de un modelo de evolución que surge a partir del contexto del sistema
identificado mediante el análisis arquitectónico detallado y en consideración a los requisitos
técnicos y operativos de la Dirección Nacional de Admisiones de la Universidad Nacional de
Colombia. El modelo de evolución permite priorizar los módulos del sistema mediante el análi-
sis de dependencias ascendentes y el impacto positivo previsto de la evolución, y presenta las
adaptaciones requeridas a tres patrones de arquitectura utilizados como estrategia principal para
la evolución de manera iterativa e incremental, sin necesidad de interrumpir parcial o totalmente
la operación del sistema o la dependencia.

Palabras clave: arquitectura de software, evolución arquitectónica, modelo de evolución, arquitectura

monolítica, monolito, arquitectura de microservicios, vista arquitectónica, patrón
 xi

Abstract
The final work presents the case study of the evolution of an information system with mono-
lithic architecture towards microservices. The work done is based on the creation, implementa-
tion and validation of an evolution model that emerge from the context of the system identified
through the detailed architectural analysis, and in consideration of the technical and operational
requirements of Dirección Nacional de Admisiones of the Universidad Nacional de Colombia.
The evolution model allows system modules to be prioritized by analyzing upstream depen-
dencies and the expected positive impact of evolution, and presents the required adaptations
to three architecture patterns used as the main strategy for evolution in an iteratively and in-
crementally, without need to partially or totally halt the operation of the system or dependency.

Keywords: software architecture, architectural evolution, evolution model, monolithic architecture,

monolith, microservices architecture, architectural view, pattern
Este Trabajo Final de maestría fue calificado en abril de 2022 por el siguiente evaluador:

Mario Alberto Pérez Rodríguez

Profesor Facultad de Ingeniería
Universidad Nacional de Colombia
Contenidos

Agradecimientos vii

Resumen x

Lista de Figuras xvi

Lista de Tablas xvii

1. Introducción 1
1.1. Introducción al Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Marco Teórico 4
2.1. Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Arquitecturas Monolíticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Arquitecturas de Microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Evolución Arquitectónica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Diseño Guiado por el Dominio (DDD) . . . . . . . . . . . . . . . . . . . . . . . . 16

3. Trabajos Relacionados 18

4. Sistema de Información ISys 21

4.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Vistas de Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1. Vista de Descomposición . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2. Vista de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.3. Vista de Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.4. Vista de Modelo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3. Vista de Componentes y Conectores . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4. Vista de Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Contenidos xv

5. Modelo de Evolución Arquitectónica 33

5.1. Entradas y Salidas del Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Priorización de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Patrones de Evolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.1. Patrón Aplicación Estranguladora . . . . . . . . . . . . . . . . . . . . . . 36
5.3.2. Patrón API Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.3. Patrón Token de Acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6. Validación del Modelo 42

6.1. Aplicación del Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7. Conclusiones y Trabajo Futuro 51

7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.2. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

A. Apéndice: Matriz de dependencia del sistema de información ISys 52

Bibliografía 54
Lista de Figuras

4-1. Vista de descomposición del monolito ISys. . . . . . . . . . . . . . . . . . . . . 24

4-2. Vista de capas del sistema monolítico ISys. . . . . . . . . . . . . . . . . . . . . . 26
4-3. Ejemplo de una vista de usos en UML. . . . . . . . . . . . . . . . . . . . . . . . 27
4-4. Vista de componentes y conectores del sistema monolítico ISys. . . . . . . . . . 31
4-5. Vista de despliegue del sistema monolítico ISys. . . . . . . . . . . . . . . . . . . 32

5-1. Representación del flujo de la aplicación del modelo de evolución. . . . . . . . . 34

5-2. Estrangulación de un monolito. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5-3. Proceso de estrangulación de un módulo. . . . . . . . . . . . . . . . . . . . . . . 37
5-4. Esquema del API Gateway en el modelo. . . . . . . . . . . . . . . . . . . . . . . 39
5-5. Flujo del manejo de las sesiones del modelo. . . . . . . . . . . . . . . . . . . . . 40

6-1. Modelo de priorización de dos ejes. . . . . . . . . . . . . . . . . . . . . . . . . . 43

6-2. Imagen del Event Storming realizado al módulo de idioma de ISys. . . . . . . . . 45
6-3. Vista de descomposición del sistema con el primer submódulo evolucionado del
módulo de idioma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6-4. Vista de capas del submódulo calificación de idioma evolucionado a microservicios. 47
6-5. Modelo de datos del submódulo calificación del módulo idioma evolucionado. . 48
6-6. Vista de componentes y conectores del sistema de información ISys con el primer
submódulo evolucionado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6-7. Vista de despliegue del sistema de información ISys del primer submódulo evolu-
cionado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A-1. Matriz de descomposición del monolito ISys . . . . . . . . . . . . . . . . . . . . 53

Lista de Tablas

3-1. Enfoques de análisis para la migración de una arquitectura monolítica a una ar-
quitectura de microservicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4-1. Matriz de estructura de dependencia de módulo. . . . . . . . . . . . . . . . . . 28

4-2. Matriz de estructura de dependencia detallada por usos de funcionalidad. . . . . 28
4-3. Agrupación de paquetes en los módulos. . . . . . . . . . . . . . . . . . . . . . . 28
4-4. Resultado de la matriz de dependencias agrupadas por módulos. . . . . . . . . . 29

5-1. Definición y descripción de las variables de entrada y salida del modelo. . . . . . 35

6-1. Matriz de dependencias ascendentes con impacto. . . . . . . . . . . . . . . . . . 42

1. Introducción
La arquitectura de microservicios se ha convertido en la arquitectura líder de implementación
para sistemas de información complejos gracias a múltiples ventajas que brindan a nivel técnico
y competitivo para las organizaciones, pues permite, entre otras, la adopción de cambios de
manera natural y la optimización de los recursos [44]. Empresas como Netflix, Amazon, Ebay y
Uber han adoptado e impulsado los microservicios como patrón arquitectónico de sus sistemas
por la capacidad de escalamiento y disponibilidad que brinda la arquitectura [45], [35]. Por otra
parte, las arquitecturas monolíticas incorporan la mayoría de funcionalidad del sistema en un
componente ejecutable, lo que dificulta abordar de manera efectiva varios atributos de calidad
[44]. Evolucionar una arquitectura monolítica a microservicios no es una labor sencilla, pues
requiere contemplar múltiples factores que determinarán el éxito o fracaso del proceso, como
los retos organizacionales y arquitectónicos que plantea la transición [24].

Este trabajo exponen el estudio de caso del sistema de información integrado (ISys o Integrated
System) de la Dirección Nacional de Admisiones (DNA) de la Universidad Nacional de Colom-
bia (UNAL), que como parte del plan tecnológico de la dependencia, requiere evolucionar la
arquitectura monolítica de ISys a microservicios, conservando su operación constante, evitando
reprocesos operativos y manteniendo los datos históricos. Se plantea como objetivo del estudio
la generación de un modelo que permita la evolución entre arquitecturas, a través del análisis de
la descomposición modular y de componentes y conectores. El modelo se basa en un conjunto
de patrones que permiten transiciones progresivas entre la arquitectura origen y la arquitectura
destino.

El estudio se fundamenta en la arquitectura de software que define las estructuras de los sis-
temas con base en un conjunto de elementos, relaciones y propiedades. La especificación de las
estructuras basadas en un contexto pueden conformar un estilo o un patrón y se representan
mediante vistas arquitectónicas. Todos los estilos y patrones arquitectónicos tienen caracterís-
ticas que permiten diferenciar unos de otros [46]. Definir el contexto de una arquitectura es
complejo, por ello se han desarrollado técnicas como el diseño guiado por el dominio que per-
mite modelar el contexto de un sistema inspirado en el contexto real del negocio [17].

Para realizar la evolución de una arquitectura monolítica hacia microservicios existen diferentes
estrategias en la literatura: Big Bang, rama por abstracción, composición de interfaz de usuario y
aplicación estranguladora. Cuando la evolución se realiza de manera transitiva se deben asumir
2 1 Introducción

ciertos retos derivados del proceso, como identificar el tamaño adecuado de los microservicios
[22], determinar el orden de evolución de los servicios [40], implementar transacciones dis-
tribuidas [44], conservar los datos históricos [47], la seguridad del sistema [44], entre otros.

ISys cumple un papel fundamental en la DNA y requiere adaptabilidad para garantizar que se-
mestre a semestre las normas y reglamentos definidos para los procesos de la dependencia se
cumplan. Sin embargo, debido a limitaciones de la tecnología se dificulta realizar los cambios
y actualizaciones requeridas para el sistema, razón por la cual se decidió evolucionar ISys de
una arquitectura monolítica hacia una arquitectura de microservicios. Comprender el contexto
y estado actual de un sistema se puede realiza a través del análisis de vistas como la vista de
descomposición modular, vista de capas, vista de usos, vista de modelos de datos, vista de com-
ponentes y conectores y vista de despliegue [13].

El modelo de evolución arquitectónica que se propone para realizar la evolución del sistema
de información ISys describe en detalle los aspectos técnicos y operativos relevantes sobre los
cuales se fundamentan las decisiones, describe las variables de entrada y salida del modelo, la
forma de priorizar los servicios que se evolucionarán mediante el nivel de acoplamiento o in-
terdependencia entre módulos del sistema y las adaptaciones que requieren los patrones para
poder evolucionar el sistema de la manera deseada.

La validación del modelo de evolución comprende dos fases. Durante la primera fase se aplica
el modelo al sistema de información ISys y se evoluciona un submódulo. En la segunda fase se
realiza el análisis de los resultados obtenidos, los cuales son evaluados a partir de las variables
de salida del modelo.

1.1. Introducción al Problema

La Universidad Nacional de Colombia tiene como misión fomentar el acceso con equidad al sis-
tema educativo colombiano de educación superior [51], adaptando los sistemas de admisión
para los distintos programas académicos de forma dinámica y según las necesidades nacionales.
Este proceso es realizado por la Dirección Nacional de Admisiones de la UNAL, apoyado por
un sistema de información. El sistema de información de la DNA posee una arquitectura mo-
nolítica, lo cual plantea una serie de retos como 1) la capacidad para responder de forma efi-
ciente a los contextos dinámicos de los procesos de admisión de la UNAL, 2) el escalamiento
flexible de algunos servicios que se sobrecargan en escenarios específicos, y 3) la actualización
tecnológica que es fundamental para mantener un sistema de información seguro. Sin embargo,
el nivel de acoplamiento del sistema con sus dependencias genera conflictos serios de versión
haciendo sumamente riesgoso y compleja la transición tecnológica. Como alternativa, el grupo
de desarrollo de la DNA planteó la propuesta de realizar la evolución arquitectónica de ISys a
1.2 Objetivos 3

microservicios y desea ejecutarla de forma transparente para el usuario, sin afectar la operación
de la dependencia ni la operación del sistema de información.

1.2. Objetivos
1.2.1. Objetivo General
Diseñar un modelo de evolución arquitectónica de monolito a microservicios para el sistema de
información ISys de la Dirección Nacional de Admisiones de la Universidad Nacional de Colom-
bia mediante estrategias de desacoplamiento.

1.2.2. Objetivos Específicos

1. Analizar la descomposición modular del sistema de información ISys actual mediante ele-
mentos, relaciones y propiedades arquitectónicas.

2. Analizar los componentes y conectores del sistema de información ISys actual mediante
elementos, relaciones y propiedades arquitectónicas.

3. Diseñar una estrategia de transición progresiva del sistema de información ISys a una ar-
quitectura de microservicios a partir de los análisis de la arquitectura monolítica.

4. Validar el modelo de evolución implementando la estrategia de transición a un submódulo

del sistema de información ISys.

1.3. Contribución
La contribución de este trabajo final es un modelo de evolución arquitectónica validado a partir
de la aplicación en un submódulo de ISys, que permite la transición de la arquitectura monolítica
del sistema hacia una arquitectura de microservicios, el cual cubre las necesidades técnicas y
operativas de la DNA de la UNAL. El modelo resultante proporciona un conjunto de estrategias
para realizar la evolución de forma iterativa e incremental.
2. Marco Teórico

2.1. Arquitectura de Software

La arquitectura de software es una rama especializada de la ingeniería de software que estudia el
diseño estructural de los sistemas de software y permite una comprensión global de los atributos
funcionales y no funcionales del sistema [13]. La arquitectura de software es una representación
abstracta que formaliza en los sistemas de software los objetivos de las organizaciones [7], y fa-
cilita la comunicación entre los arquitectos y los stakeholders, dando claridad a los atributos
requeridos (funcionales y de calidad) y la forma en la cual se cumplen los objetivos [13].

La arquitectura de software no es una fase específica del desarrollo, pero está presente en cada
etapa de vida del software y se manifiesta en todas las fases de desarrollo, constituye las prin-
cipales decisiones de diseño que influyen en la calidad de producción de software [50] y su
consideración desde tempranas etapas generalmente impacta positivamente la calidad del soft-
ware. Es correcto pensar que la arquitectura de software comienza su intervención en la etapa
de diseño, pero incorrecto asimilar que toda la etapa de diseño se limita a la arquitectura de
software, pues según [9], Grady Booch recalca que “toda arquitectura es diseño pero no todo diseño es
arquitectura”, las decisiones arquitectónicas son fundamentales para el sistema y cualquier cam-
bio arquitectónico impacta de forma relevante el costo. Que un sistema carezca de un diseño
arquitectónico no significa que también carezca de una arquitectura, pues uno de los fundamen-
tos de la arquitectura de software refiere que todos los sistemas tienen una arquitectura [50] y
por ende todos los sistemas pueden ser analizados y estudiados a partir de la arquitectura de
software.

Para el análisis y estudio de los sistemas, la arquitectura de software se compone de una colec-
ción de elementos, relaciones y propiedades. Los elementos representan las unidades com-
putacionales de un sistema y detallan las funciones que cumplen dentro de la arquitectura [13],
pueden existir en tiempo de ejecución, en tiempo de desarrollo o incluso de forma física [11].
Las relaciones representan las interacciones entre los elementos del sistema, definen el proceso
de comunicación, coordinación y cooperación, y proporcionan estandarización sobre cómo los
elementos pueden o no estar relacionados unos con otros [13]. Las relaciones al igual que los
elementos, pueden existir en tiempo de ejecución, en tiempo de desarrollo o de forma física [11].
Las propiedades representan comportamientos visibles o medibles del sistema como los requisi-
tos funcionales o de calidad [50]. Las propiedades describen información complementaria sobre
2.1 Arquitectura de Software 5

los elementos y sus relaciones, generalmente determinan la capacidad de una arquitectura y de

qué manera cumplen con los requisitos.

Los elementos y sus relaciones definen las estructuras del sistema. Una estructura es una colec-
ción de elementos y relaciones que proporcionan detalles de algunas características de com-
posición del sistema. Las estructuras en arquitectura de software se agrupan en tres categorías
según su naturaleza. La primera categoría comprende las estructuras modulares que dividen
el sistema en diferentes partes basadas en unidades de implementación, las cuales pueden in-
terpretarse como estructuras estáticas ya que la definición de los elementos y las relaciones
se producen en tiempo de diseño. Cada módulo definido tiene una o varias responsabilidades
coherentemente asociadas dentro del sistema. La segunda categoría abarca las estructuras de
componentes y conectores que detallan las relaciones que se presentan entre elementos del sis-
tema en tiempo de ejecución, y expresan su comportamiento ante estímulos internos o externos
del sistema, razón por la cual se interpretan como estructuras dinámicas. La tercera y última ca-
tegoría contiene las estructuras de asignación las cuales reflejan las decisiones de las estructuras
indirectamente relacionadas con el software en ambientes de desarrollo o ejecución, como el
hardware, el sistema operativo o el equipo de desarrollo asignado [7].

La disposición de las estructuras proporcionan diferentes perspectivas del sistema, pero los ele-
mentos y las relaciones de una estructura no son completamente independientes de otras es-
tructuras. Por la naturaleza de la estructura analizada se pueden omitir algunas relaciones que
no aportan significado en el análisis, lo cual no indica una carencia de otro tipo de relación entre
los elementos de otras estructuras [7]. Una especialización concreta de las estructuras con un
conjunto de restricciones crean un estilo arquitectónico [13].

La arquitectura de la mayoría de los sistemas de software tienen bases en arquitecturas ya exis-

tentes y ampliamente conocidas. Es normal que sistemas de software tengan características ar-
quitectónicas comunes aunque no estén relacionados y no hayan sido diseñados por los mismos
arquitectos. Por ejemplo, la mayoría de las aplicaciones que a diario se utilizan, se conectan y
obtienen información de un computador que está a miles de kilómetros y gracias a ello cumplen
su función. Los dispositivos en los cuales funciona la aplicación se les llama clientes y a ese com-
putador que está a miles de kilómetros y responde a múltiples peticiones de diferentes clientes,
se le llama servidor. Ese sistema, en donde uno o muchos clientes se comunican con un servi-
dor, es un estilo arquitectónico ampliamente utilizado llamado cliente-servidor. De esa forma,
un estilo arquitectónico (o simplemente estilo) es una especificación de las estructuras más co-
munes de los sistemas, que provee un conjunto base de elementos y relaciones, y se limita a
una serie de restricciones. Los estilos engloban las decisiones arquitectónicas de diseño que
pueden ser reutilizables en otros sistemas bajo un contexto [50] y tienen la particularidad de
ser agnósticos a la tecnología y al dominio [11]. Los estilos arquitectónicos son útiles durante el
proceso de diseño como planos cartográficos, solución para el diseño de un sistema, bases para
6 2 Marco Teórico

la adaptación del contexto, inspiración de una solución, o incluso motivación para el surgimiento
de nuevos estilos [46]. Un sistema puede tener múltiples estilos, dependiendo de la perspectiva
arquitectónica que sea revisado y su categoría.

Los patrones arquitectónicos (o simplemente patrones), al igual que los estilos, son una generali-
zación de estructuras arquitectónicas comunes de los sistemas. La gran diferencia con los estilos
radica en que los patrones se fundamentan en un problema recurrente de diseño para contex-
tos que tienen ciertas características [11], mientras que los estilos solo requieren del contexto.
En otras palabras, un patrón es una posible solución de diseño aplicable a un problema de un
conjunto definido de contextos [46]. Según [50] los estilos y patrones difieren en al menos tres
aspectos importantes: el alcance (los estilos arquitectónicos son estratégicos mientras que los
patrones son herramientas de diseño táctico), la abstracción (los estilos requieren interpretación
humana y por si mismos no crean un diseño concreto del sistema, mientras que los patrones de-
finen elementos concretos que corresponden al sistema) y la relación (un patrón puede aplicarse
en múltiples estilos según su definición pero siempre será aplicado en el contexto del estilo,
mientras que un estilo puede incluir múltiples patrones).

Cada uno de los artefactos construidos durante el proceso de diseño y desarrollo del software
deben ser documentados de forma eficaz, y el proceso arquitectónico no es la excepción. “The
best architects produce the best documentation not because it’s “required”, but because they see that it is essential
to the matter at hand: producing a high-quality product, predictably and with as little rework as possible” [Los
mejores arquitectos producen la mejor documentación no porque sea “requerida”, sino porque
ven que es esencial para el asunto en cuestión: producir un producto de alta calidad, de manera
predecible y con el menor trabajo posible] ([13], p.12). Uno de los conceptos más importantes
dentro de la documentación de la arquitectura de un sistema es el de vista arquitectónica [13].

Las vistas arquitectónicas son representaciones de las estructuras del sistema. Las representa-
ciones poseen diferentes grados de formalidad en su documentación y varían en el tipo de no-
tación. La notación informal no hace uso de ningún estándar para representar las estructuras
del sistema, puede utilizar elementos gráficos o textuales particulares para la vista y debe ir
acompañada de un resumen (bien sea textual u oral) que permita interpretar el significado de la
notación. Las notaciones informales no tienen bases para un análisis formal [13]. La notación
semiformal se expresa mediante una notación gráfica estandarizada que provee elementos con
significado, pero sin un tratamiento semántico completo [13]. El Lenguaje de Modelado Unifi-
cado (Unified Modeling Language en inglés, UML) es por lo general la forma en la cual se repre-
sentan las arquitecturas con notación semiformal. La notación formal a diferencia de la notación
semiformal, provee elementos con significado y un tratamiento semántico completo. Esencial-
mente las notaciones formales tienen base matemática y la forma más común de representación
es mediante los Lenguajes de Descripción de Arquitectura (Architecture Description Languages
en inglés, ADLs). Una vista arquitectónica tiene un objetivo concreto que desea representar,
2.1 Arquitectura de Software 7

generalmente enfocada en características del sistema, guiada por el principio de separación de

preocupaciones [46]. Una vista arquitectónica compila algunas de las decisiones de diseño de los
arquitectos relacionadas con el objetivo estudiado y poseen un grado de especificación. Actual-
mente existen “plantillas” para la generación de vistas, con elementos y relaciones comunes que
proveen una perspectiva del sistema llamada punto de vista (o viewpoint en inglés) de la arqui-
tectura [50]. La documentación de una arquitectura debe estar compuesta de múltiples vistas
que resalten las características del sistema y habitualmente se realiza mediante un Documento
de Descripción de la Arquitectura (Architecture Description Document en inglés, ADD), el cual
compila las vistas más relevantes. La creación, análisis y mantenimiento de las arquitecturas de
los sistemas es guiado por las descripciones de la arquitectura que se encuentran estandarizadas
por la norma ISO/IEC/IEEE 42010 [23].

Las vistas de módulos permiten desglosar las estructuras del sistema en unidades de imple-
mentación coherentemente relacionadas. Cada vista puede tener el nivel de detalle deseado o
según se necesite. [13] resalta esta categoría por la ayuda que brinda principalmente a la co-
municación con los stakeholders, construcción y análisis del sistema. Las vistas de módulos
definen como único tipo de elemento los módulos que son unidades de implementación de soft-
ware agrupadas por responsabilidades comunes [13]. Las relaciones posibles en esta categoría
son: es parte de que representa una contenencia submodular entre dos elementos, depende de que
define una relación de dependencia de un módulo a otro y es un que concreta una relación he-
reditaria de un módulo general a un módulo específico [13]. Las propiedades pertenecientes a
las vistas de módulos son las siguientes: nombre que provee el principal identificador de distin-
ción, responsabilidad que proporciona el rol del módulo en el sistema, visibilidad de la(s) interfaz(ces)
que define la exposición para uso de un módulo o submódulo en el entorno e información de la
implementación que atañe información relevante adicional al tipo de vista que se documenta [13].
Las estructuras estáticas permiten definir la manera en que el sistema fue o será desarrollado,
la composición y generalización del sistema, qué tan dependiente son unos módulos de otros
internamente, cuál es su nivel de dependencia con elementos externos, qué módulos o aspectos
se encargan de funcionalidades transversales en el sistema o la relación directa existente entre
los módulos y los datos [13].

Algunas de las vistas más relevantes en esta categoría son:

• Vista de descomposición [13]

• Vista de usos [13]

• Vista de capas [13]

• Vista de modelo de datos [13]

Las vistas de componentes y conectores permiten representar las estructuras dinámicas del sis-
tema, aquellos elementos que son relevantes en tiempo de ejecución [7]. Estas vistas permiten
8 2 Marco Teórico

analizar la organización entre los componentes que definen el comportamiento interno del sis-
tema y la interacción con el entorno. Generalmente las vistas de componentes y conectores
apoyan el razonamiento sobre los atributos de calidad de un sistema [13]. Los elementos que dis-
tinguen las vistas de componentes y conectores son dos. Los componentes denotan las unidades de
procesamiento y almacenamiento de datos, y los conectores representan la interacción entre com-
ponentes a través de rutas establecidas [50]. Los componentes pueden comunicarse con otros
componentes a través de puertos (o interfaces del componente) [13]. La unión es la relación que
las vistas definen y permite la conexión entre los componentes y conectores. Cuando un conec-
tor se relaciona con un componente debe ir acompañado de un rol (o interfaz de un conector),
que define el alcance de la relación. Los elementos de las vistas de componentes y conectores de-
berían tener las propiedades básicas como lo son nombre (provee el principal identificador) y tipo
(definición genérica del elemento). También existen otras propiedades opcionales (comúnmente
no funcionales) según el tipo de vista representada como concurrencia, rendimiento, confiabilidad, se-
guridad o recursos necesarios, entre otras [13].

Las vistas de asignación permiten relacionar el software con estructuras que no son de soft-
ware pero que desempeñan un rol en los entornos de organización, desarrollo, instalación y
ejecución de los sistemas [7], [11], con el propósito de analizar el desempeño y estudiar formas
de optimizar los recursos proveídos, la gestión de equipos para la continuidad del proyecto y
la administración de los archivos para mantener la integridad del sistema [13]. Los elementos
pertenecientes a las vistas de asignación son los elementos de software propios y relacionados con
las vistas de módulos o las vistas de componentes y conectores, y los elementos de ambiente que
pueden referirse al hardware requerido para el ambiente productivo, los equipos de desarrollo
que intervienen en el proceso de construcción o los sistemas de gestión de archivos [13]. Cada
elemento de software debe tener al menos la asignación (allocated to en inglés) a un elemento de
ambiente, y de la misma manera cada elemento de ambiente debe tener al menos un elemento
de software asignado. Sin embargo, la relación entre elementos puede ser muchos a muchos
[13]. Las propiedades de las vistas de asignación frecuentemente exhiben las características que
el software requiere y las características que el ambiente provee, con el propósito de determinar
el éxito o fracaso de la asignación a través de comparaciones [13]. La vista de asignación más
conocida es la vista de despliegue [13].

2.2. Arquitecturas Monolíticas

En el estilo cliente-servidor, a los dispositivos que utilizan los usuarios finales para interactuar
con el sistema y que demandan recursos a través de una red se les llama clientes (sea un computa-
dor o un dispositivo móvil), mientras que todo lo relacionado con el funcionamiento interno,
que no es visible para el usuario final pero provee los recursos y responde a múltiples peticiones
se le llama servidor. Los sistemas de software convencionales del estilo se componen de tres
2.2 Arquitecturas Monolíticas 9

capas a considerar. La primera es la interfaz de usuario que se ejecuta principalmente al lado del
cliente, el servidor le provee los recursos que por lo general poseen el formato HTML, JavaScript
o CSS. La segunda capa es la lógica del negocio que se encarga de interpretar las peticiones de
los clientes y generar respuesta a ellas. Por último se tiene la tercera capa que es de datos, en-
cargada de persistir la información [29].

Un sistema monolítico es aquel que incorpora mayoritariamente la capa de interfaz de usuario

y la capa de lógica de negocio en un componente principal. Un componente monolítico posee la
mayor parte de la funcionalidad del sistema y su despliegue se realiza de forma unitaria [47], [44],
[36], es decir que los módulos del componente no pueden ser ejecutados de forma independiente
[40]. Los monolitos que tienen un buen diseño aplican diversos tipos de patrones que permiten
añadir flexibilidad para un desarrollo incremental y estructurar la aplicación para evitar el alto
acoplamiento entre los elementos de la arquitectura. Para el correcto funcionamiento, un mono-
lito se relaciona frecuentemente con otros componentes, tales como bases de datos, servicios en
la nube, sistemas externos, directorios, sistema de archivos, sistemas de envío de correos, entre
otros. Para que el monolito sea capaz de soportar los diferentes tipos de conectores entre los
componentes, necesita tener diferentes interfaces que expongan el tipo de relación requerida.

Los monolitos se caracterizan principalmente por las siguientes propiedades:

i. Única unidad de despliegue: Los monolitos se componen de un conjunto de módulos
que se ejecutan de manera unificada [36], lo que quiere decir que la mayor parte de la
funcionalidad del sistema se encuentra en un proceso de ejecución.

ii. Comunicación a través de memoria: Esta propiedad deriva de la propiedad anterior y es

precisamente la capacidad que tienen los monolitos de comunicar información entre sus
módulos y capas a través de la memoria, debido a que una de sus características principales
de los procesos es el traspaso de datos por el medio en cuestión.

iii. Dependencia tecnológica: Los monolitos son implementados en un stack tecnológico de

propósito general el cual está relacionado con el entorno de ejecución, lo que hace inviable
incorporar más de un stack en el componente. Como consecuencia, la arquitectura genera
en muchas ocasiones no solo una dependencia con la tecnología, sino también con una
versión específica de ella [42].

iv. Repositorio de control de versiones unificado: Como lo explica [36], aunque el estilo
monolítico no exige que todo el código base de la aplicación se encuentre unificado, en
la mayoría de las aplicaciones con esta arquitectura es común que así sea, por lo cual el
control de versiones se concentra en un repositorio.
Estas propiedades le proporcionan a las arquitecturas monolíticas una serie de ventajas y desven-
tajas. Algunas de las ventajas que proporcionan el estilo arquitectónico monolítico son las si-
guientes:
10 2 Marco Teórico

• Topología simple de despliegue: [36] Para tener un sistema funcional se requiere ejecu-
tar los componentes internos del sistema, pero a causa de la propiedad i., el número de
componentes tiende a ser bajo ya que el monolito posee gran parte de la funcionalidad.
Esto permite que los despliegues sean sencillos desde su concepción, pues para poner
nuevas versiones del sistema en producción la mayoría de veces será suficiente detener el
proceso principal (monolito), realizar el cambio de los archivos o el compilado y ejecutar
nuevamente el proceso.

• Monitoreo del sistema: [36] Esta ventaja también es resultado de la propiedad i. ya que
monitorear un sistema monolítico se ve reducido a monitorear el bajo número de com-
ponentes del sistema. Esto es un gran beneficio especialmente cuando se poseen equipos
pequeños o un presupuesto ajustado, pues requiere menor esfuerzo y poca o nula tecnifi-
cación para realizar la vigilancia.

• Implementación de operaciones en múltiples dominios: Muchas veces se requiere com-

binar datos de diferentes dominios de la aplicación para otorgar una respuesta completa al
cliente. Gracias a la propiedad ii., en las aplicaciones monolíticas se puede realizar a través
de memoria, lo cual favorece el rendimiento, simplifica la implementación, disminuye el
tiempo requerido para ello y delega el manejo de errores al sistema operativo quien se
encarga de todo lo relacionado con el control del proceso.

• Reutilización de código: Una buena práctica de software es la codificación de funcionalida-

des mediante alta cohesión, lo cual permite, entre otras ventajas, reutilizar código basado
en funcionalidad. Debido a las propiedades iii. y iv. es posible hacer este proceso en ar-
quitecturas monolíticas, en donde muchas veces se generan módulos con funcionalidades
genéricas o transversales al sistema, ahorrando tiempo en el desarrollo o mantenimiento
y reduciendo posibles bugs durante la implementación. Sin embargo, es importante re-
calcar que esta práctica debe ser utilizada con mucha precaución, dado que aumenta la
dependencia y el acoplamiento en el sistema.

• Implementación de pruebas de software: [36] En esencia, la codificación de pruebas de

software para un componente de la arquitectura que contiene la mayor parte de funcionali-
dad del sistema, es más sencillo que para otras arquitecturas que poseen funcionalidades
primordiales en diferentes componentes como SOA o microservicios, especialmente en
temas de integración.

Sin embargo, las arquitecturas monolíticas poseen desventajas que han motivado la transición a
través del tiempo de este tipo de arquitecturas clásicas hacia arquitecturas modernas. Algunas
de ellas son:

• Escalamiento horizontal: Es común que los componentes monolíticos realicen un alto

consumo de recursos de infraestructura en su ambiente productivo. Una consecuencia de
2.2 Arquitecturas Monolíticas 11

la propiedad i., es que cuando aumenta la demanda del sistema y se utiliza escalamiento
horizontal como respuesta a dicha demanda, se obliga a crear otras instancias idénticas que
consumirán una cantidad de recursos similar. Esto aumenta los costos de la infraestructura
y hace que sea inviable a largo plazo mantener el modelo de escalamiento. Si adicional-
mente se suma que en la mayoría de los casos el aumento de demanda se da por un servicio
en específico y que en realidad no es necesario escalar todo el componente, es una gran
desventaja para el estilo.

• Despliegue de cambios pequeños: En ocasiones se requiere aplicar cambios pequeños en

producción, lo cual implica por la propiedad i., que todo el procedimiento de despliegue
sea realizado. Según el procedimiento definido, algunos sistemas deben indisponerse por
un tiempo determinado, lo que dificulta un despliegue continuo.

• Vulnerabilidad al alto acoplamiento: [36] Las arquitecturas monolíticas no son causa ni

consecuencia de un alto acoplamiento, pero si es un medio perfecto para acceder a ello. Si
los desarrolladores que implementan la arquitectura no son estrictos en el diseño y la im-
plementación, es muy común que se generen dependencias nocivas en el sistema, lo cual
conlleva a un alto acoplamiento. De cierta forma, es un efecto adverso de la reutilización
de código expuesta entre las ventajas de la arquitectura.

• Actualización tecnológica: Como se menciona en la propiedad iii., una aplicación mono-

lítica únicamente puede tener un stack tecnológico, lo que genera una fuerte dependencia
de la aplicación con la tecnología. Esto dificulta las actualizaciones tecnológicas frecuentes
de la aplicación, pues existe el riesgo de que las funcionalidades que se utilizan cambien
su comportamiento habitual e introduzcan errores [42]. Por lo general, realizar las adecua-
ciones sobre cambios menores de versión resulta sencillo, pero realizar cambios mayores
de versión implica una revisión estricta y una serie de pruebas que validen el correcto
funcionamiento del software.

• Condicionada a limitaciones tecnológicas: Como es natural, cada tecnología tiene un con-

junto de virtudes y limitaciones. Como consecuencia de la propiedad iii., una arquitectura
monolítica está condicionada a las limitaciones de la tecnología.

• Mayor probabilidad de conflictos en el control de versiones: Cuando se requieren varios

desarrolladores para la implementación o soporte del monolito, crece la probabilidad de
que dos o más desarrolladores colisionen en los archivos donde se deben hacer cambios, lo
cual genera conflicto en el sistema de control de versiones, especialmente cuando poseen
la propiedad iv. La probabilidad de conflictos aumenta en la medida en la que el personal
que debe interactuar con el monolito es mayor.
12 2 Marco Teórico

2.3. Arquitecturas de Microservicios

Las arquitecturas de microservicios nacen como una alternativa a los problemas recurrentes
de algunos estilos como las arquitecturas monolíticas [45]. Este estilo está basado en la com-
putación distribuida y poseen un conjunto de componentes orientados a pequeños servicios
diseñados en torno al negocio, operan de forma autónoma e independiente y su comunicación
se realiza de manera coordinada mediante protocolos ligeros [29], [35]. Retomando la estructura
convencional en capas del estilo cliente-servidor los cuales poseen tres módulos principales, en
una arquitectura de microservicios principalmente los módulos de lógica de negocio y datos se
rompen en pequeños servicios limitando el alcance de su dominio. Esto no quiere decir que el
módulo de interfaz de usuario no se pueda dividir en microservicios, sino que es poco frecuente.
Un gran reto para la arquitectura está en definir los límites de cada microservicio. La complejidad
de las arquitecturas de microservicios es alta, por ello comúnmente aplican diversos patrones
que ayudan a simplificar la dinámica en el sistema.

Algunas de las propiedades más importantes de los microservicios son las siguientes:

i. Servicios pequeños con procesos independientes: [29] La principal característica de los

microservicios es la división de una aplicación en múltiples componentes de forma modu-
lar, en donde cada componente realiza una funcionalidad específica y limitada dentro del
sistema. Cada uno de los componentes, por su definición formal, ejecuta un proceso que
es totalmente independiente de otros componentes.

ii. Arquitectura distribuida: Al ser una arquitectura que posee múltiples componentes, en
gran cantidad de ocasiones se requiere consultar dos o más de ellos para completar la
respuesta a una solicitud. Cada uno de los componentes brindará la porción de informa-
ción que corresponde a su dominio y de esta manera se reúne la información total para la
respuesta.

iii. Comunicación mediante protocolos ligeros: Por ser una arquitectura distribuida con pro-
cesos independientes, la comunicación entre microservicios a través de memoria no es
viable. Por ello la comunicación entre componentes se debe realizar mediante mecanis-
mos de red que permitan una ágil transmisión de datos. Entre los más comunes tenemos
REST y gRCP que utilizan el protocolo HTTP [44].

iv. Base de datos independiente: Una característica derivada de los servicios independientes
definidos por un contexto o dominio, es la posibilidad de tener bases de datos (incluyendo
sus motores) de forma independiente, que materialice las entidades comprendidas por el
límite definido para el servicio.

Las ventajas que proveen este tipo de arquitectura son diversas, entre las más destacadas son
las siguientes:
2.3 Arquitecturas de Microservicios 13

• Pluralidad tecnológica: [44] Gracias a la propiedad i. cada uno de los microservicios

definidos puede ejecutarse de manera autónoma e independiente. Consecuencia de esto
es la viabilidad de que cada microservicio esté construido en el stack tecnológico más con-
veniente, lo cual induce una arquitectura con oportunidad de tener múltiples tecnologías.

• Actualización tecnológica sencilla: [44] Debido a la propiedad i., los microservicios de

la arquitectura tienen un límite de dominio y funcionalidad definido. Cuando hay actua-
lizaciones de la tecnología (bien sean menores o mayores) que requieren adopción del
cambio, es más rápido de realizar y probar, pues únicamente se tendrá en cuenta lo que
comprende el microservicio, lo cual es limitado.

• Adopción de nuevas tecnologías: [44] Esta ventaja es parte de la pluralidad tecnológica

que ofrecen los microservicios, pues basta con crear un nuevo microservicio que ofrezca
la funcionalidad requerida o volver a construir un microservicio en la tecnología deseada,
con el objetivo de aprovechar al máximo las características de la tecnología.

• Mayor autonomía para grandes equipos de desarrollo: [36] Cuando el área de tecnología
de una organización requiere de bastantes desarrolladores, es habitual que se establezcan
pequeños grupos de entre cuatro y siete integrantes. En una arquitectura de microser-
vicios cada uno de los equipos tiene el límite de sus obligaciones bien definido, pues la
responsabilidad de cada uno viene delimitado por el alcance del dominio del conjunto
de microservicios asignados. Como los microservicios son diseñados y desarrollados de
forma modular, el equipo posee total control y autonomía sobre el conjunto de microser-
vicios a su cargo, sin una alta dependencia hacia otros equipos.

• Reducción del Time to market: Una de las grandes ventajas que poseen los microservicios es
la capacidad de despliegue independiente. Ello se ve reflejado en la frecuencia con la que
se lanzan a producción cambios pequeños o nuevas funcionalidades [36]. Mientras que
en arquitecturas centralizadas como las aplicaciones monolíticas muchas veces se debe
esperar a que un conglomerado de cambios se encuentre disponible para que la indispo-
nibilidad del sistema sea justificada, en este tipo de arquitecturas distribuidas se puede
realizar de manera independiente sin afectar fuertemente la disponibilidad del sistema.

• Acoplamiento limitado: Gracias a las fronteras trazadas por los microservicios, la interde-
pendencia también se verá limitada al lindero del microservicio.

• Eficiencia en el escalamiento: [36] En todos los sistemas de información existen módulos

específicos que soportan una mayor carga que otros. Gracias a los microservicios es posi-
ble brindar escalamiento a los módulos que requieren soportar un mayor trabajo, esto
hace que la arquitectura sea más eficiente en el aprovechamiento de la infraestructura
disponible.
14 2 Marco Teórico

• Aumento de la disponibilidad: Un resultado de las arquitectura de microservicios es la

eliminación de SPOFs (puntos únicos de fallo por sus siglas en inglés), pues el fallo en un
microservicio representa una indisponibilidad temporal del servicio que presta, pero los
otros servicios continuan operando. Lo mismo pasa con los despliegues ya que al ser
independientes los pasos a producción de un microservicio, puede significar una indispo-
nibilidad temporal del servicio en cuestión, pero el resto del sistema seguirá operativo.
Esto supone un aumento en la disponibilidad total del sistema.

• Habilitan la interoperabilidad interna y con otros sistemas: Como se mencionó en la

propiedad iii. los microservicios requieren mecanismos de red y protocolos ligeros para
comunicarse entre ellos. Esta característica permite que sin importar la tecnología de cada
microservicio sea posible compartir información no solo a nivel interno, sino también a
nivel externo con otros sistemas.

• Dominio de datos: Cada microservicio define su propio dominio del negocio según la
propiedad iv. Esto quiere decir que cada componente tiene injerencia únicamente en
sus datos, lo cual permite tomar decisiones tecnológicas más asertivas como por ejemplo
decidir si utilizar una base de datos relacional o no relacional, el nivel de carga que ha de
soportar la base de datos y si se requiere alguna táctica arquitectónica, entre otras.

A pesar de las ventajas que brindan las arquitecturas de microservicios, existen algunas desven-
tajas que vale la pena tener en cuenta cuando se toman decisiones de este tipo:

• Mayor complejidad en la administración y monitoreo del sistema: Mientras que en las

arquitecturas monolíticas solamente se debe desplegar un componente, para las arquitec-
turas de microservicios se debe tener todos los componentes derivados de la propiedad i.
Así mismo, observar la traza y el correcto estado de todos los componentes es más difí-
cil. Evidentemente, entre mayor cantidad de microservicios, mayor será la complejidad
de administración y monitoreo.

• Aumento de la latencia en el sistema: Todos los sistemas con el estilo cliente servidor
tienen una latencia que depende de la calidad de la red utilizada. En arquitecturas tradi-
cionales como las monolíticas, el tiempo de respuesta para una petición no solo depende
de la velocidad de procesamiento de los componentes de aplicación y base de datos, sino
también de la latencia del conector que hay entre los componentes. Muchas de las peti-
ciones que se realizan a arquitecturas de microservicios requieren de dos o más compo-
nentes para completar la respuesta a la petición, pero debido a las propiedades ii. y iii.
inevitablemente se inducen latencias adicionales en el sistema.

• Dependencia del canal de comunicación: Otra de las grandes desventajas que tienen este
tipo de arquitecturas es que se convierten dependientes del canal de comunicación, pues
como ya se ha mencionado anteriormente en reiteradas ocasiones, en muchas de las peti-
ciones los microservicios requieren interoperar con otros microservicios y no hay forma
2.4 Evolución Arquitectónica 15

de que se efectúe la interacción si no es a través de la red. Del mismo modo, si se conges-

tiona la red la latencia aumenta y los servicios tardarán más en completar la operación.

• Alto costo en los errores de diseño: Los errores de diseño de las arquitecturas distribuidas
tienen un mayor costo en comparación con las arquitecturas tradicionales [36]. Si bien
se ha dicho que adoptar nuevas tecnologías y actualizaciones es más sencillo para esta
arquitectura, el desarrollo completo y los cambios en los límites de un microservicio es
más costoso en tiempo y esfuerzo que una arquitectura monolítica, ya que se necesita
configurar las interacciones con los demás componentes de la manera como se especifica
en la propiedad iii.

• Complejidad para las transacciones en el sistema: Cuando una transacción sólo com-
prende un microservicio, la complejidad puede ser la misma que en una aplicación mo-
nolítica. Pero en las circunstancias en donde las transacciones comprenden más de un
microservicio, el proceso se complica. Una consecuencia de la propiedad iv. es la pérdida
de la integridad referencial que habitualmente proveen los motores de bases de datos,
trasladando la responsabilidad a los microservicios o a una capa intermedia que provea
esa funcionalidad. Cualquiera de las dos posibles soluciones planteadas, requiere un alto
esfuerzo y aumenta la complejidad del sistema.

2.4. Evolución Arquitectónica

La evolución arquitectónica de los sistemas de software se refiere a aquellos cambios que ex-
perimentan los elementos, relaciones y propiedades. Habitualmente el diseño y la estructura
original de los sistemas de software varían con el tiempo con el fin de soportar las correcciones
y los nuevos requisitos [50]. La causas de la evolución de una arquitectura pueden ser diversas,
entre las más comunes se encuentran factores como requisitos tergiversados o mal compren-
didos, un rápido cambio del modelo de negocio [46], satisfacer nuevas o cambiar propiedades
no funcionales del sistema y la necesidad de adaptarse a nuevos entornos operativos [50]. En
la literatura se puede encontrar el concepto como evolución, transformación, mantenimiento,
adaptación, entre otros, pero en esencia se refiere al mismo proceso de rediseñar y reestructurar
las arquitecturas. Para realizar la evolución de una arquitectura se requiere un profundo conoci-
miento del sistema, de lo contrario se verá afectada la calidad del diseño y tenderá a degradarse
significativamente con el tiempo [50], [9]. Sin embargo, las organizaciones deben afrontar la alta
rotación de personal, la cual también se padece en los equipos de tecnología. Los sistemas que
pierden calidad durante su evolución, pero son fundamentales y cumplen un rol importante en
la organización, comúnmente se les llama sistemas heredados (o Legacy Systems) [33].

En la actualidad existen muchos sistemas heredados que las organizaciones intentan evolucionar
con algún objetivo particular, bien sea a otras arquitecturas o a la misma arquitectura. A pesar
16 2 Marco Teórico

de que suene atractivo hacer nuevamente un sistema desde cero en el proceso, [44] enfatiza en
no es lo mejor, pues el sistema heredado contiene sabiduría y entendimiento de la organización
que volver a implementar resultaría costoso y riesgoso. Existen diversas incógnitas y retos al
evolucionar una arquitectura tal como lo describen [6], entre las más destacadas se encuentran
la capacidad limitada de recursos, la operatividad continua y funcional requerida, y el riesgo
existente en la incorporación de nuevas tecnologías.

2.5. Diseño Guiado por el Dominio (DDD)

El diseño guiado por el dominio es un enfoque propuesto por [17] que permite modelar y cons-
truir las aplicaciones de software basado en el contexto real del negocio, de manera que la es-
tructura de la aplicación sea semejante al “qué” y “cómo” en los procesos de la organización. La
relación que se genera permite una excelente comunicación entre los expertos del dominio y los
desarrolladores, pues los desarrolladores son quienes deben adoptar un lenguaje ubicuo que per-
mita una relación directa entre el código y el contexto del negocio. Sin embargo, no es suficiente
adoptar una terminología afín, también es importante abordar el dominio de forma modular o
por subdominios, que sean altamente cohesivos y bajos en acoplamiento, definidos por con-
textos limitados [43]. DDD permite la definición de un conjunto de servicios basados en los
subdominios del cual se hace uso comúnmente para definir los microservicios en ese tipo de
arquitecturas [44].

Evans [17] define algunos conceptos que son relevantes en DDD. El primero es el de entidad que se
refiere a una instancia de un modelo del dominio que tiene identidad propia y que son mutables.
El segundo es el de objeto de valor que describe una característica de la entidad y que es inmutable,
por lo tanto cuando una entidad cambia de característica, realmente está reemplazando su objeto
de valor. Las entidades deben encapsular los comportamientos de forma cohesiva y para aque-
llas operaciones de dominio que conceptualmente no pertenecen a las entidades nace la tercera
definición que es servicio, el cual implementará gran parte del comportamiento del dominio de
forma stateless [52]. Luego se tienen los agregados que son los responsables de limitar la transac-
cionalidad de un conjunto no vacío de entidades y cuando se tiene más de una entidad dentro
de un agregado debe existir una entidad raíz. Continuando con los conceptos clave, existen dos
relacionados con las entidades que son repositorio y fábrica. Los repositorios son referentes al
patrón repository el cual se encarga de separar el dominio del mapeo de datos a través de capas
[19], y las fábricas referentes al método u objeto de fábrica que encapsula la creación compleja
de entidades [20]. Adicionalmente existen dos conceptos relacionados dentro del enfoque que
son los comandos y eventos. Los comandos (o modificadores) son operaciones que ejecutan los
actores (como un usuario o sistema externo) y producen cambios de estados en el sistema [17],
y los eventos de dominio son resultado de la reacción de un agregado a un comando, que cap-
turan ocurrencias del sistema [52].
2.5 Diseño Guiado por el Dominio (DDD) 17

Comprender en su totalidad y de manera correcta el dominio de una organización es uno de los

mayores retos que presenta DDD. Por ello existen algunas estrategias para alcanzar el objetivo,
entre las de mayor popularidad se encuentra Event Storming el cual es un taller propuesto por
[8] que busca el entendimiento colaborativo entre expertos del dominio y expertos técnicos,
mediante el uso del lenguaje ubicuo. El resultado del taller es un tablero o un rollo de papel con
múltiples pósit de colores, donde se pueden identificar principalmente eventos y agregados del
dominio [44].
3. Trabajos Relacionados
En la literatura se encuentran múltiples maneras de realizar una evolución de monolito a mi-
croservicios, entre las cuales se destacan cuatro. La primera conocida como Big Bang es realizar
el desarrollo completo del sistema como microservicios y únicamente ponerlo en producción
cuando se haya finalizado, puede ser desarrollado por un equipo paralelo y no se requieren es-
tados intermedios ni convivencia entre el monolito y los microservicios. Una evolución Big Bang
tiene varias desventajas especialmente en sistemas con requisitos dinámicos, pues cualquier
cambio requerido en el monolito operativo también debe ser implementado en los microservi-
cios, lo que lo convierte en un modelo sumamente costoso, además el gran riesgo que conlleva
el lanzamiento de un sistema nuevo es la alta probabilidad de bugs [46]. La segunda opción es
mediante el patrón rama por abstracción que permite sustituir gradualmente los servicios a través
de una capa abstracta que redirecciona las interacciones internas del sistema [36]. La tercera
opción es a través de composición de interfaz de usuario, que concentra su esfuerzo en verticalizar la
arquitectura por dominio [35]. La cuarta posibilidad a considerar es mediante el patrón aplicación
estranguladora [18], el cual es el preferido de la gran mayoría de estudios para realizar la evolución
arquitectónica, pues brinda ventajas evidentes que permiten de manera transitiva convertir el
sistema heredado en obsoleto, mientras que el nuevo sistema asume gradualmente las funcio-
nalidades.

Este tipo de evolución de monolito a microservicios conlleva una serie de retos frecuentes. El
primero de ellos es hallar el tamaño adecuado y los candidatos de microservicios [22]. En la
actualidad existen diferentes métodos automáticos [26], [14], [16], [1], [21], [5], [27], [12], [4],
semiautomáticos [25], [49], [28], [30], [31], [39], [53], [2] y manuales para la descomposición.
Los métodos automáticos son de bajo costo y rápida implementación pero demasiado rígidos,
mientras que los métodos manuales son de alto costo y requiere extensos tiempos de imple-
mentación pero bastante flexibles en diseño [32].

El segundo reto cuando la evolución se realiza de manera transitiva, es determinar qué servicios
se evolucionarán primero a microservicios, para lo cual se utilizan algunos enfoques. En los tra-
bajos previos que abordan evoluciones de arquitecturas monolíticas a microservicios se utilizan
diversos enfoques [41], [10], [40], [22] que se pueden resumir como se muestra en la tabla 3-1.
Estos enfoques no son excluyentes entre sí [40], al contrario en muchas ocasiones pueden ser
complementarios. Con base en estos enfoques se generan nuevos métodos de análisis que per-
miten estructurar la información recolectada y generar nuevos modelos de evolución, como
 19

Enfoque Descripción

Tiene como principal insumo el código fuente del monolito y evaluar

Análisis estático
el nivel de acoplamiento entre elementos del sistema
Su fundamento está basado en el comportamiento del sistema durante
Análisis dinámico
el tiempo de ejecución
Utiliza elementos de diseño para el análisis. Algunos métodos utilizan
Guiado por modelos metadatos para abstraer la arquitectura y realizar transformaciones
semiautomáticas o automáticas

Tabla 3-1.: Enfoques de análisis para la migración de una arquitectura monolítica a una arqui-
tectura de microservicios.

análisis basados en grafos y patrones [10], análisis algorítmicos [41] o análisis de datos de car-
gas de trabajo [22]. Adicionalmente, es importante establecer parámetros de priorización en
la migración, los cuales ayudan a identificar el orden en que los microservicios serán extraídos
del monolito y desarrollados en microservicios. [36] describe una técnica basada en dependen-
cias ascendentes y descendentes entre los candidatos identificados, priorizando los servicios
de menor a mayor según el número de dependencias ascendentes que posea, pues cada depen-
dencia ascendente requiere una adaptación del servicio dependiente. El objetivo del análisis
es reducir la cantidad de cambios que requiere el proceso, aunque el método no contempla la
dificultad que puede representar el cambio. Otra técnica descrita por [36] para priorizar a los
candidatos es determinando la urgencia y necesidad del cambio o el beneficio obtenido del pro-
cedimiento. Ambas técnicas pueden ser combinadas.

El tercer reto está relacionado con las transacciones del sistema. En un monolito las transac-
ciones se realizan de forma simple y en muchas ocasiones la integridad de la información la
administra la base de datos, pero en una arquitectura de microservicios una transacción puede
llevarse a cabo empleando más de un microservicio y almacenar información en dos o más bases
de datos [48]. Para este inconveniente la literatura provee dos opciones: la primera de ella es
el protocolo two-phase commit que consta de una fase de preparación y una fase de realización,
generalmente coordinado por un administrador de transacciones [48]; la segunda opción es me-
diante el patrón sagas que consiste en ejecutar una secuencia de transacciones locales en cada
microservicio y luego publicar un evento o un mensaje indicando que puede ejecutarse la si-
guiente transacción local [44].

El cuarto reto de la evolución está relacionado con la migración y conservación de los datos del
sistema heredado. En la gran mayoría de casos, es necesario realizar una reestructuración del
diseño de la base de datos y adecuar según el dominio de los microservicios. Idealmente cada
20 3 Trabajos Relacionados

microservicio tendrá relación con un conjunto de datos y la separación puede ser a nivel lógico
o físico [36]. El reto es mantener operativo y disponibles los datos del sistema heredado con la
estructura antigua, junto con la nueva estructura obtenida del diseño de los microservicios. Una
alternativa es realizar procesos de extracción, transformación y carga (ETL) como lo recomiendan
[13], [47] y [33].

El quinto reto es un tema sensible y una decisión crucial para la seguridad del sistema, pues está
relacionado con la autenticación y la autorización de los usuarios. Algunos sistemas hereda-
dos luego de autenticar a un usuario, utilizan sesiones con estado, otros utilizan un token que
requiere una llave secreta para generar y validar la legitimidad. [44] categoriza tres opciones
para mantener una misma autenticación para la aplicación monolítica y para la aplicación en mi-
croservicios. La primera opción es adaptar la aplicación de microservicios a la seguridad de la
aplicación monolítica, aunque es contraproducente cuando los monolitos tienen sesiones cen-
tralizadas y usan contextos de seguridad en memoria, pues lo convierte en una aplicación con
estado. La segunda opción es realizar la adaptación del sistema monolítico para coexistir con las
sesiones sin estado habituales de los microservicios, lo cual resulta conveniente especialmente
porque todos los servicios podrán conocer la identidad del usuario e implementar de forma in-
dependiente sus controles de acceso. La tercera opción es mantener un modelo híbrido que
conserve el método de seguridad antiguo para el monolito e implemente un método nuevo para
los microservicios, aunque el mayor inconveniente es mantener integridad entre los usuarios,
los permisos y las sesiones de ambos métodos.
4. Sistema de Información ISys
El acceso a la educación superior es un privilegio al que pocos estudiantes pueden acceder en
Colombia. Para 2019, alrededor de 1.600.000 personas aspiraban obtener un cupo para técnicos,
tecnólogos y carreras profesionales, de los cuales tan solo 51,6 % de los candidatos lo logró. Del
total de aspirantes, 69 % pretendían ingresar en una institución pública para realizar sus estu-
dios [34]. La Universidad Nacional de Colombia (UNAL) se caracteriza por sus altos estándares
académicos y por ser la universidad más apetecida del país para estudiar una carrera profesional.
En la última década, anualmente más de 100.000 aspirantes compitieron para clasificar a uno de
los 97 programas académicos que se ofrecen en pregrado, de los cuales aproximadamente 12.000
consiguieron hacerlo. Con un índice de admisión inferior al 12 % la UNAL debe garantizar un
proceso de selección objetivo, íntegro y transparente. Adicionalmente la UNAL se caracteriza
por brindar oportunidades de acceso a poblaciones vulnerables y en desventaja social, imple-
mentando diferentes programas de admisión especial para pregrado. Así mismo, la universidad
brinda programas de posgrado como especialidades, especializaciones, maestrías y doctorados,
que también son altamente demandados.

Desde 1940, la UNAL implementa pruebas de admisión como filtro para seleccionar a sus estu-
diantes, siempre enfocadas a capacidades cognitivas de la persona. En sus principios, el instituto
de psicología aplicada de la UNAL era la dependencia encargada de construir y aplicar la prueba
a los candidatos, posteriormente entre los años 1952 y 1961 se delegó a cada facultad la respon-
sabilidad de aplicar los procesos y pruebas de admisión correspondientes. No es sino hasta el
año 1964 que se crea una dependencia específicamente para realizar los procesos de admisión, la
cual fue nombrada como División de Admisiones, Registro y Control Académico, en 1972 cambia
su nombre a Departamento de Admisiones e Información Profesional, hasta que en 1998 recibe
el nombre actual de Dirección Nacional de Admisiones (DNA) [15]. Cada una de las etapas del
proceso era realizada de forma manual y requería de una ardua labor humana.

4.1. Antecedentes
A través del tiempo, la prueba y el modelo de admisión se han reformulado en numerosas oca-
siones, variando los componentes de la prueba, cantidad de preguntas y métodos de calificación
de respuestas, modelo de clasificación y selección de programa, distribución de aspirantes en
grupos de selección de carrera de pregrado, entre otras variables [15]. Para los procesos de ad-
22 4 Sistema de Información ISys

misión del segundo semestre de 2007, la DNA incorporó un sistema de información que permite
a los aspirantes realizar la inscripción y posteriormente consultar los resultados obtenidos del
proceso, sistema que recibe por nombre ISys (Integrated System) y apoya la labor operativa de
la dependencia, por lo cual ha tenido que responder a los cambios y adaptar su funcionamiento
según corresponde a los nuevos requisitos del modelo de admisión periodo a periodo. La evolu-
ción continua del sistema ha sido realizada por múltiples colaboradores y trae consigo el legado
de cada una de las adaptaciones que ha requerido, convirtiéndose así en un sistema heredado,
complejo y de gran tamaño.

ISys soporta tres procesos principales de la DNA: admisión de pregrado (con sus diferentes moda-
lidades y métodos de admisión), admisión de posgrado (es el proceso más plural ya que depende
mucho del programa y los requisitos) y clasificación o certificación de lengua extranjera inglés (los admiti-
dos de pregrado, el siguiente semestre a su admisión deben presentar una prueba de clasificación
del nivel de inglés, mientras que algunos programas de posgrado requieren un nivel mínimo de
inglés por lo cual los aspirantes deben realizar una prueba que certifique el nivel exigido). Todos
los procesos contienen cuatro subprocesos cronológicos de la siguiente manera: Configuración del
proceso, inscripción de los candidatos, aplicación de la prueba y calificación de la prueba. Adicionalmente,
los procesos de pregrado y posgrado conllevan un subproceso adicional que es el de admisión de
los aspirantes, el cual se realiza a posteriori del subproceso de calificación en el cual se determinan
los aspirantes que logran obtener uno de los cupos para estudiar en la universidad.

ISys es un monolito construido en Java, con Spring MVC y Struts. En sus inicios fue desarrollado
en la versión 1.6 de Java y actualizado posteriormente a Java 1.7. Para la versión 1.8 de Java,
se incluyeron nuevas características al lenguaje como funciones lambdas, streams e implementa-
ciones de seguridad y cambios en varias de las clases principales del paquete util como Date y
Time [37] entre otros, que llevaron a la obsolescencia la mayoría de las dependencias del sis-
tema. Durante varios meses se intentó actualizar las tecnologías sin resultados positivos, pues
la incompatibilidad entre las versiones y dependencias del proyecto estropearon el monolito.
Adicionalmente, sumada a la evolución del framework de Spring MVC a Spring Boot, el equipo
técnico junto con la dirección de la dependencia, planearon un proyecto de actualización del
monolito para modernizar las tecnologías y corregir algunos errores de diseño introducidos du-
rante la evolución continua, lo cual es común en los sistemas heredados [46]. Este proyecto no
pudo completarse debido a múltiples factores que habitualmente afectan a los monolitos, des-
critos por [44] como el infierno monolítico, entre ellos la complejidad de evolucionar un sistema
de gran tamaño, el lento desarrollo y la continua operatividad del sistema y la confiabilidad de
entrega de un sistema nuevo construido a partir de nuevos stack tecnológicos. Luego de varias se-
siones de análisis y revisión de alternativas, los microservicios prometieron solucionar muchos
de los inconvenientes experimentados en los dos procesos fallidos de modernización, añadiendo
una propuesta de valor que es la característica natural de los microservicios de ser una arquitec-
tura evolutiva.
4.2 Vistas de Módulos 23

Luego de establecer la arquitectura de microservicios como una arquitectura idónea, conve-

niente y viable para los procesos operados por la dependencia y que además permite abordar de
mejor manera varios de los problemas técnicos que con anterioridad se habían experimentado,
surge la duda de cómo establecer un modelo de evolución que permita realizar el proceso sin
afectar la operatividad del sistema, conservando los datos históricos; dando lugar al tema prin-
cipal de este trabajo.

ISys posee una arquitectura modular basada en el dominio, con una separación lógica en tres
capas, tradicional de las aplicaciones web. El modelo de datos es relacional, diseñado a partir
del paradigma de objetos. La aplicación provee algunos recursos y consume otros de sistemas
externos con quienes se comunica mediante protocolos de comunicación.

4.2. Vistas de Módulos

4.2.1. Vista de Descomposición
El sistema ISys posee nueve módulos de los cuales cinco hacen referencia a los subprocesos
cronológicos de los procesos de pregrado y posgrado, dos módulos que soportan funcionalida-
des generales de los tres procesos principales, un módulo encargado de la interoperabilidad del
sistema y un módulo de idioma que recopila las funcionalidades exclusivas de los subprocesos
cronológicos de ese proceso. Esta estructura puede evidenciarse en la vista representada por la
figura 4-1.
24 4 Sistema de Información ISys

ISys
Admisión Inscripción Reportes Común

Aplicación Calificación Intercambio de información

Configuración Idioma

Idioma

Aplicación Idioma Calificación Idioma Inscripción Idioma

Configuración Idioma

Convenciones

Sistema Módulo Submódulo Módulo con procesos de pregrado y

posgrado

Módulo con procesos de pregrado,

posgrado e idioma

Módulo con subprocesos de idioma

Figura 4-1.: Vista de descomposición del monolito ISys.

La primera impresión de la descomposición del sistema es un error de diseño, pues como se

logra evidenciar los módulos están orientados por los subprocesos de los procesos principales y
funcionalidades genéricas, con excepción del módulo de idioma que hace referencia al proceso
y cuyos submódulos si refieren a los subprocesos. Indagando en el sistema se logra identificar
4.2 Vistas de Módulos 25

una implementación obsoleta del proceso idioma en los módulos de color azul de la figura 4-1.
La razón por la cual existe el módulo de idioma de esa manera es debido a un cambio radical
en los subprocesos de idioma, que requería conservar el histórico de la información y el deseo
de desacoplar el proceso como un desarrollo independiente del sistema, lo que deriva en esa
decisión.

4.2.2. Vista de Capas

ISys se compone de dos capas físicas: La capa de aplicación y la capa de persistencia de datos.
En la capa de aplicación se encuentra el monolito, el cual posee tres capas horizontales y una
capa vertical. La primera capa horizontal en la jerarquía es la capa de presentación construida en
Struts, que contiene los segmentos interfaz de usuario y acción. La segunda capa es de lógica de
negocio que se compone de dos segmentos de capa, el controlador encargado de procesar y dar
respuesta a las solicitudes de los clientes, y el segmento servicio que apoya las funcionalidades
más amplias y complejas. La capa vertical contiene funcionalidades genéricas y comunes que
pueden ser utilizadas por las demás capas lógicas de la aplicación. Para la conexión con la capa
inferior el monolito implementa los patrones DAO y DTO. La capa de persistencia es una base
de datos relacional. La vista descrita es representada por la figura 4-2.

La arquitectura posibilita que el sistema tenga flexibilidad gracias a la composición y al ais-

lamiento que brindan las capas y permite agrupar de manera coherente las responsabilidades
y competencias del sistema. En ISys se logra determinar de manera clara la responsabilidad
de cada uno de los elementos de la arquitectura y se conserva correctamente la jerarquía en la
comunicación.
26 4 Sistema de Información ISys

Aplicación

Monolito

Presentación Común
«permitido
Interfaz de Usuario usar»

«permitido usar»

Acción

«permitido usar»

Lógica de negocio

sedadilitU
«permitido

OTD
Controlador usar»

«permitido usar abajo»

Servicio

«permitido usar»

Acceso a datos
«permitido
DAO usar»

«permitido usar»

Datos

Base de datos
Datos

Convenciones

Capa Física (Tier)

Capa Lógica (Layer)
Capa Lógica (Layer)
Segmento de capa (Layer Segment)

Figura 4-2.: Vista de capas del sistema monolítico ISys.

4.2 Vistas de Módulos 27

4.2.3. Vista de Usos

Las vistas de usos permiten establecer una relación funcional entre los módulos del sistema.
La vista se compone de la relación depende de que representa el uso de un módulo a otro para
su correcto funcionamiento. Según [13] este estilo es útil para planear desarrollo incremental,
estimar los efectos de un cambio y para depuración y pruebas. Una vista de usos en notación
UML se ve como la figura 4-3.

Módulo A «usa» Módulo B

«usa» «usa» «usa»

Módulo C «usa» Módulo D

Figura 4-3.: Ejemplo de una vista de usos en UML.

Aunque la vista de usos permite detallar las dependencias entre los elementos, cuando el sis-
tema posee una gran cantidad de módulos, tiende a ser complicado detectar todas las relaciones
existentes. Es por ello que otra representación común de la vista es la matriz de estructura de depen-
dencia, la cual lista los módulos del sistema como filas y columnas de una matriz. En las matrices
de estructura de dependencia, los módulos localizados en las columnas son dependientes de los
módulos ubicados en las filas si la intersección de la columna y la fila posee un valor diferente
de vacío. Por ejemplo: suponga que en una matriz de estructura de dependencia M , un módulo
x se encuentra ubicado en la fila i y un módulo y se encuentra en la columna j. Si el valor de
Mij es diferente de vacío, significa que el módulo y usa el módulo x. El valor en la intersección
de la fila y la columna depende del nivel de abstracción. Si el análisis del estilo de usos es de alto
nivel de abstracción, probablemente solo se desee contabilizar el uso del módulo, por lo cual
su valor será vacío cuando no tengan relación, y 1 cuando tengan una relación de dependencia.
Si se desea un análisis más detallado, el valor de la intersección puede ser un número que re-
presente la cantidad de submódulos que usa, la cantidad de clases del módulo que utiliza o las
veces que realiza el llamado a una funcionalidad del módulo. En cualquier caso, toda la matriz
debe manifestar el mismo nivel de detalle requerido.

Las tablas 4-1 y 4-2 representan matrices de estructura de dependencia en diferente nivel de
detalle de la vista presentada en la figura 4-3. La tabla 4-1 posee un nivel de abstracción alto,
por lo tanto asigna el valor de 1 cuando existe una relación entre los módulos y un valor vacío
cuando no. En la tabla 4-2 se representan más detalles del sistema, por lo cual el valor de la
28 4 Sistema de Información ISys

intersección indica la cantidad de veces que el módulo de la columna usa una funcionalidad del
módulo localizado en la fila.

A B C D A B C D
A A
B 1 1 1 B 5 1 2
C 1 C 2
D 1 D 3

Tabla 4-1.: Matriz de estructura de dependen- Tabla 4-2.: Matriz de estructura de dependen-
cia de módulo. cia detallada por usos de funciona-
lidad.

Para analizar el sistema de información ISys se usó una matriz de dependencia elaborada de ma-
nera automática por la herramienta Structure 101 que mediante el análisis de código fuente per-
mite identificar el número de dependencias ascendentes y descendentes. El resultado obtenido
tiene como base los paquetes del sistema, aunque según el análisis de descomposición un mó-
dulo está compuesto por uno o más paquetes. La matriz obtenida por la herramienta es la repre-
sentada por el anexo A. Con base en la matriz de la herramienta, se realizó la clasificación de los
paquetes en uno de los módulos identificados en el análisis de descomposición, de la siguiente
manera:

Módulo Paquetes

Admisión certificacion y progcur

Aplicación aplicacion
Calificación calificacion e instructivos
comun, context, eventos, exception, menu, notificaciones,
Común
periodos, temporal y util
Configuración conf, dto y snum
Idioma idioma
aspirantes, epago, inscripcion, inscripciones, paes, resolu-
Inscripción
ciones y snies
Intercambio de Información catedra, Interfaz, sia, webservices
Reportes reportes

Tabla 4-3.: Agrupación de paquetes en los módulos.

Posteriormente se realizó la suma correspondiente de las dependencias, ignorando las existentes

entre paquetes de un mismo módulo, ya que el objetivo del estudio es analizar las dependencias
4.2 Vistas de Módulos 29

externas de los módulos del sistema, por ello se obvian las dependencias internas. La tabla 4-4
detalla los resultados obtenidos.

Módulo Dependencias Ascendentes Dependencias Descendentes

Admisión 4011 1528
Aplicación 835 2758
Calificación 1066 6174
Común 7944 172
Configuración 5135 1718
Idioma 252 1092
Inscripción 1933 7498
Intercambio de Información 492 593
Reportes 7 142

Tabla 4-4.: Resultado de la matriz de dependencias agrupadas por módulos.

Gracias a la matriz de dependencias se logra evidenciar los módulos que poseen menos depen-
dencias ascendentes como reportes, idioma, intercambio de información y aplicación; y menos
dependencias descendentes como reportes, común e intercambio de información. Teóricamente
los módulos con menor cantidad de dependencias ascendentes representan un menor esfuerzo
en la evolución hacia microservicios [36].

4.2.4. Vista de Modelo de Datos

El modelo de datos de ISys posee una estructura relacional de manera tradicional, a partir de un
modelo entidad-relación y en tercera forma normal. Posee una división lógica mediante esque-
mas relacionados con los paquetes del sistema, con un total de 289 tablas y más de 4.500 vistas.
Para obtener el modelo de datos se usó el cliente SQL Datagrip que a través de ingeniería inversa
logra reconstruir las tablas gráficamente. Por asuntos de seguridad, se omite la presentación del
modelo de datos en este documento.

En el análisis se logra identificar algunos errores de normalización en el modelo, consecuen-

cia del mantenimiento continuo del sistema y la complejidad de los cambios requeridos. De
igual manera existe un alto acoplamiento por la implementación de herencia en entidades fun-
damentales del modelo como las de inscrito, aspirante y aspirante posgrado/pregrado, que son
entidades que conceptualmente se utilizan en la mayoría de los módulos del sistema, pero que
su creación se lleva a cabo en el proceso de inscripción. Sin embargo, el modelo posee un alto
nivel de diseño, escalable y ofrece una excelente base conceptual del dominio del sistema lo que
30 4 Sistema de Información ISys

permite reestructurar los datos para acoger la evolución de arquitectura.

4.3. Vista de Componentes y Conectores

ISys se constituye con una serie de componentes que en conjunto proveen el servicio a la de-
pendencia. Por un lado están los componentes internos que proveen la mayor parte de la funcio-
nalidad del sistema, algunos de ellos de propiedad del proveedor de infraestructura en la nube
como el cortafuegos (isys_waf) y el balanceador de carga (isys_lb), por lo que no requieren de
un análisis dentro de las vistas de módulos de la arquitectura; y otros de propiedad intelectual
de la dependencia como el monolito (isys_app) y la base de datos (isys_db). Por otro lado se
encuentran los componentes que representan los sistemas externos a los cuales se les brinda in-
formación a través de interfaces REST como el sistema de pruebas de admisión para personas en
situación de discapacidad (psdda), el gestor de contenidos de la dependencia (admisiones) y el
sistema de información académica de la universidad (sia). También están los sistemas externos
de los cuales se consume un servicio, como el directorio de acceso de la universidad (unal_ldap)
y el sistema de información académica del cual se consultan las vistas de la base de datos. Por
último, el componente que hace posible la interacción del cliente con el sistema es un navegador
web (navegador) el cual a través de internet logra el acceso al sistema.

El navegador utiliza un conector HTTP para realizar la conexión con isys_lb, aunque durante la
operación está siempre interceptado por el componente isys_waf quien provee protección con-
tra algunos ataques de seguridad. El componente isys_lb redirige hacia isys_app las peticiones a
través de un conector HTTP. Las peticiones son interpretadas y procesadas por el componente
isys_app quien dependiendo de la solicitud puede consultar sistemas externos como unal_ldap
para la autenticación de usuario mediante el conector LDAP o consultar históricos de los estu-
diantes de la universidad a través de JDBC a sia. Habitualmente isys_app almacena y consulta la
información en el componente isys_db por medio de JDBC. También existe consumos por parte
de sistemas externos por REST a isys_app, como en el caso de psdda, admisiones y sia.
4.4 Vista de Despliegue 31

«Cliente»
navegador

«Cortafuego»
HTTP isys_waf

«Balanceador de Carga»
isys_lb

REST
HTTP
«Sistema Externo» «Sistema Externo»
psdda REST
sia
JDBC
«Monolito»
isys_app
REST
«CMS» LDAP «LDAP»
admisiones unal_ldap
JDBC

«Base de Datos»
isys_db

Convenciones
Sistema ISys
Sistemas externos

Figura 4-4.: Vista de componentes y conectores del sistema monolítico ISys.

4.4. Vista de Despliegue

La infraestructura en la nube en los últimos años se ha convertido en la opción preferida para la
administración de servicios web dadas sus múltiples ventajas, entre ellas el ahorro en costo, la
alta disponibilidad del servicio y el respaldo de la información [3]. El sistema ISys se encuentra
alojado en Amazon Web Services (AWS) quien provee la infraestructura requerida para el sistema
en producción. La vista de despliegue del sistema monolítico es la representada por la figura 4-5.
32 4 Sistema de Información ISys

«Servicio en la Nube»
Web Application
Firewall {Proveedor = AWS-ELB}
{Proveedor = AWS-WAF}
«Nodo»
Servidor de Aplicación
{Proveedor = AWS-EC2,
OS = Centos 7,
«Servicio en la Nube»
Elastic Load Balancing TipoInstancia = t2.xlarge}
«Entorno de Ejecución»
Tomcat 7.0 / JRE 1.7 : 8080
«Nodo»
Servidor de Base de Datos
{Proveedor = AWS-EC2,
OS = Centos 7,
TipoInstancia = t2.xlarge}
«Entorno de Ejecución»
PostgreSQL 9.5 : 5432

«desplegado en» «desplegado en» «desplegado en» «desplegado en»

«Monolito»
isys_app
«Cortafuego» «Balanceador de Carga» «Base de Datos»
isys_waf isys_lb «Artefacto» isys_db
sitio.war

Convenciones
AWS - VPC
AWS - Sub VPC pública
AWS - Sub VPC privada

Figura 4-5.: Vista de despliegue del sistema monolítico ISys.

La arquitectura posee una nube virtual privada (o VPC por sus siglas en inglés) que se compone
de dos segmentos: una sub VPC pública que permite el acceso de las peticiones del cliente
hacia el Elastic Load Balancing (o ELB), y una VPC privada que aísla las instancias de Servidor de
Aplicaciones y Servidor de Base de Datos por cuestiones de seguridad. Adicionalmente se tiene la
instancia de un Web Application Firewall (WAF), el cual protege el ingreso a la VPC de solicitudes
de algunos atacantes. Como se mencionó en la sección anterior, debido a que tanto el WAF
como el ELB son administrados por el proveedor no tienen un entorno de ejecución identificado
en la arquitectura. El servidor de aplicaciones posee un sistema operativo Centos 7 y es una
instancia de tipo t2.xlarge que posee altas características en memoria y procesamiento. Dentro
del entorno de ejecución se tiene un tomcat 7.0 ejecutado sobre JRE 1.7 de Java expuesto sobre
el puerto 8080, y el artefacto que se asigna al entorno es un WAR que contiene todo el monolito
compilado. El servidor de base de datos también posee un sistema operativo Centos 7 y tiene
configurado una instancia del tipo t2.xlarge, su entorno operativo es la base de datos relacional
postgres 9.5 expuesta por el puerto 5432 el cual sólo es accesible desde la instancia de servidor
de aplicaciones por razones de seguridad.
5. Modelo de Evolución Arquitectónica
El análisis preliminar del sistema permite una visión general del monolito y establece una base
concisa para modelar una estrategia de evolución que cumpla con los requisitos operativos y
tecnológicos de la DNA, pues de lo contrario puede verse afectada la dependencia en sus pro-
cesos. Se definieron cinco requisitos no funcionales, de los cuales dos de ellos son atributos de
calidad:

• Operatividad del sistema: es de vital importancia que el sistema mantenga una operación
continua en todos los procesos que actualmente brinda a la dependencia debido al alto
número de inscritos para los procesos.

• Conservar los datos históricos: para el sistema es elemental mantener disponibles y acce-
sibles los datos históricos, ya que con ellos se realizan algunas validaciones normativas de
los procesos.

• Impacto imperceptible para el usuario: este requisito se fundamenta en evitar que los
usuarios deban hacer reprocesos en sus labores diarias, ya que se pueden afectar los tiem-
pos operativos ocasionando sobrecostos.

• La seguridad del sistema no será comprometida: es esencial que la seguridad del sistema
no se vea comprometida en ningún momento del proceso de evolución.

• Tiempos de respuesta: es importante que el sistema mantenga tiempos de respuesta si-

milares durante la evolución y posterior a ella.

El modelo provee una estrategia transicional que cumple con los requisitos no funcionales, el
cual permite segmentar y separar uno a uno los módulos del sistema. La figura 5-1 brinda una
visión general del modelo, el cual recibe las variables de entrada y de forma iterativa implementa
los patrones definidos por el modelo durante la evolución del sistema, generando unas salidas
que son entradas para la siguiente iteración del modelo.
34 5 Modelo de Evolución Arquitectónica

Primera Segunda N-ésima

iteración iteración iteración

API Gateway

Aplicación Aplicación
0 Aplicación
0
Estranguladora Estranguladora Estranguladora
Entrada Entrada Entrada
Salida
Token de Acceso
Salida Salida

Convenciones
Matriz de dependencias
Variables de entrada y salida
Implementación del patrón

Figura 5-1.: Representación del flujo de la aplicación del modelo de evolución.

5.1. Entradas y Salidas del Modelo

El primer paso del modelo de evolución es definir las variables de entrada y salida. Las variables
de entrada permiten reconocer el contexto, el estado inicial del sistema y el nivel de abstracción.
Las variables de salida proveen el alcance y el resultado de la implementación del modelo.

Para el modelo de evolución arquitectónica se estandarizaron las siguientes variables:

5.2 Priorización de Servicios 35

Variable Descripción Función

Las vistas de componentes y conectores permiten

Vista de compo- representar las estructuras dinámicas del sistema,
Entrada y salida
nentes y conectores aquellos elementos que son relevantes en tiempo de
ejecución [7]
Estas vistas generalmente representan la disposición
del código y el dominio del sistema, aunque en oca-
Vista de descom-
siones puede descomponerse por atributos de cali- Entrada y salida
posición
dad, implementación de una línea de productos u or-
ganización de los equipos de desarrollo [13]
Una capa es la agrupación de un conjunto de módu-
los que proveen una serie de responsabilidades co-
Vista de capas herentes [13], de tal manera que la capa pueda in- Entrada y salida
teractuar con otras de forma jerárquica y ordenada
[50]
Uno de los componentes más importantes a consi-
Vista de modelo de
derar son los datos que intervienen en los procesos Entrada y salida
datos
de un sistema de información [9].
Es la representación de la vista de usos que per-
Matriz de depen-
miten establecer una relación funcional y el nivel de Entrada
dencias
acoplamiento entre los módulos del sistema [13]
Define los aspectos más importantes del sistema en
Vista de despliegue etapa de validación y transición hacia el entorno ge- Entrada y salida
neral de ejecución del sistema [46]

Tabla 5-1.: Definición y descripción de las variables de entrada y salida del modelo.

5.2. Priorización de Servicios

Uno de los aspectos más importantes en la evolución de una arquitectura monolítica a microser-
vicios es saber identificar qué módulos requieren un menor trabajo para ser evolucionados y
generan un mayor beneficio o poseen mayor urgencia de cambio en el sistema. Teóricamente
el menor trabajo requerido se obtiene a través de las dependencias ascendentes ya que brindan un
valor cuantitativo para obtener los módulos menos acoplados y por ende se pueden asociar a un
menor número de cambios en los módulos restantes. El beneficio o la necesidad de urgencia, el
cual se llamará a partir de este momento como impacto positivo, se obtiene de manera empírica
clasificando en una escala de 1 a 10 el valor que posee cada módulo, utilizando el conocimiento
36 5 Modelo de Evolución Arquitectónica

de los expertos del dominio; donde el valor 1 representa un bajo impacto positivo y 10 un alto
impacto positivo.

Los datos resultantes se deben estructurar y graficar en un modelo de priorización de dos ejes
[36], donde el eje x representa de mayor a menor las dependencias ascendentes que posee el
sistema y el eje y representa el impacto positivo. También es necesario calcular el promedio
de los valores de cada uno de los ejes, para dividir la gráfica en cuadrantes. Los cuadrantes
permiten identificar de manera rápida los mejores candidatos a evolucionar, considerando los
módulos del cuadrante superior derecho como los mejores candidatos, pues suponen una mayor
facilidad y un alto impacto positivo en el sistema. Finalmente se debe analizar y debatir según
criterio de expertos, cuál de los módulos ubicados en el cuadrante superior derecho es el más
indicado para iniciar el proceso de evolución.

Este proceso deberá repetirse siempre que se desee evolucionar un servicio, con los nuevos
valores de la matriz de dependencias ascendentes y el impacto positivo de los módulos, pues al
extraer un servicio del monolito, los valores de referencia cambian haciendo variar el resultado
de la gráfica.

5.3. Patrones de Evolución

El modelo realiza la adaptación de tres patrones que proveen soluciones adecuadas para el ob-
jetivo deseado.

5.3.1. Patrón Aplicación Estranguladora

Debido a que el propósito de la evolución es transformar ISys de una arquitectura monolítica
a microservicios, este patrón es ideal para realizar el proceso de forma incremental y gradual.
Para ello se crea una nueva aplicación con la arquitectura destino, la cual irá implementando las
funcionalidades que se van extrayendo del monolito. La figura 5-2 ilustra las etapas de extracción
de microservicios de un monolito a través del tiempo. En la etapa inicial existe el monolito
como componente principal dentro de la arquitectura, el objetivo del patrón es heterogeneizar
la arquitectura en las etapas intermedias de tal modo que el monolito vaya disminuyendo su
tamaño y los microservicios asumiendo las funcionalidades extraídas. De esta manera se obtiene
una convivencia entre las arquitecturas monolítica y de microservicios en el sistema. En la etapa
final, se tendrá un sistema homogéneo con arquitectura de microservicios.
5.3 Patrones de Evolución 37

Linea del tiempo

Etapa inicial Etapas intermedias Etapa final

Microservicio Microservicio
Microservicio Microservicio
Monolito Monolito Microservicio Monolito
Microservicio Microservicio
Microservicio Microservicio

Figura 5-2.: Estrangulación de un monolito.

El orden de extracción de los servicios del monolito se debe realizar según lo definido en la sec-
ción 5.2. Una vez seleccionado el servicio a evolucionar se debe analizar y diseñar a través de
DDD, identificando los conceptos clave con la ayuda de event storming. Primero se identifican los
eventos del sistema ordenados cronológicamente, luego los comandos y los actores que invo-
can dicha acción. Cuando un comando se ejecuta en un sistema externo, este se debe identificar
junto con el evento resultante de dicha acción. Posteriormente, es necesario identificar los agre-
gados involucrados en cada uno de los eventos. Si no es el primer módulo extraído del sistema,
se debe ensamblar los dominios analizados hasta el momento. Con un solo dominio construido,
se debe identificar los límites de los microservicios agrupando los eventos que poseen agregados
cercanos, los cuales implementarán las funciones del módulo que se estrangula. La relación en-
tre los módulos y los microservicios es plural, pues se representa como uno a uno, uno a muchos
o muchos a uno, por lo tanto no se limita la evolución a que arquitectónicamente un microser-
vicio pueda implementar una o varias de las funcionalidades de uno o diferentes módulos. El
proceso descrito se puede resumir mediante la figura 5-3.

Inicio
Priorización de Identificar los eventos sí
servicios en el del sistema Identificar los ¿El comando se ejecuta Referenciar el
monolito cronológicamente comandos y actores en un sistema externo? sistema externo

no

Ensamblar el nuevo dominio generado no Identificar los

con el dominio resultante de previas ¿Es el primer módulo agregados de los
extracciones extraido? eventos

sí

Identificar los Estrangular el

candidatos a módulo del Fin
microservicios monolito

Figura 5-3.: Proceso de estrangulación de un módulo.

38 5 Modelo de Evolución Arquitectónica

Sin embargo, no solo los microservicios acogen la totalidad del módulo estrangulado, pues el
proceso se hace a través de todas las capas de la arquitectura, lo que quiere decir que también la
interfaz de usuario y los datos del módulo deben evolucionar a la nueva arquitectura. La interfaz
de usuario será acogida por un proyecto frontend, el cual implementa la totalidad de la capa de
presentación del sistema. En relación con los datos, la estructura del almacenamiento puede
cambiar, es por ello que se debe realizar un proceso de extracción, transformación y carga (ETL)
de modo que se engranen los datos al nuevo modelo de microservicios.

5.3.2. Patrón API Gateway

Cuando existen múltiples servicios que deben ser accedidos por el cliente, como es el caso de los
microservicios, conviene centralizar los llamados mediante un componente intermediario que
se encargue de redirigir las solicitudes al servicio correspondiente, de esta manera los clientes
se desinteresan de conocer la ubicación de los múltiples servicios, haciendo necesario que solo
requieran la ubicación del servicio centralizador, conocido como API Gateway. Este patrón en-
capsula la arquitectura de la aplicación y se encarga de funcionalidades como la autenticación,
la autorización y el monitoreo [44].

El modelo de evolución realiza algunas adaptaciones en el patrón API Gateway del sistema. La
primera consideración importante dentro de la arquitectura es la ubicación del monolito y el
frontend. Habitualmente el gateway en una arquitectura redirecciona únicamente hacia la capa
de lógica de negocio, es decir, los microservicios que exponen APIs para los clientes. En el
modelo de evolución se involucra dentro de las responsabilidades del gateway la redirección y
el control de acceso a la capa de presentación, lo cual brinda una serie de ventajas al sistema,
como la navegación fluida para el usuario entre las diferentes tecnologías del sistema, una sesión
con tiempo de actividad similar para ambas arquitecturas (revisar el patrón token de acceso), el
control de acceso y el uso de un solo nombre de subdominio para el acceso a todo el sistema.
La forma en la que el gateway realiza las redirecciones correctamente es a través de las rutas
definidas para cada endpoint. La figura 5-4 representa un esquema de la idea explicada anterior-
mente.
5.3 Patrones de Evolución 39

Cliente

API Gateway

Rutas 1 Rutas 2
Rutas 3 Rutas 4 Rutas 5 Rutas 6

Frontend Microservicio Microservicio Microservicio Microservicio

Monolito

Presentación
Lógica de Negocio

Figura 5-4.: Esquema del API Gateway en el modelo.

Otras de las responsabilidades del gateway dentro del modelo es la de realizar la verificación,
refresco y la adecuación del token de acceso en el sistema.

5.3.3. Patrón Token de Acceso

La seguridad es uno de los factores más importantes dentro de los sistemas de información. Para
ISys no es la excepción y hace parte de los requisitos técnicos a considerar para la evolución.
El escenario plantea tres opciones. La primera es adaptar el modelo viejo de autenticación del
monolito, con las características de un sistema stateful que utiliza cookies de sesión, para que
soporte sesiones stateless, pero el cliente deberá manejar los dos tipos de sesión. La segunda es
modificar todo el módulo de seguridad del sistema heredado para convertirlo en stateless, aunque
se debe poner en consideración que dicho cambio puede reflejar un riesgo para el monolito, pues
altera la estabilidad que posee y requiere un arduo trabajo para llevarse a cabo. La tercera es
mantener dos modelos de seguridad independientes, que cumplan su funcionalidad según el
sistema en uso, pero algunos inconvenientes que posee son los de mantener persistencia entre
los usuarios y sus roles para ambos módulos y tener sincronía en las sesiones activas ya que al
utilizar por un tiempo prolongado una de las dos arquitecturas, la sesión de la otra arquitectura
puede caducar aunque el usuario realmente esté activo en el sistema. El modelo de evolución
implementa la primera opción.

El monolito ISys utiliza un sistema basado en cookies de sesión, de tipo stateful, que mediante
roles de usuarios autoriza o deniega el acceso a los servicios. Sin embargo, dadas las característi-
40 5 Modelo de Evolución Arquitectónica

cas de los microservicios, no es viable mantener una sesión de tipo stateful para todo el sistema.
Es por ello que se requiere adaptar el modelo de autenticación del monolito para que también
genere sesiones de tipo stateless que contengan la información del usuario requerida. Esto es
posible a través de un token de acceso, el cual debe ser generado por el monolito. Para el modelo
se utiliza el estándar JSON Web Token (JWT) como token de acceso por sus características que
permiten la autenticación, la autorización, la identidad federada y sesiones de tipo stateless [38],
asegurando la integridad de la información enviada y permitiendo su validación. El JWT alma-
cena la información del usuario en el cuerpo y especifica información en las cabeceras como
el algoritmo de cifrado usado para la firma. El monolito genera el JWT a partir de la informa-
ción que posee del usuario y lo firma con el algoritmo asíncrono RSA que le permite al sistema
mantener una llave privada de manera segura y otra con acceso público para que los servicios
que desean validar la integridad del token puedan hacerlo. De esta manera, la llave pública es
conocida por todos los servicios del sistema, mientras que la llave privada solo es conocida por
el monolito. Como los servicios serán autónomos en la validación del token, por cuestiones de
seguridad el JWT debe poseer una vigencia corta, de tal manera que constantemente se requiera
la generación de un token nuevo. Para renovar el token, en este modelo no existe token de
refresco como lo sugiere OAuth 2.0, por el contrario se posee la cookie de sesión habitual del
monolito, la cual posee un tiempo de vigencia mayor al del token y le permite al monolito iden-
tificar plenamente el usuario para generar un nuevo token.

Inicio
sí sí
¿La petición tiene ¿El token es válido Fin
token? y está vigente?

no no

Solicitar token al Solicitar token al Generar nuevo token Convenciones

monolito monolito de usuario Proceso del gateway
Proceso del monolito

Generar token con rol no ¿La sesión del monolito sí

público está vigente?

Figura 5-5.: Flujo del manejo de las sesiones del modelo.

Como se mencionó en el patrón anterior, la puerta de enlace para el sistema es el API Gateway
quien, entre sus funciones, valida en primera instancia la autenticidad del token. Si el token está
vigente el gateway permite el flujo normal de la petición por el sistema, de lo contrario realiza la
5.3 Patrones de Evolución 41

petición al monolito quien se encarga de validar si la sesión aún se encuentra activa para generar
un nuevo token, de lo contrario le será concedida una sesión con rol público. El flujo del proceso
está representado por la figura 5-5.

La estrategia de renovación del token del modelo permite mantener vigentes durante tiempos
de actividad similares las dos sesiones, ya que cada vez que se solicita generar un token en el
monolito se reactivan las sesiones. Ambas sesiones viajan a través de cookies y por la misma
cabecera son devueltas del lado del cliente, no obstante, el API Gateway se encarga de convertir
el token en una cabecera HTTP Authorization para enviar el token de esta forma a los microser-
vicios. Cada microservicio debe implementar el control de acceso a sus endpoints basado en
roles.
6. Validación del Modelo
La validación del modelo de evolución se compone de dos actividades principales: la primera es
la aplicación de la estrategia definida en el sistema de información ISys donde se implementan
de forma práctica los patrones que componen el modelo, y la segunda es la medición y control
del desarrollo de la evolución en donde se analiza si las salidas del modelo cumplen con los
requisitos propuestos para este trabajo.

6.1. Aplicación del Modelo

Las entradas del modelo son las vistas y el análisis generado durante el capítulo 4, identificando
el estado inicial del sistema: es un sistema de información con arquitectura monolítica tradi-
cional, construido con un stack tecnológico antiguo.

El primer proceso dentro del modelo es priorizar los servicios que posee el monolito, para lo
cual se hace uso de las dependencias ascendentes del sistema y se halla el impacto positivo
que tendría un módulo al evolucionar hacia microservicios. La tabla 6-1 muestra el resultado
obtenido del sistema de información ISys.

Módulo Dependencias Ascendentes Impacto

Admisión 4011 2
Aplicación 835 8
Calificación 1066 4
Común 7944 6
Configuración 5135 9
Idioma 252 10
Inscripción 1933 7
Intercambio de Información 492 5
Reportes 7 8

Tabla 6-1.: Matriz de dependencias ascendentes con impacto.

Con la información recolectada se grafica el modelo de priorización de dos ejes de Newman, el

cual se representa por la figura 6-1.
6.1 Aplicación del Modelo 43

Priorización de Módulos
12

10
Admisión
Aplicación
8
Calificación
Común
Impacto

6 Configuración
Idioma
Inscripción
4
Intercambio de
Información
2 Reportes

0
9000 8000 7000 6000 5000 4000 3000 2000 1000 0
Número de dependencias

Figura 6-1.: Modelo de priorización de dos ejes.

Se halla el promedio de cada uno de los ejes y se representa con las líneas rojas de la figura 6-1,
dividiendo en cuadrantes la gráfica. De esta manera se puede observar que a pesar de que el
módulo de reportes posee el menor número de dependencias en el sistema, no es el mejor can-
didato para evolucionar debido a su bajo impacto. También se puede observar que el módulo
común posee una alta prioridad, pero por su gran cantidad de dependencias no es un buen can-
didato, ya que extraerlo es sinónimo de bastantes cambios en el sistema. Así que los módulos
candidatos para evolucionar son Idioma, Calificación e Inscripción. Con un enfoque orientado por
el deseo de generar la menor cantidad de cambios en el monolito durante la evolución, se se-
lecciona Idioma como primer módulo para realizar su extracción. Posteriormente, con el análisis
de los expertos y considerando en su generalidad, que el módulo hace referencia a un proceso
del sistema y por ende, el módulo posee similitudes operativas en varios de los subprocesos de
los otros procesos de la dependencia, se reafirma la decisión catalogando el módulo como un
ambiente seguro para experimentar y generar conocimientos técnicos en el equipo de desarrollo.

Luego de priorizar el módulo, se realiza la adaptación del modelo de seguridad del monolito, am-
pliando su capacidad para permitir la generación del JWT con los requisitos técnicos necesarios
y retornando su contenido como se plantea en el modelo. Es evidente que por el algoritmo
asimétrico RSA512 la longitud de la firma aumenta cerca de un 400 % en comparación con el
algoritmo simétrico SHA512. La sesión en caché habitual del monolito tiene una caducidad a
los 20 minutos de inactividad. El tiempo de vigencia definido para el JWT es de 5 minutos y
44 6 Validación del Modelo

gracias a la estrategia de autenticación y autorización entre el gateway y el monolito, diseñada

en el modelo de evolución, el tiempo de caducidad de la sesión por inactividad está en un rango
de entre 15 y 20 minutos, haciendo imperceptible para el usuario la adaptación de seguridad
llevada a cabo.

En la generación del nuevo proyecto se atendie un consejo de [36] de experimentar con tec-
nologías conocidas, por ello se escoge Java como stack tecnológico principal, dado el conoci-
miento que posee el grupo por el stack que se trabaja en el monolito. El framework predilecto es
Spring Cloud por el conjunto de herramientas que posee para los sistemas de microservicios.
Una de las herramientas acogidas es el servidor de configuración central para que los microser-
vicios puedan obtener de él las configuraciones básicas, como controles de acceso, llave RSA
pública para validación del JWT, entre otras. La tecnología seleccionada para la adaptación del
API Gateway es Spring Cloud Gateway por sus ventajas técnicas en el uso de Spring WebFlux que
permite un manejo asincrónico de las peticiones y que adicionalmente permite la flexibilidad téc-
nica para implementar las estrategias descritas por el modelo, logrando la correcta sincronía con
el monolito para el manejo de las sesiones, la conversión del token de una cookie a la cabecera
HTTP Authorization y redirecciones correctas para los servicios de presentación y lógica de ne-
gocio. Para la capa de presentación se crea un nuevo proyecto en Angular, una tecnología Node
JS basado en componentes visuales, que posee grandes beneficios en el manejo de formularios
y sus validaciones.

Para administrar, sincronizar y componer las trazas del sistema, se utiliza Apache Kafka, un
broker de mensajería robusto, de código abierto, funcional y bastante completo que brinda se-
guridad y confianza. Es un proyecto desarrollado en Java que permite adaptar los servicios a las
necesidades del modelo. Para ello se requiere incluir a la arquitectura 3 componentes: el Apache
Kafka naturalmente, Zookeeper que le permite a Kafka coordinar los procesos distribuidos y un
servicio Logger que se encarga de generar la composición de las trazas de los que requieren más
de un microservicio. Toda la información se almacena en una base de datos no relacional debido
al gran volumen de datos que se genera, con el objetivo de que la búsqueda de información se
realice de forma óptima.

Una vez la base del proyecto está completa, se procede con el análisis mediante DDD del módulo
a estrangular. Se implementa por tres sesiones Event Storming, cada una de ellas aproximadamente
de una hora, donde se logra identificar el lenguaje ubicuo, los eventos cronológicamente ordena-
dos, los comandos junto con los usuarios que intervienen en el módulo, los sistemas externos y
los agregados del sistema. Para finalizar, se hallan las relaciones más comunes entre los eventos
y agregados del sistema y con base en las propiedades comunes se identifican los candidatos a
microservicios más apropiados, todo esto guiado por los expertos del sistema.
6.2 Resultados 45

Evento Agregado Comando Sistema Externo Usuario

Figura 6-2.: Imagen del Event Storming realizado al módulo de idioma de ISys.

Para evolucionar todo el módulo de idioma, se requieren cuatro microservicios: configuración

(microservicio encargado de realizar toda la configuración del proceso de idioma), inscripción
(microservicio con función de permitir el registro de los futuros examinandos), citación (este
microservicio se encarga de todo lo relacionado con la citación de los inscritos a la prueba) y
calificación (microservicio relacionado con el carga de notas al sistema, consulta de resultados
y publicación de los mismos). Los microservicios obtenidos concuerdan con la categorización
de los subprocesos del módulo idioma, los cuales son bastante similares a los subprocesos de
los procesos de pregrado y posgrado, afirmando el análisis de los expertos discutido durante la
priorización de los servicios. Para comenzar el proceso de evolución, se decide implementar
calificación como primer microservicio en el sistema, por lo cual se revisan los aspectos técnicos
requeridos para la evolución del submódulo, analizando los endpoints requeridos para el cliente
y vinculado a ello las interacciones que requiere el microservicio con el monolito.

6.2. Resultados
Luego de extraer el submódulo calificación del módulo Idioma del monolito, mediante el modelo
de evolución propuesto en este documento, los resultados se pueden evidenciar a través de las
vistas actualizadas del sistema.
46 6 Validación del Modelo

La descomposición del sistema ahora contempla dos módulos: el monolito y el microservicio de

calificación. El monolito sigue manteniendo su estructura modular, aunque a nivel submodular
se estrangula calificación del módulo idioma y pasa a ser parte de un microservicio. La figura 6-3
representa el resultado obtenido a nivel modular de la evolución.

ISys

Monolito

Admisión Inscripción Reportes Común

Aplicación Calificación Intercambio de información

Configuración Idioma

Calificación

Calificación Idioma

Idioma

Aplicación Idioma Inscripción Idioma Configuración Idioma

Convenciones

Sistema Monolito Microservicio Módulo con procesos de pregrado y

posgrado

Módulo con procesos de pregrado,

Módulo Submódulo posgrado e idioma

Módulo con subprocesos de idioma

Figura 6-3.: Vista de descomposición del sistema con el primer submódulo evolucionado del
módulo de idioma.
6.2 Resultados 47

Mientras el monolito conserva su estructura en capas (figura 4-2), se incorpora la arquitectura

del nuevo microservicio del sistema, donde se evidencia una separación física entre la capa de
presentación y lógica de negocio. La capa de presentación se ve representada por el proyecto
Angular, y el microservicio por un REST API en Spring Boot.

Presentación

Calificación
Idioma

Interfaz de usuario

«permitido usar»

Microservicio

Calificación Idioma

Lógica de negocio Común

Controlador
«permitido
«permitido usar» usar»

Servicio
sedadilitu
oledom

ojop

«permitido usar»
Acceso a datos
«permitido
Repositorio usar»

«permitido usar»

Datos

Base de datos
Datos

Convenciones

Capa Física (Tier)

Capa Lógica (Layer)
Capa Lógica (Layer)
Segmento de capa (Layer Segment)

Figura 6-4.: Vista de capas del submódulo calificación de idioma evolucionado a microservicios.
48 6 Validación del Modelo

A nivel de datos, se diseña e implementa un nuevo modelo de datos que acoge las múltiples es-
tructuras antiguas del sistema y las estructuras vigentes y se combinan como una sola estructura.
La tabla de historico_resultado_inscrito_idioma contiene los resultados de forma estandarizada
de los diferentes procesos antiguos de idioma y conserva una relación con el nombre de la tabla
del modelo antiguo por conservar la trazabilidad del sistema. La tabla resultado_idioma conserva
conserva la estructura del modelo funcional antes de la evolución.

resultado_inscrito_idioma resultado_idioma

tipo_resultado_idioma

historico_resultado_inscrito_idioma tabla_modelo_antiguo

Figura 6-5.: Modelo de datos del submódulo calificación del módulo idioma evolucionado.

Para la migración de datos, se realizó un proceso ETL en Python para transformar y cargar la
información relacionada con el modelo en la nueva base de datos.

La vista de componentes y conectores provee un panorama más completo de la estructura de

unidades funcionales en el sistema. El navegador realiza la petición HTTP al DNS quien resuelve
en un balanceador de cargas de AWS, nombrado isys_lb, quien a su vez redirige la petición HTTP
hacia el gateway. El gateway realiza el proceso de validación de sesiones explicado en el modelo
y resuelve por ruta si el contenido requerido lo provee el monolito isys_app o el frontend. Si el
contenido servido está relacionado con isys_app la conexión se sigue realizando mediante HTTP,
de lo contrario si el contenido está relacionado con el frontend la conexión con el sistema se
convierte en consumo REST desde el frontend hacia los microservicios y el navegador seguirá
consumiendo el componente frontend a través de HTTP. Tanto el isys_app como el frontend pueden
hacer redirección de tráfico HTTP entre ellos con el objetivo de que la usabilidad del usuario no
se vea afectada y por el contrario sea continua. A nivel operativo, isys_app seguirá consumiendo
los componentes externos unal_ldap y sia y proveyendo a través del gateway los servicios REST
que brindaba antes de la evolución. Así mismo, isys_app debe consumir a través del gateway
los nuevos servicios que brinda el microservicio calificacion, pero calificacion si puede consumir
directamente de isys_app, esto sucede por un tema de permisos de acceso entre redes, tema
que será abordado en el análisis de la vista de despliegue. El componente calificacion obtiene
sus propiedades de configuración del config_server. Todos los componentes de la aplicación de
microservicios deberán realizar registros de las trazas del sistema a través de kafka.
6.2 Resultados 49

«Cliente» Convenciones
navegador
Sistema ISys
Sistemas externos

HTTP «Cortafuego»
isys_waf

«Sistema Externo»
psdda
REST «Balanceador de Carga»
isys_lb

REST

«CMS» REST
admisiones REST HTTP
«Aplicación Web»
frontend
REST

«API Gateway»
gateway

HTTP
TCP
HTTP

REST Consumer
REST REST
«Microservicio»
logger

«Sistema Externo» «Microservicio» «Microservicio» «Servicio» Producer

sia calificacion config_server kafka
JDBC «Monolito» REST
isys_app
REST
«Servicio»
JDBC JDBC zookeeper
MongoSinkConnector
JDBC

«Base de Datos» «Base de Datos» «Base de Datos»

«LDAP» LDAP calificacion_db
«Base de Datos» config_server_db log_db
unal_ldap
isys_db

TCP

Figura 6-6.: Vista de componentes y conectores del sistema de información ISys con el primer
submódulo evolucionado.

Para el lanzamiento a producción del sistema resultante del modelo de evolución se requiere
algunos ajustes a la vista de despliegue. Para las bases de datos se adapta el nodo de Servidor de Base
de Datos para que posea también el entorno de ejecución de Mongodb y se reutiliza el entorno de
ejecución de PostgreSQL 9.5 para las nuevas bases de datos que requiere el sistema. Esta decisión
se toma por cuestión de presupuesto. El Servidor de Aplicación mantiene sus características. Tanto
el Servidor de Aplicación como el Servidor de Base de Datos se encuentran en una sub VPC privada.
Se hace la adquisición de un clúster de Kubernetes en AWS con tres nodos de tipo t3.medium,
donde se ejecutarán de forma administrada los nuevos componentes del sistema en sus entornos
de ejecución correspondientes. Al clúster únicamente se puede acceder a través del Gateway por
aspectos de seguridad. El clúster se encuentra dentro de otra sub VPC privada que se encuentra
en una VPC diferente a la del Servidor de Aplicación y Servidor de Base de Datos. El Elastic Load Balancing,
quien se encuentra en una sub VPC pública, permite la conexión de clientes externos al sistema.
La vista descrita anteriormente se puede ver representada por la figura 6-7.
50 6 Validación del Modelo

«Monolito»
isys_app
Convenciones «Base de Datos» «Base de Datos»
AWS - VPC «Artefacto» calificacion_db config_server_db
sitio.war
AWS - Sub VPC pública
AWS - Sub VPC privada «desplegado en» «desplegado en» «desplegado en»

«Nodo» «Nodo»
Servidor de Aplicación Servidor de Base de Datos
{Proveedor = AWS-EC2, {Proveedor = AWS-EC2,
OS = Centos 7, OS = Centos 7,
TipoInstancia = t2.xlarge} TipoInstancia = t2.xlarge}

«Entorno de Ejecución» «Entorno de Ejecución» «Entorno de Ejecución»

Tomcat 7.0 / JRE 1.7 : 8080 PostgreSQL 9.5 : 5432 Mongodb 4.4 : 27017

«desplegado en» «desplegado en»

«API Gateway»
«Cortafuego» gateway «Base de Datos» «Base de Datos»
isys_waf «Balanceador de Carga» «Microservicio» isys_db log_db
isys_lb «Artefacto» frontend
gateway.jar

«desplegado en»
«desplegado en» «desplegado en»
«desplegado en»
«Clúster»
ISys
{Proveedor = AWS-EKS}

«Nodo»
«Servicio en la Nube» «Contenedor» «Contenedor» Nodo 1
Web Application «Servicio en la Nube» Gateway Frontend {Proveedor = AWS-EC2,
Elastic Load Balancing TipoInstancia = t3.medium}
Firewall {Proveedor = AWS-ELB}
{Proveedor = AWS-WAF}
«Entorno de Ejecución» «Entorno de Ejecución»
JRE 14 : 80 NGINX : 80

«Contenedor» «Contenedor»
Servidor de Configuración Calificación
«Nodo»
«desplegado en» «Entorno de Ejecución» «Entorno de Ejecución» Nodo 2
JRE 14 : 80 JRE 14 : 80 {Proveedor = AWS-EC2,
TipoInstancia = t3.medium}

«Contenedor»
Kafka

«Entorno de Ejecución»
JRE 11 : 9092
«Nodo»
«desplegado en» Nodo 3
«desplegado en» «Contenedor» «Contenedor» {Proveedor = AWS-EC2,
Logger Zookeeper TipoInstancia = t3.medium}

«Entorno de Ejecución» «Entorno de Ejecución»

JRE 14 : 80 Apache / JRE 11 : 2181

«desplegado en» «desplegado en»

«Microservicio» «Microservicio» «Microservicio»

config_server logger calificacion
«Servicio» «Servicio»
«Artefacto» kafka «Artefacto» zookeeper «Artefacto»
config_server.jar logger.jar calificacion.jar

Figura 6-7.: Vista de despliegue del sistema de información ISys del primer submódulo evolu-
cionado.
7. Conclusiones y Trabajo Futuro

7.1. Conclusiones
El modelo presentado permite la evolución arquitectónica de monolito a microservicios del sis-
tema de información ISys de manera transitiva, manteniendo la disponibilidad del sistema y de
los datos históricos, conservando la operación habitual de la organización sin afectar los proce-
sos y sin comprometer la seguridad del sistema. El modelo de evolución resultante es flexible, su
implementación de manera iterativa apoya la priorización de servicios y favorece el análisis y el
diálogo de expertos sobre el sistema. En el inicio de cada iteración se requiere volver a generar
la matriz de dependencias del sistema, para que a través del modelo se logre priorizar los ser-
vicios. Las variables de entrada y salida del modelo soportan en gran medida la descripción del
trabajo realizado durante el proceso de evolución arquitectónica. La adaptación de los patrones
en el modelo brinda ventajas técnicas que permiten asumir los retos particulares del sistema en
su proceso de evolución.

7.2. Trabajo Futuro

El trabajo realizado ofrece diferentes oportunidades para trabajos futuros. En principio, se re-
comienda continuar utilizando el modelo de evolución en los siguientes submódulos para com-
pletar la evolución total del módulo de Idioma, y posteriormente continuar con los módulos
adicionales del sistema. También se recomienda realizar una evaluación minuciosa sobre el
rendimiento del API Gateway con el objetivo de verificar la efectividad de la tecnología en esce-
narios de streaming o sockets. Otra gran oportunidad es continuar la implementación del modelo
de cultura organizacional y automatización para integración y pasos a producción, de manera
que se transforme en un proceso DevOps que complemente el modelo de evolución. Por último,
es importante realizar medición de diferentes atributos de calidad que permitan determinar las
ventajas y desventajas técnicas y tecnológicas resultantes de la implementación del modelo.
A. Apéndice: Matriz de dependencia del
sistema de información ISys
 53

Figura A-1.: Matriz de descomposición del monolito ISys

Bibliografía
[1] ABDULLAH, M ; IQBAL, W ; ERRADI, A: Unsupervised learning approach for web applica-
tion auto-decomposition into microservices. In: JOURNAL OF SYSTEMS AND SOFTWARE
151 (2019), S. 243–257. http://dx.doi.org/10.1016/j.jss.2019.02.031. – DOI
10.1016/j.jss.2019.02.031. – ISSN 0164–1212

[2] AL-DEBAGY, O ; MARTINEK, P: A Microservice Decomposition Method Through Using Dis-

tributed Representation of Source Code. In: SCALABLE COMPUTING-PRACTICE AND EXPE-
RIENCE 22 (2021), Nr. 1, S. 39–52. http://dx.doi.org/10.12694/scpe.v22i1.1836.
– DOI 10.12694/scpe.v22i1.1836. – ISSN 1895–1767 J9 – SCALABLE COMPUT–PRAC JI –
Scalable Comput.–Pract. Exp.

[3] AZURE, Microsoft: ¿Qué es IaaS? https://azure.microsoft.com/es-es/overview/

what-is-iaas/

[4] BANDARA, C ; PERERA, I ; TECHNOLOGY, LSEG: Transforming monolithic systems to microser-

vices - An analysis toolkit for legacy code evaluation. In: 20th International Conference on Ad-
vances in ICT for Emerging Regions, ICTer 2020, Institute of Electrical and Electronics Engineers
Inc., 2020. – ISBN 9781728186535 (ISBN), 95–100

[5] BARESI, Luciano ; GARRIGA, Martin ; DE RENZIS, Alan: Microservices identification through
interface analysis. In: Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial
Intelligence and Lecture Notes in Bioinformatics) Bd. 10465 LNCS, 2017. – ISBN 9783319672618,
S. 19–33

[6] BARNES, Jeffrey M. ; GARLAN, David ; SCHMERL, Bradley: Evolution styles: foundations and
models for software architecture evolution. In: Software & Systems Modeling 13 (2014), Nr. 2,
649–678. http://dx.doi.org/10.1007/s10270-012-0301-9. – DOI 10.1007/s10270–
012–0301–9. – ISSN 1619–1374

[7] BASS, Len ; CLEMENTS, Paul ; KAZMAN, Rick: Software Architecture in Practice. Third. Addison-
Wesley Professional, 2012. – ISBN 9780321815736

[8] BRANDOLINI, Alberto: Introducing EventStorming. 2017. – 234 S. http://leanpub.com/

introducing_eventstorming
 55

[9] BROWN, Simon: Software Architecture for Developers: Technical leadership by coding, coaching, col-
laboration, architecture sketching and just enough up front design. Leanpub, 2015. – 275 S. http:
//gen.lib.rus.ec/book/index.php?md5=5EAFB7A3F234817908D3F4C9FA05551B

[10] BUSHONG, Vincent ; ABDELFATTAH, Amr S. ; MARUF, Abdullah A. ; DAS, Dipta ; LEHMAN,
Austin ; JAROSZEWSKI, Eric ; COFFEY, Michael ; CERNY, Tomas ; FRAJTAK, Karel ; TISNOVSKY,
Pavel ; BURES, Miroslav: On Microservice Analysis and Architecture Evolution: A Systematic Mapping
Study

[11] CERVANTES, Humberto ; KAZMAN, Rick: Designing Software Architecture: A Practical Approach.
2016. – 388 S. – ISBN 9780134390789

[12] CHRISTOFOROU, Andreas ; ODYSSEOS, Lambros ; ANDREOU, Andreas S.: Migration of soft-
ware components to microservices: Matching and synthesis. In: SPANOUDAKIS, G (Hrsg.)
; DAMIANI, E (Hrsg.) ; MACIASZEK, L (Hrsg.) ; MACIASZEK, L (Hrsg.): ENASE 2019 - Proceed-
ings of the 14th International Conference on Evaluation of Novel Approaches to Software Engineering,
SciTePress, 2019. – ISBN 9789897583759, 134–146

[13] CLEMENTS, Paul ; BACHMANN, Felix ; BASS, Len ; GARLAN, David ; IVERS, James ; LITTLE, Reed
; MERSON, Paul ; NORD, Robert ; STAFFORD, Judith: Documenting Software Architectures: Views
and Beyond. Second. Addison-Wesley Professional, 2010. – 537 S. https://martinfowler.
com/articles/microservices.html. – ISBN 978–0321552686

[14] DAOUD, M ; MEZOUARI, A E. ; FACI, N ; BENSLIMANE, D ; MAAMAR, Z ; FAZZIKI, A E. ; M.,

Hamlich (Hrsg.) ; L., Bellatreche (Hrsg.) ; A., Mondal (Hrsg.) ; C., Ordonez (Hrsg.): Auto-
matic Microservices Identification from a Set of Business Processes. http://dx.doi.org/10.1007/
978-3-030-45183-7_23. Version: 2020

[15] DNA: Evolución de la Prueba de Admisión a la Universidad Nacional de Colombia. 2013

[16] ESKI, Sinan ; BUZLUCA, Feza: An automatic extraction approach - Transition to microservices
architecture from monolithic application. In: ACM International Conference Proceeding Series Bd.
Part F1477, Association for Computing Machinery, 2018. – ISBN 9781450364225

[17] EVANS, Eric: Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison Wesley,
2003. – 560 S. – ISBN 0321125215

[18] FOWLER, Martin: StranglerFigApplication. https://martinfowler.com/bliki/

StranglerFigApplication.html. Version: 2004

[19] FOWLER, Martin ; RICE, David ; FOEMMEL, Matthew ; HIEATT, Edward ; MEE, Robert ;
STAFFORD, Randy: Patterns of Enterprise Application Architecture. Addison Wesley, 2002. – 560
S. – ISBN 0321127420
56 A Bibliografía

[20] FREEMAN, Eric ; FREEMAN, Elisabeth ; SIERRA, Kathy ; BATES, Bert ; LOUKIDES, Mike (Hrsg.):
Head First Design Patterns. 2013. – ISBN 9780596007126

[21] FREITAS, F ; FERREIRA, A ; CUNHA, J ; MELIUZ: Refactoring Java Monoliths into Executable
Microservice-Based Applications. In: 25th Brazilian Symposium on Programming Languages, SBLP
2021, held in conjunction with the Brazilian Conference on Software: Theory and Practice, CBSoft 2021,
Association for Computing Machinery, 2021. – ISBN 9781450390620 (ISBN), 100–107

[22] FRITZSCH, J ; BOGNER, J ; ZIMMERMANN, A ; WAGNER, S ; B., Meyer (Hrsg.) ; B., Meyer (Hrsg.) ;
M., Mazzara (Hrsg.) ; J.-M., Bruel (Hrsg.): From monolith to microservices: A classification of refac-
toring approaches. http://dx.doi.org/10.1007/978-3-030-06019-0_10. Version: 2019

[23] INTERNATIONAL ORGANIZATION OF STANDARDIZATION: Systems and software engineering —

Architecture description, ISO/IEC/IEEE 42010. (2011), S. 37

[24] KALSKE, Miika ; MÄKITALO, Niko ; MIKKONEN, Tommi: Challenges When Moving from
Monolith to Microservice Architecture. Version: feb 2018. http://dx.doi.org/10.
1007/978-3-319-74433-9_3. 2018. – DOI 10.1007/978–3–319–74433–9_3. – ISBN 978–
3–319–74432–2, S. 32–47

[25] KAMIMURA, Manabu ; YANO, Keisuke ; HATANO, Tomomi ; MATSUO, Akihiko: Extracting
Candidates of Microservices from Monolithic Application Code. In: Proceedings - Asia-Pacific
Software Engineering Conference, APSEC Bd. 2018-Decem, IEEE Computer Society, 2018. – ISBN
9781728119700, 571–580

[26] KAPLUNOVICH, A: ToLambda - Automatic path to serverless architectures. In: 3rd IEEE/ACM
International Workshop on Refactoring, IWOR 2019, Institute of Electrical and Electronics Engi-
neers Inc., 2019. – ISBN 9781728122700 (ISBN), 1–8

[27] KURYAZOV, Dilshodbek ; JABBOROV, Dilshod ; KHUJAMURATOV, Bekmurod: Towards De-

composing Monolithic Applications into Microservices. In: 14th IEEE International Conference
on Application of Information and Communication Technologies, AICT 2020 - Proceedings, Institute of
Electrical and Electronics Engineers Inc., 2020. – ISBN 9781728173856

[28] LAPUZ, N ; CLARKE, P ; ABGAZ, Y ; M., Yilmaz (Hrsg.) ; P., Clarke (Hrsg.) ; R., Messnarz (Hrsg.) ;
M., Reiner (Hrsg.): Digital Transformation and the Role of Dynamic Tooling in Extracting Microservices
from Existing Software Systems. http://dx.doi.org/10.1007/978-3-030-85521-5_20.
Version: 2021

[29] LEWIS, James ; FOWLER, Martin: Microservices. https://martinfowler.com/articles/

microservices.html. Version: 2014

[30] LI, S S. ; ZHANG, H ; JIA, Z J. ; LI, Z ; ZHANG, C ; LI, J Q. ; GAO, Q Y. ; GE, J D. ; SHAN, Z H.:
A dataflow-driven approach to identifying microservices from monolithic applications. In:
 57

JOURNAL OF SYSTEMS AND SOFTWARE 157 (2019). http://dx.doi.org/10.1016/j.jss.

2019.07.008. – DOI 10.1016/j.jss.2019.07.008. – ISSN 0164–1212

[31] MAISTO, Salvatore A. ; DI MARTINO, Beniamino ; NACCHIA, Stefania: From Monolith to

Cloud Architecture Using Semi-automated Microservices Modernization. Version: 2020.
http://dx.doi.org/10.1007/978-3-030-33509-0_60. In: Lecture Notes in Networks and
Systems Bd. 96. 2020. – DOI 10.1007/978–3–030–33509–0_60. – ISSN 23673389, S. 638–647

[32] MALLIDI, R K. ; SHARMA, M ; SINGH, J: Legacy Digital Transformation: TCO and ROI Analysis.
In: International Journal of Electrical and Computer Engineering Systems 12 (2021), Nr. 3, 163–170.
http://dx.doi.org/10.32985/IJECES.12.3.5. – DOI 10.32985/IJECES.12.3.5. – ISSN
18476996 (ISSN)

[33] MENS, T: Introduction and roadmap: History and challenges of software evolution. In:
Software Evolution (2008), 1–11. http://dx.doi.org/10.1007/978-3-540-76440-3_1. –
DOI 10.1007/978–3–540–76440–3_1. – ISSN 9783540764397 (ISBN)

[34] MINISTERIO DE EDUCACIÓN NACIONAL DE COLOMBIA: Información Estadística. https://

snies.mineducacion.gov.co/portal/. Version: 2021

[35] NEWMAN, Sam ; LOUKIDES, Mike (Hrsg.) ; MACDONALD, Brian (Hrsg.): Building Microservices.
O’Reilly Media, Inc., 2015. – 250 S. – ISBN 9781491950357

[36] NEWMAN, Sam: Monolith to Microservices. O’Reilly Media, Inc., 2019. – 221 S. – ISBN
9781492047834

[37] ORACLE: What’s New in JDK 8. https://www.oracle.com/java/technologies/javase/

8-whats-new.html

[38] PEYROTT, Sebastian: The JWT Handbook. 2018 https://auth0.com/resources/ebooks/

jwt-handbook

[39] POLÁK, Marek ; HOLUBOVÁ, Irena: Information system evolution management - A complex
evaluation. In: RYSAVY, O (Hrsg.) ; VRANIC, V (Hrsg.): ACM International Conference Proceeding
Series Bd. Part F1305, Association for Computing Machinery, 2017. – ISBN 9781450348430

[40] PONCE, Francisco ; MARQUEZ, Gaston ; ASTUDILLO, Hernan: Migrating from monolithic
architecture to microservices: A Rapid Review. In: Proceedings - International Conference of the
Chilean Computer Science Society, SCCC Bd. 2019-Novem, 2019. – ISBN 9781728156132

[41] REN, Zhongshan ; WANG, Wei ; WU, Guoquan ; GAO, Chushu ; CHEN, Wei ; WEI, Jun ; HUANG,
Tao: Migrating web applications from monolithic structure to microservices architecture.
In: ACM International Conference Proceeding Series, Association for Computing Machinery, sep
2018. – ISBN 9781450365901
58 A Bibliografía

[42] RICHARDSON, Chris: Monolithic Architecture pattern. https://microservices.io/

patterns/monolithic.html. Version: 2014

[43] RICHARDSON, Chris: Decompose by subdomain. https://microservices.io/patterns/

decomposition/decompose-by-subdomain.html. Version: 2017

[44] RICHARDSON, Chris ; MICHAELS, Marina (Hrsg.) ; MENNERICH, Christian (Hrsg.) ; DRAGOSAVL-
JEVIÇ, Aleksandar (Hrsg.) ; WEIDERT, Lori (Hrsg.) ; COLLINS, Corbin (Hrsg.) ; BRENER, Alyson
(Hrsg.) ; MILES, Andy (Hrsg.) ; DALINNIK, Dennis (Hrsg.) ; TUDOR, Marija (Hrsg.): Microservices
Patterns. First Edit. Shelter Island : Manning Publications Co, 2019. – ISBN 9781617294549

[45] RICHARDSON, Chris ; SMITH, Floyd: Microservices - From Design to Deployment. In: Nginx
(2016), S. 80

[46] ROZANSKI, Nick ; WOODS, Eoin: Software systems architecture: working with stakeholders using
viewpoints and perspectives. Second. 2012. – 49–5717–49–5717 S. http://dx.doi.org/
10.5860/choice.49-5717. http://dx.doi.org/10.5860/choice.49-5717. – ISBN
9780321718334

[47] SANTIS, Sandro D. ; FLOREZ, Luis ; NGUYEN, Duy V. ; ROSA, Eduardo: Evolve the Monolith to
Microservices with Java and Node. In: IBM Redbooks (2016), 125. http://www.redbooks.
ibm.com/redbooks/pdfs/sg248358.pdf. ISBN 0783442119

[48] SANTOS, N ; RITO SILVA, A: A complexity metric for microservices architecture migration.
In: 17th IEEE International Conference on Software Architecture, ICSA 2020, Institute of Electrical
and Electronics Engineers Inc., 2020. – ISBN 9781728146591 (ISBN), 169–178

[49] SELMADJI, A ; SERIAI, A ; BOUZIANE, H L. ; MAHAMANE, R O. ; ZARAGOZA, P ; DONY, C: From

Monolithic Architecture Style to Microservice one Based on a Semi-Automatic Approach.
In: 2020 IEEE International Conference on Software Architecture (ICSA), 2020. – ISBN VO –, S.
157–168

[50] TAYLOR, Richard ; MEDVIDOVIC, Nenad ; DASHOFY, Eric: Software Architecture: Foundations,
Theory, and Practice. Wiley, 2008. – ISBN 9780470167748

[51] UNAL: Misión y Visión de la Universidad Nacional de Colombia. https://unal.edu.co/

la-universidad/mision-y-vision.html

[52] VERNON, Vaughn: Implementing Domain-Driven Design. Addison-Wesley Professional, 2013. –

656 S. – ISBN 9780321834577

[53] ZARAGOZA, P ; SERIAI, A.-D. ; SERIAI, A ; BOUZIANE, H.-L. ; SHATNAWI, A ; DERRAS, M ;

INSTITUTE FOR SYSTEMS AND TECHNOLOGIES OF INFORMATION, Control ; (INSTICC), Commu-
nication: Refactoring monolithic object-oriented source code to materialize microservice-
 59

oriented architecture. In: H.-G., Fill (Hrsg.) ; M, van S. (Hrsg.) ; MACIASZEK, L (Hrsg.) ; MACI-
ASZEK, L (Hrsg.): 16th International Conference on Software Technologies, ICSOFT 2021, SciTePress,
2021. – ISBN 9789897585234 (ISBN), 78–89