“Año de la unidad, la paz y el desarrollo”

Proyecto para obtener el Título Profesional Técnico a nombre de la Nación

Simplificación de la interacción del usuario: Desarrollo de un

microservicio de listado de widgets para el uso de la aplicación móvil de
una empresa como parte de su plan de modernización durante el
periodo 2023

DEPARTAMENTO
Tecnología Digital

CARRERA
Diseño y Desarrollo de Software

ELABORADO POR:
Tantahuilca Torres, Josimar Javier

ASESOR
Castañeda Alban, Jorge Eduardo

LIMA – PERÚ
2023
 2

ÍNDICE DE CONTENIDOS

RESUMEN .............................................................................................................................................................. 4
I. PLANTEAMIENTO Y DEFINICIÓN DEL PROBLEMA ................................................................................... 6
1.1 Formulación del Problema .................................................................................................................. 6
1.1.1 Análisis del Sector ...................................................................................................................... 6
1.1.2 Análisis de la Empresa ............................................................................................................... 7
1.1.3 Planteamiento del Problema ...................................................................................................... 7
1.1.4 Análisis de Causas ..................................................................................................................... 8
1.1.5 Diagnóstico ................................................................................................................................. 9
1.1.6 Árbol de Objetivos ...................................................................................................................... 9
1.2 Justificación del Proyecto ................................................................................................................ 10
II. OBJETIVOS ................................................................................................................................................. 11
2.1 Objetivo General ................................................................................................................................ 11
2.2 Objetivos Específicos ....................................................................................................................... 11
III. FUNDAMENTO TEÓRICO ...................................................................................................................... 12
3.1 Requisitos de la Solución ................................................................................................................. 12
3.2 Posibles Soluciones .......................................................................................................................... 13
3.3 Determinación de la Solución Óptima ............................................................................................. 15
3.4 Marco Teórico y Estado del Arte de la Solución ............................................................................. 15
3.4.1 Marco Teórico ........................................................................................................................... 15
3.4.2 Estado del Arte.......................................................................................................................... 17
3.4.3 Bases Teóricas.......................................................................................................................... 18
IV. DESARROLLO DE LA SOLUCIÓN ......................................................................................................... 21
4.1 Diagrama de Gantt ............................................................................................................................. 21
4.2 Diagrama de Base de Datos ............................................................................................................. 22
4.3 Maquetados de la Aplicación ........................................................................................................... 23
4.4 Requerimientos Funcionales ............................................................................................................ 26
4.5 Requerimientos no Funcionales ...................................................................................................... 26
V. EVALUACIÓN DE RESULTADOS ............................................................................................................... 27
5.1 Resultados de las Pruebas ............................................................................................................... 27
5.1.1 Pruebas de Funcionalidad ....................................................................................................... 27
5.1.2 Pruebas de Rendimiento .......................................................................................................... 27
5.1.3 Pruebas de Usabilidad ............................................................................................................. 27
5.1.4 Pruebas de Seguridad .............................................................................................................. 27
5.2 Beneficios Obtenidos ........................................................................................................................ 27
CONCLUSIONES ................................................................................................................................................. 29
RECOMENDACIONES ......................................................................................................................................... 30
REFERENCIAS BIBLIOGRÁFICAS ...................................................................................................................... 31
 3

ÍNDICE DE TABLAS Y FIGURAS

Tabla 1. Alternativas de la solución......……………………………………………………….….. 13

Tabla 2: Ponderación y peso………… ….…………………………………………………….….. 13

Tabla 3: Matriz de evaluación ………...……………………………………………………….….. 14

Tabla 4: Requerimientos Funcionales ….…………………………………………………….….. 25

Tabla 5: Requerimientos no Funcionales ...………………………………………………….….. 25

Figura 1: Árbol de objetivos……………………….……………………………………………...… 9

Figura 2: Diagrama de Gantt …...……………………………...…………………………………. 20

Figura 3: Diagrama Entidad-Relación ...…………………… …………………………..……….. 21

Figura 4: Opción de configuración ……………………………………...………………………... 22

Figura 5: Opción de configuración bloqueada ……………………………...…………………… 22

Figura 6: Listado de widgets ……………………………………………………...…………….… 23

Figura 7: Listado de widgets después de actualización …………………………...…………... 23

Figura 8: Mensaje de error al ingresar a la configuración ……………………………...…….... 24

Figura 9: Mensaje de error al tratar de editar ……………………………………………...….… 24

 4

RESUMEN

Este informe técnico detalla el desarrollo de un microservicio de listado de widgets para una

aplicación móvil, enfatizando su construcción, implementación y los resultados alcanzados.

El proyecto tenía como objetivo enriquecer la funcionalidad de la aplicación móvil

proporcionando a los usuarios un acceso fluido a una colección versátil de widgets.

El proceso de desarrollo implicó un enfoque integral para el diseño y la implementación de

microservicios. Comenzando con una planificación y un diseño arquitectónico meticulosos, el

microservicio se diseñó estratégicamente para integrarse perfectamente en el marco

existente de la aplicación móvil. Las consideraciones incluyeron la arquitectura del sistema,

el diseño de API, el almacenamiento de datos, los protocolos de seguridad, eficiencia,

capacidad de respuesta y escalabilidad. Se llevó a cabo utilizando C# como lenguaje de

programación central, aprovechando el poder de gRPC (google Remote Procedure Call) y el

patrón CQRS (Command Query Responsibility Segregation).

El resultado de este esfuerzo fue un microservicio de listado de widgets optimizado y

receptivo. Mejora de la funcionalidad dentro de la aplicación móvil, con acceso rápido e

intuitivo a una variedad de widgets.

Este informe ofrece una exploración en los aspectos técnicos del desarrollo del microservicio

de listado de widgets, describiendo las metodologías, herramientas y tecnologías empleadas

en el proceso. También examina los beneficios tangibles de este microservicio, arrojando luz

sobre los avances en la experiencia del usuario y sus posibles implicaciones para el desarrollo

futuro de aplicaciones y proyectos de microservicios similares.

 5

Palabras clave: microservicio, desarrollo, mejora

ABSTRACT

This technical report details the development of a widget listing microservice for a mobile

application, emphasizing its construction, implementation, and the achieved results. The

project aimed to enrich the mobile app's functionality by providing users with seamless access

to a versatile collection of widgets.

The development process involved a comprehensive approach to microservice design and

deployment. Beginning with meticulous planning and architecture design, the microservice

was strategically crafted to integrate seamlessly into the mobile app's existing framework.

Considerations included system architecture, API design, data storage, security protocols,

efficiency, responsiveness, and scalability. It was carried out using C# as the core

programming language, leveraging the power of gRPC (google Remote Procedure Call) and

the CQRS (Command Query Responsibility Segregation) pattern.

The outcome of this endeavor was a highly optimized and responsive widget listing

microservice. Enhancing functionality within the mobile app, with quick and intuitive access to

a variety of widgets.

This report offers an exploration of the technical aspects of the widget listing microservice

development, outlining the methodologies, tools, and technologies employed in the process.

It also examines the tangible benefits of this microservice, shedding light on the

advancements in user experience and their potential implications for future app development

and similar microservice projects.

 6

Keywords: microservice, development, enhancement

I. PLANTEAMIENTO Y DEFINICIÓN DEL PROBLEMA

1.1 Formulación del Problema

1.1.1 Análisis del Sector

La industria del techado ha sido una parte integral del sector de la

construcción. Al respecto, Expert Market Research (2022) señala que:

El mercado de techos de Estados Unidos alcanzó un valor de

aproximadamente 21,9 mil millones de dólares en 2022 y se espera

que crezca a una tasa compuesta anual de alrededor del 6,6% en el

período previsto de 2023-2028 para alcanzar un valor de alrededor de

32,14 mil millones de dólares en 2028.

Además, como ocurre con muchas industrias, la digitalización y las soluciones

de software han sido fundamentales para mejorar la eficiencia, comunicación,

precisión y productividad en las tareas de techado. El software para techado

ayuda a las empresas en la gestión de proyectos, la gestión de relaciones con

los clientes, las estimaciones y otros procesos claves. Según DataForma

(2022):

Los contratistas que utilizan software para techados tienen una ventaja

sobre aquellos que se apegan a sus antiguos sistemas organizativos.

Invertir en el software adecuado puede ayudar a las empresas de

techado a dar una buena impresión a los clientes potenciales,

completar proyectos de manera eficiente y prepararse para el éxito con

futuros clientes.
 7

Con el auge de la construcción inteligente, existe una demanda creciente de

soluciones de software integradas adaptadas a la industria del techado. De

acuerdo con un estudio realizado por Market Research Intellect, el mercado

global de software para techos está creciendo a un ritmo acelerado y se

pronostica que para el periodo 2023 – 2031 presente un crecimiento

significativo.

1.1.2 Análisis de la Empresa

La empresa es un proveedor líder de soluciones de software para la industria

del techado en los Estados Unidos, cuyo nombre es reservado por políticas de

privacidad de esta organización. Con su completo conjunto de herramientas

tecnológicas, ayuda a los contratistas de techado en todos los aspectos de su

negocio.

El énfasis de la empresa en la innovación y en satisfacer las demandas

específicas de su clientela ha solidificado su posicionamiento en el mercado.

Sin embargo, como cualquier empresa con visión de futuro, busca

continuamente mejorar sus servicios y brindar experiencias mejoradas a sus

usuarios.

1.1.3 Planteamiento del Problema

A pesar de las sólidas capacidades del software de la empresa, se identificó

una brecha en brindar a los usuarios acceso rápido e intuitivo a una amplia

gama de widgets, una característica que podría mejorar aún más la eficiencia

en la ejecución de tareas.

Problema General:

¿Cómo puede el desarrollo y la integración de un microservicio de listado de

widgets mejorar la solidez arquitectónica y la eficiencia de la aplicación móvil

en el contexto del plan de modernización del periodo 2023?

Problemas Específicos:
 8

a. ¿Cómo se puede diseñar e integrar arquitectónicamente el microservicio de

listado de widgets en el sistema de aplicaciones móviles existente sin causar

interrupciones ni requerir revisiones importantes?

b. ¿Cuáles son los requisitos funcionales y no funcionales necesarios para el

microservicio de listado de widgets?

c. ¿Cómo se puede estructurar el microservicio para garantizar que no solo

crezca con la creciente demanda, sino que también siga siendo modular,

facilitando la posible integración con otros sistemas o servicios en el futuro?

d. ¿Cuáles son las mejores prácticas, herramientas y metodologías que se

emplearán en el desarrollo e implementación del microservicio para garantizar

su incorporación exitosa a la aplicación móvil?

1.1.4 Análisis de Causas

a. Acceso limitado: La aplicación no ofrecía una plataforma intuitiva para que los

usuarios pudieran acceder y utilizar rápidamente varios widgets. Esta

limitación llevó a que los usuarios pudieran perderse funcionalidades

beneficiosas o pasar demasiado tiempo navegando por el software para

encontrar las funciones deseadas.

b. Falta de escalabilidad en diseño y servicios: El diseño anterior de la aplicación

no se adaptaba fácilmente a la adición de nuevos widgets. Además, la mayoría

de los servicios vienen de sistema monolítico haciendo difícil la extensión de

nuevas funcionalidades.

c. Experiencia de usuario inconsistente: Debido a las limitadas capacidades de

integración y accesibilidad de los widgets, los usuarios experimentaban

inconsistencias en la navegación y el rendimiento de la aplicación. Esto

provocaba una menor participación del usuario, una posible frustración o

incluso una migración a plataformas de la competencia que ofrecen una

experiencia de más fluida.

 9

1.1.5 Diagnóstico

El área de diseño identificó la necesidad de cambio en la interfaz de usuario lo

que originó el requerimiento para la creación de un microservicio de listado de

widgets.

1.1.6 Árbol de Objetivos

Figura 1

Árbol de objetivos

Fuente: Elaboración propia.

 10

1.2 Justificación del Proyecto

a. Experiencia de usuario mejorada: con el microservicio de listado de widgets, los

usuarios pueden acceder y utilizar fácilmente una variedad de ellos, lo que hace que

el software sea más fácil de usar e intuitivo.

b. Escalabilidad: el proyecto sienta las bases para futuras incorporaciones, garantizando

que el software siga siendo ágil y adaptable a las necesidades cambiantes de la

industria del techado.

c. Posicionamiento en el mercado: al abordar esta brecha, la empresa refuerza su

compromiso con la innovación y se posiciona como un líder del mercado que escucha

a sus usuarios y evoluciona constantemente para satisfacer sus demandas.

d. Eficiencia operativa: Para los contratistas de techado, el tiempo suele ser esencial.

Esta incorporación garantiza que dediquen menos tiempo a buscar y más tiempo a

utilizar las herramientas que necesitan, lo que en última instancia conduce a una mejor

gestión de proyectos y la satisfacción del cliente.

 11

II. OBJETIVOS

2.1 Objetivo General

Determinar las pautas para el desarrollo y la integración de un microservicio de listado

de widgets para mejorar la solidez arquitectónica y la eficiencia de la aplicación móvil

en el contexto del plan de modernización del periodo 2023

2.2 Objetivos Específicos

a. Determinar cómo se puede diseñar e integrar arquitectónicamente el microservicio de

listado de widgets en el sistema de aplicaciones móviles existente sin causar

interrupciones ni requerir revisiones importantes

b. Establecer cuáles son los requisitos funcionales y no funcionales necesarios para el

microservicio de listado de widgets

c. Determinar cómo se puede estructurar el microservicio para garantizar que no solo

crezca con la creciente demanda, sino que también siga siendo modular, facilitando

la posible integración con otros sistemas o servicios en el futuro

d. Determinar cuáles son las mejores prácticas, herramientas y metodologías que se

emplearán en el desarrollo e implementación del microservicio para garantizar su

incorporación exitosa a la aplicación móvil

 12

III. FUNDAMENTO TEÓRICO

3.1 Requisitos de la Solución

El núcleo del microservicio es la capacidad de listado. El servicio debe traer de manera

competente una lista de widgets disponibles, que satisfagan las diversas preferencias

de los usuarios, ya sea que busquen widgets de diferentes categorías o tipos

específicos. En consonancia con esto, la capacidad de filtrar y clasificar es primordial.

El microservicio debería permitir a los usuarios la flexibilidad de examinar los widgets

en función de parámetros como categoría o fecha de lanzamiento.

Igualmente, cruciales son los puntos de integración. Para lograr una sinergia perfecta

entre el microservicio, la aplicación principal y cualquier otro sistema externo

potencial, el microservicio necesita de APIs –Application Programming Interface– bien

definidas. Estas interfaces deberían facilitar una variedad de operaciones, desde

buscar hasta actualizar los detalles del widget. Para mantenerse actualizado y

reactivo a las tendencias emergentes, el sistema debe admitir actualizaciones y

adiciones. Esto implica privilegios administrativos para introducir nuevos widgets,

ajustar los detalles de los widgets existentes o incluso ocultar ciertos widgets de los

listados.

El rendimiento es otro factor crucial. Dada la multitud potencial de widgets y usuarios

simultáneos, las respuestas rápidas, incluso bajo cargas sustanciales, no son

negociables. A medida que aumenta la demografía de los usuarios y se expande el

repertorio de widgets, la escalabilidad se vuelve fundamental. Esto implica una

asignación eficiente de recursos.

La seguridad es primordial. Por lo tanto, es esencial implementar protocolos seguros

de transmisión de datos y protegerse contra amenazas como la inyección SQL. Junto

con la seguridad, la confiabilidad juega un papel vital. Con el objetivo de lograr una

alta disponibilidad, el servicio debe incorporar mecanismos como copias de seguridad,

 13

redundancia y estrategias de conmutación por error para combatir posibles tiempos

de inactividad.

Por último, un requisito de cara al futuro es la mantenibilidad. A medida que evoluciona

el panorama tecnológico, el servicio debería permitir actualizaciones sin esfuerzo, lo

que requiere prácticas de codificación claras y documentación exhaustiva. Un aspecto

que a menudo se subestima es el monitoreo y registros. La implementación de

herramientas para monitorear constantemente el estado del sistema y mantener

registros puede ser invaluable para solucionar problemas.

3.2 Posibles Soluciones

Tabla 1

Alternativas de la solución

Alternativas Descripción
A Integración monolítica
B Microservicio alojado en la nube
C Microservicio en contenedores
Fuente: Elaboración propia.

Tabla 2

Ponderación y peso

Ponderación Peso
Excelente 4 puntos
Bueno 3 puntos
Regular 2 puntos
Malo 1 punto
Fuente: Elaboración propia.
 14

Tabla 3

Matriz de evaluación

Alternativa Costo (20%) Tiempo (20%) Calidad (30%) Seguridad (30%) Puntaje Total

A 4 x 0.2 = 0.8 3 x 0.2 = 0.6 1 x 0.3 = 0.3 2 x 0.3 = 0.6 2.3

B 2 x 0.2 = 0.4 1 x 0.2 = 0.2 4 x 0.3 = 1.2 4 x 0.3 = 1.2 3.0

C 3 x 0.2 = 0.6 2 x 0.2 = 0.4 4 x 0.3 = 1.2 4 x 0.3 = 1.2 3.4

Fuente: Elaboración propia.

Nota. La contribución de los líderes técnicos involucrados definió el peso de cada columna de la evaluación.

Analizando los resultados de la Tabla 3. Teniendo en cuenta los requisitos y los objetivos del plan de modernización, la opción C surge

como la solución óptima, proveer el microservicio en contenedores que utiliza Docker y Kubernetes. Se alinea con las prácticas actuales

de la empresa y ofrece los beneficios técnicos deseados. La alternativa B es una propuesta igual de llamativa, usando microservicios

alojados en la nube empleando Amazon Web Services – AWS – Lambda o Azure Functions, pero tienen la desventaja de no estar en

uso en la empresa, esto conlleva a un mayor tiempo de desarrollo. Por último, la alternativa A es la opción menos deseada por ser

obsoleta y no se alinea con el plan de modernización de la empresa a utilizar microservicios como base.
 15

3.3 Determinación de la Solución Óptima

Después de realizar el análisis de las distintas alternativas en las cuales se puede

crear el servicio de listado de widgets se determinó desarrollar un microservicio en

contendores. Esta alternativa se diferencia de las otras por las siguientes razones:

a. La empresa tiene experiencia con los microservicios en contenedores, esto agilizaría

el desarrollo.

b. Con una plataforma como Kubernetes, el escalado se vuelve casi instantáneo. Si el

servicio de listado de widgets experimenta un aumento en la demanda, Kubernetes

puede generar automáticamente más contenedores para manejar la carga. Este

escalado dinámico es beneficioso para la gestión de recursos y puede manejar picos

de tráfico tanto esperados como inesperados.

c. El enfoque en contenedores garantiza que el microservicio se pueda implementar en

varios entornos, ya sea la máquina local de un desarrollador, un entorno de prueba o

una plataforma en la nube, todo sin ningún cambio. Esta portabilidad reduce los

errores específicos del entorno y agiliza los procesos de implementación.

d. Plataformas como Docker y Kubernetes tienen una comunidad sólida. Continuamente

se desarrolla una gran cantidad de herramientas, extensiones y complementos. Este

ecosistema garantiza que la empresa pueda aprovechar soluciones de vanguardia y

también encontrar ayuda para la resolución de problemas cuando sea necesario.

3.4 Marco Teórico y Estado del Arte de la Solución

3.4.1 Marco Teórico

Antecedentes

Los microservicios, ahora una técnica reconocida en la creación de software

se originó a finales de la década de 1990 y principios de la década de 2000.

Este estilo arquitectónico implica la creación de aplicaciones como colecciones

de módulos de función única con interfaces y operaciones bien definidas (Ali,

 16

2023). Las principales motivaciones detrás de este enfoque fueron mejorar la

comunicación entre plataformas y simplificar las complejas arquitecturas de

sistemas.

El concepto de desarrollar software a partir de elementos modulares

independientes tiene sus inicios en el enfoque de Service Oriented

Architecture –SOA–. Durante su apogeo a finales de los 90 y principios de los

2000, SOA promovió la creación de software como una colección de servicios

versátiles, que permitían su reutilización en diversos escenarios.

Un pionero de este pensamiento modular fue IBM –Internation Business

Machines– con Enterprise Java Beans –EJB– introducido en 1997. EJB,

centrado en componentes del lado del servidor, facilitó el diseño segmentado

de aplicaciones de nivel empresarial dentro del entorno de computación

distribuida de Java. Sin embargo, todavía había problemas frustrantes con el

uso de EJB. Sólo se podían utilizar mientras se trabajaba en Java y no se

podían comunicar con otros sistemas (Foote, 2021).

A medida que el protocolo de mensajería de servicios web SOAP –Simple

Object Access Protocol– evolucionó, se volvió más complejo y lento. Esto llevó

al surgimiento de lo que hoy se conoce como Representational State Transfer

–REST– entre 2008 y 2010 como un sustituto más sencillo. Al utilizar HTTP –

Hypertext Transfer Protocol– para las funciones CRUD –Create Read Update

Delete–, REST resonó con los principios incipientes de los microservicios

debido a su simplicidad y adaptabilidad.

La etiqueta "microservicios" se introdujo por primera vez durante una reunión

de expertos en software celebrada en 2011-2012. Entre ellos, James Lewis y

Martin Fowler, quienes hablaron sobre una dirección arquitectónica

compartida que habían estado investigando. Su principal descubrimiento

fueron los beneficios de diseñar software como grupos de pequeños servicios,

 17

donde cada servicio podría operar de forma aislada, pero comunicarse

utilizando métodos simplificados como las API HTTP.

En palabras de Ali (2023):

El viaje de SOA a los microservicios ha estado marcado por un

refinamiento y una evolución continuos, influenciados por numerosos

pioneros de la industria. Como resultado, la arquitectura de

microservicios actual es más que un simple enfoque para estructurar

aplicaciones: es un testimonio de la resiliencia y la capacidad de

innovación de la industria del software.

3.4.2 Estado del Arte

Según la investigación realizada por Nunes et al. (2021):

La adopción de la arquitectura de microservicios ha adquirido grandes

proporciones debido a sus beneficios y a la popularización de

herramientas impulsadas por contenedores, como Kubernetes y

Docker. Además, el desarrollo de aplicaciones basadas en

microservicios es una tarea compleja, especialmente porque pueden

estar compuestas por múltiples partes heterogéneas. En particular, uno

de los principales desafíos es cómo llevar a cabo el escalado

automático de los microservicios; es decir, agregar o eliminar recursos

según demanda, evitando al mismo tiempo el desperdicio de recursos,

como procesamiento y memoria.

Muchas compañías cambiaron de un sistema monolítico a microservicios,

entre ellos se encuentra Amazon, que, en 2001, con el creciente tráfico de

usuarios, retrasos en los desarrollos y desafíos estructurales decidieron

refactorizar su modelo monolítico desde cero y dividirlo en componentes

modulares (Thönes, 2015). Otra figura importante que decidió migrar fue

Netflix que comenzó su servicio de streaming en el 2007, y para el 2008 ya

 18

presentaba desafíos de escalabilidad. La compañía sufrió de una fuerte

corrupción de su base de datos y por 3 días quedaron inoperativos. Este fue

el momento en que decidieron moverse a una arquitectura distribuida.

3.4.3 Bases Teóricas

Azure functions: Es una solución sin servidor que le permite escribir menos

código, mantener menos infraestructura y ahorrar costos (Microsoft, 2023).

AWS Lamba: Es un servicio informático que le permite ejecutar código sin

aprovisionar ni administrar servidores (AWS, 2019).

Base de datos: Es un conjunto organizado de información o datos,

almacenados electrónicamente en un sistema informático (Oracle, 2022).

C#: Es un lenguaje de programación moderno que se utiliza para desarrollar

aplicaciones en todas las plataformas (Microsoft, 2023).

Consumer: Es un componente que se suscribe a Kafka topics y lee datos de

ellos. Procesa y consume mensajes o registros publicados sobre esos topics,

a menudo utilizados para procesamiento y análisis de datos en tiempo real

(AWS, s.f.).

Contenedor: Es una pieza ligera de software ejecutable que incluye todo lo

necesario para ejecutar un determinado software (Docker, 2023).

Diagrama de Gantt: Herramienta de gestión de proyectos que ayuda en su

planificación y programación. Se define como una representación gráfica de la

actividad en función del tiempo; ayuda a los profesionales del proyecto a

monitorear el progreso (APM, 2021).

Endpoint: Son dispositivos físicos que se conectan e intercambian

información con una red informática (Microsoft, s.f.).

Escalabilidad: Es la capacidad de un sistema de cambiar el tamaño para

manejar los cambios de carga (Microsoft, 2023).

 19

Grpc: Es un framework de código abierto y de alto rendimiento para llamadas

a procedimientos remotos (RPC). Utiliza un protocolo independiente del idioma

llamado Protocol Buffers (Protobuf) para definir la estructura de las interfaces

de datos y servicios. gRPC está diseñado para una comunicación rápida y

eficiente entre sistemas distribuidos, lo que lo hace adecuado para crear

microservicios y API (Google, s.f.).

HTTP: Es un protocolo de comunicaciones diseñado para transferir

documentos de hipertexto entre computadoras a través de la World Wide Web

(Microsoft, 2014).

JSON Web Token -JWT-: Es una forma compacta y autónoma de representar

información entre dos partes como un objeto JSON. Los JWT se utilizan

comúnmente para la autenticación y el intercambio de datos en aplicaciones

web y API, proporcionando un medio seguro y a prueba de manipulaciones

para transmitir información (JWT, s.f.).

Microservicio: Es una pieza de software, pequeña, independiente y

débilmente acoplado que realiza una función en específico dentro de un

sistema más grande (Newman, 2015).

Modularidad: En informática y programación se refiere a dividir un sistema en

módulos o componentes separados. Cada módulo maneja una funcionalidad

específica y opera de forma independiente (Lenovo, s.f.).

Producer: Es un componente que publica datos o mensajes de Kafka topics.

Envía registros a topics específicos, haciendo que los datos estén disponibles

para el uso de los consumidores de Kafka (AWS, s.f.).

Protobuf: Es un formato de serialización de datos independiente del idioma

desarrollado por Google. Se utiliza para codificar datos estructurados en un

formato binario compacto y eficiente. Protobuf permite definir estructuras de

datos y sus reglas de serialización de manera independiente del lenguaje, lo

 20

que lo hace útil para la comunicación entre diferentes lenguajes y sistemas de

programación (Google, s.f.).

Requerimientos funcionales: Describe lo que debe hacer el producto o

servicio (Microsoft, 2023).

Requerimientos no funcionales: Describe cómo debe funcionar el producto

o servicio (Microsoft, 2023).

REST API: son endpoints de servicio que admiten conjuntos de operaciones

HTTP (métodos), que proporcionan acceso para crear, recuperar, actualizar o

eliminar los recursos del servicio (Microsoft, 2023).

SOA: Es un método de desarrollo de software que utiliza componentes de

software llamados servicios para crear aplicaciones comerciales (AWS, s.f.).

SQL: Es un lenguaje de programación diseñado para la administración y

manipulación de base de datos relacionales (Oracle, 2022).

Kafka: Plataforma de procesamiento de flujo de código abierto utilizada para

crear canales de datos en tiempo real y aplicaciones de transmisión. Está

diseñado para manejar flujos de datos distribuidos, tolerantes a fallos y de alto

rendimiento (AWS, s.f.).

Kreya: Herramienta utilizada para consumir servicios basados en gRPC

(Kreya, s.f.).

Kubernetes: Es una plataforma portátil, extensible y de código abierto para

gestionar cargas de trabajo y servicios en contenedores (Kubernetes, 2023).

 21

IV. DESARROLLO DE LA SOLUCIÓN

4.1 Diagrama de Gantt

Figura 2

Diagrama de Gantt

Fuente: Elaboración propia.

Nota. El diagrama muestra las estapas de desarrollo del servicio
 22

4.2 Diagrama de Base de Datos

Figura 3
Diagrama Entidad-Relación

Fuente: Elaboración propia

Nota. Solo se muestran las tablas involucradas
 23

4.3 Maquetados de la Aplicación

Figura 4 Figura 5
Opción de configuración Opción de configuración bloqueada
 24

Figura 6 Figura 7
Listado de widgets Listado de widgets después de actualización
 25

Figura 8 Figura 9
Mensaje de error al ingresar a la configuración Mensaje de error al tratar de editar
 26

4.4 Requerimientos Funcionales

Tabla 4

Requerimientos Funcionales

# RQF Descripción
RQF-001 Diseñar tablas involucradas en el listado de widgets
RQF-002 Listado de widgets globales
RQF-003 Actualizar widgets globales
RQF-004 Agregar widgets globales
RQF-005 Listado de widgets por compañía
RQF-006 Actualizar widgets por compañía
Versión 1.0
Autores Josimar Javier Tantahuilca Torres

4.5 Requerimientos no Funcionales

Tabla 5

Requerimientos no Funcionales

# RQNF Descripción
RQNF-001 Tiempo de respuesta
RQNF-002 Rendimiento
RQNF-003 Tolerancia a fallos
RQNF-004 Identificación
RQNF-005 Auditoría de tablas
RQNF-006 Documentación del servicio
Versión 1.0
Autores Josimar Javier Tantahuilca Torres
 27

V. EVALUACIÓN DE RESULTADOS

5.1 Resultados de las Pruebas

5.1.1 Pruebas de Funcionalidad

Todas las funcionalidades principales, como retornar un listado de widgets,

filtrar y ordenar, se realizaron correctamente sin anomalías. Casos extremos

específicos, como la consulta de widgets inexistentes o filtros no válidos,

arrojaron los mensajes de error esperados.

5.1.2 Pruebas de Rendimiento

El equipo de calidad se encargó de realizar las pruebas de rendimiento sobre

el microservicio y validar que el sistema es robusto y puede soportar una carga

moderada de peticiones.

5.1.3 Pruebas de Usabilidad

Los desarrolladores encontraron intuitivos los endpoints del microservicio. La

documentación completa y los mensajes de error claros mejoraron aún más la

usabilidad, facilitando una interacción y resolución de problemas fluidas.

5.1.4 Pruebas de Seguridad

Las pruebas soltaron los indicadores necesarios. Peticiones no autorizadas

son rechazas y la validación de usuarios con permisos limitados se ejecuta

correctamente.

Los resultados de las pruebas confirman que el microservicio de widgets cumple con los

requerimientos solicitados. De esta manera su integración con la aplicación móvil y futuros

sistemas no tendrán inconvenientes.

5.2 Beneficios Obtenidos

• Debido a la naturaleza modular de los microservicios la implementación se realiza de

forma más rápida que si se hubiese hecho con el monolito.

 28

• Las mejoras en la escalabilidad garantizan que la aplicación pueda manejar cargas

altas con mínima degradación en el rendimiento.

• Mejoras en las mediades de seguridad fortalecen las defensas de la aplicación.

 29

CONCLUSIONES

Analizando los objetivos declarados, el desarrollo y la integración del microservicio de listado

de widgets dentro del marco de la aplicación móvil logró el cometido esperado dando forma

a este para que sea más robusta y eficiente, en consonancia con el plan de modernización

de la compañía para el periodo 2023.

El microservicio fue diseñado para integrarse en la arquitectura del sistema existente. Esto

se logró empleando un enfoque en contenedores que minimizó el impacto en la configuración

actual y permitió el desarrollo y las pruebas en paralelo sin interrupciones.

El establecimiento de requisitos funcionales y no funcionales claros fue fundamental. Estos

requisitos guiaron el proceso de desarrollo, garantizando que el microservicio realizara sus

funciones de manera efectiva.

Los principios de diseño del microservicio garantizaron la modularidad y escalabilidad. Esta

previsión ha preparado el sistema para el crecimiento futuro. Su naturaleza modular también

permite la posibilidad de integración con otros sistemas.

La adopción de mejores prácticas, herramientas y metodologías, como el desarrollo ágil, los

canales de integración/implementación continua –CI/CD– y estrategias de prueba integrales,

resultó fundamental. Estas prácticas aseguraron el cumplimiento del proyecto con estándares

de calidad y permitieron iteraciones y mejoras rápidas durante el proceso de desarrollo.

 30

RECOMENDACIONES

a. Comprender el negocio: antes de embarcarse en el proceso de desarrollo, entienda

los requisitos empresariales y las necesidades de los usuarios. Esto garantiza que el

microservicio estará alineado con los objetivos generales de la aplicación y

proporcionará valor real a los usuarios finales.

b. Domine el stack tecnológico: Asegúrese de que el equipo de desarrollo teconlogías

elegidas.

c. Garantice pruebas rigurosas: implemente un régimen de pruebas riguroso que cubra

pruebas unitarias, pruebas de integración y pruebas de un extremo a otro. Las

pruebas automatizadas deben ser parte del proceso de CI/CD para detectar

problemas de manera temprana y frecuente.

d. Plan de implementación: las estrategias de implementación deben considerarse

desde el principio. Usando los contenedores de Docker y la orquestación con

Kubernetes pueden simplificar enormemente la implementación, el escalado y la

gestión de microservicios.

e. Monitoreo continuo: implemente herramientas de monitoreo en tiempo real para

detectar y resolver problemas potenciales de manera proactiva.

f. Vigilancia de seguridad: con el panorama cambiante de las amenazas cibernéticas,

actualice y fortalezca continuamente las medidas de seguridad del microservicio.

 31

REFERENCIAS BIBLIOGRÁFICAS

Amazon Web Services. (2019). What Is AWS Lambda?

https://docs.aws.amazon.com/lambda/latest/dg/welcome.html

Amazon Web Services. (s.f.). What is Apache Kafka? https://aws.amazon.com/what-

is/apache-kafka/

Amazon Web Services. (s.f.). What is Service-Oriented Architecture? Service-Oriented

Architecture Explained - AWS. https://aws.amazon.com/what-is/service-oriented-
architecture/

Association for Project Management. (2021). What is a Gantt chart? Association for Project
Management. https://www.apm.org.uk/resources/find-a-resource/gantt-chart/

Auer, F., Lenarduzzi, V., Felderer, M., & Taibi, D. (2021). From monolithic systems to
Microservices: An assessment framework.Elsvier

Bashari Rad, B., Bhatti, H. J., & Ahmadi, M. (2017). An Introduction to Docker and Analysis
of its Performance, 17(3), 228-235. IJCSNS International Journal of Computer
Science and Network Security

Bin Ali, M. (31 de agosto de 2023). The History of Microservices: From Thought Experiment
to Industry Standard [Publicación]. LinkedIn. https://www.linkedin.com/pulse/history-
microservices-from-thought-experiment-industry-muaath-bin-ali

Dataforma. (02 de febrero de 2022). 7 Ways Roofing Software Is Changing the Game.
https://www.dataforma.com/blog/7-ways-roofing-software-is-changing-the-game/

Docker. (2023). What is a Container? https://www.docker.com/resources/what-container/

Dragoni, N., Giallorenzo, S., Lluch-Lafuente, A., Mazzara, M., Montesi, F., Mustafin, R., &
Safina, L. (2016). Microservices: yesterday, today, and tomorrow. Researchgate

Expert Market Research. (s.f.). United States roofing market report.

https://www.expertmarketresearch.com/reports/united-states-roofing-market

Falahah, Kridanto Surendro, W. D. S. (2021). Circuit Breaker in Microservices: State of the

Art.IOP Publishing

Foote, K. D. (22 de abril de 2021). A Brief History of Microservices.

https://www.dataversity.net/a-brief-history-of-microservices/

Google. (s.f.). Introduction to gRPC. https://grpc.io/docs/what-is-grpc/introduction/

JWT.IO (s.f.). Introduction to JSON Web Tokens. https://jwt.io/introduction

Kreya. (s.f.). Calling APIs made easy. https://kreya.app/

Kubernetes. (s.f.). Overview https://kubernetes.io/docs/concepts/overview/

 32

Lenovo. (s.f.). Modularity: What is It and How Does it Enhance Business Productivity?
https://www.lenovo.com/us/en/glossary/modularity/?orgRef=https%253A%252F%252
Fwww.google.com%252F

Lourenço, J. P. O. E. (2022). Monolith Development History for Microservice. INESC-ID

Market Research Intellect. (2023). Global Roofing Software Market Size & Forecast.
https://www.marketresearchintellect.com/product/global-roofing-software-market-
size-forecast/?utm_source=Pulse&utm_medium=019

Microsoft (05 de abril de 2023). A tour of the C# language. https://learn.microsoft.com/en-

us/dotnet/csharp/tour-of-csharp/

Microsoft (10 de noviembre de 2023). Manage requirements, Agile methods - Azure

DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-
requirements?view=azure-devops&tabs=agile-process

Microsoft. (12 de mayo de 2014). http Protocol. https://learn.microsoft.com/en-us/previous-

versions/aa767734(v=vs.85)

Microsoft. (19 de mayo de 2023). Design for scaling - Microsoft Azure Well-Architected
Framework. https://learn.microsoft.com/en-us/azure/well-
architected/scalability/design-scale

Microsoft. (s.f.). Azure REST API reference documentation. https://learn.microsoft.com/en-

us/rest/api/azure/

Microsoft. (s.f.). What Is an Endpoint

https://www.microsoft.com/en/security/business/security-101/what-is-an-endpoint

Newman, S. (2015). Building Microservices. (2ª ed.). O’Reilly Media

Nunes, J. P. K. S., Bianchi, T., Iwazaki, A. Y., & Nakagawa, E. Y. (2021). State of the Art on
Microservices Autoscaling: An Overview. Anais do XLVIII Seminário Integrado de
Software e Hardware

Oracle. (2022). What is a database? https://www.oracle.com/database/what-is-database/

Rensin, D. K. (2015). Kubernetes: Scheduling the Future at Cloud Scale. O’Reilly Media

Thönes, J. (2015). Microservices.IEEE Computer Society

Wolff, E. (2016). Microservices: Flexible Software Architectures. Leanpub