- Microservice architecture is becoming a standard by default in most of the enterprises because many projects have been implemented using this architecture in the last few years and results have been very positive. Extracting microservices from legacy monolithic software is an extremely complicated task. Each enterprise application is unique. This paper aims to investigate the existing methodologies of monolith decomposition into microservices. The same enterprise application was decomposed into microservices using 3 different methods. Evaluation criteria were proposed that were used to analyze advantages and disadvantages of each.
Microservices are entering mainstream, according to NGINX research only 30% of
companies not using them at all. NGINX researched 1800 IT professionals and results
show that nearly 70% of organizations are using or investigating a microservices
architecture, while nearly 1/3 are already using microservices architecture in
production. [
Migration to microservices from monolithic legacy software cannot be
implemented in a fast way. It is important to know that there is a high overall cost associated
with decomposing an existing system to microservices [
This article's main goal is to analyze existing legacy monolith application
decomposition into microservices architecture based application methodologies. During
literature review and analysis three main directions how decomposition from
monoliths to microservices could be realized were identified [
A comparison between selected methodologies was done by decomposing the same enterprise legacy monolith application, named DataProvider, into microservices three times, using all selected methodologies. Benefits and drawbacks of each methodology were analyzed and compared. 2
The primary function of the DataProvider application is to provide important organization data from one place to others information systems in an organization. Different types of data like accounts, books, customers and so on are stored in different mainframe systems within an organization.
The DataProvider application (Figure 1) consist of three main components: • Business logic – collecting and caching data from old mainframe systems. Business logic writes collected data to the DataProvider local database. Entity framework is used to communicate application and database. • Database – MS SQL database technology is used to store collected data from mainframe systems. • Rest API – HTML endpoint for other information systems to access important organization data in DataProvider. Swagger tools are used to provide Rest API functionality.
Application is written with Microsoft .NET framework and C# programing language is used.
Alessandra Levcovitz, Ricardo Terra and Marco Tulio Valente describe a technique to
identify microservices on monolithic systems [
The first step is mapping database tables into subsystems. Each subsystem represents a business area of an organization. DataProvider application has 15 database tables, 9 subsystems, and 8 different business areas. This step of methodology allows identifying a number of tables and business areas. Identify database tables is a task that requires only technical skills. On the other hand, identify business subsystems and assign a table to them require additional effort to understand the business process.
In the second step dependency graph between facades, business functions and database tables were created. It shows business functionality and database dependencies. 5 graphs were pretty straightforward: containing only 1 database table, 1 business functionality layer and 0 dependencies from other database tables and business functionality subsystems. The other 12 database tables were joined into one more complex and complicated dependency graph. Some business functionality contains up to 4 dependencies from other database tables. Mostly 4 business functionality layers identified for full operation from facade to the database table to be accomplished.
Based on the dependency graph unique pairs of facades and database tables were identified and mapped with business subsystems functions. DataProvider application has 68 unique pairs of database tables and facades. 15 facades were in pairs with only 1 database table. Some of the facades were in pair with different database table up to 8 times. More complicated dependency graph more unique pairs exist.
In the last step candidates to be transformed into microservices were identified. For each distinct pair obtained on the prior step, inspect the code of the facade and business functions that are on the path from the facade to the database table in the dependency graph.
37 microservices candidates were found in the DataProvider application after decomposition was done using method I. More functions and tables subsystem had more microservice candidates were identified. It is a possibility that the microservice candidate size could be very small if it contains only one business function. The method requires identifying business subsystems, to do that business knowledge is needed which is why the method couldn’t be implemented completely automated.
Genc Mazlami, Jurgen Cito and Philipp Leitner created microservices extraction from
the monolithic systems model [
The first step is the monolith transformation into the graph representation. In the graph, each vertex represents class from the monolith and undirected edges represent its coupling with other classes in the monolith.
DataProvider application has 273 classes at all. The biggest number of dependencies which one class has is 96. 17 classes have 0 dependencies and are not part of a graph. The average classes coupling is ~10. Unit, integration and manual tests classes were excluded from the graph. More quality code has less coupled classes are, so lower number of edges in the graph indicates a higher quality of code. It is not clear how to treat class inheritance from the article, in this evaluation decision was made to treat class inheritance as not dependency.
The second and final transformation is to cut the graph in components that are going to represent recommended microservices candidates. The authors proposed three different strategies of how to do it: logical coupling, semantic coupling and contributor coupling. During this comparison, semantic coupling was chosen in evaluation.
8 microservices candidates were found in the DataProvider application. 180 classes were identified for a specific business domain by class name. It was not possible to identify the business domain by class name for 93 classes. ~33% of classes need additional effort to review and assign manually to the specific business domain or refactor and split into more classes. Code quality playing a vital role in how easily a microservice candidate could be identified in the graph. If code is written following clean code standards class should only have one responsibility, few dependencies, and meaningful name. Automation could be used in extraction accurately only if the monolith code has high quality. If a class has a lot of dependencies, not a meaningful name or has too many responsibilities it is not clear to which microservice candidate it belongs. In this case, the additional effort needed to refactor class. Code-Based Method is very formal and requires additional tools to be implemented properly. These tools are note available only algorithm and a mathematical model is provided, so organizations should implement them itself. 5
Chen-Yuan Fan and Shang-Pin proposed a migration process based on SDLC,
including all of the methods and tools required during design, development, and
implementation [
In first step Domain-Driven Design (DDD) was used to find microservice candidates in the original system. The bounded context analysis results are a key tool to identify microservice candidates in DataProvider application. The DDD was used to identify specific domains in solution and identify domain modules in each domain. DDD approach analysis allows extracting of low-coupling microservices.
The second step involves the analysis of the database structure. It is common practice that each microservice should use a discrete database. This allows to avoid high coupling between services. On the other hand, splitting some data into separate databases could cause data inconsistency. Foreign keys could be used as an indication of the microservice candidate.
After Domain-Driven Design and database analysis, 8 microservices candidates were found in the DataProvider application. 1 additional microservice should be created. To connect all microservices into one solution new microservice was introduced. Sync Service provides data synchronization and an interface for front-end systems. The most important things for a successful migration from monolith to microservices using Business-Domain-Based Method is Strong business knowledge, business process stability in the organization and high-quality database schema. 6
This section compares the extraction methods evaluations results in different aspects. Detailed results about evaluations present in Table I.
Classes
Extraction Storage-Based Method found most microservice candidates in the DataProvider application. The Storage-Based Method found 37 candidates, CodeBased Method found 8 candidates and Business-Domain-Based Method found 8 candidates also. In Storage-Based Method microservice is extracting as a concrete function in the application while in Business-Domain-Based Method microservice represents the specific business domain. It is obvious that Storage-Based Method will always provide more microservices than Business-Domain-Based Method because the business domain always has at least one function. Code-Based Method is more flexible than other compared methods, it provides optionality to choose the strategy on how microservice should be extracted. Semantic coupling strategy was chosen during this comparison, its key idea, in general, is very similar to Domain-Driven Design so what explains why it found the same number of microservice candidates as BusinessDomain-Based Method. Another extraction strategy is logical coupling which focuses on concrete functions. It could be predicted that microservice candidates would be found similar to Method I.
The main idea of microservice is that it should have only one responsibility. Responsibility could be business or functional type. Business responsibility is bigger than functional because it contains at least one function and usually it contains much more than one. Split by functions microservices is much smaller and has been named as serverless. If organizations decide to split they monolith application into microservices by business domains when they should choose Business-Domain-Based Method or Code-Based Method with semantic coupling strategy. If the decision is splitting into microservices by functions when Storage-Based Method or Code-Based Method with logical coupling strategy could be used.
The most common and popular practice is that each microservice should use its private database. Business-Domain-Based Method perfectly fits this approach. StorageBased Method splits monolith into microservices by functions and some functions most likely going to use the same table. If the decision was made to use this method database probably going to be shared. Methods authors do not provide any recommendations on how to deal with this challenge. Code-Based Method authors assume that monolith application use repository pattern and each table is represented as a repository class in solution. Methods don’t contain any recommendation of how databases should be adapted to microservice architecture.
Code-Based Method with the contributor coupling strategy could be implemented fully automatically. Monolith must be implemented with an object-oriented programming language because the extraction model is based on classes as the atomic unit of computation and the graph. Code-Based Method with a semantic coupling strategy could be implemented semi-automatically. In this case, business domains should be identified manually. How accurate the method will be able to identify class relation to business domain depends on a naming convention in code. Storage-Based Method and Business-Domain-Based Method can’t be implemented automatically. Storage-Based Method requires manually identify business subsystems and assign database tables to one of the subsystems. Business-Domain-Based Method requires two manual analysis to do.
Storage-Based Method designed to work with backend type applications. It is programming language agnostic. Database storing data in tables must be part of the application, because extraction use tables to generated graph. Code-Based Method is suitable for backend type applications written with an object-oriented programming language. The extraction model is based on classes as the atomic unit. If the application is written with another type of language or with a few different languages when it is not possible to use Code-Based Method for microservices extraction. BusinessDomain-Based Method is technologically agnostic and could use with any kind of programming languages and databases.
Business-Domain-Based Method is in the least formal and most universal comparing with other compared methods. On the other hand, it is most uncertain and requires the implementer to have a strong knowledge of application business domain and implementation technical details. Code-Based Method is the most formal and requires an additional tool to generate graph representing dependencies of classes. It is not clear what would be cheaper in time and resources: implement the tool and use it or use other methods to do microservices extraction from the monolith. Storage-Based Method do not require any additional tool to implement, but it requires some business domain knowledge to identify business subsystems.
Code quality has the most impact on Code-Based Method because it creates classes’ dependencies graph. Clean and solid code generates a more accurate graph. The more accurate graph allows extracting more accurate microservices. Code quality also has an impact on Storage-Based Method and Business-Domain-Based Method as well. The better code quality is, the easier it is to extract functions from it. 7
Choosing the right microservices extraction from the legacy monolith application method is a very hard task and crucial for a successful migration. Each legacy monolithic application is unique and creates unique challenges. One best methodology on how to extract microservices from monolith does not exist. Each case is different and the organization should choose which method or combination of methods best suits for its migration from monolith to microservices. Selected methodology or combination of methodologies should be: able to extract microservices by selected factors and compatible with technological stack and database technologies used in application.