## 2 State of the Art
This test results indicated that the Consul application used as service discovery technology might be preferred compared to the microservices with Eureka service discovery technology. Although this study is similar to ours, the unique difference to our research is that we use containers, while they lack it. [PERSON] et al. [9] developed a performance evaluation in the process of migrating a monolithic application to microservices. Hereby, the models such as NGINX and IBM were analyzed, which allowed the migration of Monolithic to Microservices. The services were implemented using RESTful web services to finally deploy microservices using technologies such as Spring Boot, Eureka, and Zuul. To obtain the performance-related metrics and analyze the advantages and disadvantages of each migration phase, they used as a tool the Apache JMeter. Each version of the application's performance was evaluated and compared with the performance of the metrics. This allowed them to determine which microservices architecture exhibits a better execution in terms of a performance quality attribute. The response time and error rate of unprocessed requests were faster compared to other applications involved in migration. This study is similar to ours. However, the significant variance with the current study is that the authors lacked to use containers. However, they agreed that before the use of the microservices approach, a model is required for the successful migration and, thus, evaluates performance and scalability. In the migration process, the study application was modified at the code and design level, including patterns such as Singleton, Facade, Choke, Single Service per Host, Service Discovery, and API Gateway. It has used to evaluate performance as an attributed quality in each phase of the migration process. This system was configured to generate results regarding the use of resources such as CPU, memory, network, and access to databases. [PERSON] and [PERSON] [10] obtained performance results related to query response time, efficient hardware usage, hosting costs, and packet loss rate for three microservices. Complex architectures were associated with long-term development cycles and additional license expenses for third-party applications. Also, the employment of more qualified developers and test personnel in the team has been another factor that increased the total cost. However, such architectures increase productivity and lower prices as they are energy efficient in the long term. In general, there is no single microservices pattern that is better or more efficient than the others. Instead, each design pattern works best in different settings. They concluded that Microservices are still undeveloped, and therefore, best practices of their use are critical to their successful adaptation and incorporation in the future of Service-oriented architecture (SOA). This work contributed to ours due to their case studies' experience to obtain the results using design patterns. They used Node JS and Python to implement microservices, MongoDB for the data platform, and Docker Compose for the container environment. This study emphasizes that an entire ecosystem needs to be orchestrated with Kubernetes, Mesosphere, or Docker Swarm, together with monitoring at the System infrastructure level. [PERSON] and [PERSON] [11] explained a comparison between deployments of microservice versus the implementation of a monolithic design. These authors deployed the proposed microservices on the Docker containers and tested them using a social networking application as a case study. Due to the comparison of the performance, they installed and used Jmeter8 to submit continuous requests to both designs. For the monolithic design, they used a web API to transmit the request to the application. In contrast, for a microservice design, they used HAProxy to send requests to the target service.