CD 8386 PDF
CD 8386 PDF
CD 8386 PDF
carlos.arboleda@epn.edu.ec
DECLARACIÓN
Yo, Arboleda Cola Carlos Augusto, declaro bajo juramento que el trabajo aquí descrito es
de mi autoría; que no ha sido previamente presentado para ningún grado o calificación
profesional; y, que he consultado las referencias bibliográficas que se incluyen en este
documento.
___________________________
CERTIFICACIÓN
Certifico que el presente trabajo fue desarrollado por Arboleda Cola Carlos Augusto, bajo
mi supervisión.
____________________________
DIRECTOR DE PROYECTO
iv
CERTIFICACIÓN
Certifico que el presente trabajo fue desarrollado por Arboleda Cola Carlos Augusto, bajo
mi supervisión.
____________________________
CO-DIRECTOR DE PROYECTO
v
AGRADECIMIENTO
El sentimiento más profundo de gratitud que puedo tener es a mis padres y hermanos, por
las enseñanzas y apoyo incondicional que me supieron dar. Así como la paciencia que han
tenido conmigo en los aciertos y desaciertos de mi vida.
Hago una mención especial a Pamela Flores, directora de este proyecto, que, con su
conocimiento, dedicación y apoyo, no he logrado solo culminar este trabajo, sino además
me permitió conocer una persona espectacular a la cual admiro y le deseare siempre el
mejor de los éxitos.
vi
DEDICATORIA
Dedico este trabajo y los proyectos que aún me propongo por culminar a Hugo y Rosario,
mis padres, que han sabido guiarme con su ejemplo para formarme como persona,
impulsarme en cumplir mis sueños, y entender la importancia de valores como la
perseverancia, honestidad y respeto. Así como a Vico y Damián, mis sobrinos, que llegaron
a iluminar nuestras vidas y llenarlas de sonrisas con su existencia.
vii
ÍNDICE DE CONTENIDO
DECLARACIÓN ................................................................................................................... ii
CERTIFICACIÓN ................................................................................................................ iv
AGRADECIMIENTO ............................................................................................................ v
DEDICATORIA ................................................................................................................... vi
INTRODUCCIÓN ................................................................................................................. 1
Etapa de puntuación................................................................................................... 19
Resumen .................................................................................................................... 20
Edge Server................................................................................................................ 28
Logging ……………………………………………………………………………………..29
Dashboards ................................................................................................................ 29
Hardware .................................................................................................................... 30
3.2.4. Validación..................................................................................................... 35
Anexo 2 – Checklist de Susan Fowler en Libro “Production Ready Microservices” .... 102
ÍNDICE DE FIGURAS
Fig. 1: Ejes principales del Proyecto de Titulación .............................................................. 3
Fig. 2: Resumen de contribuciones relevantes sobre microservicios .................................. 4
Fig. 3: Ejemplo Arquitectura Monolítica ............................................................................... 6
Fig. 4: Ejemplo Arquitectura Orientada a Microservicios ..................................................... 8
Fig. 5: Método SACAM [2] ................................................................................................. 12
Fig. 6: Dependencia Stack Tecnológico Monolítico ........................................................... 15
Fig. 7: División de Equipos Arquitectura Monolítica .......................................................... 16
Fig. 8: Despliegue Arquitectura Monolítica [3] ................................................................... 16
Fig. 9: Independencia Stack Tecnológico en Microservicios ............................................. 17
Fig. 10: División de equipos en Microservicios .................................................................. 18
Fig. 11 Despliegue Arquitectura Microservicios [3] ............................................................ 18
Fig. 12: Tipos de Descomposición..................................................................................... 25
Fig. 13: Modelo de cuatro capas de Ecosistema de Microservicios [11] ........................... 26
Fig. 14: Ecosistema y Componentes de microservicios .................................................... 31
Fig. 15: Modelo Conceptual Migración Microservicios ...................................................... 32
Fig. 16: Lineamientos para descomposición en microservicios ......................................... 38
Fig. 17 Scheme for Migration towards Microservices ........................................................ 39
Fig. 18: Diagrama Global de Paquetes Inicial SISLAB [35] ............................................... 43
Fig. 19 Modelo de Dominio Inicial SISLAB [35] ................................................................. 44
Fig. 20: Diagrama de Clases Inicial SISLAB [35] .............................................................. 45
Fig. 21: Diagrama de Paquetes actuales en SISLAB ........................................................ 48
Fig. 22: Clases en Paquete Recurso de SISLAB .............................................................. 49
Fig. 23: Clases en Paquete Conexión de SISLAB ............................................................. 49
Fig. 24: Clases en Paquete Persistencia de SISLAB ........................................................ 50
Fig. 25: Clases en Paquete VO de SISLAB ....................................................................... 51
Fig. 26: Dependencias a clase Conexión en SISLAB ........................................................ 52
Fig. 27: Estructura de Base de Datos SISLAB .................................................................. 55
Fig. 28: Arquitectura por Capas Inicial SISLAB [35] .......................................................... 57
Fig. 29: Arquitectura Física SISLAB .................................................................................. 58
Fig. 30: Relación Capa Negocio y Datos en SISLAB ........................................................ 59
Fig. 31: Modelo de Dominio Actual SISLAB ...................................................................... 60
Fig. 32: Diagrama de Modelo de Dominio Dividido SISLAB .............................................. 61
Fig. 33: Primera Propuesta de Descomposición de BD de SISLAB .................................. 62
Fig. 34: Script para consulta de número y tamaño de registros en SISLAB ...................... 65
Fig. 35: Segunda Propuesta de Descomposición de BD de SISLAB ................................ 70
xi
ÍNDICE DE TABLAS
Tabla 1: Diferencias entre SOA y Microservicios [20] ......................................................... 9
Tabla 2: Prioridad de Atributos de Calidad [24] ................................................................. 13
Tabla 3: Clasificación de criterios SACAM ........................................................................ 14
Tabla 4: Indicadores SACAM ............................................................................................ 19
Tabla 5: Puntuación SACAM ............................................................................................. 20
Tabla 6: Preguntas seleccionadas para Evaluación de Microservicios ............................. 37
Tabla 7: Número de Tablas Padre e Hijas iniciales en SISLAB ........................................ 46
Tabla 8: Entidades en Base de Datos de SISLAB ............................................................. 54
Tabla 9: Funciones del Sistema Actuales SISLAB ............................................................ 60
Tabla 10: Relaciones en Entidades de BD de SISLAB ..................................................... 65
Tabla 11: Número y tamaño de registros en entidades de SISLAB .................................. 67
Tabla 12: Lectura y Escritura Intensiva en Entidades de SISLAB ..................................... 68
Tabla 13: Resumen de Tablas sensibles en SISLAB ........................................................ 69
xiii
RESUMEN
Este proyecto plantea el desarrollo de una propuesta metodológica que permita facilitar la
migración hacia microservicios enfocada en la descomposición de una arquitectura
monolítica tradicional. Para esto se parte de una caracterización de ambas arquitecturas,
seguido de un análisis de los patrones de descomposición existentes, y posteriormente se
realiza la identificación de los componentes de la arquitectura basada en microservicios.
Esto se complementa con la elaboración del primer prototipo “Scheme for Migration
towards Microservices” (SMMicro), que, si bien no existe un proceso mecánico a seguir
para una migración óptima, SMMicro permitirá establecer un punto de referencia al
identificar directrices y lineamientos que faciliten una transición de arquitecturas.
Finalmente, se valida SMMicro sobre un estudio de caso seleccionado de la “Dirección de
Gestión de Información y Procesos” (DGIP) de la Escuela Politécnica Nacional del Ecuador.
ABSTRACT
Software Engineering has sought from the outset the design, construction and maintenance
of computer applications, according to the needs of organizations and technical
requirements given by a consumer. Thus, Microservice Based Architecture is born as an
approach for the improvement of traditional architectures, centered on stability, reliability,
high resilience and easy scaling.
This project proposes the development of a methodological proposal that facilitates the
migration towards micro-services focused on the decomposition of a traditional monolithic
architecture. For this, a characterization of both architectures is followed, followed by an
analysis of the existing decomposition patterns, and later the identification of the
components of the architecture based on microservices. This is complemented by the
development of the first SMMicro prototype (Scheme for Migration towards Microservices),
which, although there is no mechanical process to be followed for optimal migration,
SMMicro will allow establishing a benchmark in identifying guidelines that facilitate a
transition of architectures. Finally, SMMicro is validated on a case study selected from the
“Dirección de Gestión de Información y Procesos” (DGIP) of the National Polytechnic
School of Ecuador.
INTRODUCCIÓN
Este capítulo se centra en el entendimiento general del proyecto, sus limitaciones, explicar
cómo se ha planteado su desarrollo, así como establecer su aporte a la ciencia dentro de
la Ingeniería de Software.
Para comenzar debemos tener en consideración, que una metodología posee como objeto
de investigación el sistema de procedimientos científicos que orientan de forma lógica al
investigador en el hallazgo de los resultados pretendidos [1]. De esta forma en la Ingeniería
de Software existen varias metodologías que han sido probadas y analizadas en diferentes
escenarios para poder ser validadas y aceptadas como tal. Así pues, en este proyecto se
plantea únicamente una propuesta metodológica, enfocada a la migración de arquitecturas
de software en sistemas web.
Por su parte Balalaie [4] además de tratar el tema DevOps se centra en porque utilizar
microservicios y los diferentes componentes que conlleva una arquitectura distribuida. De
una manera más detallada Salah [5] muestra un análisis claro de cómo ha sido la evolución
de este enfoque y los tipos de herramientas que se han venido utilizando, como Remote
Procedure Call (RPC), Simple Object Access Protocol (SOAP), Representational State
Transfer (REST), entre otros. En este contexto, se trata de forma poco detallada la
descomposición de sistemas monolíticos, a diferencia de investigadores como Escobar [6],
Levcovitz [7] o Ahmadvand [8] que definen claramente este aspecto como uno de los más
relevantes dentro de una migración, tratan varias metodologías de descomposición y
algunas problemáticas y limitantes que se pueden encontrar en estudio de casos. Gouigoux
[9] por su parte trata estos temas asociado a su experiencia y lecciones aprendidas en
diferentes sistemas migrados, que resaltan una selección adecuada de granularidad al
descomponer, así como Mosleh [10] enfatiza elegir un nivel adecuado de modularidad.
Otro punto que considerar son los principios que se deben respetar al hablar de una
arquitectura basada en microservicios, como lo son: estabilidad, confiabilidad,
escalabilidad, tolerancia a fallos, preparación para catástrofes, desempeño y monitoreo.
Todos estos tratados por autores como Fowler [11] o Dragoni [12] que analizan el impacto
a futuro que podrá tener un traslado a microservicios y por consiguiente los elementos que
se deben discutir si se desea un exitoso cumplimiento de objetivos. En este camino es de
vital importancia asociar estos principios con los diferentes componentes que estructuran
los microservicios, así pues, Bakshi [13], y Sanchez [14] desglosan algunos elementos
claves como Discovery Server, Configuration Server, Load Balancing, Circuit Breaker,
Edge Server que facilitan la construcción y despliegue de arquitecturas distribuidas.
3
De igual forma, existen seis ejes sobre los cuales se delimita el alcance de este proyecto,
los cuales se los puede apreciar en la Figura 1, tomando en consideración que estos
mismos pilares son aquellos tomados como referencia por los principales autores en los
últimos años, tal como lo muestra la Figura 2.
Este capítulo tiene como objetivo definir conceptos generales y esclarecer dudas referentes
a las arquitecturas de software monolíticas y las basadas en microservicios. Además de
caracterizarlas y realizar una comparativa en el contexto que tendrá el proyecto de
titulación.
Si bien se entiende un servicio como una pieza de funcionalidad del sistema, que busca
optimizar el aplicativo para la máxima utilidad del consumidor, en donde idealmente cada
servicio es diferente ya que se optimiza de forma independiente para los casos de uso de
sus clientes. En este contexto, una aplicación monolítica web significa un aplicativo con
una única base de código, que ofrece una variedad de servicios que utilizan diferentes
interfaces tales como páginas HTML, encapsulados a un mismo repositorio [3], como se
muestra en la Figura 3.
6
Para comprender de mejor manera el motivo por el cual una arquitectura monolítica no
siempre es la mejor opción por tomar, se muestra los siguientes inconvenientes:
RedHat [17] define la Arquitectura de Microservicios como “Un nuevo estilo arquitectónico
para crear servicios de bajo acoplamiento, pero autónomos”, por su parte Martin Fowler
[18] menciona que “El término Arquitectura de Microservicios ha surgido en los últimos años
para describir una forma particular de diseñar aplicaciones de software como suites de
servicios desplegables de forma independiente”.
Con este tipo de arquitectura se busca descomponer un software complejo en pequeñas
aplicaciones independientes comunicándolas con protocolos ligeros, que sean
modificables sin afectar el compartimiento general del sistema [19]. De esta manera se
entiende que es diferente a la arquitectura tradicional en donde se construía una sola
aplicación que lo hacia todo. Teniendo también en cuenta que, como cualquier otra
arquitectura, dependerá el entorno y fines para el cual se utilice. Un ejemplo clásico de un
sistema descompuesto en microservicio se puede apreciar en la Figura 4.
8
Al tratar el tema de microservicios siempre existe una relación con una arquitectura
netamente basada en servicios, sin embargo, los enfoques son diferentes, aunque esto no
quiere decir que el uno sea mejor que otro, todo dependerá cual es el fin de su utilización:
SOA (Service Oriented Architecture) se basa principalmente en una orquestación de sus
servicios, mientras que la arquitectura basada en microservicios se enfocan en una
coreografía de servicios por así decirlo [20]. Sin embargo, los microservicios surgen como
una respuesta de mayor flexibilidad y escalamiento horizontal en cuanto al rendimiento
general de la aplicación se refiere.
SOA se centra en organizaciones en las que existen equipos de desarrollo para back-end,
y por separado equipos de desarrollo para interfaces de usuario, mientras que, en un
enfoque basado en microservicios, un equipo debe implementar todo para facilitar la
comunicación y así acelerar la implementación de las características. En SOA, una nueva
característica puede implicar cambios en numerosos servicios y por lo tanto requieren la
comunicación entre un gran número de equipos, mientras que los microservicios tratan de
9
evitarlo [21]. Si bien a nivel técnico hay puntos comunes como que ambos conceptos se
basan en servicios, incluso la granularidad del servicio puede ser similar. Sin embargo,
desde puntos de vista conceptuales, arquitectónicos y organizacionales ambos enfoques
tienen efectos diferentes. En la Tabla 1 se sintetizan algunas diferencias entre SOA y
Microservicios.
SOA Microservices
Scope Enterprise-wide Architecture for one project
architecture
Flexibility Flexibility by orchestration Flexibility by fast deployment and
rapid, independent development of
Microservices
Organization Services are implemented Service are implemented by teams
by different organizational in the same project
units
Deployment Monolithic deployment of Each Microservice can be deployed
several services individually
UI Portal as universal UI for Service contains UI
all services.
Existe una gran variedad de características por las cuales se puede elegir una arquitectura
basada en microservicios, a continuación, se describe un breve compendio de las razones
principales tratadas en [20] y [21]:
Hay muchos enfoques para evaluar las arquitecturas de software como: basado en la
simulación, basado en escenarios, basado en la experiencia y basado en modelos
matemáticos. Algunos de ellos son [22]: SAAM-Scenario-based software architecture
analysis method; ATAM-Architecture-based Trade off Analysis Method; ALPSM-
Architecture Level Prediction of Software Maintenance; ALMA-Architecture-Level
Modifiability Analysis; SBAR-Scenario Based Architecture Reengineering; SALUTA-
Scenario-based Architecture Level Usability Analysis; SAAMCS-SAAM for Complex
Scenarios; ESAAMI-Extending SAAM by Integration in the Domain; ASAAM-Aspectual
Software Architecture Analysis Method; SACAM-Software Architecture Comparison
Analysis Method.
Dado que nuestro objetivo es lograr un enfoque comparativo entre dos arquitecturas, se
procederá a utilizar los aspectos más relevantes encontrados en SACAM (The Software
Architecture Comparison Analysis Method) elaborado por el Software Engineering Institute
de la Universidad Carnegie Mellon. Este método fue creado para proporcionar una
justificación para un proceso de selección de arquitectura, comparando la aptitud de dos o
más candidatos para un sistema requerido [2].
12
2.3.1. SACAM
Etapa de Preparación
Candidatos comparativos
Objetivos empresariales
Los objetivos empresariales varían acorde al enfoque que posea la empresa, sin embargo,
al tratar con productos de software se los puede generalizar de manera que equilibren el
tiempo, el costo y la calidad con el valor comercial esperado del software producido.
Así pues, Steve Masters [23] de Carnegie Mellon University menciona algunos de los
siguientes objetivos empresariales:
Los objetivos de negocio se utilizan para crear un conjunto de criterios de comparación que
sirven como el criterio para la comparación global. Los criterios se refinan en escenarios
de atributos de calidad [2].
Para definir de mejor manera la priorización de atributos de calidad, utilizaremos la norma
ISO/IEC 9126 y el criterio realizado por Senthilkumar y Arunkumar [24], en donde establece
lo siguiente:
Una vez definida la prioridad para los atributos de calidad, se procede a relacionarlos con
los objetivos empresariales definidos en el paso anterior. Cada objetivo empresarial puede
corresponder a uno a varios atributos de calidad, sin embargo, la prioridad global del criterio
define cual será el valor cualitativo (Alta, Media, Baja) que se utilizará en el resto de la
metodología.
▪ Este enfoque corresponde con la idea de los llamados equipos interfuncionales, tal
como lo proponen los métodos con Scrum. Estos equipos deben abarcar diferentes
funciones para que puedan cubrir un amplio espectro de tareas. Sólo un equipo
diseñado a lo largo de estos principios puede estar a cargo de un componente
desde los requisitos de ingeniería hasta la implementación y operación. La división
en artefactos técnicos y la interfaz entre los artefactos se puede resolver dentro de
los equipos [20]. Aunque en este tipo de arquitectura los cambios se pueden
introducir más rápido que en el monolito de despliegue, produciendo una
gobernanza descentralizada momentánea eficiente, se debe tener en consideración
que si no se realiza una separación adecuada de microservicios no existirá
realmente una independencia.
18
Los tipos de vista seleccionados del paso 3 tienen que ser extraídos y refinados hasta que
ofrezcan un nivel apropiado de detalle para una comparación de arquitectura. Procurar
detectar indicadores que soportan los escenarios de atributos de calidad del paso 2 [2].
Para establecer los indicadores se toma como referencia información adicional sobre la
evolución hacia sistemas basados en microservicios de Salah [5], y la caracterización
realizada previamente en la tercera etapa de SACAM.
Monolítico Microservicios
1 Secuencia de desarrollo multifuncional No Si
6 Gobernanza descentralizada No Si
8 Balanceador de carga Si Si
Etapa de puntuación
Proporciona a cada candidato a la arquitectura una puntuación que indica qué tan bien
soporta los escenarios de atributos de calidad generados en el taller de clasificación de
criterios de la Etapa 2 [2]. Para califica la aptitud de las arquitecturas candidatas se valorar
sobre un peso máximo de 1.5 en caso de ser Buena, 1 en caso de ser Media y 0.5 en caso
de ser baja.
20
Resumen
puede concluir que una arquitectura monolítica no posee dificultades en realizar un aplicativos de
manera eficiente, e inclusive en cuanto a consumo de recursos se refiere, una arquitectura
monolítica no requiere la misma cantidad de componentes que evidencia la arquitectura
distribuida. Así pues, la mejora continua de un sistema es quizás la mayor ventaja en cuanto a
microservicios, junto a la adaptabilidad, puesto que la construcción de cada microservicio se lo
hace de forma independiente y con un equipo de desarrollo que se centra en el requerimiento del
cliente y como se puede emplear inclusive un stack tecnológico diferente para cada servicio.
Dentro del análisis realizado se debe resaltar además las desventajas encontradas para la
utilización de microservicios, entre ellas: un riguroso cuidado al momento de realizar una
descomposición de microservicios, puesto que es el punto de partida de la arquitectura; también
el hecho de que siempre se encontrara resistencia al cambio dentro de una empresa cuando el
equipo de desarrollo probablemente ya se encuentra adecuado a una metodología de trabajo;
además lo que implica un uso mayor de recursos y costos a comparación de los monolitos.
Aunque hoy en día este último punto es relativamente fácil manejar gracias al uso de servicios
cloud como IaaS (Infrastructure as a service), PaaS (Platform as a service) y SaaS (Software as
a service) que detallaremos más adelante.
A pesar de que las ventajas e inconvenientes de los microservicios y monolitos fueron tomadas
en cuenta para mostrar una caracterización objetiva, aún quedan consecuencias conocidas y
desconocidas dependientes de casa sistema, puesto que como ya se mencionó, el tamaño del
aplicativo influye considerablemente en cuanto a microservicios se refiere, por ende, es
importante analizar antes si la aplicación se beneficiara de escalabilidad, integridad, resiliencia y
agilidad. Finalmente utilizando el método SACAM se recomienda analizar la factibilidad de definir
directrices de migración de una arquitectura monolítica hacia microservicios, puesto que si
representa una mejora significativa para empresas dedicadas a la producción de software.
22
En este capítulo se desarrolla la propuesta metodológica que definirá las directrices para
una migración de una arquitectura monolítica hacia una arquitectura basada en
microservicios, tomando como referencia el análisis teórico realizado en los capítulos
previos. Así como la construcción del esquema SMMicro, ya que si bien no existe un
proceso mecánico a seguir, hay varias estrategias definidas por autores que facilitan la
extracción de lineamientos de transición que trataremos a lo largo de este capítulo.
Es importante recalcar que, desde el punto de vista del sistema de microservicio, el diseño
organizacional incluye la estructura, dirección de autoridad, granularidad y composición de
los equipos. Un buen diseño de sistemas de microservicio abarca las implicaciones de
cambiar estas propiedades organizacionales y que el buen diseño de servicios es un
subproducto del buen diseño organizacional. Así como también es importante analizar
cómo se encuentra estructurado el aplicativo previo a una migración.
Por ende, es crucial examinar la estructura organizativa y el estado actual del sistema a
migrar, para aplicar una estrategia de transformación se puede:
Existen varios pasos para fragmentar un monolito, entre estos, identificar los componentes
que pueden ser utilizados como servicios independientes, así pues, autores como Eberhard
Wolff [20] y Chris Richardson [26] recomiendan seleccionar las principales funcionalidades
generales del monolito y posteriormente dividir esas funcionalidades en pequeños
componentes independientes. Sin embargo, existen otras propuestas como
descomposición por contexto, madurez o acceso a datos, cada una de ellas empleadas de
tal forma que respete que los microservicios deben ser tan simples como sea posible, o
bien, la empresa se arriesga a reemplazar un software monolítico con varios monolitos más
pequeños.
Netflix [28] adopta un enfoque basado en funcionalidad para dividir su sistema en servicios.
De hecho, se podría argumentar que están siguiendo este enfoque hasta el extremo, en el
sentido de que tienen una guía para tener una sola funcionalidad por servicio, como
recomendar una lista de películas basadas en un usuario dado y sus calificaciones para
diferentes películas.
24
Analizar el nivel de madurez es otra manera para identificar secciones candidatas de una
aplicación a convertirse en microservicios. Por lo general al hablar de organización
empresarial tenemos que tener en cuenta que ya debieron existir varias iteraciones de
definición de objetivos y especificaciones para el aplicativo. Las partes cuyos
requerimientos funcionales y no funcionales son estables y bien comprendidos deben ser
agrupadas, mientras que las cosas que son menos estables y sujetas a iteraciones más y
más rápidas podrían pasar a otros servicios separados versionados. En otras palabras, se
podría considerar agrupar servicios que se encuentren estables a lo largo del tiempo como
por ejemplo registro de usuarios, y separar aquellos que no varían con el tiempo y la
demanda de usuario como el servicio de compra y venta.
Para poder analizar este tipo de descomposición debemos tener en cuenta la eficacia de
la persistencia y las entidades sensibles por número de relaciones que posean. Carneiro
[27] recomienda analizar el acceso de almacenamiento esperado para las distintas
funcionalidades y clasificarlas de acuerdo con "lectura intensiva", "escritura intensiva" y
"lectura y escritura balanceadas". La ventaja de este enfoque es que los esquemas de un
servicio, las consultas de acceso o incluso el motor de almacén de datos (ya sea un
relacional, no relacional, almacén de valores clave, basado en documentos u otro método)
se pueden optimizar para el acceso de lectura o escritura intensiva en aislamiento. De
forma similar, se pueden aplicar diferentes estrategias de almacenamiento en caché de
datos para cada uno de los servicios. Por ejemplo, uno podría decidir no introducir la
complejidad relacionada con el almacenamiento en caché si un servicio se ocupa
principalmente de datos de escritura intensiva.
Por último, una descomposición por contexto puede ser una solución si encontramos
servicios que no se definan igual en diferentes contextos, esto dependerá del nivel de
complejidad del sistema analizado, puesto que, en un sistema con funcionalidades bien
definidas para cada actor, siempre contendrá atributos que varíen su función para
determinados escenarios.
En el artículo del experto en microservicios Martin Fowler “Bounded Context” [29] explica
que, por ejemplo, un cliente puede ser polisémico, es decir un cliente puede significar dos
cosas diferentes en diferentes contextos. Los atributos y la lógica de negocio asociados
25
con un cliente diferirán grandemente para la unidad de la atención al cliente que para el
contexto del negocio de la unidad de ventas. Tal separación podría ir tan lejos que los
únicos datos compartidos entre tales servicios centrados en el cliente serían un
identificador de cliente único. Ambos servicios de cliente específicos de dominio también
podrían hacer referencia cruzada a un tercer servicio de cliente de nivel inferior para datos
compartidos como la dirección del cliente u otra información de contacto.
Tipos de Descomposición
Por Funcionalidad Por Madurez Por Acceso a Datos Por Contexto
Se analiza: Se analiza: Se analiza: Se analiza:
piezas individuales de Partes cuyos La eficacia de la Servicios que no se
funcionalidad que en requerimientos persistencia y las definan igual en
general proporciona el funcionales y no entidades sensibles diferentes contextos.
aplicativo. funcionales son por número de • Complejidad
• Complejidad estables y aquellos relaciones que estimada:
estimada: que no lo son. posean.
Alta
Media • Complejidad • Complejidad
estimada: estimada:
Media Alta
Una propuesta que abarca estos aspectos para microservicios puede dividirse en cuatro
capas, aunque los límites de cada una no siempre están claramente definidos: algunos
elementos de la infraestructura tocarán cada parte del modelo. Las tres capas inferiores
son las capas de infraestructura: en la parte inferior del modelo encontramos la capa de
hardware y, además, la capa de comunicación, seguida por la plataforma de aplicación y
finalmente la cuarta capa (superior) es donde viven todos los microservicios individuales.
Layer 4: Microservices
Layer 2: Communication
Layer 1: Hardware
La gestión de estos servidores también debe ser considerado, para esto el sistema
operativo que se elija dependerá del enfoque que posea la empresa en cuanto a la
utilización de distribuciones libres o propietarias. Una vez instalado el sistema operativo,
se debe usar una herramienta de administración de configuración para instalar todas las
aplicaciones y establecer todas las alineaciones necesarias. Posteriormente los hosts
necesitan una adecuada supervisión y registro de nivel de host para que si existe falla de
disco, fallo de red o si la utilización de CPU sobrepasa el límite, puedan ser fácilmente
diagnosticado, mitigado, y resuelto. Todas estas consideraciones son administradas de
mejor manera con tecnologías IaaS, PaaS y SaaS que detallaremos más adelante.
Esta capa se centra en la comunicación de microservicios, e interactúa con las otras capas
del ecosistema. Utilizando un protocolo específico, un microservicio enviará datos en un
formato estandarizado a través de la red a otro microservicio que puede estar en un punto
final del API de microservicios, o lo enviará a un intermediario de mensajes que se
asegurará de que los datos se envíen al otro punto dado.
Así pues, en una arquitectura monolítica, el tráfico solo necesita ser enviado a una
aplicación y distribuido apropiadamente a los servidores que alojan la aplicación. En la
arquitectura de microservicios, el tráfico debe ser encaminado apropiadamente a un gran
número de aplicaciones diferentes, y luego distribuirse apropiadamente a los servidores
que alojan cada microservicio específico, y para esto se utilizan tecnologías como service
discovery, service registry, y load balancing.
27
Encargada de todos los servicios y herramientas internas que son independientes de los
microservicios, mismos que deben construirse de tal forma que los equipos de desarrollo
no tengan inconvenientes en diseñar, construir o mantener nada que no sea sus propios
microservicios. Una plataforma de aplicaciones puede incluir una herramienta interna de
autoservicio para desarrolladores, un proceso de desarrollo estandarizado, un sistema de
compilación y despliegue automatizado y centralizado, pruebas automatizadas, una
solución de despliegue estandarizada y centralizada, un registro centralizado, y monitoreo
a nivel de microservicio.
Una vez analizados los diferentes aspectos del ecosistema de microservicios, podemos
realizar un estudio más detallado al especificar cada componente por separado para
después encajarlos en cada capa y así obtener un esquema más claro de cómo luciría una
arquitectura basada en microservicios.
Discovery Server
El denominado servidor de registro o descubrimiento sirve para delimitar y proveer los end-
points de los servicios a ser consumidos. A su vez obtiene instancias disponibles de cada
microservicio y permite que cada microservicio sepa lo que otro ejecuta en caso de tener
algún tipo de relación de comunicación [11]. Cabe considerar que también se puede incluir
un componenete Configuration Server que centralice y provea remotamente la
configuración de cada microservicio, de manera simple es la encargada de realizar cambios
en nuestras API sin la necesidad de volver a implementar código. Esto además hace
28
Load Balancing
Circuit Breaker
De esta manera se lo puede configurar para actuar de una forma distinta dependiendo el
escenario en el cual se haya producido el daño. Cabe recalcar que también es aplicable
cuando se producen errores al consumir servicios externos al sistema, ya que el aplicativo
no debería seguir gastando recursos al mandar peticiones continuas, si no tiene respuesta
en un determinado tiempo o número de intentos.
Edge Server
Message Broker
Sin embargo, este componente posee mayor relevancia en cuanto a manejo de datos se
refiere, dado que cada microservicio maneja su propia base de datos relacional o no
relaciones, siempre existirá una dependencia entre ellos y por ende un message broker se
encarga de gestionar sus transacciones y guarda un log de eventos que nos permita
después poder garantizar la transaccionalidad en caso de existir un fallo. Dada su estrecha
relación entre la capa de comunicación y aplicación, se lo puede aplicar en cual quiera de
ellas.
Logging
En este punto tratamos la monitorización, y como uno de sus ejes principales un registro
de logs de toda la información relevante, lo que permite a los desarrolladores comprender
el estado del microservicio con un histórico de información para poder prevenir problemas
futuros [11]. Una vez que ha madurado nuestro registro de logs se puede proponer un
componente adicional que es el uso de Alertas para notificar cuando un microservicio está
teniendo una conducta diferente a la normal. Por lo general este tipo de alertas se las
programa en base a un registro del comportamiento que ha tenido un servicio ya sea en
estado normal, peligroso o crítico, y que posteriormente nos permitirá establecer reglas de
comportamiento para identificar daños mínimos que puedan evolucionar en catástrofes.
Dashboards
Se centran en monitorear que todas las funcionalidades del sistema se encuentren activas
y sus respectivas conexiones con la base de datos [11]. De esta forma reflejan con
precisión la salud de los microservicios, se acoplan fácilmente con los componentes como
Service Discovery o Message Broker, y están construidos de tal manera que cualquier
persona podría verlos y entender el estado del software sin dificultad.
30
Hardware
Una vez aclarado esto, es notorio que los aspectos más relevantes a analizar en una
migración son el uso de IaaS y PaaS, puesto que envuelven nuestros microservicios de tal
manera que se aíslan en contenedores o máquinas virtuales para lograr una mejor
estabilidad y resistencia. No obstante, esto dependerá de la cantidad de recursos que
utilice el sistema a ser migrado, y también de los recursos disponibles por la empresa, ya
que se puede contratar los servicios en la nube o utilizar servidores físicos propios.
31
3.2.1. Comprensión
Una vez analizado los diferentes estudios y teorías sobre microservicios, se plantea como
primera etapa la comprensión de las actividades a realizar por parte de los directivos de la
empresa propietaria del sistema. Se debe informar y motivar a la institución sobre cual es
cronograma por seguir, objetivos, alcance y los beneficios que obtendrán al incluir una
transformación no solo del aplicativo, sino además de posibles cambios en la cultura
organizacional que se posee para desarrollar software.
Es así como, como herramientas de ayuda para facilitar la apertura al cambio dentro de la
empresa se plantean:
Cabe enfatizar que no se puede realizar una migración adecuada si no se tiene la apertura
al cambio por parte de los directivos.
actual que nos permita comprender como evoluciono el sistema y las implicaciones de
realizar una transformación a microservicios sobre ese aplicativo.
▪ Metodología de desarrollo.
▪ Requerimientos Funcionales.
▪ Requerimientos No Funcionales.
▪ Diagrama Global de Paquetes.
▪ Clases pertenecientes a paquetes del sistema.
▪ Esquema Lógico de Base de Datos.
▪ Esquema Físico de Base de Datos.
▪ Modelo de Dominio Inicial.
▪ Patrón de Diseño.
▪ Arquitectura Física.
3.2.2. Descomposición
Para una descomposición optima como ya lo menciona [26], es primordial definir las
operaciones que realiza el sistema, así pues, nos podemos valer de las siguientes
herramientas para facilitar su estudio:
En este punto se debe enfatizar que esta propuesta se limita a sistemas mínimamente
construidos con modelo por capas de software, ya que una vez identificadas las funciones
34
3.2.3. Asociación
Una vez realizada la descomposición final, se debe acoplar cada elemento dentro las capas
del ecosistema de microservicios. Esto se lo plantea como la tercera etapa de nuestro
modelo, para lo cual se debe utilizar tanto los componentes como herramientas que se
adapten mejor a nuestro estudio de caso.
Se debe tener en cuenta que, si bien todas las capas del ecosistema son necesarias, los
componentes que cada una utilice dependerán del aplicativo analizado, es decir, en base
a los recursos de la empresa y los diferentes escenarios en el cual se plantea poner en
producción el sistema, se deberán seleccionar varios, todos, o inclusive más componentes
de los que se han planteado a lo largo de esta propuesta: Dashboards, Logging, Alertas,
Discovery Server, Load Balancing, Config Server, Circuit Breaker, Message Broker, IaaS,
PaaS, SaaS.
35
Así pues, se parte de la capa cuatro en donde se construye nuestro núcleo del ecosistema
con los microservicios previamente descompuestos, tanto en la capa de negocio, como en
la capa de datos. Continuamos con la capa tres en donde analizamos todo lo que es
plataforma de aplicación, para en conjunto con los componentes necesarios que se puedan
adaptar a la capa cuatro, se forme lo referente a comunicación y finalmente despliegue de
las funcionalidades que se planteó para cada microservicio. Para todo esto nos valemos
consecutivamente de:
Cabe recalcar que no se ha hecho referencia a la capa de vista, puesto que desde 2016
ya existen nuevas tendencias y estudios en evolución referente a lo que es “Micro
Frontends”, que se enfoca netamente en trabajar la interfaz de usuario de forma
descompuesta, varias referencias interesantes e información más detallada se lo puede
encontrar en el artículo de Michael Geers [33]. Aunque estos conceptos quedan fuera del
alcance de este proyecto ya que aún se encuentran en desarrollo, y únicamente se ha
tomado referencias ya comprobadas en diferentes casos de estudio y por diferentes
autores, en donde poseemos una mayor confiabilidad de nuestras fuentes bibliográficas,
ya sea de libros o artículos.
3.2.4. Validación
En este punto cabe recalcar la diferencia entre Validación y Verificación, acorde a la IEEE
tenemos [34]:
Por ende, se entiende que la verificación es aplicable a cada una de las fases en las cuales
se desarrolló un producto, es decir, si se construyó el producto de forma correcta. Mientras
que la validación evalúa que el producto final cumpla con los requerimientos, es decir, si
se construyó el producto correcto.
Para determinar si hemos construido el producto deseado, en nuestro caso el esquema del
sistema migrado a microservicios, lo dividiremos en dos secciones, la primera comprende
lo estrictamente relacionado con el modelo propuesto, y la segunda parte en donde ya se
encuentre en producción el sistema. Teniendo en cuenta que ésta segunda parte se
plantea para trabajos futuros.
Una manera de validar los aspectos de microservicios los plantea Susan Fowler [11] en
donde recopila todos los aspectos de un ecosistema de microservicios en varias preguntas,
sin embargo, se debe seleccionar las más adecuadas puesto que existen preguntas que
corresponden a un sistema ya en producción o a temas estrictamente relacionados con su
libro como testeo de resiliencia o documentación de microservicios, que además incluye
un checklist aplicable cuando el aplicativo ya se encuentre en etapas de prueba, este se lo
puede observar en el Anexo 2.
Por nuestra parte para esta etapa de SMMicro se seleccionaron preguntas que puedan ser
aplicadas a varios estudios de caso, acorde a toda la información recolectada a lo largo del
trabajo, en conjunto con algunas de las propuestas por Susan Fowler estrictamente a lo
que se refiere con estabilidad, confiabilidad, escalabilidad y rendimiento. El cuestionario
completo se lo puede observar en el Anexo 3.
Estabilidad y Confiabilidad
1 ¿El microservicio tiene un repositorio central donde se almacena todo el código?
2 ¿El ecosistema de microservicio tiene una línea de implementación estandarizada?
3 ¿Qué acceso tiene el entorno de transición a los servicios de producción?
4 ¿Las implementaciones para la producción se hacen todas al mismo tiempo, o se
implementan incrementalmente?
5 ¿Qué son estas dependencias de microservicios?
6 ¿Cómo este microservicio mitiga los fallos de dependencia?
7 ¿Hay copias de seguridad, alternativas, retrocesos o almacenamiento en caché defensivo
para cada dependencia?
8 ¿Son confiables los controles de salud al microservicio?
37
9 ¿Hay interruptores en su lugar para evitar que el tráfico de producción se envíe a hosts y
microservicios poco saludables?
10 ¿Existen procedimientos para depreciar los puntos finales API de microservicios?
Escalabilidad y Rendimiento
1 ¿Cuáles son los cuellos de botella de recursos de este microservicio?
2 ¿Escalarán las dependencias con el crecimiento esperado de estos microservicios?
3 ¿Se puede enrutar automáticamente el tráfico a otros centros de datos en caso de falla?
4 ¿El microservicio está escrito en un lenguaje de programación que permitirá que el servicio
sea escalable y funcional?
5 ¿Hay alguna escalabilidad o limitaciones de rendimiento en la forma en que el microservicio
maneja las solicitudes?
6 ¿Existe alguna escalabilidad o limitaciones de rendimiento en la forma en que el
microservicio procesa las tareas?
7 ¿Este microservicio maneja los datos de una manera escalable y eficiente?
8 ¿Qué tipo de datos necesita cada microservicio para almacenar?
9 ¿Cuál es el esquema necesario para sus datos?
10 ¿Este microservicio necesita un mayor rendimiento de lectura o escritura?
11 ¿Es de lectura pesada, de escritura pesada o ambas cosas?
12 ¿La base de datos de este servicio se escala horizontal o verticalmente? ¿Es replicado o
particionado?
13 ¿Es este microservicio usando un dedicado una base de datos compartida?
14 ¿El microservicio tiene un único punto de falla?
15 ¿Se han identificado todos los escenarios de falla y posibles catástrofes del microservicio?
16 ¿Cuáles son las fallas comunes en el ecosistema de los microservicios?
17 ¿Cuáles son los escenarios de falla de la capa de hardware que pueden afectar este
microservicio?
18 ¿Qué fallas en la capa de comunicación y en la capa de aplicación pueden afectar este
microservicio?
19 ¿Cómo impactan las fallas y las interrupciones de este microservicio en el negocio?
20 ¿Hay niveles de falla bien definidos?
En este punto se definen lineamientos dentro del modelo conceptual previamente definido. La imagen a continuación presentada es
únicamente referencial, para poder observar a detalle todos los campos, se encuentra el Anexo 4 en donde se puede visualizar de mejor
manera cada sección.
recomienda analizar las funcionalidades del aplicativo en producción para apreciar de mejor manera los posibles
capa de negocio del aplicativo. de la lógica de negocio del sistema. Diagrama de Base de Datos Descompuesto.
Extraer la primera propuesta de descomposición de la base de datos. microservicios.
Modelo de Entidades de Base de Datos.
Definir el número de relaciones padre e hija de tablas. Tabla con entidades sensibles por número de relaciones. Es primordial buscar que cada microservicio aisle al máximo sus datos, sin embargo, al tratarse de una base de
Aplicación de patrones de descomposición en la Abstraer una fragmentación adecuada manteniendo Definir el tamaño y número de registros de las tablas. Querys sobre la Base de Datos. datos relacional se deben realizar varios posibles escenarios de descomposición puesto que existen varios factores
capa de datos del aplicativo. de la lógica de negocio del sistema. Clasificar las tablas en base a lectura y escritura intensiva. Cuadro comparativo de lectura y escritura de entidades. que influiran en el rendimiento final del sistema, estre ellas aquellas entidades estrechamente relacionadas que
Abstraer la segunda propuesta de descomposición de la Base de Datos. Diagrama de Base de Datos Descompuesto. deberán mantener cierta relación de dependencia.
Comparar la independencia entre propuestas de capa de negocio con descomposición en Base de Pruebas en ambiente de producción del sistema. Para seleccionar una descomposición final, se debe analizar las posibles variaciones que tendra la Base de Datos en
Identificación de una propuesta de descomposición Obtener un diagrama de descomposición que se Datos. Matriz con llamadas de la capa de persistencia a Base de Datos. conjunto con la capa de negocio, sus llamadas, relaciones e instancias. Utilizar un ambiente de producción
final. acople con la lógica de negocio del sistema.
Elegir mejor propuesta de descomposición entre capa de negocio y BD. Diagrama final de descomposición. facilitará la visualización de todos estos factores de comportamiento.
Analizar el acoplamiento y configuración de los microservicios previamente definidos. Lista de componentes factibles para integrar en sistema analizado. Esta sección se centra exclusivamente en los microservicios y cualquier cosa delimitada a ellos, teniendo en cuenta
Selección de componentes para acoplamiento en Estructurar los microservicios que en sí facilitaran el
Diagramar el sistema en base a la capa cuatro del ecosistema y los componentes necesarios para el Diagrama de componentes en capa cuatro de ecosistema de microservicios. que sus configuraciones se pueden almacenar en el mismo repositorio del microservicio para ser accedidas por las
capa cuatro de ecosistema de microservicios. núcleo de la nueva arquitectura.
aplicativo analizado. Diagrama de sistema en base a ecosistema de Microservicios. herramientas de las capas inferiores, evitando cambios directos sobre las mismas.
Analizar el acoplamiento de los componentes para la plataforma de aplicación de microservicios. Lista de componentes factibles para integrar en sistema analizado. Encargada de todos los servicios y herramientas internas que son independientes de los microservicios, mismos que
Selección de componentes para acoplamiento en Integrar los componentes que faciliten la
Diagramar el sistema en base a la capa cuatro del ecosistema y los componentes necesarios para el Diagrama de componentes en capa tres de ecosistema de microservicios. deben construirse de tal forma que los equipos de desarrollo no tengan inconvenientes en diseñar, construir o
Asociación
posee un sistema de microservicios. como un sistema basado en microservicios. Analizar las estrategias para un despliegue de microservicios. Compendio de estrategias utilizables durante la migración. microservicios se puede caer en fallos o errores graves ya estando en producción.
Documento con Preguntas sobre Estabilidad y Confiabilidad.
Evaluación de cumplir las características básicas de Comprobar que el sistema analizado puede cumplir Un sistema distribuido posee características únicas que deben ser validadas, una vez evaluado esto se procede a
Analizar el sistema como un ecosistema de microservicios Documento con Preguntas sobre Escalabilidad y Rendimiento.
un sistema distribuido. los requisitos de un ecosistema de microservicios. evaluarlo como microservicios.
Checklist de validación de componentes de sistema distribuido.
SMMicro se lo construye con el fin de encapsular todos los aspectos antes vistos, de una forma fácil de comprender y utilizar. La imagen a
continuación presentada es únicamente referencial, para poder observar a detalle todos los campos, se encuentra el Anexo 5 en donde se
puede visualizar de mejor manera cada sección.
Una vez obtenidos los sistemas candidatos evaluamos la lógica de negocio que mejor se
adapte a un enfoque sobre microservicios. Cabe recalcar que, dado el alcance de este
proyecto, no se puede aplicar el esquema sobre un aplicativo de gran magnitud, sin
embargo, se lo aplicara sobre un sistema que cumpla los requerimientos mínimos para
poder identificar el cambio de arquitectura.
ANÁLISIS DE CAMBIO
Para realizar el análisis de cambio se mantuvo reuniones iniciales con la Ing. Geovanna
Saltos, coordinadora del área, en donde se informó las implicaciones del proyecto con la
planificación del trabajo a realizarse. De igual forma dentro del área de desarrollo se
mantuvo una constante comunicación con la Ing. Sara Cruz para facilitar la limitación del
alcance, sin embargo, estas reuniones no tuvieron la necesidad de ser documentadas
debido a que la información no era para personas externas a la Escuela Politécnica
Nacional y que además se firmó un acta de confidencialidad que permitía el libre acceso a
todo el Sistema de Gestión y Administración de Laboratorios.
ESTUDIO DE ANTECEDENTES
a) Información General
Metodología de Desarrollo
En esta fase se documentará a lo largo del desarrollo del proyecto los documentos del
diseño (Requerimiento, BDD), Documentos de la Aplicación y Documentos para el Usuario
final (manuales de usuario)
42
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, el cual consiste
en reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteración se
establecen en función de la evaluación de las iteraciones precedentes.
El ciclo de vida que se desarrolla por cada iteración se maneja bajo dos disciplinas:
Disciplina de Desarrollo
Disciplina de Soporte
b) Módulos
1. Gestión de Inventarios,
2. Facturación,
3. Gestión de Usuarios,
4. Gestión de Servicios,
5. Ordenes de Trabajo,
43
6. Información Gerencial
7. Reportes
1. Gestión de Inventarios
2. Gestión de Servicios
3. Ordenes de Trabajo
4. Reportes
c) Base De Datos
informeresultados 1 1
proforma 2 1
ordentrabajo 2 2
metodo 2 0
laboratorio 2 1
detalleproforma 0 3
detalleorden 0 4
personal 2 3
cargospersonal 1 0
tipopersonal 1 0
servicio 3 2
factura 3 1
detallefactura 0 2
muestra 2 1
detallemuestra 0 1
tiposervicio 1 0
usuario 0 1
El sistema desde su creación ha tenido varios cambios es toda su estructura física y lógica.
La mayoría de los cuales no han sido documentados, por lo cual se procede a obtener la
siguiente información a través de un análisis del SISLAB actualizado al año 2017.
a) Información General
Metodología de Desarrollo
Si bien la metodología para el desarrollo del sistema fue RUP, en la actualidad dentro de
la DGIP, se utiliza únicamente SCRUM como marco de referencia para desarrollo con
metodología ágil, así como para correcciones y actualización de sistemas de software.
b) Módulos
1. Gestión de Inventarios
2. Gestión de Servicios
3. Ordenes de Trabajo
4. Reportes
5. Facturación
Paquetes
• Paquete VO: Contiene los métodos que serán utilizados por cada clase para los
módulos dentro del SISLAB.
48
• Paquete Recurso: Posee recursos adicionales que serán de utilidad para todo
el sistema, como por ejemplo encriptación de información.
Diagrama de Clases
Se procede a analizar las clases de los paquetes con relaciones más importantes con la
lógica de negocio del sistema, por ende, se realiza un completo barrido de la información
que posee el aplicativo en producción.
Además, se considera que el objetivo de este análisis es identificar posibles entidades que
posteriormente serán agrupadas o separas acorde a como se adapte la arquitectura
basada en microservicios.
Se debe considerar que tanto la gráfica de las clases del paquete persistencia, como el del
paquete VO se muestran únicamente sus nombres para una mejor visualización. Sin
embargo, el análisis se lo realizo con sus atributos y métodos como en los demás paquetes
del sistema.
c) Base De Datos
La base de datos ha sufrido varios cambios considerables, entre los cuales destaca la
creación de tablas adicionales y aislamiento de tablas ya existentes en otros esquemas. El
número inicial de tablas en la creación del sistema fue de 26, a la fecha se encontraron un
total de 44 tablas en el primer esquema analizado, puesto que ahora existe un esquema
separado destinado exclusivamente a facturación. A continuación, se muestra un resumen
del esquema “bddcorpepn.Laboratorios” con los respectivos comentarios realizados por los
creadores de las tablas.
53
bodega_usuario 0 1
caracteristica 2 0
caracteristica_usuario 0 1
compra 1 2
concentracion 1 0
control_existencia_metodo 0 4
detalle 0 10
detalle_proforma 0 4
detallemetodo 1 3
detalleorden 1 3
estadoproducto 1 0
grado 1 0
hidratacion 1 0
laboratorio_usuario 0 0
metodo 4 1
movimientosinventario 0 3
muestra 2 1
norma 0 0
orden_trabajo 3 1
ordeninventario 1 4
laboratorio y personal –
unidad.
posgiro 1 0
presentacion 1 0
producto 1 2
proforma 2 1
proveedor 1 1
pureza 0 0
riesgoespecifico 1 0
saldo_existencia 0 0
servicio 3 2
tipo_justificacion 2 0
tipordeninv 1 0
tiposervicio 1 0
unidadmedida 3 0
d) Arquitectura
Plataforma multicapa
La arquitectura física impuesta por el modelo de seguridad de red define un modelo de tres
capas. Dicho modelo presenta además una distribución de componentes software,
distinguiéndose tres niveles lógicos con funciones distintas: uno para los servicios de
usuario, otro para los servicios de la lógica de negocio (la lógica principal de la aplicación),
y otro nivel para los servicios de datos.
Todos estos componentes se distribuyen entonces en capas lógicas, pero con disposición
en forma de servicios para aquellas funciones de interés general como una Arquitectura
Orientada a Servicios (SOA)
El sistema fue desarrollado como una aplicación web que permite a los usuarios gestionar
la información de los laboratorios de la EPN. Es por esta razón que el proyecto fue
desarrollado en base al estándar empresarial J2EE, utilizando la arquitectura de tres capas:
Capa del Cliente, Capa Intermedia la cual contiene la presentación y la lógica del negocio
y la Capa de Datos.
Patrón de diseño
Se utiliza el patrón MVC (Modelo Vista Controlador) durante el desarrollo, para separar la
lógica de control, la lógica de negocio y la lógica de presentación, a continuación, se
presentan algunas consideraciones dentro de SISLAB.
▪ Controlador: Contiene los eventos del sistema, aquellos que invocan la lógica
del negocio conforme a las operaciones que el usuario realice en el sistema. El
gestor que reacciona ante los eventos procesa sus acciones y comunica el
modelo y la vista es JSF (Java Server Faces). El controlador se ve reflejado en
las reglas de navegación contenidas en el fichero faces-config.xml y el servlet
faces definido en el fichero web.xml.
Arquitectura Física
Finalmente, la arquitectura física del ambiente de producción del sistema ha sido levantada
de la siguiente manera:
Como esquema adicional tenemos que SISLAB está constituido como lo muestra la Figura
30, en donde se evidencia su estructura de monolito únicamente haciendo referencia a dos
esquemas de base de datos, BD1 en donde engloba la mayor cantidad de entidades de
SISLAB y BD2 en lo referente a Facturación que si se lo maneja independientemente para
todos los sistemas de la DGIP.
Cabe acotar que existe un alto grado de dependencia entre las bases de datos debido a
que varias entidades del esquema de facturación en BD2 utilizan datos de las entidades
de BD1, y simultáneamente algunas tablas dentro del BD1 utilizan datos que se obtienes
de la segunda base de datos.
60
Modelo de Dominio
Sin embargo, se debe analizar si esta propuesta es la óptima o existe una mejor opción
viable para descomponer.
Además, se debe aclarar que existe dos contenedores adicionales, uno que posee todas
las tablas referentes a facturación y el otro que posee las tablas que no tienen relaciones
directas con las demás tablas, como lo son: detalle; saldo_existencia; y
control_existencia_metodo.
Para analizar la primera propuesta obtenida y realizar una nueva descomposición por base
de datos partimos definiendo las tablas sensibles dentro del sistema, para esto observamos
el número de relaciones que poseen y de esta manera tenemos:
bodega 2 1 3
bodega_usuario 0 1 1
caracteristica 2 0 2
caracteristica_usuario 0 1 1
cargospersonal 1 0 1
cliente 2 1 3
compra 1 2 3
concentracion 1 0 1
control_existencia_metodo 0 0 0
detalle 0 0 0
detalle_proforma 0 3 3
detallemetodo 0 1 1
detalleorden 1 3 4
estadoproducto 1 0 1
64
existencias 1 11 12
grado 1 0 1
hidratacion 1 0 1
laboratorio 1 1 2
laboratorio_usuario 0 1 1
metodo 2 1 3
movimientosinventario 0 2 2
muestra 1 1 2
norma 0 0 0
orden_trabajo 1 1 2
ordeninventario 1 3 4
personal 1 2 3
posgiro 1 0 1
presentacion 1 0 1
producto 1 2 3
proforma 1 1 2
proveedor 1 1 2
pureza 0 0 0
riesgoespecifico 1 0 1
saldo_existencia 0 0 0
servicio 2 2 4
tipo_justificacion 0 0 0
tipocliente 1 0 1
tipopersonal 1 0 1
tipoproducto 1 0 1
tipoproveedor 1 0 1
65
tipordeninv 1 0 1
tiposervicio 1 0 1
unidad 5 0 5
unidadmedida 1 0 1
De acuerdo con esto tendríamos como principales tablas sensibles por número de
relaciones: detalleorden; existencias; ordeninventario; servicio y unidad.
Para poder realizar un análisis de las tablas sensibles por acceso a datos, analizamos el
contexto en el cual se desarrollan las actividades del SISLAB. Es decir, las funciones que
cumple el aplicativo en los diferentes escenarios que se ejecuta. Como complemento se
realiza además un análisis del número y tamaño de los registros existentes en la base de
datos, desde su puesta en producción, a través del siguiente script:
bodega X -
bodega_usuario - -
caracteristica X -
característica_usuario - -
cargospersonal X -
cliente X X
compra X X
concentracion X X
control_existencia_metodo X X
detalle X X
detalle_proforma X X
detallemetodo X X
detalleorden X X
estadoproducto X -
existencias X X
grado X -
hidratacion X -
laboratorio X -
68
laboratorio_usuario - -
metodo X X
movimientos_inventario X X
muestra X X
norma - -
orden_trabajo X X
ordeninventario X X
personal X X
posgiro X -
presentacion X -
producto X X
proforma X X
proveedor X -
pureza - -
riesgoespecifico X -
saldo_existencia X X
servicio X X
tipo_justificacion - -
tipocliente - -
tipopersonal - -
tipoproducto - -
tipoproveedor - -
tipordeninv - -
tiposervicio - -
unidad X -
unidadmedida X -
Con esta información podemos establecer una segunda propuesta de descomposición para la base de datos, en donde se resalta una
distribución adecuada de las tablas sensibles previamente identificadas:
Al analizar las dos propuestas se debe verificar que exista la máxima independencia
posible entre cada componente, por ende, el número de llamadas de las clases a las tablas
de la base de datos debe ser mayor entre el microservicio del modelo de dominio con su
base de datos correspondiente (Por ejemplo, MS1 con BD1) y menor con las bases de los
otros microservicios (Por ejemplo, MS1 con BD2).
Para poder constatar esto, se estructura una matriz con las llamadas de la capa de
persistencia del sistema y las dos propuestas de descomposición de la base de datos:
Propuesta1 Propuesta2
BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5
Cliente 2 0 0 0 0 2 0 0 0 0
DetalleProforma 5 0 0 0 0 2 3 0 0 0
DetalleProformaAux 3 0 0 0 1 0 3 0 0 1
DetalleTransferenciaInterna 5 0 0 2 0 2 3 0 2 0
DetalleMetodo 2 0 3 0 1 0 2 3 0 1
Metodo 4 0 1 0 0 0 5 0 0 0
MS1
Laboratorio 2 0 1 0 0 0 3 0 0 0
LaboratorioUsuario 2 1 1 0 0 1 3 0 0 0
Proforma 3 1 1 0 0 4 1 0 0 0
Servicio 3 0 1 0 0 0 4 0 0 0
TipoCliente 1 0 0 0 0 1 0 0 0 0
TipoServicio 1 0 0 0 0 0 1 0 0 0
33 2 8 2 2 47 12 28 3 2 2 47
BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5
CargosPersonal 1 0 0 0 0 1 0 0 0 0
DetalleMuestra 3 0 0 0 0 2 1 0 0 0
DetalleOrden 0 1 0 0 0 1 0 0 0 0
DetalleOrdenTrabajo 3 4 0 0 0 3 4 0 0 0
DetalleOrdenTrabajoAux 3 2 0 2 1 1 4 0 2 1
MS2 GenericoDetalleOrden_Compra 0 1 0 0 0 1 0 0 0 0
Muestra 2 1 0 2 0 0 3 0 2 0
OrdenTrabajo 2 2 1 1 0 4 1 0 1 0
Personal 1 3 0 0 0 3 1 0 0 0
TipoPersonal 0 1 0 0 0 1 0 0 0 0
TrabajoAnalista 2 4 0 0 0 3 3 0 0 0
17 19 1 5 1 43 20 17 0 5 1 43
BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5
Bodega 0 0 2 0 0 0 0 2 0 0
BodegaUsuario 0 0 3 0 0 0 1 2 0 0
Caracteristica 0 0 1 0 0 0 0 1 0 0
Compra 0 0 3 0 0 0 3 0 0 0
Concentracion 0 0 1 0 0 0 0 1 0 0
EstadoProducto 0 0 1 0 0 0 0 1 0 0
Existencias 0 0 2 0 0 0 0 2 0 0
Grado 0 0 1 0 0 0 0 1 0 0
Hidratacion 0 0 1 0 0 0 0 1 0 0
MovInventario 2 0 2 0 1 0 2 2 0 1
OrdenInventario 0 0 4 0 0 0 2 2 0 0
MS3
Posgiro 0 0 1 0 0 0 0 1 0 0
Presentacion 0 0 1 0 0 0 0 1 0 0
Producto 0 0 2 0 0 0 0 2 0 0
Proveedor 0 0 2 0 0 0 2 0 0 0
RiesgoEspecifico 0 0 1 0 0 0 0 1 0 0
TipoJustificacionMov 0 0 1 0 0 0 0 1 0 0
TipoOrdenInventario 0 0 1 0 0 0 1 0 0 0
TipoProducto 0 0 1 0 0 0 0 1 0 0
TipoProveedor 0 0 1 0 0 0 1 0 0 0
Unidad 0 0 1 0 0 0 1 0 0 0
UnidadMedida 0 0 1 0 0 0 0 1 0 0
2 0 34 0 1 37 0 13 23 0 1 37
BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5
Factura 3 0 1 2 0 1 3 0 2 0
Detalleactura 2 0 0 2 1 0 2 0 2 1
EstadoFactura 0 0 0 1 0 0 0 0 1 0
MS4
MovimientoCaja 0 0 0 1 0 0 0 0 1 0
Pagos 0 0 0 1 0 0 0 0 1 0
TransferenciaInterna 3 0 0 2 0 0 3 0 2 0
8 0 1 9 1 19 1 8 0 9 1 19
Se puede observar con color rojo cuando el número de relaciones entre las clases y la base
de datos excede de la norma establecida. Es así como se realiza una modificación entre
las tablas de la base uno con la base dos para corregir y obtener un modelo más cercano
a lo deseado, teniendo como resultado una tercera propuesta:
Propuesta3
BD1 BD2 BD3 BD4 BD5
Cliente 2 0 0 0 0
DetalleProforma 4 1 0 0 0
DetalleProformaAux 2 1 0 0 1
DetalleTransferenciaInterna 4 1 0 2 0
DetalleMetodo 2 0 3 0 1
Metodo 2 3 0 0 0
MS1
Laboratorio 1 2 0 0 0
LaboratorioUsuario 1 3 0 0 0
Proforma 3 2 0 0 0
Servicio 2 2 0 0 0
TipoCliente 1 0 0 0 0
TipoServicio 1 0 0 0 0
25 15 3 2 2 47
Como mayor referencia se puede observar que el número de relaciones entre “MSn” con
“BDn” es más alto con el tercer modelo de descomposición.
73
20
0
BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5
20
0
BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5
20
0
BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5 BD1 BD2 BD3 BD4 BD5
Así tenemos la descomposición final de la base de datos que se adapta a nuestra descomposición del modelo de dominio:
En esta etapa como lo define la metodología, buscamos asociar los esquemas propuestos
en la etapa de descomposición y acoplarlos dentro del ecosistema previamente definido.
Para poder analizar de mejor manera elaboramos un diagrama que contenga ya el esquema en conjunto con todos los componentes internos
que posera cada microservicio, además de las relaciones que posee entre ellos. Como se observa en la Figura 44, ahora tenemos nuestra
primera estructura en la capa cuatro del ecosistema de microservicios.
En esta capa procedemos a ubicar los componentes que se consideren necesario para el
buen funcionamiento y despliegue de microservicios.
Como se menciona en SMMicro esta capa propuesta inicialmente por Susan Fowler nos
permite establecer tres componentes claves para la monitorización: Logging, Dashboards,
Alertas.
Actualmente ya existen varias soluciones cloud y plataformas como Amazon AWS [37],
Istio [38], Microprofile [39] o Microsoft Azure [40], sin embargo, la mayoría de herramienta
para ese sistema especifico las vamos a administrar en base al stack tecnológico que nos
ofrece Spring Cloud [41] y Netflix OSS [42], ya que ambas se enfocan en la administración
de servicios e incluyen una gama de herramientas que necesitamos para nuestro
ecosistema de microservicios, así pues:
▪ Partiendo de los contenedores se propone utilizar Docker [43], ya que nos permite
manejar de forma adecuada nuestros microservicios, así como los recursos que
consumen e inclusive se los puede utilizar para realizar pruebas en ambientes de
desarrollo, prueba y despliegue.
▪ En cuanto a la base de datos, por el momento ya que los datos no requieren ningún
tratamiento especial, podemos seguir utilizando Postgres SQL y dependiendo la
disponibilidad en los servidores físicos, realizar una división en diferentes bases de
datos o manejar una misma base, pero con varios esquemas para cumplir con la
independencia entre microservicios. En este punto para el componente Message
Broker que se planteó, se sugiere la utilización de Eventuate [44] para el manejo de
eventos y estados que los almacena en el log de transacciones que nos garantiza
una transaccionalidad robusta.
▪ Ya que el sistema originalmente fue desarrollado en Java, Spring Cloud Config nos
facilita un acoplamiento para soporte de servidor y cliente que a su vez utiliza GIT
para almacenamiento de código, y por ende también tiene mecanismos de
encriptación y desencriptación en la comunicación.
▪ De la misma manera Spring Cloud Netflix provee integración con Netflix OSS y así
nos permite utilizar Zuul como el proxi que necesitamos como servidor perimetral,
que a su vez se acopla con Ribbon como balanceador de carga, Eureka como
servidor de descubrimiento e Hystrix como cortador de circuitos e inclusive como
dashboard puesto que esta herramienta como el servidor de registro o
descubrimiento nos facilitan mecanismos de monitorización en tiempo real del
estado de nuestros microservicios.
83
Para poder culminar con la última etapa del modelo procedemos a validar que la
arquitectura creada cumple con algunos de los requerimientos que poseen los
microservicios. Para esto procedemos a comprobar con las preguntas establecidas en lo
que respecta a estabilidad, confiabilidad, escalabilidad y rendimiento. Sin embargo, como
menciona la propuesta metodológica se deben determinar algunas consideraciones
previas:
Patrones
Existen varios factores a tomar en cuenta para un despliegue del diagrama construido
durante toda esta fase de planificación, como primer punto tenemos que analizar la forma
en que realizaremos los cambios sobre el monolito para cumplir con nuestros objetivos.
Para esto utilizaremos el patrón de estrangulación de aplicaciones “Strangler Application
Pattern” propuesto inicialmente por Martin Fowler en 2014, pero desarrollado a profundidad
por Kyle G. Brown [50] en donde consta de tres etapas:
▪ Transformar: Consiste en crear un sitio paralelo con un servicio que cumpla una
funcionalidad en específico. En nuestro caso los cuatro microservicios planteados.
▪ Coexistir: Consiste en redirigir del sitio existente al nuevo para que la funcionalidad
se implemente de forma incremental.
▪ Eliminar: Consiste en ir eliminando la funcionalidad anterior del monolito (o
simplemente deje de mantenerla) a medida que el tráfico se redirecciona a los
nuevos microservicios.
Estrategias
Por último, todo esto debe ser englobado en una la línea de desarrollo o implementación
estandarizada, para esto Susan Fowler [11] propone primero aplicarlo en un entorno de
transición; en segundo lugar, si pasa la fase de etapas, implementarlo en un entorno de
producción pequeño, donde se incluya un porcentaje menor del tráfico en producción; y
87
tercero, si pasa esta fase, podemos extenderlo lentamente a los servidores de producción
hasta que se haya desplegado en cada host.
Preguntas de Evaluación
Estabilidad y Confiabilidad
Si, en nuestro caso se utiliza la monitorización de RedHat, en conjunto con los servidores
de balanceo de carga y administración de aplicaciones mostrado en la figura 29.
¿Hay interruptores en su lugar para evitar que el tráfico de producción se envíe a hosts y
microservicios poco saludables?
Si, las interrupciones serán administradas por Openshift o en su defecto por Hystrix y su
monitor de rendimiento que ayudarán para la prevención a futuro.
¿Existen procedimientos para depreciar los puntos finales API de microservicios?
Si, se recomienda utilizar los procedimientos embebidos que posee Spring en su
servidor de descubrimiento o registro.
Escalabilidad y Rendimiento
Entre los resultados más relevantes tenemos la descomposición final de la base de datos
del Sistema de Gestión y Administración de Laboratorios mostrado en la figura 42, acorde
a las metodologías de descomposición previamente fundamentadas. De esta manera se
busca que cada esquema de la base de datos responda a su correspondiente microservicio
de la lógica de negocio, por ende, tenemos una reducción de dependencia con lo visto en
la estructura de base de datos inicial de SISLAB. Como punto en consideración, la
dependencia existente, únicamente se la puede reducir, mas no mitigar, puesto que, al
tratarse de una migración, existen factores de la lógica de negocio que se mantendrán
constantes a lo largo del tiempo, y la única forma de cambiarlos es volviendo a rediseñar
desde cero el sistema, lo cual no es lo que se busca, ni tampoco realizar cambios que
afecten la experiencia de funcionalidad del cliente consumidor.
91
En cuanto al esquema obtenido de la relación entre la capa de negocio y los datos mostrado
en la figura 43, nos permite evidenciar la tentativa de descomposición que agrupa de mejor
manera las clases existentes en SISLAB, considerando que ahora se pretende utilizar tres
bases de datos para los tres microservicios propuestos, una base de datos para lo referente
al módulo de facturación que actualmente ya se lo maneja por separado, y finalmente una
quinta base de datos que gestione las tablas aisladas a las funciones del aplicativo, así
como futuras implementaciones que necesite expandir el número de entidades o tablas
que actualmente posee SISLAB. Este grafico se contrasta claramente con el de la figura
30, en donde teníamos un monolito que gestiona todo con una capa de persistencia robusta
y poco adaptable para un escalamiento del software, además que existían también clases
obsoletas que fueron creadas para funcionalidades distintas a las que ahora son requeridas
por otros usuarios externos a los laboratorios que desean utilizar el software.
Entre los resultados también se muestra que existe un aumento considerable del número
de componentes para que pueda ser gestionado de manera adecuada SISLAB, sin
embargo como se comentó en un inicio, SMMicro no es una receta que se pueda seguir
para obtener el mejor resultado con microservicios, la propuesta metodológica es
únicamente un punto de referencia que ayude a los encargados de la migración a tener
una visión más adecuada de cuáles son los cambio a realizar, es así que muchos
componentes serán o no necesarios, acorde al aplicativo analizado. Además, al evaluar
nuestro diseño para migración, nos percatamos que si bien se cumple con la mayoría de
preguntas que plantea SMMicro en su cuarta etapa, existen algunas consideraciones que
se pueden ir mejorando con el paso del tiempo y ya la puesta en producción del sistema.
Por ejemplo, aspectos relacionados con seguridad, posibles marcos de trabajo utilizables
o incluso cambios que permitan aumentar el rango del alcance. Por ende, se espera que
posteriormente se logre añadir más condiciones de valor para mejorar nuestra etapa de
evaluación y por ende el esquema en general.
92
Una vez analizados los resultados obtenidos, podemos obtener varias conclusiones
referentes a la migración. Partiremos haciendo mención de que el objetivo general de este
proyecto el cual fue elaborar una propuesta metodológica para la migración de sistemas
web con arquitectura monolítica, hacia una arquitectura basada en microservicios, fue
realizado y plasmado a través de cuatro etapas, cada una con varios lineamientos
propuestos con sus respectivas justificaciones, actividades a realizar, posibles
herramientas que pueden utilizar y las pertinentes consideraciones y recomendaciones. Se
propone, además, poder encapsular la propuesta metodológica de tal manera que sea fácil
de abstraer, mediante un esquema gráfico que se lo denomino Scheme for Migration
towards Microservices (SMMicro).
Una vez comprendido esto, para continuar con el cumplimiento de los objetivos específicos,
en este caso, definir los lineamientos de transición de una arquitectura monolítica a una
descomposición en microservicios, se procedió a delimitar un modelo conceptual
estructurado en: comprensión, descomposición, asociación y validación. Cada una de
estas justificadas acorde al análisis teórico previo. En donde se tiene a la descomposición
como eje principal de los resultados obtenidos, es decir, si la descomposición no sigue un
93
Finalmente, para cumplir con nuestro último objetivo específico tenemos que la validación
sobre un estudio de caso de la DGIP tomo el rumbo y los resultados esperados, aunque
no se pudo identificar el uso total de los componentes propuestos para microservicios,
puesto que SISLAB únicamente fue adaptado al alcance de este proyecto, y aún queda la
etapa de implementación del diseño obtenido para trabajos futuros, en donde
evidentemente se encontraran nuevas observaciones, correcciones y agregaciones a la
primera versión de la propuesta metodológica.
Otra de las conclusiones es que este enfoque no es aplicable en todos los sistemas, de
hecho, es enfocado en sistemas que crecieron y sobrepasaron sus límites definidos
inicialmente, que requieren gran transaccionalidad y resiliencia, pero sobre todo que
posean un monolito con estructura bien definida, ya que sin esto no se puede esperar que
los resultados sean los deseados.
Como última conclusión una arquitectura basada en microservicios nos puede proporcionar
múltiples beneficios, teniendo en cuenta varias complicaciones en su implementación. Por
ende, nuestra propuesta metodológica a través de SMMicro puede llegar a convertirse en
un punto de referencia para facilitar una migración partiendo de un monolito, sin embargo,
debe ser validado en más estudios de caso acorde a contextos similares que se tuvo en la
selección de SISLAB, e ir puliendo las deficiencias que se encuentren en el camino.
Además, es importante que los trabajos futuros no solo se enfoquen en el diseño, sino
también en el despliegue, ya que si bien el diseño es importante, la implementación de
dicho diseño en código es la única que logra descubrir falencias que quizás no fueron
consideradas. Finalmente se recomienda realizar investigación en este campo de la
Ingeniería de Software puesto que se encuentra en evolución, y es necesario una constante
actualización el modelo propuesto.
96
REFERENCIAS BIBLIOGRÁFICAS
ANEXOS
Comprensión y Descomposición
Análisis de la información de las operaciones del Establecer un punto de referencia para la Crear un nuevo esquema que muestre las clases principales del aplicativo.
sistema. descomposición
Describir el comportamiento del sistema en base al Modelo de Dominio.
Dividir la capa de negocio en base al Modelo de Dominio.
Aplicación de patrones de descomposición en la Abstraer una fragmentación adecuada manteniendo Definir la primera propuesta de descomposición de capa de negocio.
Descomposición
Asociación y Validación
posee un sistema de microservicios. como un sistema basado en microservicios. Analizar las estrategias para un despliegue de microservicios.
Evaluación de cumplir las características básicas de Comprobar que el sistema analizado puede cumplir
Analizar el sistema como un ecosistema de microservicios
un sistema distribuido. los requisitos de un ecosistema de microservicios.