Organizations require robust solutions based on technology. Therefore, software developers have designed and implemented different types of architectures overtime that help software products become resource-efficient and composed of functional requirements. Some architectures deploy their modules, either in one layer or distributed in different layers or tiers. Monolithic architecture, traditionally used in software production jointly with virtual machines, has been a successful and effective formula for small and large-scale projects since the appearance of software systems. It is known that monolithic applications’ performance is affected when the amount of data to be processed increases or exceeds a certain level of capacity. There have emerged diverse solutions through time, e.g., migration to new technologies, management of independent services, and more powerful servers. In the long term, a weak solution choice (i.e., defects in the software, configuration inconsistencies on modularity, cohesion, and coupling, and lack of security levels) could generate higher resource expenses. In the last two decades, innovation has given rise to new architectures that propose optimal solutions. In this sense, the microservices architecture is gaining space and will be part of the decision-making process in technical, financial, and marketing areas [1
]. Microservices are replacing monolithic architecture systems, narrowly focused on the distributed system while having an isolated service [2
One of the concerns when applying microservices is related to the efforts needed to implement and scale every microservice to the Cloud. Additionally, companies that deploy microservices may use different automation tools, such as DevOps, Docker, Chef, Puppet, and automatic scaling. The implementation of such tools saves time and resources. Unfortunately, it requires further development, migration, and integration. Therefore, to gain agility, independent growth, and scalability, the infrastructure costs are the main concern for companies that adopt the mentioned patterns [3
]. Another issue is the orchestration of microservices in production [4
]. Moreover, technical challenges in which microservices provide a solution lead to organizational challenges. Even if the organization may solve most or all of the appearing technical issues, the organization’s structure and skills also need to be compatible with the new architecture [5
]. Although various solutions already exist, the process of migrating from monolithic to microservices architectures still lacks accuracy measurement. Moreover, a brief literature review uncovered some differences in the performance of these architectures [6
Based on the given issues, this study focuses primarily on a compilation of results from established research about the evaluation of both architectures. Secondly, it focuses on determining the performance and the relationship between different variables such as CPU, memory consumption, network performance, disk operations, and restrictions such as development time, integration, and migration effort of an application that proceeds from a monolithic structure towards one of the microservices. Indeed, this is complementary to [7
] and an expansion of our previous work published in [8
], where the data from those measurements will let us present a complete critical analysis, and new knowledge related to the evolution from Monolithic to Microservices architectures, including their performance, and development complexity. We also analyze a complete state-of-the-art to assume a critical position regarding what remains to be performed in the given context.
Furthermore, we evaluated two different scenarios, of which one comprises an application based on a monolithic architecture that works on a virtual server with KVM. The other scenario deploys the same application, based on a microservice architecture that runs in containers. Both cases were exposed to stress tests of similar characteristics and with the same hardware resources. For its validation, we applied the non-parametric regression mathematical model to explain the dependency relationship between the known performance variables. The results and the corresponding comparisons allowed a decision that directly focused on efficient resources management and software operation efficiency. Among the main contributions of the current study, we can consider: (1) The construction of a critical analysis of research production about the comparison of performance between monolithic versus microservices architecture. (2) A critical review of variables and constraints that impact the performance of architectures migration and a critical analysis of the evolution from monolithic to microservices architectures in terms of their applications, efficiency, and development complexity. (3) An evaluation of response times and resource consumption of microservices architecture; this would justify adopting such architecture based on its modularity as a new business technology or in applications of new technological trends. (4) A quantitative comparison of monolithic versus microservices architectures through the mathematical non-parametric regression model that explains the dependency relationship between the selected variables, this will be required to decide when to use such architecture.
The remainder of this article is organized as follows. Section 2
discusses the state-of-the-art, while Section 3
presents the theoretical framework. Section 4
describes the experimental design, including an explanation of the mathematical model applied to validate the preliminary results. Section 5
details the evaluation process of both architectures as well as their findings and includes a discussion. Finally, Section 6
presents the conclusions and future work lines.
2. State of the Art
This section presents state-of-the-art defined as the contemporary research of the existing research in the field of interest. The current study has focused on reviewing the current situation of knowledge and research products to take the amount supply of it while creating new training and research scenarios that cover such prevailing problematic domain. Hence, several of them, given their familiarity, have been detailed described further below:
The study proposed by Stubbs et al. [2
] explores container technology and the challenge of service discovery in microservices architectures. The authors introduce Serfnode, a decentralized open-source solution to the service detection problem, based on the Serf project. Serfnode is a non-intrusive Docker image that constructs one or more arbitrary Docker containers. With this, they described the building of a file systems synchronization solution between Docker containers using Git. Given the conclusions of this study contributed to our research as it allowed us to identify Serfnode that unites Docker containers with another group of existing clusters without affecting the original container’s integrity. Likewise, Serfnode allowed monitoring and supervision mechanisms, which complemented the containers perfectly since they enable complete isolation and independence with the software running in each of the shared environments. While containers can simplify the deployment and distribution of individual components, they do little to address the concern of inter-service communication over a complex network. In conclusion, this study explores other options that allow us to achieve the most out of Microservices and containers.
Villamizar et al. [3
] presented a cost comparison of a Web application developed and implemented using the identical scalable scenarios with three different approaches concerning the performance tests, the cost comparison, and the response time. The first evaluation included the testing and comparing the performance and infrastructure costs of the three architectures, defining three different business scenarios. Finally, the third evaluation, comprised to identify the performance of how each architecture affects the response time to requests during peak periods, as they determined the Average Response Time (ART) during performance tests. The test results indicated that the microservices have been able to help to reduce the costs of the infrastructure when compared to standard monolithic architectures. This given study contributed to ours as it encouraged us to consider different comparison scenarios and to establish evaluation metrics or indicators.
Al-Debagy and Martinek [6
] presented a comparison between microservices and monolithic architectures in terms of performance. Two test scenarios were established to compare such performance. Another test scenario was created to examine the effect of different technologies on the performance of the microservices application. The authors concluded that microservices and monolithic applications might be able to have a similar performance within an average load in use. In the case of a lower load, with an amount of fewer than 100 users, the monolithic application may work slightly better than the microservices app. Therefore, the monolithic application is recommended for small applications as used only by a minor amount of users. In the second test scenario, the results were different in terms of performance, as the monolithic application indicated an improved performance on average. Therefore, the app can handle requests at a higher speed, so that the monolithic application may be used when the developer especially points to the application to process requests faster. A further test scenario included a comparison between two microservices applications with different service discovery technologies such as Eureka and Consul. 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.
Guaman 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.
Akbulut and Perros [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.
Singh and Peddoju [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. The results indicated that the application developed using the microservice approach and deployed using the proposed design reduces the time and the effort for deployment and continuous integration of the app. Their results also confirmed that microservice-based implementation outperforms the monolithic model due to its low response time and high throughput. Our experimental results indicate that Containers are adequate launchers for microservice-based applications compared to virtual machines (VMs).
There are several proposed studies concerning the discussion of the advantages and disadvantages of migration from a monolithic architecture to one of the microservices. Ponce et al. [12
], analyzed a rapid review of twenty migration techniques adapted from published studies about the migration from a monolithic architecture to microservices. Taibi et al. [13
] investigated the technical debts of migration from an inherited monolithic system to microservices. They were concluding that the movement to microservices allowed to reduce the technical debt in the long run. Lastly, Mazlami et al. [14
] presented a formal microservice extraction model that allowed an algorithmic recommendation of candidates in a refactoring and migration scenario. The model is implemented in a web-based prototype.
In the same context, the study of Kalske et al. [4
] has been about the evolution challenges when moving from monolith to microservice architecture. Hereby, the objective was to identify the reasons why companies decided to perform such a transition and identified the challenges such companies may face during this transition. The conclusion was that when a software company grows big enough and starts facing problems regarding the size of the codebase, which is the moment when microservices may be an excellent form to handle the complexity and size. Even though the transition provides challenges, they may be easier to solve than the obstacles that monolithic architecture presents to the companies. Bures et al. [15
] proposed the identification of business applications transactional contexts for the design of microservices. The emphasis has been to drive the aggregation of domain entities by the transactional settings where they were executed. Fritzsch et al. [16
] discussed the notion of architectural refactoring and subsequently compared ten existing refactoring approaches, which were recently proposed in the academic literature. The candidates for this review were obtained from only three academic search engines. Furthermore, the selected refactoring techniques have been investigated only theoretically.
Within the same circumstances, Kecskemeti et al. [17
] developed a methodology to divide monolithic services into several microservices. The created microservices through the proposed method were derived from a common ancestor (previously available as a monolithic service). Kamimura et al. [18
] presented a case study on a small application and a further case study on a practical industrial use with preliminary evaluation by developers. The method supported the extraction of candidates for microservices by analyzing the source code applicable to large inherited codes. Bucchiarone et al. [19
] presented an experience report of a case study from the banking domain to demonstrate how scalability looks favorable when re-implementing a monolithic architecture in microservices. Djogic et al. [20
] presented the architectural redesign of the SOA integration platform (service-oriented architecture) following the principles of microservice design. The microservices approach is the decomposition of software components and software development organizations’ ability to consolidate themselves in small independent teams that may select different programming languages and technologies for operation and work independently. Acevedo et al. [21
] implemented a development methodology of which the purpose has been to propose procedures that modify a monolithic system to an architecture based on microservices. The manuscript describes each of its phases briefly and explains its execution in an open-source monolithic application until the transformation to microservices is completed. The results yielded that microservices reduces software maintenance times, facilitates application scalability, and simplifies maintenance, while task automation reduces implementation times, allowing quality assurance.
Regarding the transition from monolithic to microservices, Sarkar et al. [22
], considered a complex industrial application that runs on Windows and needs to be migrated to a microservices-based container architecture. The authors analyzed the architectural features of the app and examined its availability for migration. Escobar et al. [23
] presented an approach to modernize legacy applications in microservices. The authors proposed a model-centered process to analyze and visualize the current structure and dependencies between business capacity and data capacity. The results indicated that the EJB data diagram improved the application’s understanding and helped architects analyze the relationship between EJBs. Debroy and Miller [24
] discussed architecture for the next generation of applications in Varidesk. The results reported details of how they addressed the challenges that arose due to the architectural change in microservices. They also presented a novel idea of how the infrastructure itself that supports continuous integration and implementation channels for the various applications may also have its own. Chen and Col. [25
] proposed a top-down analysis approach and developed a decomposition algorithm based on data flow. The comparison and evaluation proved that its identification mechanism based on the flow of data could offer candidates more rational, objective, understandable, and consistent microservices through a more rigorous and practical implementation procedure.
Finally, Sarita and Sunil in [26
] presented an approach on how to transform an existing monolithic application into a microservices architecture. They also outlined a proposed strategy for building and shipping microservices using Docker. The proposed study presented an approach to transforming an existing monolith system into microservices architecture using Dockers in the cloud as a strategy. The focus of their article differs almost entirely from the current study. In this case, a proposal is formulated for a general procedure that may be used to transform a monolithic application to Microservices. The conclusions lack any contribution, meaning that there is nothing quantifiable to determine whether there were real advantages or disadvantages. The procedure that they exposed is literary. However, an interesting point was the inclusion of agile methodologies as a suggestion for its development. The architecture they proposed is identical to that presented on all official sites. However, our proposal is different as it demonstrates the interaction of a practical and real case (collaborative systems); this is due to the implementation of a management system that allows adaptation and obtaining a substantial benefit from Microservices.
Comparing such efforts with those obtained by the current study, we developed a comparative analysis of the performance of hardware resources and applications between monolithic and microservices architectures. We considered development and production environments. Besides, we evaluated a web application based on a monolithic architecture that runs on a virtual server with KVM. The second scenario documents the identical web application, based on the microservices architecture and running on Containers. The results indicate high productivity, cost reduction, efficiency in the use of hardware resources, and applications that use microservices in containers. Another important fact is that we determine the results during the execution of services in both architectures and contrast their accuracy using a mathematical model. To the best of our knowledge, this has not been addressed in previous studies.
3. Theoretical Framework
In this section, we briefly introduce some features of the monolithic and microservices architectures. Figure 1
is a holistic visual representation of the elements involved in our entire research process. This figure includes the characteristics of the architectures, performance metrics, assessments and comparisons, use of the mathematical model, and the relationships between them. Subsequently, we reviewed variables and constraints that impact the migration from a monolithic system to microservices. At last, we present a critical review of monolithic architectures’ evolution to microservices in terms of their applications, efficiency, and development complexity.
3.1. Monolithic Architecture
In general, the monolithic architecture uses a single development technology, limiting the availability of a suitable tool for each task that the system needs to execute. According to Nielsen [27
], in a single logical executable, any change completed in a section of this kind of system involves the construction and deployment of a new version of the entire system. Most involved aspects or layers of presentation, processing, and storage are a single component of software required to run on a server (See Figure 2
In concordance with the State of the Art section of our study, the monolithic architecture offers some advantages and disadvantages that give rise to confidence or technological drawbacks. It is necessary to know the risks that can lead to short or long-term problems [28
]. Among the most significant advantages, there are stable systems, the full manage system, used by large companies in the world such as IBM, Sun Microsystems, and BMC. The professional services of these companies have a high level of knowledge about their products. Among some disadvantages: they are rigid systems and are difficult to adapt to new needs. The increase in its processing capacity goes through changing the current server for a larger one. Its technology is proprietary, which creates a significant dependency on the client towards the supplier company. Its acquisition, renewal, and support costs are high. We propose some examples of restriction of these kind systems in Section 3.5
Every computer system is required to evolve and to follow trends such as solid-state disks surpassed punched cards. The level of complexity of modern systems requires improvements in both software production and performance. Thus, this means that it has found inevitable defects in the monolithic architecture [29
]. Which, over time, will contrariwise to itself, giving rise to modern architectures such as microservices. There are cases in which applications are more efficient using this type of construction, e.g., firmware, key Logger, and viruses.
3.2. Microservices Architecture
As stated by Martin Fowler [30
], “A microservice architectural style is an approach to developing a single application as a suite of small services, each running in its process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery”. This modern architecture enables creating large, complex, and scalable applications, comprised of small, independent, and highly uncoupling processes, communicating each one using APIs [31
Microservices work as an application composed of small and individual services running in their processes and communicating with light mechanisms. The independence of each one allows it to be tolerant of failures and increases its availability. It is a new culture of automation, with decentralized processes that concede independent deployments, where the whole is modeled around the business domain [5
]. The structure of an application based on microservices differs significantly from a monolithic architecture application (See Figure 2
). Also, it can encapsulate complex and complete client business scenarios. It is unnecessary to update the entire system, except the component related to a microservice or specific container.
3.3. Software Tools for Research and Performance Measurements
In this study, we performed the monolithic application on a Kernel-based Virtual Machine (KVM) solution that implements native virtualization with Linux distributions. The other case is the application with Microservices Architecture orchestrated with Docker. Its purpose is to create lightweight and portable containers that can be executed independently and autonomous of the Operating System. Nevertheless, we mainly used open-source software tools to implement and configure virtual machines as an experimentation platform and for the implementation of the application (See Figure 3
). Furthermore, they were used for stress tests, data collection, and performance measures. The only exception was NewRelic, where a trial version was applied. They will be described briefly further below, in the way as they contributed and supported within this study:
The Kernel-based Virtual Machine is a virtualization technology for Linux systems that turn it into a hypervisor [34
]. The hypervisor provides support for multiple operating systems and enables the virtualization of hardware [35
]. Therefore, it has the advantage of being able to use the functionalities, solutions, and advances of the base operating system, without the need for additional engineering processes. A KVM needs specific system-level components for its operation, such as memory manager, process scheduler, input/output stack, device drivers, and security management. Each virtual machine runs as a Linux process and adheres to virtual hardware such as network cards, CPU, memory, disks, and graphics handler. Its allied application is QUEMU, which is also known as an operating system emulator [36
]. A KVM supports hot migration, i.e., it allows physical servers or even complete data centers to perform maintenance tasks without interrupting the guest operating system [34
]. For ease of use of the KVM, we used a graphical interface virtual machine manager application in the current study.
QEMU is an open-source, a generic virtualizer, emulator machine that allows the creation of the KVM with the Ubuntu Server. By default, this application is used through commands to generate virtual machines. Therefore it is necessary to use an additional application called Virtual Machine Manager (VMM). VMM is a desktop user interface for managing virtual machines through libvirt.
Docker Client and Server is an open platform for developers and system administrators to build, transport, and run distributed applications, whether on laptops, virtual machine data centers, or the cloud. In this research, Docker is focused on managing the containers used to run the various services.
Docker Compose is used to define and run multi-container Docker applications. In our study, it is used to define the configurations of the Microservices environment.
Sublime is a sophisticated text editor for code, markup, and prose. This was used to edit the application code and configurations to be performed to adapt to the environments.
Git is a free version control system distributed as open-source and is used to keep the application (code, files, resources) updated in all environments, thus maintaining the integrity and ensuring that both processes, as well as results, are adequate.
Java8 (JRE) is used only by the Java runtime environment to raise the Agent Server and run JMeter.
MySQL is an open-source relational database management system. It is used in this application in order to store the publications generated in the stress tests.
MongoDB is a NoSQL database system, which is a document-oriented and open source for querying and indexing. In this project, we used it to store the information generated for the Threads and Users.
During the conduction of the tests, we used JMeter [37
] and NewRelic [38
] applications. Both support data collection in real time of the performance of the resources that need to be analyzed. Hereby, the tests focus on CPU and Memory consumption, hard disk drive reading and writing speed, network, and application performance. Following is a brief description of the mentioned tools:
Apache JMeter is a Java-based open-source software tool designed to load the test’s functional behavior and measure performance. We used this tool to configure stress tests and collect information on the application’s performance and response in real time. With JMeter, the scripts were generated for stress tests, allowing them to specify the request conditions in each environment. Also, Server Agent version 2.2 was included as a component of JMeter to collect performance information. The current project was used as a service that supports the collection and interpretation of data generated during stress tests.
Server Agent is a component of JMeter in order to collect performance information. Hereby, we used it as a service that helps to collect and interpret data generated during stress tests.
NewRelic provides a performance analysis service that allows viewing and analyzing amounts of data and obtaining useful information in real time. In the current study, it is used such as JMeter. However, in this case, it predominantly focuses on collecting information about the performance of the environment where the application runs during the stress tests and later analyzing them in real-time graphs.
Containers resemble virtual machines concerning the services they provide, except that they lack a penalty (overhead) produced by the execution of a separate kernel and the virtualization of the hardware components [39
]. Containers enable each workload to hold exclusive access to resources such as processor, memory, service account, and libraries, which is essential for the development process [40
]. They also run as groups of isolated processes within an operating system, allowing them to start fast and maintain. Each container is a package of libraries and dependencies necessary for its operation, resulting in being independent and allowing the end of isolated processes. One of the most critical risks in containers is the poor visibility of the processes which run inside it to the limit of host resources [41
]. Additionally, there are cybersecurity issues as containers lack to include a secure network communication system, which results in leaving them vulnerable to the computer (network) attacks [42
]. For safety, group and permissions are handled with namespaces, which means that users do not have the same treatment inside and outside the container.
Docker is widely gaining ground in terms of container handling; this is how it has developed from being an ambiguous and unknown term Linux Containers (LXC) to become a container manager. Another similar solution is known as Kubernetes. Thus, this is a container orchestration platform that allows us to deploy, scale, and manage containers on a large scale [43
]. This open-source technology is enhancing to be the most used tool by DevOps for large-scale container projects. It has even been suggested as a solution for more interoperable cloud applications packaging [44
]. Initially, Docker used LxC as the default execution environment. However, continuous changes of distributions represented a problem when trying to standardize a generic version.
3.5. A Review of Variables and Constraints That Impact Performance in the Migration from a Monolithic System to Microservices
When a company is created, depending on different circumstances, its applications generally start being Monolithic; this is reasonable, as these systems initially work well within limited settings, requiring less of their equipment. However, as companies grow and evolve, so they also need their application architecture. As systems become large and complex, companies turn into Microservices as a long-term infrastructure solution.
Whitin this context, as an alternative to justify such migration, it is required to determine both architectures’ performance. Therefore, according to [39
], performance can be measured quantitatively, based on some variables such as CPU and memory consumption, network performance, and disk operations speed. CPU consumption
refers to the percentage measured at which the central processing unit was used to process the system’s instructions. Memory consumption
is the percentage of memory that has been used in the execution of a process. Network performance
is the measurement of data transfer, both in transmission and reception of data. Disk performance
is used to yield the efficiency of sequential read and write operations to the disk.
However, to measure qualitatively, in the current study, some examples were considered to be Wix.com, Bes tbuy, and Cloud Elements [47
] is an Israelian software company providing cloud-based web development services). Best Buy
] is an American multinational consumer electronics retailer). Cloud Elements
] is a cloud API integration platform that enables developers to publish, integrate, aggregate, and manage all of their APIs through a unified platform. These companies had to migrate from a monolithic architecture to microservices.
Among its motivations for migration, Wix.com adopted microservices to reverse massive technical problems that had created instability. In 2010, the company started dividing parts down into smaller services to manage scalability better. Similarly, the Best Buy architecture became a bottleneck for deployments. Its downtime was far too long to keep business online. At Cloud Elements, the transition also arose out of necessity, as it was a company experiencing exponential growth. A microservices design would help iterate continuously to meet new demands [47
Wix.com had to invent new patterns of integration, analysis, and fostering a new internal culture among the constraints or obstacles encountered along with the development. In Cloud Elements, its modern design generated debate and conflict. For Best Buy, one of the significant challenges was creating trust. Cultural resistance to the way software is developed and implemented is challenging changes the way people do their jobs. For these companies, almost no support tools existed when they set out on this path. The migration process was not easy. However, in a view towards the past, it has been fortunately a wise decision. However, migrating to a microservices design does not guarantee benefits for all companies. A monolithic codebase may be more efficient and with less overhead for smaller-scale applications. Although implemented, microservices can provide a backbone upon which innovation can thrive. However, the benefits of microservices must outweigh the time spent migrating and maintaining new issues. Staying with a monolithic architecture is probably a much easier task than managing a distributed system, which allows us to deduce that a progressive migration should be generated [47
3.6. A Critical Review of the Evolution from Monolithic to Microservices Architectures in Terms of Their Applications, Efficiency and Development Complexity
There exist some of the companies such as Walmart, Spotify, Netflix, Amazon, and eBay, among others [52
], and many other large-scale websites and applications that have evolved from a monolithic architecture to microservices. The following describes some of the success stories and how their design scheme might be.
Walmart needs to handle some six million page views per minute, with currently approximately some four billion people connected and more than 25 million applications available.
Spotify, which built a microservice architecture with autonomous equipment, provides services to more than 75 million active users per month, with an average session duration of 23 min.
Netflix receives an average of one billion calls to its different services. It is capable of adapting to more than 800 types of devices through its video streaming API. To offer a more stable service, for each given request, it performs five requests to different servers to avoid the loss of the continuity of the transmission [55
Amazon, which migrated three years ago to the microservice architecture, is one of the first of the large companies that implemented it in production. There is no approximation of the number of applications they can receive daily [56
The company, eBay, is one of the corporations with the most optimal vision for the future, being a pioneer in the adoption of technologies such as Docker. Its main application includes several autonomous services, and each one is executing the logic of each functional area that is offered to customers.
For a critical analysis, the design of a microservice oriented application, according to Microsoft [57
], is here described as more detailed. A crucial app that may meet the requirements of the analyzed success stories should be able to control requests by executing business logic, accessing databases, and returning HTML, JSON, or XML responses [58
]. The application needs to support a variety of clients, including desktop browsers running single-page applications (SPA), traditional web applications, mobile web applications, and native mobile applications. It is also possible that the application exposes an API for third-party consumption. Furthermore, it should be able to integrate the external microservices or applications asynchronously. Thus, this approach allows the resistance of the microservices in case of partial errors. The application should also consist of a variety of types of components, such as:
Presentation components are responsible for the control of the user interface and the consumption of remote services;
Domain or business logic, which refers to the domain logic of the application;
The access logic to databases is the data access components responsible for obtaining access to the databases (SQL or NoSQL); and.
Application integration logic, which includes a messaging channel, based mainly on message agents [59
]. The application will require scalability, allowing its vertical subsystems to scale horizontally autonomously as some subsystems will require greater scalability than others [60
Considering, for example, a mobile shopping application with the following microservices: (a) A Shopping cart service that maintains the number of items. (b) A Shipping service that supports for handling shipments and cargo. (c) An Inventory service that allows an organization to react to customer demand rapidly. (d) A recommendation service, which provides recommendations to users. (e) An Order service, which maintains an order history. (f) A review service designed to identify potential service delivery improvements. (g) A Catalogue service that keeps product catalogs [61
Moreover, also considering, e-commerce Web applications [62
], which need to be developed independently with the freedom in the use of technologies. This composition requires programming language on the server-side and the framework on the client-side. Likewise, the authentication service should be used, which subsequently would allow security in access to microservices.
Finally, the orchestration of the containers is required, where the microservices would be deployed. This solution may work significantly better than a monolithic model concerning performance, availability, and response time indicators. Finally, considering rendering applications with mobile platforms such as ANDROID and IOS. On the server-side, there are non-functional components that support the microservices (i.e., Config, Eureka, Gateway, and Composition) and the functional elements. The last ones are authentication microservices, assists, notes, co-participation, surveys, notification, and reports developed with spring boot. Each one will have private access to its database. How could access security be added to services [63
6. Conclusions and Future Work
In the current study, computational metrics such as CPU, disk reading speed, disk writing speed, memory, network reception, and transmission are evaluated for comparing a web application in a monolithic architecture versus the same application using microservices. The mathematical model based on the Non-Parametric Regression Method was applied to validate these studies’ findings. Also, we could accurately validate the results and provide a quantitative technical interpretation. The architecture of microservices with containers proved to be more efficient. This gives rise to discussion topics and is part of the planning that leads to DevOps’ use when time is a priority factor. Our findings indicate that using microservices with containers generally applied in demanding computer systems, at massive scale, and within high traffic allows jobs to be conducted independently hence faster than serialized processed. Containers were the methods used to encapsulate microservices, which simplified configuration. Since it is necessary to deploy the applications to be uploaded to the cloud, it is preferable to use containers and upload them instead of using virtual machines. Its purpose is feasible if the goal is to process a large number of requests in the shortest time possible, regardless of resource limitations and where scalability is a priority. We could also determine that both platforms (monolithic and micro-services) could be used for different purposes and different technological conditions. However, our study demonstrates more efficiency concerning hardware resources, cost reduction, and high productivity when using microservices.
As future work, we plan to optimize a collaborative native monolithic tool by migrating it to microservices. With this, we intend to continue showing the strengths and weaknesses of each of these architectures. Also, we plan the extension of the design and implementation of a users and services management system that optimizes the creation and deployment of containers, using MongoDB as a back end deployed in a Docker container, developed in Node.js, managed in cluster mode for high availability, and works through HTTPS. To solve the overload problem, we will design and implement a load balancer, whose primary purpose will be to respond to requests that come from the management system. The balancer will reply to the management system, with the address URL of the container with the least amount of users connected to it. It will also communicate with each container, every time a user connects to one of them. A high transactional rate must characterize this load balancer. Also, it must be under the principle of microservices and operate independently. Besides, it must collect each node’s status and the number of users per node. Finally, given the increase in cyber-attacks on microservices applications, we will design software solutions to increase these systems’ information security.