Abstract
Microservices are small-scale services that can operate independently. An application consisting of microservice units can be developed independently as a service unit, and it can handle individual logic without being affected by other services. In addition, it is possible to rapidly distribute the configured microservices by a container, and a container orchestration technology that manages the distributed multiple containers can be realized; thus, it is possible to update and distribute the microservices separately. Therefore, many companies are moving away from existing monolithic structures and attempting to switch to microservices. In this paper, we present a method for reconstructing a monolithic application into a container-based microservice unit. The microservices of data units are derived through the collection and analysis of monolithic design data. Furthermore, we propose a method to generate a template script based on deployment design data so that the derived microservice and support distribution can be implemented in a container environment. The results of a case study conducted verified that the container-based microservices deployed in this study work properly. In addition, for the development of monolithic applications and the development of container-based microservices presented in this paper, we confirmed that developing on the basis of microservices is efficient by conducting execution time performance evaluation for API calls at various iterations. Finally, we show that microservices constructed using the proposed method have higher reusability than those constructed using existing methods.
1. Introduction
Serverless computing is an execution model in which applications are developed and distributed based on microservice units without the need to build a separate infrastructure in a cloud environment [1]. Currently, major cloud companies are providing serverless computing technologies, such as Amazon AWS Lambda [2], Microsoft Azure Functions [3], and Google Cloud Functions [4], to their services. By 2018, serverless computing became the fastest-growing cloud service, with a reported growth of approximately 75% between 2017 and 2018 according to RightScale’s “2018 State of the Cloud Report” [5]. Forbes magazine has suggested that serverless architecture will be among the top ten technologies of note over the next five years until 2022, and it is emerging as a next-generation cloud computing paradigm [6].
Microservices, which constitute the core concept of serverless computing, are small-scale services that can operate independently. Applications consisting of microservices are loose coupling structures with different microservices; hence, individual updates are possible without knowing the internal structure of applications. Therefore, this structure has the advantage of being rapidly developed and distributed compared with the existing monolithic structure and it is highly reusable [7].
Recently, container orchestration technologies, such as Kubernetes [8], Docker Swarm [9], and Mesosphere [10], have emerged for supporting container distribution management. They are suitable for flexible management of large-scale microservice-based applications because they enable batch and automatic container creation as well as distribution management of numerous containers.
Because of these advantages of microservices and container orchestration technologies, many companies are attempting to adopt them as alternatives to the existing monolithic application structure in order to develop and distribute microservice-based applications as well as to deploy them on a container basis. However, research on how to reconfigure existing monolithic applications into microservice units remains limited [11].
There are many considerations, such as microservice size, API configuration, database processing, and security, depending on the size of the service when it is intended to reconstruct a complicated monolithic structure into a small and independent microservice [12]. In particular, one of the problems is that it is difficult to change the microservice unit because the microservice size is not fixed. Moreover, there are parameters that need to be manually defined for container-based distribution and management, such as initial container management number and network configuration, even in the case of configuration as a microservice [13]. In addition, converting existing monolithic applications to microservices requires in-depth understanding of the structure of existing monolithic applications. Therefore, methods for deriving microservices based on software architecture [14] or data flows [15] have been proposed. Evolving into an object-oriented development environment, the UML- (Unified Modeling Language-) based application design and development approach is being adopted. Thus, there is also a need to convert existing UML design data into microservices based on the application.
To overcome these problems, this paper presents a method that analyzes the design data of monolithic applications and reconstructs them into container-based microservices. We classify the UML design data of a monolithic application by hierarchy, construct a graph that can be converted into microservices, and derive microservices of an entity unit.
Based on the derived microservices and deployment design data, a method to automatically generate a template script that can be distributed and managed in a container orchestration environment is proposed. In addition, a case study is conducted to verify the validity of the proposed method and an actual reorganized microservice is shown to be deployed and executed in a container orchestration environment. Finally, through comparison and evaluation, the proposed method is shown to be superior to existing methods in terms of reusability.
2. Related Work
2.1. Microservices
Rademacher et al. [16] investigated the distinguishing features of microservices by comparing existing service-oriented architecture (SOA) concepts. They explained that microservices are more independent than SOA and that the size of microservices should be set to units that can be developed by each development team. They also showed that the coupling between microservices is extremely low and that the interface is highly abstracted. In our paper, the concept of interface is used in the construction method, and it is defined to support communication between the user and the microservices.
Dragoni et al. [17] suggested that the microservice configuration should consist of units that carry a single business capability. If the business capability unit is large, it needs to be divided into two or more smaller units, and in the microservices, the database is defined as a distributed-type database rather than being shared in a centralized manner. In our paper, we defined a business capability as an entity that is a database unit.
Yu et al. [18] proposed a reference architecture model for constructing a microservice environment in an enterprise environment. They classified three types of microservices in the proposed architecture model. The interface consists of user input, business logic that processes the input value, and a persistence layer, which contains the data area. We classify microservices into presentation, business logic, and persistence layers using the three-layer concept presented in this study.
2.2. Microservices Construction Methods
Mustafa and Marx Gómez [19] proposed a method for constructing microservices in the runtime environment. In their proposed method, after configuring a similar time zone as one session, sessions are separated when there are numerous accesses in a specific session. However, it was not confirmed whether the services that are accessed frequently clearly perform one business capability.
Mazlami et al. [14] defined a microservice as a class group unit in which changes occur for similar purposes. They constructed a graph in which a vertex corresponds to a class and an edge has a weight according to the degree of similarity of change between classes; then, they applied a clustering algorithm that removes low-weighted edges. However, it was not possible to verify the type of implemented microservices constructed in the related research. Moreover, it was not possible to verify whether the group unit of classes actually performed one business logic.
Chen et al. [15] analyzed data flow diagram (DFD) design data for monolithic applications and defined a group of functions and output data as a single microservice unit. In the existing DFD, they defined a rule for each step and connected the data related to the function that performs one business capability. Furthermore, they constructed the refined DFD data and extracted them into microservices. However, when we applied this method, completely independent microservices were not configured because the data can be associated with other functions.
2.3. Container Orchestration
Docker [20] is a container software platform for rapidly building and deploying applications in container form. It runs on the host OS without being allocated a separate OS or resource, unlike a typical hypervisor-based virtual machine. In addition, independent applications such as virtual machines can run a wide variety of applications. Docker can be deployed independently for each microservice application, and it can drive highly efficient microservice applications.
The main problem with Docker is that it does not have the ability to manage its lifecycle when dealing with a large number of containers. To overcome this problem, a container orchestration concept that supports container management and Docker Swarm [9] was developed. Docker Swarm is an open-source software that supports container orchestration in Docker. The client can manage Docker through Swarm Manager, and Swarm Manager sends a command to Docker daemon to find and assign the appropriate node to create the container.
Kubernetes is an open-source container orchestration platform originally developed by Google. Currently, major cloud vendors, such as AWS, IBM, and Microsoft, are providing cloud services in conjunction with Kubernetes, which is becoming a de facto standard. The structure of Kubernetes can be divided into master and node. The master manages several nodes, and a node creates and executes actual containers. Kubernetes’s container management functionality is accomplished through template scripts specified in YAML or JSON format. In Kubernetes, the container unit is a Pod that can be created and executed in the form of a template script. ReplicaSet can control these Pods. The scheduler can manage and maintain multiple Pods using the template script. Finally, there is a service template script that supports network functions, while external network client services, such as LoadBalancing and ServiceDiscovery, can be supported by connecting external client containers.
Kubernetes utilizes a YAML file that defines the desired state for deploying an application—e.g., how many ports it wants to service—by attaching labels to various objects, such as Pods, ReplicaSets, Services, and Volume, and passes it to the API server. In Kubernetes’ internal mechanism for creating a new Pod, the ReplicaSet controller included with the Kube controller monitors the ReplicaSet and checks if there is a Pod that satisfies the Label Selector condition defined in the ReplicaSet. A new Pod is created by configuring the Pod template and passing it to the API server.
To distribute constructed microservices in a Kubernetes container environment, we propose a method that automatically generates a Pod, ReplicaSet, and service template script files from monolithic design data.
3. Container-Based Microservice Reconstructing Method
The process of reconstructing microservices by analyzing monolithic design data is outlined in Figure 1. To reconstruct the design data as microservices, we perform the detailed activities in four steps. The explanation for each step is as follows.
3.1. Analyze Monolithic Design Data
In this step, the monolithic design data of the microservice reconstruction target are collected and analyzed. It comprises the following activities:(i)Collect monolithic design data: the type of design data to be collected is the class diagram of UML design data defined by the ECB pattern [21]. Table 1 summarizes the types and examples of stereotypes in UML design data. The three stereotypes defined in Table 1 are collected.(ii)Classify 3-tier layer: classes defined as stereotypes are collected from UML class design data and classified in a 3-tier hierarchy. Here, 3-tier implies presentation, business logic, and persistence.(iii)Map layer by class type: a 3-tier hierarchy is defined, and hierarchical mapping is performed. The stereotypes are as follows: <<Boundary>> type is the presentation layer, <<Control>> type is the business logic layer, and <<Entity>> type is mapping to the persistence layer, as shown in Table 1.
3.2. Extract Microservice
In the microservice extraction step, a graph is constructed on the basis of class information collected and classified in the previous step; then, the following activities are performed to derive the microservices of the entity unit:(i)Analyze class relationship and construct graph: a graph is constructed consisting of vertex corresponding to a class and edge representing a calling relation. The vertices classified in the presentation layer according to the mapping relationship shown in Table 1 are defined as boundary vertices (expressed as “bv”). Verices classified in the business logic layer are defined as control vertices (expressed as “cv”). Vertices classified in the persistence hierarchy are defined as entity vertices (expressed as “ev”). In addition, the calling relationship between classes in the UML design data is represented as an edge, as shown in Table 2. Generalization and realization: in relation to generalization and realization, Class A is a parent class, and it is inherited or implemented. Therefore, Class A influences Class B and calls it. Dependency and association: in relation to dependency and association, Class A calls and uses Class B’s object and method; thus, Class A is affected when Class B is changed. Composition and aggregation: in relation to composition and aggregation, Class A is included as a part of Class B; hence, if Class B is changed, Class A will be affected.(ii)Reconstruct business logic-centric graph: the microservice conversion graph is reconstructed so that the configured graph can be derived by the microservice unit. The presentation and persistence layer vertex and edge that are not directly connected to the vertex configured in the business logic layer are removed, and the graph reconfigured.(iii)Extract microservice based on main entity: in this final activity of the microservice derivation step, a microservice unit having one entity is constructed. Here, entity is a vertex class element classified in the persistence layer. It traces the vertices of the business logic and presentation layer that are called in the entity and constructs it. However, as a specific control class, which is a vertex of the business logic layer, may be called by many entity classes, the configuration area may overlap. To overcome this problem, a single main entity is determined for the control to resolve the redundancy in the configuration area. Here, one main entity for control is determined by calculating the ratio of the method that calls the entity class and the average value of the method name similarity.
If the main entity calls the other entity directly from the control point of view after constructing the microservice of the entity unit in the control of the determined entity, the design data are changed to be called to the entity through the boundary class of the presentation layer. This is because communication between microservices must be performed by API [22]. This creates a new boundary in the control-entity relationship that is called directly and changes the design data in the control-boundary-entity relationship.
Figure 2 shows the pseudocode of extract microservice based on main entity to derive a microservice in the main entity unit. The input element is graph G, and the output element is the constructed microservice graph. It repeats to determine the main entity of all control classes in the graph. If the control class calls more than one entity, calculate the ratio of the method that calls the entity and the method name similarity of the entity and determine the entity with the higher ratio as the main entity. Otherwise, the class associated with one entity will automatically determine the main entity to be associated with the entity. When the main entity is determined, iterate as many as the number of entities and proceed with the microservice configuration in entity units corresponding to the main entity. Entities for which the main entity is not determined are excluded from the microservice configuration. Finally, when the control is connected to the entity or control class of another microservice, a new boundary is created and the connection is changed to connect the microservice through the created boundary.
3.3. Implement Microservice
In this step, the API connection between the identified microservices is implemented according to the hierarchy:(i)Implement microservice by 3-tier: implement vertex classes classified in each layer as shown in Table 3. Developers can build on the basis of design data using development tools or languages for each tier.
For example, when the microservices are configured with the following three boundaries, one control, one entity, three APIs, one controller, and one DB are implemented, as shown in Figure 3, for each layer.
3.4. Deploy Microservice
The final stage of the reconstructing microservice process is microservice deployment, in which a template script is generated that supports deployment and management in a container orchestration environment based on the implemented microservices and UML deployment design data. Here, the design data collect the class and deployment design data, and the microservice refers to the microservice implemented in the Implement Microservice step. The main template scripts are Pod, ReplicaSet, and Service, which are the three main types of template scripts that run on Kubernetes, the container orchestration platform. The process of generating a template script based on the design data and microservice information is shown in Figure 5.(i)Collect deployment elements: a key template script specification model for deployment and management in the Kubernetes environment, which is a container orchestration environment, is defined as shown in Figure 6. Common info refers to elements that need to be described in all types of template scripts, and Pod, ReplicaSet, and Service are the types of template scripts required to manage container distribution. A description of each type is given in Table 4.(ii)Generate template script for container deployment: we derive the collection elements from monolithic design data to generate template script specification model elements.(1)Microservice information: the microservice information includes information about the name and number of the extracted microservice.(2)Class design data: the class information collects the class design name.(3)Deployment design data: it is classified into node information and connection information. The node information collects the node name, resource, OS, and application to create the container. The connection information collects the external and internal port, protocol, and external connection IP for communication with the outside of the container.
Table 5 is a mapping table that maps the template script elements to be generated and the collection elements defined in the monolithic design data. In the case of a Pod, a script is generated by mapping elements collected from class information and node information. ReplicaSet is generated by mapping the class design name, the number of microservices configured, and the node information for generating template information. Finally, the service generates a script by mapping the connection information collected from the deployment design data.
A method for collecting UML design data based on a mapping table and generation of a template script is shown in Figure 7. First, the UML design data are converted into a data format (.XMI) such that they can be parsed. Next, elements defined in the mapping table of the second transformed XMI data that are parsed are collected. Finally, based on the extracted collection elements, the template script type is generated.
4. Case Study
In this section, we present a case study based on the process of reconstructing an “online ticket transaction system,” which utilizes the actual UML design data, by using the method presented in Section 3. We also verify that the reconfigured microservices operate and run correctly in the container orchestration environment.
The case study “online ticket transaction system” is a system in which sellers and users can register, make inquiries, and sell events (or tickets) online. Figure 8 shows a monolithic application’s UML design data of “online ticket transaction system”; we explain the extraction of microservices and deployment of container-based microservices in Sections 4.1 and 4.2, respectively.
4.1. Case Study of Monolithic Design Data Analysis and Microservice Extraction
In the first stage, i.e., the monolithic design data analysis phase, UML class design data of the “online ticket transaction system” are collected. As a result of classifying the collected data by hierarchy, 10 boundary classes, eight control classes, and five entity classes were derived. Table 6 summarizes the hierarchical classifications for each stereotype.
Analyze the relationship between classes and construct an edge that points in the direction of the calling method. Figure 9(a) shows G(E, V) consisting of a vertex classified by class type and an edge as a calling relation. In this case, the reconstruct business logic-centric graph method is adopted to reconstruct the microservice conversion graph centered on business logic. As shown in Figure 9(b), as a reconstruction result, we can construct a conversion graph G′(E, V) capable of microservice derivation.
Based on the given microservice conversion graph, the microservice derivation of the main entity unit is performed as shown in Figure 10. The “online ticket transaction system” currently consists of five entities (Member, Report, Event, Ticket, and Payment). To construct the microservice of the entity unit, the configuration is executed by tracing the direction of the call from each entity. As a result, as shown in Figure 10, the microservice configuration areas overlap in ev3, ev4, and ev5.
To address the case in which the microservice configuration area is overlapped, one main entity is determined per control vertex. Figure 11 shows the process of determining the main entity of cv6 among cv6, cv7, and cv8 classes in which microservice overlap occurs. cv6 (TicketViewController) calls ev3 (EventInfo) and ev4 (TicketInfo) methods. Therefore, cv6 must determine the main entity of either ev3 or ev4; it is calculated by applying the method calling and the method name similarity as decision criteria. The rate of the invoking method is calculated as of 25% because ev3 calls one of the four methods that ev3 has. In the case of ev4, one of four methods is called; hence, again, the rate is calculated as 25%. The name similarity is calculated at a rate of 100% because it includes a method called “Ticket” in all the methods of ev4 called “TicketViewController,” which is the class name of cv6. In the case of ev3, the rate is calculated as 0% because it does not include “ticket” and “transaction” methods. Finally, the invocation method and name similarity calculation values are averaged, respectively, and hence, ev3 is calculated as 12.5%, ev4 is calculated as 62.5%, and ev4 is determined as the main entity.
As with cv6, the main entity is determined in the same way for cv7 and cv8, which invoke various entities. As a result, ev4 is determined as the main entity of cv7 and ev8 as well as of cv5, and five microservices of entity units are configured without overlapping the configuration area, as shown in Figure 12.
If the microservice configuration area is not duplicated, but the existing control accesses other microservice entities (cv6 ⟶ ev3, cv7 ⟶ ev3, and cv8 ⟶ ev4), it changes the design data to create a new boundary and invokes it in the case of a relationship that directly calls the entity. As shown in Figure 13, in the case of cv6, cv7, and cv8, which are microservice controls that directly call other microservice entities, a new boundary (new bv1, bv2, bv3) is created to change the design data to perform boundary communication between microservices.
4.2. Case Study of Microservice Implementation and Deployment
The reconfigured microservices that are extracted in the previous step are implemented by hierarchy and implement interconnection APIs between microservices. Figure 14 shows the process of implementing member microservices among the microservices configured in the “online ticket transaction system” according to the hierarchy presented in Table 3. In this case study, ExpressJs, which is a package module of Node.js API, is used for API implementation of the presentation layer. The controller of the business logic layer uses node.js on the basis of JavaScript and MySQL as the database of the persistence layer.
Figure 15 shows the actual source code of member microservice implemented according to the classified layer. In the case of the API, it is implemented on the basis of the internal input method parameter information of the boundary class. In the case of membership of bv1, the API path is implemented as “/user/signup,” and the input parameters are implemented to receive app id, app pass, and name. In the case of the controller, it is implemented on the basis of the name and method of the control class. It is created and invoked in conjunction with the API path. Finally, in the case of DB, we implement the table name on the basis of the entity class name and field name as SQL statements based on the method parameter.
After implementation by layers, connection of API is implemented between microservices. The process of implementing a new bv1 among the three new boundaries generated in the microservice extraction step is the same as that shown in Figure 16. The new bv1 is implemented so that cv6 is a boundary containing information to call the EventSelect () method of cv3, and the new bv1 is implemented to invoke EventSelect () with API Path “/event/EventSelect.”
After implementing the microservices, a template script is generated to support distribution management in Kubernetes, which is a container orchestration environment. The design data on the left-hand side of Figure 17 are the UML deployment design data of the “online ticket transaction system,” consisting of two nodes and one connection information. We export the UML deployment design data to an XMI file for creating the Pod, ReplicaSet, and Service template script according to the method shown in Figure 7.
The right-hand side of the output screen of Figure 17 is the result of exporting design data as XMI data. The nodes and connection information are defined as <element> and <connector> tag value, respectively. Tag internal attributes are defined as name, stereotype, type, and value, where name is the name of the node or connection information, stereotype is the type of the design element (OS, Device, etc.), type is the property of the type (RAM, CPU, etc., for the device), and value is the value for type. For example, DBserver, which is a node name, has a device stereotype, the type of a device is CPU, and the value of RAM is expressed as XMI data with one core and 256 MB specified as the value. The mapping table for the collection element of the transformed XMI data is defined in Table 7 and the XMI data are parsed as shown in Figure 18.
Based on the mapping table of the extracted values, a template script for each type is generated as shown in Figure 19. The area marked with ① denotes the process of creating the name of the Pod template script per microservice name. The area indicated by ② denotes the process of generating the replica value of the ReplicaSet template script by the number of configured microservices. The area marked ③ denotes the process of extracting class diagram information and creating Pod, ReplicaSet, and label of the Service template script. The area marked with ④ denotes the process of extracting the node information of the deployment diagram and creating the container and template information of the Pod and ReplicaSet template script. The area marked with ⑤ denotes the process of extracting connection information and creating the Service template script.
4.3. Microservice Verification
We verified that the template script file generated in Section 4.2 works correctly. For the verification, Kubernetes, which is a container orchestration environment, was constructed and one master and two nodes were driven into a virtual machine environment. In the case of the master, 2 vCPUs and 4 GB of RAM were allocated, and for a node, 2 vCPUs and 2 GB of RAM were allocated. The result of executing the three generated types of template scripts in the Kubernetes environment is shown in Figure 20. Here, no. 1 is a screen for inquiring about all the Pod states in the Kubernetes control environment. As a result of executing the generated script, five Pods (userpod, reportpod, ticketpod, eventpod, and paymentpod) were created. Furthermore, it was confirmed that all the Pod states were normal operation. No. 2 is the result of executing the template script of ReplicaSet. Currently, five Pods are managed through labeling and we can confirm that all the Pods are running through the Pod status. No. 3 is the result of executing the service template script. It was confirmed that five Pods by labeling are connected to each endpoint by configuring the protocols, port information, and external IP.
(a)
(b)
(c)
When the implemented microservices were deployed in the Kubernetes environment, we verified that they work correctly. As shown in Figure 21, after implementing the user microservice of the “online ticket transaction system,” it was distributed to the container environment (userpod). To check whether the distributed member microservice executed, we confirmed the response using Postman [23], an API test tool.
As shown in Figure 22, after the API test, the request was sent to the userpod and it was confirmed that the response was received. The left panel of Figure 22 shows a situation in which a signup API (user/signup) is called from the host information of the userpod 10.244.5.2. To sign up for membership, we sent information (app id, app pass, and name) directly to the user in JSON form and confirmed that the information input from the userpod is processed. The upper right panel of Figure 22 is a command for querying database information in dbserver of userpod before an API call. The bottom right panel is a screen to query database information of dbserver of userpod after an API call. As a result of the API call, it was confirmed that the information input from the database information of dbserver of userpod was generated.
5. Microservice Construction Method Evaluation
We analyzed the distinguishing features and advantages of the presented microservice construction method in comparison with existing related methods and also evaluated them in terms of reusability.
5.1. Comparative Analysis with Related Methods
Table 8 summarizes the evaluation of existing microservice configuration methods and the proposed microservice configuration method according to the stated criteria. The criteria are defined with reference to the microservice configuration standard [16–18]. A microservice is defined to operate independently (independence), microservice interface communication is included (interface), business capability is performed, and independent data elements are included (data store).
Existing related studies have shown that a composed microservice can have an independent configuration, but it cannot be clearly confirmed whether it has a single business logic or whether it can have a single business logic but not be an independent configuration. However, the proposed method performs independent configuration and a single business logic and is classified as 3-Tier. Thus, it can have both an interface element and a database element related to input/output at the same time.
5.2. Performance Evaluation
For performance evaluation, we implemented the monolithic code of the “online ticket transaction system” and the microservices-based code according to the method proposed in this paper, respectively, on the same host, as illustrated in Figure 23.
As shown in Figure 24, the API execution time was measured after application deployment to each environment. We measured 10, 20, 50, 100, 250, 500, and 1000 iterations of each of the implemented monolithic and microservices at 0.1 second intervals to measure the maximum, minimum, and average values of the response times for API calls.
Table 9 shows the API call averages for the monolithic and microservice implementations. Less execution time means higher throughput for the application.
As shown in Table 9, when the API call was made, the average API execution of the structure converted to microservices was faster in most iterations than the monolithic structure. Figure 25 compares the total average execution time of the APIs for each iteration.
As shown in Figure 25, in the case of monolithic, it can be seen that the execution time increases rapidly at 500 iterations and beyond. Conversely, in the case of the microservices based on the method presented in this paper, it can be seen that the performance is stable at 500 iterations and 1000 iterations.
5.3. Reusability Evaluation
An application consisting of microservice units can be individually updated without knowing the internal structure of other microservices. This is because microservices have high reusability compared to monolithic structures. We measured the reusability metric of the microservices constructed by applying the proposed method and related methods to the same monolithic application [15]. Cohesion and coupling were measured as the reusability metric; high cohesion and a low coupling value indicate high reusability. Figure 26 shows the result of applying the design data of the “online ticket transaction system” presented in the case study to the DFD-based microservice composition method [15]. The dotted area represents the configured microservices and consists of a total of nine microservice units grouped into one data and process.
The reusability metric measurement uses the method of calculating the degree of cohesion and coupling of design data designed by object-oriented software [24]; the method of calculating the cohesion is the same as that shown in equations (1) and (2). is the sum of weight for a method M based on M appearances in groups of a subset tree. is the value obtained by dividing the sample value by the weighted sum of the group of attributes connected with the method; it has a sample value between zero and one. TM is the total number of methods in Cohesion (X) is calculated by averaging the sampled values of all the values. In the case of Chen et al. [15], attribute was defined as data, the method was defined as a process that accesses data, and the degree of cohesion was measured. In our approach, we define attribute as entity and method as boundary. We also define control that accesses entity and measures the cohesion.
Table 10 shows the result of cohesion calculation of microservices constructed through each configuration method. In the case of Chen et al. [15], nine groups of microservices were constructed. In the case of the proposed method, five groups were constructed. The relation and group weight values associated with the configured group were calculated.
The individual values, which are the result of dividing the maximum value of the sum of the group weights in the groups by relation, are shown in Table 11. The average value of of the microservice constructed through each configuration method was calculated. The degree of cohesion of the microservice constructed in [15] was 0.694, whereas that of the microservice constructed by the proposed method was calculated to be 0.823.
Equation (3) shows the calculation method for measuring the degree of coupling between classes. A, D, and I represent the number of classes of association, dependency, and inheritance relationships, respectively. The higher the relationship, the higher is the degree of coupling between classes. Further, a, b, and c are nondeterministic constants, which are to be considered by the developer or designer. In the case of monolithic design data, the constant a is 1 for direct connection and 0.5 for indirect connection. In the case of Chen et al. [15], the degree of coupling between data processes was measured. In the case of microservices constructed using the proposed method, the degree of coupling between entities and controls was measured.
The sum of the combined measurements of the design Chen et al. [15] was calculated as 13.5, as stated in Table 12. On the other hand, in the case of the microservice design data constructed using the proposed method, as the direct connection relation of ev3-ev6, ev3-cv7, and ev4-ev8 is changed to an indirect connection by the new boundary, it was calculated as 9.5, as stated in Table 13.
Therefore, we measured the cohesion and the coupling, which are the reusability factors of the microservices constructed by the related research method [15] and the proposed method. Table 14 shows that the proposed microservice configuration method has high cohesion and low coupling and is highly reusable.
6. Conclusion
This paper presented a method for analyzing monolithic application design data and constructing them as container-based microservice units. The proposed methodology involves processes of monolithic design data analysis, microservice extraction, microservice implementation, and microservice deployment. In the monolithic design data analysis stage, monolithic design data were collected and classified into different types. In the step of microservice extraction, a graph was constructed by analyzing classes and associations; then, an entity unit microservice was derived. In the microservice implementation stage, the implementation of microservices was conducted by layer. Finally, in the microservice deployment phase, we created a deployment support script that can gather deployment environment elements and deploy microservices in a container environment based on the collection elements.
In addition, we conducted a case study on each step of the proposed microservice construction method. Finally, we confirmed that the “online ticket transaction system,” which is a monolithic application, was configured as a microservice unit and distributed and operated on a container basis. Moreover, by comparing the proposed method with related research and evaluating the reusability of the constructed microservices, we confirmed that the microservices developed in this study are superior in terms of reusability.
If the proposed microservice construction method is applied to an existing monolithic application, it can be configured as a container-based microservice unit at low cost. The advantage is that, in the initial container environment, the user need not manually generate a template script; he or she can generate a template script through the mapping table. Therefore, further development of the microservice unit in the serverless computing environment is expected in the future.
In particular, future research will focus on developing a monitoring tool to manage efficient container operation after distributing microservices constructed by the proposed method and on improving the performance of API Gateway to solve the network overhead issue between microservices.
Data Availability
The data used to support the findings of this study are available from the authors upon reasonable request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIP) and the Ministry of Education (no. NRF-2017R1D1A1B03030243).