Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Esta obra est´a bajo una Licencia
Creative Commons Atribuci´on
4.0 Internacional.
Tipo de art´ıculo: Art´ıculos originales
Tem´atica: Tecnolog´ıas de la informaci´on y las comunicaciones
Recibido: 22/10/2024 |Aceptado: 29/11/2024 |Publicado: 30/09/2025
Identificadores persistentes:
DOI: 10.48168/innosoft.s24.a299
ARK: 42411/s24.a299
PURL: ark:/42411/s24.a299
Dise˜no de una arquitectura de microservicios en
contenedores virtuales
Design of a microservices architecture in virtual containers
Samantha Yazmin Elizalde Valencia1[0009- 0001- 8412- 3176]*, Jos´e Juan Hern´andez
Mora2[0000-0003-2878-7290], Mar´ıa Guadalupe Medina Barrera3[0000-0003-3074-0029], Juan Ramos
Ramos4[0009-0004-7440-7257]
1Instituto Tecnol´ogico de Apizaco. Direcci´on postal. m23370041@apizaco.tecnm.mx
2Instituto Tecnol´ogico de Apizaco. Direcci´on postal. juan.hm@apizaco.tecnm.com
3Instituto Tecnol´ogico de Apizaco. Direcci´on postal. guadalupe.mb@apizaco.tecnm.com
4Instituto Tecnol´ogico de Apizaco. Direcci´on postal. juan.rr@apizaco.tecnm.com
∗Autor para correspondencia: m23370041@apizaco.tecnm.mx
Resumen
En este art´ıculo se presenta la propuesta metodol´ogica para el dise˜no e implementaci´on de una arquitectura
de microservicios en contenedores. La propuesta abarca desde las metodolog´ıas utilizadas para la fase de
investigaci´on de las primeras fases de desarrollo del proyecto hasta la parte de la metodolog´ıa utilizada para
la creaci´on de un sistema inform´atico de prueba. Se propone una arquitectura basada en arquitecturas de
dominio, as´ı como tambi´en se expone el dise˜no de la arquitectura f´ısica del sistema, basado en los requerimientos
expuestos por la instituci´on colaboradora para el caso de prueba. Como parte de los resultados, se describe la
configuraci´on de los microservicios y contenedores, as´ı como su integraci´on en una red com´un de servicios en
ejecuci´on.
Palabras claves: Arquitectura, Contenerizaci´on, Docker, Microservicios
Abstract
This article presents the methodological proposal for the design and implementation of a containerized micro-
services architecture. The proposal covers the methodologies used for the research phase of the initial stages of
project development, as well as the methodology used to create a test computing system. An architecture based
on domain architectures is proposed, as well as the design of the system’s physical architecture, based on the
requirements presented by the collaborating institution for the test case. The results describe the configuration
of the microservices and containers, as well as their integration into a common network of running services.
Keywords: Architecture, Containerization, Docker, Microservices
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
40
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Introducci´on
En la actualidad, incontables organizaciones siguen atrapadas con software construido sobre bases obsolestas y
poco robustas, la magnitud de este problema es bastante amplia pues resulta que aproximadamente el 65 % de
aplicaciones empresariales son sistemas legacy. Lo m´as frustrante es ver c´omo estas organizaciones desperdician
entre el 60 % y 80 % de sus presupuestos de TI simplemente manteniendo estos sistemas totalmente obsoletos,
en lugar de invertir en innovaciones que realmente podr´ıan transformar sus negocios [1].
Estos sistemas legacy funcionan, pero con muchas dificultades, creados a partir de arquitecturas monol´ıticas
dif´ıcil de sobre llevar, documentaci´on pobre o inexistente, y dependencia de tecnolog´ıas que muchas veces ya se
encuentran obsoletas y el intentar integrar con plataformas modernas resulta una tarea aun mas compleja [2].
Las arquitecturas de microservicios emergen en este panorama como una alternativa alentadora. Estudios
sugieren que implementar microservicios en contenedores puede mejorar el rendimiento hasta en un 15 %,
gracias a que cada componente ocupa su propio espacio y se despliega casi instant´aneamente [3]. Este art´ıculo
muestra las metodolog´ıas propuestas para dise˜nar arquitecturas basadas en microservicios usando contenedores
Docker.
Metodolog´ıas propuestas para el desarrollo del proyecto
En esta secci´on se presentan las metodolog´ıas sugeridas para el desarrollo del proyecto, desde la parte del
estudio y an´alisis de la informaci´on, hasta la parte donde detalla el proceso de como se genera el desarrollo del
sistema de software.
Metodolog´ıa de investigaci´on
Despu´es de analizar algunas de las metodologias de invetigaci´on se opto por dos enfoques que cumplian con
ciertas caracteristicas importantes para llevar acabo el proyecto: la investigaci´on tecnol´ogica y la investigaci´on
tecnol´ogica en ingenier´ıa. Estas metodologias resultan adecuados para proyectos donde el objetivo principal
no es establecer nuevas teor´ıas sino la de reconstruir procesos mediante la adaptaci´on y mejora de soluciones
existentes.
La investigaci´on tecnol´ogica permitira el examinar soluciones existentes, tomar sus mejores elementos y adap-
tarlos a las necesidades del proyecto [4]. La investigaci´on tecnol´ogica en ingenier´ıa a˜nade un componente de
suma importancia: el proyecto de intervenci´on [5]. Como se puede ver en la figura 1, este componente va m´as
all´a del an´alisis te´orico, requiriendo la implementaci´on de una soluci´on que pueda ser evaluada. En este caso,
esto se traduce en el desarrollo de un sistema funcional en base a la arquitectura propuesta. Esto permitir´a
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
41
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
verificar si se cumple con los requisitos planteados en la pregunta de investigaci´on. Adem´as, incorpora un
proceso iterativo que permite retroalimentaci´on constante durante las diferentes etapas del proyecto.
Figura 1. Metodolog´ıa de investigaci´on
A continuaci´on, se proponen las siguientes etapas para realizar la investigaci´on:
1. Identificaci´on del problema: Esta etapa se centra en identificar y formular el problema a investigar,
en esta parte es donde se establecen los objetivos espec´ıficos y se encarga de delimitar el alcance de la
investigaci´on.
2. Revisi´on bibliogr´afica: Realizar una revisi´on de la literatura vinculada con el tema de investigaci´on,
identificando antecedentes y metodolog´ıas utilizadas en otros trabajos de investigaci´on.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
42
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
3. An´alisis de la informaci´on: En esta fase se elaboran algunas soluciones al problema o se plantean
nuevas dudas sobre el tema, utilizando la informaci´on recopilada en la fase anterior.
4. Elaboraci´on del proyecto de intervenci´on: En esta parte se lleva a cabo el desarrollo e implemen-
taci´on del sistema utilizando una metodolog´ıa de desarrollo de software.
5. Validaci´on y verificaci´on: Esta etapa se realiza mediante la aplicaci´on de casos de prueba.
6. Resultados: Interpretar los resultados obtenidos en base a los objetivos de la investigaci´on, as´ı como
se˜nalando posibles ´areas de mejora.
7. Conclusiones: Elaborar conclusiones fundamentadas en los hallazgos obtenidos, adem´as de sugerir
recomendaciones para futuras investigaciones.
Metodolog´ıa de desarrollo del sistema inform´atico
Para la gesti´on del proyecto, se propone una metodolog´ıa ´agil que fusiona elementos de Scrum y Kanban. Como
se muestra en la figura 2, Scrum proporciona la estructura necesaria esto a base de sprints con entregables y
revisiones peri´odicas que permiten ajustar el rumbo del proyecto [6]. Kanban proporciona un esquema visual
a trav´es de sus tableros lo que permite mejorar la planificaci´on de los sprints [7].
Dado que el equipo de desarrollo est´a conformado por un grupo reducido (tres integrantes), se implementa
la variante Small-Scale Scrum [8], adecuada por promover la auto organizaci´on, la comunicaci´on constante y
responsabilidades compartidas en equipos compactos. Esta combinaci´on metodol´ogica permite tener una mejor
planificaci´on de las iteraciones con retroalimentaci´on continua. La metodolog´ıa se segmentar´a en Sprints con
el objetivo de mantener un ritmo de entregas progresivas y adaptarse a las demandas del cliente.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
43
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Figura 2. Metodolog´ıa de desarrollo del sistema
1. Evaluaci´on de herramientas y tecnolog´ıas: Comparar herramientas de contenedores y APIs.
2. Estudio de casos: Realizar el an´alisis de casos de estudio con atributos parecidos para identificar
pr´acticas sugeridas y retos.
3. Recolecci´on de requisitos: En esta etapa, se llevar´an a cabo entrevistas con interesados para identificar
las necesidades del sistema.
4. Planificaci´on de sprints:
Planificaci´on Inicial. En la siguiente etapa se busca establecer el ´ambito general del proyecto, los
objetivos, los roles y el backlog inicial.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
44
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Planificaci´on de Sprint. Se organiza el trabajo que se llevar´a a cabo durante el sprint.
Gesti´on del Flujo de Trabajo utilizando Kanban. En esta etapa se garantiza un flujo constante
de trabajo y eliminar cuellos de botella.
Daily Scrum. El prop´osito de esta etapa es supervisar el avance y solucionar bloqueos de forma
r´apida.
Revisi´on y Retrospectiva de Sprint. Se muestra al Product Owner el avance funcional y se
recibe retroalimentaci´on.
Entrega Incremental. Al concluir cada sprint, entregar versiones del producto.
Repetici´on del Ciclo. Explorar e incorporar mejoras o nuevas caracter´ısticas a trav´es de itera-
ciones continuas.
5. Definici´on de microservicios. En este segmento se seleccionar´an los microservicios que se desem-
pe˜nar´an en el sistema.
6. Dise˜no de Contenedores: Elaborar la estructura que incorporar´an cada contenedor.
7. Puesta en marcha en producci´on: Implementar la arquitectura en el entorno de producci´on.
Arquitectura del sistema
Esta secci´on expone el dise˜no arquitect´onico sugerido para el sistema, detallando tanto su estructura l´ogica en
capas como su implementaci´on f´ısica. La arquitectura establece la estructura modular del sistema, detallando
las distintas capas funcionales y sus interrelaciones, mientras que la arquitectura f´ısica ilustra la disposici´on
precisa de los elementos de infraestructura, ajustada espec´ıficamente a las necesidades t´ecnicas y operativas
de la instituci´on colaboradora.
Arquitectura del sistema
La arquitectura de software mostrada se basa en principios de dise˜no orientado al dominio, fusionados con una
perspectiva de microservicios (ver figura 3). El eje de esta perspectiva se basa en un entendimiento detallado del
´ambito empresarial, lo que demanda una colaboraci´on cercana entre desarrolladores y expertos del ´area [9]. Esta
estructura diferencia la l´ogica central (n´ucleo) de los componetes tecnol´ogicos por medio de capas, mientras
incorpora microservicios para elementos funcionales especificos. Lo que permite simplificar significativamente
el mantenimiento y la evoluci´on del sistema [10]. Esta arquitectura proporciona un entorno de trabajo flexible,
escalable y modular, creado espec´ıficamente para respaldar la evoluci´on constante de sistemas complejos y su
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
45
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
posible traslado a ambientes cloud. La soluci´on implementa una estructura por capas independientes que a´ısla
las reglas de negocio centrales de las dependencias externas (frameworks, bases de datos e interfaces) [11].
Figura 3. Metodolog´ıa de desarrollo del sistema
N´ucleo (L´ogica de negocio): El n´ucleo alberga las entidades y el pensamiento empresarial, bas´andose
en el principio de la arquitectura de cebolla y limpia. Esto garantiza que la l´ogica empresarial est´e
separada y sea aut´onoma de la infraestructura.
Casos de uso: Implementan casos de uso espec´ıficos y se comunican con el n´ucleo a trav´es de interfaces.
Esto est´a inspirado en la arquitectura hexagonal, en la que los servicios funcionan como mediadores.
Adaptadores (Interfaces): Los puertos y adaptadores enlazan el n´ucleo y los servicios con sistemas
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
46
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
externos como bases de datos, APIs externas, entre otros. Esto garantiza que el n´ucleo se mantenga
aut´onomo respecto a los detalles de implementaci´on de la infraestructura.
Microservicios: Cada caracter´ıstica del sistema se pone en marcha como un microservicio aut´onomo,
desplegado en contenedores. Esto permite la escalabilidad y el despliegue constante, conforme a las
pr´acticas ´optimas de la arquitectura de microservicios.
Marcos y conductores: Considerando la arquitectura limpia, esta capa est´a situada en el exterior,
donde puede provocar un da˜no m´ınimo. Suele incluir marcos y herramientas como la base de datos y el
marco web.
Vista f´ısica del Sistema
Para probar la metodolog´ıa propuesta se desarrollara el sistema de gesti´on deportiva del Instituto del Deporte
del Estado de Tlaxcala (IDET). El IDET, es una instituci´on cuyo objetivo estrat´egico es transformar el deporte
local mediante cuatro ejes principales: masificaci´on, deporte social, deporte popular y deporte escolar [12].
Mediante el cual se identificaron tanto los requisitos funcionales como no funcionales orientados a: gesti´on de
citas m´edicas deportivas, administraci´on de historiales cl´ınicos de atletas, generaci´on de reportes estad´ısticos
y de monitoreo, control completo del ciclo de consultas m´edicas. Este an´alisis posibilit´o la creaci´on de los
siguientes artefactos esenciales: diagramas de casos de uso, casos de abuso, diagrama de clases para entidades
m´edicas-deportivas, flujos de procesos cl´ınicos y administrativos, especificaciones de comportamiento para
m´odulos clave.
Los hallazgos de este estudio establecieron la base del dise˜no f´ısico del sistema como se exhibe en la figura
4, garantizando que la arquitectura sugerida cumpla con las necesidades detectadas y los criterios de calidad
establecidos.
Dentro de la arquitectura, los usuarios pueden acceder a la aplicaci´on desde navegadores en computadoras,
tabletas y tel´efonos, estableciendo comunicaci´on mediante solicitudes HTTP. A partir de estas peticiones,
el frontend, desarrollado en React ofrece una interfaz visual. React gestiona los estilos del sistema a trav´es
de archivos CSS y utiliza JavaScript para mejorar la interactividad y la experiencia del usuario. Cuando un
usuario interact´ua con la interfaz, el frontend env´ıa una solicitud a Django, que en este caso act´ua como
middleware a trav´es de Django REST Framework. Este ´ultimo fact´ua como un enlace entre la capa visual
y los microservicios. En el backend, los modelos de datos juegan un rol crucial, debido a que representan la
estructura de la informaci´on y su almacenamiento en la base de datos.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
47
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Figura 4. Vista f´ısica del sistema
El sistema cuenta con varios microservicios, creados para mejorar y verificar la informaci´on en los formularios.
El sistema incorpora los siguientes microservicios:
Microservicio de Validaci´on de Credenciales: Validaci´on de CURP de atletas mediante un servicio
Node.js alojado en servidor la implementaci´on estara basada en un repositorio Git clonado.
Microservicios de Anal´ıtica y Reportes: Generaci´on de diagramas estad´ısticos, elaboraci´on de re-
portes personalizados en PDF con par´ametros ajustables por el usuario y acceso seguro a la base de
datos a trav´es de ORM.
Microservicio de buscador de medicamentos: El cual se pretende integrar a la parte de consultas
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
48
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
m´edicas, permite realizar la toma de decisiones m´as acertada para el profesional de la salud, en cuanto
a medicamentos se refiere, y proporciona informaci´on sobre dosis recomendadas, reacciones adversas y
otros datos relevantes. Este es un microservicio que pertenece al Departamento de Salud y Servicios
Humanos de EE. UU., el cual se encuentra en la nube, y se acceder´a a trav´es de una API. Adem´as,
requiere un servicio adicional para su funcionamiento.
Microservicio de traducci´on: Ya que toda la informaci´on del buscador de medicamentos estaba
disponible en ingl´es, se requiere la implementaci´on de un traductor que permita mostrar la informaci´on
en el idioma adecuado seg´un el contexto de uso; este microservicio pertenece a lingva-translate. El
cual permite la traducci´on tanto para hacer la petici´on como tambi´en para recibir la informaci´on, esto
mediante un servicio Node.js.
Para asegurar la escalabilidad y portabilidad, cada elemento esencial del sistema est´a alojado en contenedores
Docker, lo que permite su despliegue tanto en servidores locales como en la nube, dependiendo del requisito
del cliente. La interacci´on entre diversos contenedores y microservicios se lleva a cabo mediante las API REST.
Resultados y discusi´on
En esta secci´on se expondr´a parte de la implementaci´on del proyecto de intervenci´on. Se mostrar´a desde la
configuraci´on del frontend, backend y microservicios, as´ı como tambi´en c´omo se configuraron los microservicios
dentro de los contenedores y c´omo se comunican entre s´ı.
Configuraci´on del frontend y backend
El sistema busca trabajar de forma modular, lo cual permite agregar nuevas funcionalidades sin comprometer
demasiado el desempe˜no del sistema; es por esto que se necesita separar las funcionalidades de frontend y
backend.
Para trabajar el frontend, se trabaj´o a trav´es del framework de desarrollo React, alojado en el puerto 5173,
el cual realiza todo lo relacionado a la parte visual del sistema. En cuanto al backend, se trabaj´o en base al
framework de desarrollo Django, que permiti´o realizar toda la parte de los modelos de datos y manejar la parte
de la l´ogica central de la aplicaci´on. Este servicio se ejecuta en el puerto 8000. Para lograr la comunicaci´on de
ambas partes, se utilizo con la herramienta Django Rest Framework, que permiti´o la comunicaci´on convirtiendo
los modelos de datos a un formato JSON, esto a trav´es de las vistas y archivos serializadores.
La siguiente figura muestra un ejemplo de la vista DeportesViewSet, la cual se trata de una vista basada en
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
49
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
ViewSet de Django REST Framework. La cual incluye las operaciones b´asicas de API REST.
Dentro de esta vista se define el conjunto de datos (Deporte), que ser´a utilizado por la vista, lo que permite
seleccionar todos los registros pertenecientes a dicho modelo. Tambi´en, al hacer referencia al serializador
(DeporteSerializer), indica que los datos del modelo (Deporte) deber´an ser convertidos a JSON usando el
serializador.
Figura 5. Vista basada en ViewSet
Mientras que en la figura 6, se muestra el archivo serializador perteneciente al modelo de datos de Deporte.
Esta es la parte encargada de convertir los datos que se env´ıan en formato JSON y tambi´en es el encargado
de convertir los datos recibidos por la API. Lo cual permite crear, eliminar o actualizar registros. Dentro
del serializador se utiliza la clase ModelSerializer, la cual permite la creaci´on de serializadores a partir de un
modelo de Django.
Figura 6. Serializer basado en ModelSerializer
Ahora, en la parte del frontend, ser´a necesario configurar una API cliente como se observa en la figura 7, que
permita la interacci´on con el backend. Con base en una URL, permite la conexi´on con el servidor, lo que ayuda
a obtener la informaci´on de los deportes. Y por lo tanto tener a las funciones CRUD, pero esta vez desde el
frontend.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
50
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Figura 7. API cliente
De esta manera, los datos de los modelos podr´an ser gestionados por el backend a trav´es de la API.
Configuraci´on de los microservicios
En cuanto a los servicios creados por el equipo de desarrollo, la configuraci´on es muy similar, ya que estos
dos microservicios de generaci´on de reportes y estad´ısticas de citas y consultas se encuentran en dos proyectos
Django diferentes, alojados en los puertos 8001 y 8002. Para realizar la comunicaci´on, se obtiene la informaci´on
desde las URLs pertenecientes al microservicio backend (Figura 8). Lo que permite que estos microservicios
procesen y filtren los datos relevantes para ser presentados en el frontend, ya sea mediante gr´aficos o para
enriquecer la informaci´on contenida en los archivos PDF generados.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
51
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Figura 8. Vista de filtrado de microservicio de estadisticas
Los microservicios clonados de repositorios git corresponden al servicio de traducci´on y de validaci´on de
CURP, est´an desarrollados en Node.js y se encuentran alojados en los puertos 3000 y 3001. Para su ejecuci´on
fue necesario instalar los requerimientos especificados en su documentaci´on. El manejo de su informaci´on se
realiza mediante el consumo de sus respectivas APIs (Figura 9). Las APIs se encargar´an de gestionar las
peticiones necesarias para lograr la comunicaci´on del frontend con alguno de los dos servicios externos.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
52
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Figura 9. API servicio de validaci´on de CURP
En el caso del microservicio externo que se encuentra alojado en la nube, se define una funci´on, la cual consulta
la API de FDA para obtener la informaci´on de los medicamentos, se realiza la b´usqueda de informaci´on y
devuelve una lista de los objetos procesados.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
53
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Figura 10. Funci´on para acceder a OPEN FDA
Configuraci´on de contenedores (Docker)
Para contenerizar los microservicios, fue necesario crear un archivo Dockerfile dentro de la carpeta correspon-
diente de cada uno, el cual permiti´o crear la imagen de cada microservicio, en el cual se especifica el entorno
base sobre el que se construir´a la imagen, directorio de trabajo, instalaci´on de dependencias, exposici´on de
dependencias y comando de arranque.
Por otro lado el archivo docker compose permiti´o administrar los m´ultiples contenedores donde se asign´o una
red en la cual se estar´an comunicando, esta opci´on es especialmente ´util para aplicaciones que cuentan con
m´ultiples servicios.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
54
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Figura 11. Microservicios en contenedores
Conclusiones
La propuesta de una arquitectura basada en microservicios en contenedores (Docker) demuestra ser un reem-
plazo para los sistemas legacy, ofreciendo escalabilidad, modularidad y portabilidad. Este art´ıculo present´o la
metodolog´ıa que abarca desde el an´alisis hasta la producci´on, validando la arquitectura mediante un caso de
estudio real en el Instituto del Deporte del Estado de Tlaxcala (IDET). Dentro de lo cual se pudo observar
que, gracias a la contenerizaci´on, se simplifica el despliegue y gesti´on de microservicios, reduciendo conflictos
de dependencias.
Mientras que la combinaci´on de Django (backend) y React (frontend) permite una separaci´on de respon-
sabilidades, mientras que el usar Django REST Framework permiti´o facilitar la comunicaci´on con servicios
externos.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
55
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
Contribuci´on de Autor´ıa
Samantha Yazmin Elizalde Valencia: Conceptualizaci´on,Investigaci´on,Metodolog´ıa,Software,Validaci´on,
Redacci´on - borrador original. Jos´e Juan Hern´andez Mora: Conceptualizaci´on,Investigaci´on,Metodolog´ıa,
An´alisis formal,Recursos,Visualizaci´on,Supervisi´on,Administraci´on de proyectos,Curaci´on de datos,Escri-
tura, revisi´on y edici´on. Mar´ıa Guadalupe Medina Barrera: Conceptualizaci´on,Visualizaci´on,An´alisis formal,
Recursos,Supervisi´on,Administraci´on de proyectos,Escritura, revisi´on y edici´on. Juan Ramos Ramos: Con-
ceptualizaci´on,Visualizaci´on,Curaci´on de datos,An´alisis formal,Recursos,Supervisi´on,Administraci´on de
proyectos,Escritura, revisi´on y edici´on.
Referencias
[1] R. A., “The cost of legacy systems: How outdated it holds com-
panies back,” Mar. 21 2025. [Online]. Available: https://www.linkedin.com/pulse/
cost-legacy-systems-how-outdated-holds-companies-back-andre-occec
[2] L. S´anchez, “Sistemas legacy - modernizando la infraestructura tecnol´ogica,” 2024. [Online]. Available:
https://www.initiumsoft.com/blog initium/sistemas-legacy/
[3] A. F. S. Chiza, “An´alisis de rendimiento entre una arquitectura monol´ıtica y una arquitectura de
microservicios – tecnolog´ıa basada en contenedores,” Repositorio Core, Tech. Rep., 2018. [Online].
Available: https://core.ac.uk/download/pdf/200323828.pdf
[4] F. Bello, “Reflexi´on: La investigaci´on tecnol´ogica o cuando la soluci´on es el problema,”
Revista de la Facultad de Ingenier´ıa, Universidad de Carabobo. [Online]. Available: http:
//servicio.bc.uc.edu.ve/faces/revista/a6n13/6-13-3.pdf
[5] C. D. la Cruz Casa˜no, Metodolog´ıa de la investigaci´on tecnol´ogica en ingenier´ıa. Universidad Continental,
2016. [Online]. Available: https://www.academia.edu/94930372/Metodolog%C3%ADa de la investigaci%
C3%B3n tecnol%C3%B3gica en ingenier%C3%ADa
[6] M. V. Estrada-Velasco, P. R. Saltos-Ch´avez, J. A. N. nez Villacis, and W. C. Cunuhay-Cuchipe,
“Revisi´on sistem´atica de la metodolog´ıa scrum para el desarrollo de software,” Revista Cient´ıfica, 2021.
[Online]. Available: https://dialnet.unirioja.es/servlet/articulo?codigo=8384028
[7] A. Castro, “Scrum y kanban: Una combinaci´on efectiva para la gesti´on ´agil,” Enero 13 2025. [Online].
Available: https://www.linkedin.com/pulse/scrum-y-kanban-una-combinaci%C3%B3n
[8] D. Garcia, “Scrum para equipos peque˜nos, una introducci´on,” Feb. 19 2019. [Online]. Available:
https://www.inteldig.com/2019/02/scrum-equipos-pequenos/
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
56
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 40-57
https://revistas.ulasalle.edu.pe/innosoft
[9] G. E. O. Tib´an and L. F. C. S´anchez, “Desarrollo de un prototipo de microservicios con clean architecture,”
2023. [Online]. Available: https://dspace.ups.edu.ec/bitstream/123456789/28179/1/MSQ862.pdf
[10] J. D. L. Hinojosa, “Arquitectura de software basada en mi-
croservicios,” 2017. [Online]. Available: https://1library.co/document/
y81dmvwz-arquitectura-software-basada-microservicios-desarrollo-aplicaciones-asamblea-nacional.html
[11] R. C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall,
2017.
[12] IDET, “Misi´on y visi´on,” Instituto del Deporte de Tlaxcala. [Online]. Available: https://idet.tlaxcala.
gob.mx/index.php/mision-vision
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
57
