Impacto de arquitecturas de microservicios en el desarrollo Web

Este Trabajo Fin de Máster consiste en crear una versión de un TPV utilizando una arquitectura basada en microservicios. Como primera aproximación se ha elegido un subconjunto de tres entidades que están relacionadas entre sí: Gestión de Artículos, Gestión de Proveedores y Gestión de Pedidos. De esta forma, podremos analizar el comportamiento y la comunicación entre los microservicios, y los beneficios y desventajas de este tipo de desarrollo. Tecnológicamente, el proyecto se desarrolla en Java, bajo el framework de Spring y tomando como base el proyecto del TPV, implementando el despliegue continuo a través de Heroku y las bases de datos a través del MongoDB Cloud. Para la gestión del proyecto se utilizó metodología ágil de tipo Kanban. Comparado con el estilo monolítico, la arquitectura en microservicios incrementa la dificultad y complejidad de la solución al momento que proporciona un aumento en la facilidad del mantenimiento y en la encapsulación del código. Los microservicios, al estar separados, aumentan la dificultad del desarrollo cuando es necesario hacer peticiones a otros microservicios. Otra desventaja es que cuantos más microservicios haya, más posibles versiones se soportan. Esto puede ocasionar además un aumento relevante de la cantidad de servidores, bases de datos y repositorios necesarios para tener desplegado al completo el sistema. Esto además implica complicaciones para los desarrolladores. Por otra parte, al estar separados, los microservicios dan la ventaja de ser menos complejos para su mantenimiento, ya que al estar cada uno por separado, el encapsulamiento es mayor que en los monolitos. Otra ventaja que ofrecen los microservicios es la posibilidad de separar distintas mejoras si se desea y la temporalidad de un servicio. Por otra parte, se pueden desplegar más copias de los microservicios más sobrecargados sin necesidad de desplegar la aplicación al completo. Como conclusión general, se recomienda el uso de microservicios en aquellos casos en los que sea posible encapsular ciertas partes del monolito de forma independiente, clara y precisa. Se deben considerar todas las posibilidades antes de tomar una decisión y contar con asesoría de expertos que puedan analizar y definir cuál sería la mejor distribución de microservicios para una aplicación, o si debería considerarse el desarrollo monolítico con alguna arquitectura o patrón específico. Abstract: This Master's Project is to create a version of a POS using an architecture based on microservices. As a first approximation, a subset of three entities that are related to each other has been chosen: Article Management, Provider Management and Order Management. In this way, we can analyze the behavior and communication between microservices, and the benefits and disadvantages of this type of development. Technologically, the project is developed in Java, under the Spring framework and based on the POS project, implementing continuous deployment through Heroku and the databases through the MongoDB Cloud. For the project management, an agile Kanban methodology was used. Compared to the monolithic style, microservice architecture increases the difficulty and complexity of the solution while at the same time providing an increase in the ease of maintenance and in the encapsulation of the code. Microservices, being separated, increase the difficulty of development when it is necessary to make requests to other microservices. Another disadvantage is that the more microservices there are, the more possible versions are supported. This can also cause a significant increase in the number of servers, databases and repositories necessary to have the system fully deployed. This also implies complications for the developers. On the other hand, being separated, the microservices give the advantage of being less complex for their maintenance, since being separate entities, the encapsulation is greater than in a monolith. Another advantage offered by microservices is the possibility of separating different improvements if desired and the temporality of a service. Furthermore, more copies of the most overloaded microservices can be deployed without the need to deploy the entire application. As a general conclusion, the use of microservices is recommended in those cases in which it is possible to encapsulate certain parts of the monolith independently, clearly and precisely. All possibilities must be considered before making a decision and having expert advice that can analyze and define what would be the best distribution of microservices for an application, or if monolithic development should be considered with some specific architecture or pattern