REVIEW OF METHODS FOR MIGRATING SOFTWARE SYSTEMS TO MICROSERVICES ARCHITECTURE

Majority of software systems in business use, known as legacy systems, have monolithic structure hard to maintain and upgrade with new features. The most common option to overcome this situation is reengineering of existing software systems, which can be perform in different ways and with different outcomes. One of the recent most popular approaches is migration to microservices architectures, which makes distribution of software functionalities in small and independent units possible. Each unit, called microservice is self-contained and independent, which makes system manipulation and modification easier. Several methods for migration to microservice architecture have recently been proposed. This article presents a review of methods for migrating existing systems towards microservices. In addition, this article presents software artifacts affected by migration methods and used algorithms. Implications and benefits of the presented study, as well as validity issues are discussed, followed with concluding remarks and future research directions.


INTRODUCTION
Due to the rapid change of business conditions and constant improvement of technologies, software systems constantly change to remain useful for their users (Benestad, Anda, & Arisholm, 2010), which indicates that software maintenance is very important for improvement of software quality (Z. Stojanov, J. Stojanov, & Dobrilović, 2019). All changes can harm monolithic and legacy systems because their structure is solid and hard to modify. Through uncontrolled modifications, software systems deviate from the intended architecture, which commonly results with unmanageable monoliths (Sarkar et al., 2009). The problem with maintenance of legacy software systems is that subsequent modifications lead to their increased complexity and decrease of quality, making them hard for further maintenance (Kazanavičius & Mažeika, 2019), resulting in decreased organizational ability to quickly respond to changes in the business environment (Baškarada, Nguyen, & Koronios, 2020). To avoid the stated problems, software systems should evolve or migrate to better architecture patterns, and microservices are one of them.
In last few years, many methods for migration to microservices architecture have been proposed (Ponce, Márquez, & Astudillo, 2019). Migration to microservices has become popular in industry since microservice architecture is highly scalable (Mazzara et al., 2021), and it supports agility (microservices are easy to deploy), reliability (faults in one microservice do not propagate to other microservices), and modifiability (microservices are easy to modify) (Kazanavičius & Mažeika, 2019). However, since microservices are a new architecture style, there are no general guidelines for migrating monolithic systems to microservices (Kazanavičius & Mažeika, 2019), strongly indicating that there is a need for proposing new migration methods and reviewing existing methods to systematize knowledge in this contemporary technical area.
Based on the above statements, this paper aims to present the results of reviewing scientific papers on migration methods to microservice architectures. The paper presents literature review method based on guidelines proposed by (Kitchenham, 2004), as well as findings of literature review and discussion of implications and limitations of the presented study.
The reminder of the paper is structured as follows. In Background section microservices, monolith systems, reengineering and legacy systems are described. Section Related Work outlines other papers performing similar literature review analyses. In section Research Methods there is a description of the performed research. Section Findings displays review results. The paper ends with Discussion and Conclusion sections.

BACKGROUND
The research presented in this article deals with a certain type of software architecture. Fundamentals of this architecture and the terms used in this article are described in the following four subsections: Microservices, Monolith Systems, Legacy Systems and Reengineering.

Microservices
The base for microservices architecture is serviceoriented architecture, and because of that both share the same features. They are flexible and can easily adapt to new challenges, which makes software application easy to maintain and extends its life cycle (Dragičević & Bošnjak, 2019). The difference between these two architectures is the number and size of services, the way of sharing resources, and reuse (Bucchiarone et al., 2020). The number of services included in microservice architecture depends on the complexity of a system and boundaries between services. The size of a microservices depends on functionality they perform (Newman, 2020). In terms of sharing, the main logic in service-oriented architecture is "share-as-much-as-possible", but in microservices architecture it is opposite "share-as-little-aspossible" (Bucchiarone et al., 2020). It means that microservices are closed in view of sharing information related to internal implementation.
They use network endpoints to connect with other units (other parts of systems, other microservices).

Microservices
are independent units communicating through lightweight messages, which ensures more dynamic maintenance because when the one microservice is changed it does not affect other microservices in the system (Newman, 2021). This microservice characteristic is named high cohesion and loose coupling. Cohesion relates to which level the units use the same parts (Bruce, & Pereira, 2018), while coupling indicates the level a change in one part of the system will affect a change in another (Newman, 2020).
Microservices are collection of separate connected services communicating through the network. Because the services do not share all information and implementation details are not essential for good communication and working of the system, each service can be developed using different technologies (Wolff, 2017). Because of its adaptability and easy maintenance, microservices are a common choice today. They can easily adapt to new trends and enable existing software systems to continue their life cycle moving to microservices architecture through reengineering.

Monolith Systems
Monolith architecture is a traditional way for building software applications. Systems built in monolithic architecture are written and deployed as a single block (Chawla & Kathuria, 2019). In the early development stage, it is easier to work with monolith systems because they are not complex. As the application grows and becomes more complex, the development process slowdowns because all parts of code are interconnected, and it becomes more difficult for maintenance (Kalske, 2017). Changes to any part of application may affect many system components and even disable the entire system (Chawla & Kathuria, 2019). This is the reason for migrating these types of systems to microservices.

Legacy Systems
Legacy systems are old systems built in outdated technologies but still in everyday use. Because of monolith architecture they are difficult to maintain and upgrade. In addition, they cannot be easily replaced because they have supported business processes for years and gradually upgraded their functions. These systems contain a significant One option is to reengineer and move to a microservices architecture.

Reengineering
Reengineering is a process in which an old system changes its architecture to a new architecture pattern but keeps all functionalities. It should begin when the old system becomes too difficult to be maintained due to outdated and complex architecture that cannot longer be upgraded with new features. The process ensures that software continues to be used with better quality, and with lower costs of maintenance (Singh et al., 2019). Migrating existing software system to microservices is an option that can ensure further system use. This is not an easy process and there are no precisely defined rules for migration. The main task in this process is identification of functionalities of a system and their migration to microservices (Velepucha & Flores, 2021). The methods and techniques to be used for migration process depend on goals, system artifacts and dependencies between them. The process usually begins with manual inspections of application structure. There are also automatic approaches, with software tool support, which identify candidates for microservice migration. The working principle of these methods is based on grouping similar elements, and proposing microservices (Kirby et al., 2021). The last step is checking the results and migrating the system to new architecture.

RELATED WORK
Microservices are an approach for architecting distributed software systems using independent and fine-grained services, which has gained attention by researchers and practitioners from industry in the last decade (Newman, 2021). This has resulted in a large number of case studies reporting practical experiences, as well as in secondary studies reporting reviews of published case studies. Identification of relevant studies and systematization of empirical knowledge introduced evidence-based software engineering that aims to contribute to improvement of practical experience of software engineers (Dyba, Kitchenham, & Jorgensen, 2005;Zhang, Babar, & Tell, 2011). Literature review in software engineering can be conducted as a Systematic Literature Review (SLR) (Kitchenham, 2004;Kitchenham et al., 2009), a Systematic Mapping Study (SMS) (Petersen et al., 2008;Petersen, Vakkalanka, & Kuzniarz, 2015), or as an informal literature review (Niazi, 2015). A literature review of studies dealing with reviews of microservice architectures is presented in this section.
Based on the literature review of 62 empirical studies, Wolfart et al. (2021) proposed a roadmap for modernization of an existing legacy system with microservices, which contains the following typical activities: analyze the driving forces, understand the legacy system, decompose the legacy system, define the microservice architecture, execute the modernization, integrate the microservices and the legacy, verify and validate the microservices, and monitor the microservices (infrastructure). Taibi et al. (2018) conducted a systematic mapping study with 85 papers on the use of micro services, aimed at identification of common patterns and principles. The authors systematized mostly used patterns in organization of microservices, their advantages and disadvantages. The architecture patterns are categorized in sense of orchestration and coordination-oriented architecture patterns, deployment patterns, and patterns reflecting data management. Di Francesco et al. (2019) reported a systematic mapping study with 103 primary studies aimed at identification, classification, and evaluation of microservice architectures from the perspectives of publication trends, research focus, and potential for adoption in software industry. Waseem et al. (2020) presented a systematic mapping study on use of microservices architectures in DevOps. This study included 47 primary studies published in the period from January 2009 to July 2018, based on which the authors identified the following key themes: (1) microservices development and operations in DevOps, (2) approaches and tool support for microservices architectures in Devops, and (3) microservice architecture migration experiences. Migration experience relates to identification of migration motivators, challenges, and patterns in migration process. Bushong et al. (2021) presented a systematic mapping study aimed at reviewing approaches and techniques for analyze of microservice systems, as well as evolution of microservice based systems. The study is based on reviewing 55 primary studies and provides review  (2021) presented a literature review of 37 papers on migration problems and related challenges from monolithic architecture to microservices. The problems relate to team organization, selection of suitable tools, incorporation of new technologies, completeness of migration process, identification and design of microservices, and information consistency when moving from one to multiple databases. Li et al. (2021) presented a systematic literature review on quality attributes of microservices architectures based on 72 selected primary studies. Analysis of literature revealed the following most important quality attributes: scalability, performance, availability, monitorability, security, and testability. For all quality attributes, the most suitable tactics to address them are identified.
Analysis of published literature reviews on microservice architectures revealed that this is very interesting and promising research area, but also that there are a lot of space to perform additional research. This article intends to present review of literature dealing with methods for migration of existing software systems to microservice architecture.

RESEARCH METHODS
The research follows guidelines for performing systematic literature reviews in software engineering (Kitchenham, 2004;Kitchenham et al., 2009). The research is conducted in some steps that are common for literature reviews, which is presented in Figure 1.
The first step is determination of keywords related to the selected research subject. The words that are selected as the most suitable are classified into two groups due to future combination in search strings. The first group contains words: reengineering, migration, identification. The second group contains only word microservices. Combining the selected keywords, the following search strings are formed: "reengineering" and "microservices" "migration" and "microservices" "identification" and "microservices" The second step is searching for papers in digital libraries. The best results are found on Google Scholar ScienceDirect, IEEE Xplore and Springer libraries.
METHODS for migration to microservices 14 primary studies Google Scholar ScienceDirect IEEE Xplore, Springer "reengineering" and "microservices" "migration" and "microservices" "identification" and "microservices"  Based on the formed search strings, the search for papers was performed in the selected digital libraries. Through analysis of collected papers' titles, abstracts, and the reported findings, 14 primary studies are selected. Details about collected studies are systematized in Excel tables, which contain detailed bibliographical data of each study, and specific data extracted based on the proposed review objective (migration method, used algorithm, affected software artifacts, domain of software use, and software types). In Table 1 primary studies (ps) are listed used for more detailed analysis and construction of the findings.

FINDINGS
Numerous reasons for the migration of existing software systems to microservices are mentioned in the analyzed literature. The main identified reasons are improvement of software elasticity, more controlled transformation and evolution, and better scaling of existing software for new requirements. Migration also helps to reduce size of existing systems and makes it easier to upgrade and maintain them. This is very important since several industrial studies reported increased complexity of maintained software systems, which To improve stated disadvantages of existing software systems, the authors of the selected primary studies proposed methods for migration to microservices. The methods, artifact used as input for microservices migration methods, and used algorithms are shown in Table 2. Methods used for migration vary from interview and conversation-based methods, methods that analyze different software artifacts (source code, classes, method invocation during execution, methods call graphs, etc.), clusters them and propose microservice candidates, to methods focused on analysis of business cases.
Detailed analysis of methods revealed that they use different system artifact as main input for decomposition and microservices identification. The most commonly used artifacts are: source code -classes and their interaction, software execution traces and logs, code bases of application frontend and backend, databasestables, business rules and stored procedures. Some methods use system requirements, relationship between program groups and data or business processes. Analysis indicate that majority of methods use different source code elements because there are strict language grammars for writing code, as well as tools that can analyze code, which is essential for automating some steps in migration process.
Algorithms identified in primary studies are listed in Table 2. Primary studies marked as ps1, ps4, ps9 and ps13 do not mention the use of any algorithm and because of that there are empty cells in rows associated to these primary studies. Algorithms used in primary studies are:  Decomposition Algorithm. This is an algorithm for microservice proposition using OpenAPI specification and reference vocabulary for input and creating links between the input operation and the description of operation in the best way. Operations with similar concept represent one group and then become candidates for microservice.
[ps3]  Semantic Assessment Algorithm. This algorithm is a part of decomposition algorithm analyzing each operation in software system. [ps3]  Fast Community graph clustering algorithm.
This algorithm represents a software system as a graph and then clusters it to detect microservices candidates.
[ps6]  NSGA II. Nondominated Sorting Genetic Algorithm sorts and compares all solutions to detect microservices. The algorithm is described by Deb et al. (2002) and used in [ps6, ps10].  SArF software clustering algorithm. This algorithm collects all software resources into clusters for microservices, without human interaction. The algorithm is described by Kobayashi et al. (2012) and used in [ps7].  Determination of microservices boundary. This algorithm generates a graph from the classes and their functions, while interaction algorithm clusters graph and forms application behavior characteristic interaction matrix.
[ps8]  AMI algorithm. An Automated Microservices Identification algorithm discovers key objects and determines connection between them and classes. Based on identified objects and connections it divides a software system into a set of microservices.
[ps11]  Collaborative Clustering algorithm. This algorithm uses matrix for storage dependencies between each couple of activities and clusters them based on shared activities to propose microservices.
[ps12]  Affinity Propagation algorithm. This algorithm performs clustering based on measurement of data similarity, which is described by Frey and Dueck (2007) and used in [ps14].
Most of the methods described algorithms they use for microservices extraction. Although they have different name, the basic principle is the same. The algorithms differ in the input parameters, and whether they are automatic, semi-automatic or manual. Based on the analysis of methods, affected software artifacts, and used algorithms in migration to microservices, a general migration process is proposed and presented in Figure 2. The output of the proposed process are microservices candidates. Identified migration methods are tested on some specific software applications. Domains of applications use, software types and used migration methods are presented in Table 3.

MICROSERVICES
The most used application is web store named JPetStore [ps8, ps10, ps11, ps14], which is a legacy ERP system with monolithic architecture. Analysis of domain of use revealed that migration was performed in variety of domains, such as banking systems, learning applications, business and booking software, blogs, and forums. Variety of software types are identified in primary studies, but common to all of them is that they are monolithic, and therefore, they most often migrate to microservices to increase their performances (availability, scalability, reliability, and maintainability).

DISCUSSION
Results of literature review indicate that several methods have been used for migration of existing software systems to microservices architectures. These methods use variety of software artifacts as a starting point in analysis and implement different algorithms for decomposition of existing systems and identification of microservices candidates. In this section, implications of the presented study, and limitations that threat validity are discussed.

Implications
This paper presents a preliminary literature review designed on the systematic literature review guidelines (Kitchenham, 2004;Kitchenham et al., 2009), but with some simplifications related to the selection of keywords and databases for search of studies. Due to the stated simplifications, the study resulted in a smaller number of selected primary studies. Nevertheless, presented findings indicate that this type of preliminary literature reviews can be valuable evidence for a larger audience from academia and industry.
This study presents details on tailored guidelines for conduct of preliminary literature review, which can be of great benefits for PhD students and young researchers (Pickering & Byrne, 2014). This study can be used as a model for conducting preliminary literature reviews in PhD research, and later for extension of reviews to achieve systematic review of the relevant literature.
Researchers in the field of software architectures and reengineering of software systems can use this study findings as a starting point for inquiry of different methods and algorithms for migration to microservice architectures, as well for decisions on methods suitable for implementation in specific domains and for specific software types.
Finding of this study reported experiences from the selected case studies can help software architects and maintenance experts in selection of optimal migration methods for their domains and software systems, which can help avoiding typical obstacles and problems in reengineering existing software systems.

Limitations and Validity
Although presented findings and discussed benefits indicate that the presented study is useful for both researchers and experts from industry, there are some limitations that treat its validity and should be discussed (Wright, Kim, & Perry, 2010). In addition, literature review studies should discuss some specific validity issues, such as construction of search strings, selection of sources, and role of bias in selection and classification of studies (Ampatzoglou et al., 2019).
The first limitation relates to selection of keywords and composition of search strings used for finding the relevant studies. The search strings are listed in the main section of this article, but identification of potential synonyms for the selected keywords can provide improved search and potential identification of a larger number of relevant studies. For example, keyword "identification" can be used together with synonyms "discovery" and "finding" using logical OR operator in search strings, which can lead to discovery of more studies related to migration methods. The second limitation relates to use of more digital libraries for searching. Publisher such as Wiley or ACM list a large number of articles, which should be included in further literature reviews. Additional problem relates to access to articles, since some publishers do not allow access without subscription. These limitations will be considered in further, more detailed, and systematic literature reviews.

CONCLUSIONS
Microservices are contemporary architectural patterns for structuring software systems, with increased scalability, availability, reliability, and maintainability compared to older patterns. These characteristics of microservices attract many organizations to migrate their old systems. Although several methods have been proposed for migration of old systems to microservice architecture in the last ten years, there is no general guideline. This article provides systematization of methods for migration of existing software systems to microservices based on a literature review. The findings of this paper provide detailed insight into methods used for migration of software systems to microservice architectures, accompanied with detailed overview of software artifacts used in the methods, domains of use and software types transformed during migration process. The findings of this study are valuable for experts from software industry during reengineering of old systems since they can find information about migration methods connected to affected software artifacts, domain of use and software types. Researcher from academia can use this review study as a starting point for their studies or can use and adapt the review method presented in the study.
Future work will be pursued in two directions. The first one is conduct of a systematic literature review in which stated limitation of this study will be addressed. The second one is development of a method and a tool for migration of web applications in complex technical systems to microservices architecture.

ACKNOWLEDGEMENT
The Ministry of Education, Science and Technological Development of the Republic of Serbia supports this research under the project "The Development of Software Tools for Business Process Analysis and Improvement", project number TR32044.