Backend monolithic app to microservices architecture migration – 1st part

Migration app featured image

Generally, companies software are built in a three part system: a client side/user interface, a database, and a side-server application called a monolith. Monoliths are often built as a single logical executable, in a single-tiered with multiple layers: presentation, business logic, and data-access. These apps are easy to design and develop, though they are difficult to maintain and make evolve, which makes them technologically locked-in and unadapted for the Cloud. To follow the evolution of Cloud Computing and Service-Oriented Architecture (SOA), microservices (MS) have naturally emerged as the next trend due to the advantages they provide. These advantages include increased maintainability, better scalability, and an overall better synergy with DevOps techniques. This makes migrating legacy software towards a microservice-oriented architecture (MSA) an attractive prospect for organizations.

Comparison of monolithic and microservices architecture
Figure 1: Comparison of monolithic and microservices architecture

What are microservices?

Microservice-oriented architecture is an architecture-style to develop a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms (HTTP resource, API). These services are built around business capabilities and are independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
MSAs can be more complex to organize and may increase technological requirements and network use, though, it shows high technological adaptability, modularity, high scalability, reusability, and can be independently developed by small teams.
Microservices architecture are more complex to organized and increased technological requirements and network use, though, it shows high technological adaptability, modularity and loose coupling, it’s highly scalable, reusable and can be independently developed in small team.

How do we move towards microservices?

Monolithic application to microservices migration architecture can be divided into two steps.
The first step is to identify a microservice-oriented architecture from the monolith’s source code. Its main goal is to extract the target application architecture to help architects modernize their application.
The second step is to transform the existing source code to one implementing the identified MSA. That’s the materialization.

The two-step process of the migration towards an MSA
Figure 2: The two-step process of the migration towards an MSA

Recovery phase: Layered identification approach

This first step consists in identifying and reorganizing the monolith’s functionalities into classes to propose a set of microservice candidates to guide the transformation phase. However, not all classes are equal, some are structural and some are data-oriented. We propose an identification approach that takes both roles into consideration.

The layered identification approach leverages well-established design patterns and anti-patterns to guide the process of identifying microservices. Our approach takes in consideration these design patterns and anti-patterns and proposes an identification process in three steps:

  • Recover the OO artifacts from the OO source.
  • Categorized the OO artifacts in different layers of the architecture (presentation, business and data-access).
  • From the extracted internally layered architecture’s artifacts, the microservice candidates are identified through an automatic clustering approach.

We analyze the monolith’s presentation layer to determine the endpoint of each business functionality, then we apply a vertical decomposition to these endpoints in order to find the necessary classes to implement each feature as a microservice. In this process, we also define a bounded context of the data-access layer for each microservice.

Recovering the layered architecture by reverse-engineering

To identify microservice candidates, we have to extract the layered architecture artifacts from the existing code of the monolithic application. It involves identifying its structural elements and the relationship between them by analyzing the existing source code. From these artifacts, the layered architecture can be revealed through reverse-engineering techniques. To facilitate the labeling process and to represent the extracted layered architecture, we propose the Layered Architecture Metamodel (LAMM) presented in the figure below.

Layered Architecture Metamodel (LAMM)
Figure 3: Layered Architecture Metamodel (LAMM)

This metamodel can be divided in three viewpoints:

  • Layered Architecture: responsible for representing the typical 3 Layers architecture (presentation, business-logic and data access).
  • DI/IoC: responsible for representing the decoupling mechanism to create high-cohesive layer artifacts.
  • Data Persistence: responsible for representing the various data types found in web applications.

A semi-automatic process is applied to place the application’s classes into one of these three by mapping them to one of the LAMM entities. Once we’ve mapped the classes into the appropriate entity, we analyze the dependencies to their layer counterparts. Once all entities and their relationship have been mapped to the LAMM model, the microservice identification step begins.

Microservice identification process using extracted artifacts

We use a hierarchical clustering algorithm to create a dendrogram which is cut following a depth-first algorithm and presented to the user for validation.
To guide the clustering, we combine two similarity measures. The first measure calculates the structural cohesion between the classes of a microservice candidate and produce a similarity which promotes structural cohesion by rewarding clusters in which there are more internal relationships. When applied on our LAMM model, it will ideally propose decomposition that favors vertical microservices focused on business capabilities and limit the risk of creating wrong cuts. The second measure calculate the data cohesion of a microservice candidate to encourage clusters with classes that manipulate the same class and promote clusters who are data autonomous. When applied to a clustering algorithm it will ideally propose a decomposition that favors grouping classes manipulating the same data and limit the risk of creating Shared Persistence between microservice by creating data ownership.

Figure 4: Exemple of dendogram
Figure 4: Exemple of dendogram
exemple of decomposition
Figure 5: Exemple of decomposition by our approach

The main contribution of this model-driven approach is the identification of microservices from the original source code. The proposed approach leverages the internal layered architecture of monolithic applications while providing a visualization tool to assist experts in the identification validation.
The internal architecture is often detailed in the code source through class annotations, namespaces, and configuration files. The proposed approach uses the layered architecture to vertically decompose a monolith while minimizing the coupling between microservices. Particularly, we were able to demonstrate that adding artifacts about the layered architecture of the monolithic application had a positive impact on the identification process.
In future works, we intend to extend our identification approach to integrate refactoring, packaging, and deployment of the identified MSA. To further strengthen our validation, we intend to use this end-to-end migration approach to generate and evaluate the quality of our MSA at runtime.

To be continued…


[1] J. Lewis and M. Fowler, “Microservices: a definition of this new architectural term,”,
2014, accessed: 2020-06-20.
[2] L. Bass, I. Weber, and L. Zhu, DevOps: A Software Architect’s Perspective. Addison-Wesley Professional, 05 2015.
[3] N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, F. Montesi, R. Mustafin, and L. Safina, Microservices: Yesterday, Today, and Tomorrow. Cham: Springer International Publishing, 2017, pp. 195– [Online]. Available: 12
[4] C. Richardson, Microservices Patterns: With examples in Java. Manning Publications, 2018. [Online]. Available:
[5] D. Taibi, V. Lenarduzzi, and C. Pahl, Microservices Anti-patterns: A Taxonomy. Cham: Springer International Publishing, 2020, pp. 111– [Online]. Available: 5
[6] O. Al-Debagy and P. Martinek, “A microservice decomposition method through using distributed representation of source code,” Scalable Comput. Pract. Exp., vol. 22, no. 1, pp. 39–52, 2021. [Online]. Available:
[7] T. Lutellier, D. Chollak, J. Garcia, L. Tan, D. Rayside, N. Medvidovic, and R. Kroeger, “Comparing software architecture recovery techniques using accurate dependencies,” in 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 2, 2015, pp. 69–78.
[8] Z. Wen and V. Tzerpos, “An effectiveness measure for software clustering algorithms,” in 12th International Workshop on Program Comprehension (IWPC 2004), 24-26 June 2004, Bari, Italy. IEEE Computer Society, 2004, pp. 194–203. [Online]. Available:
[9] D. M. Le, P. Behnamghader, J. Garcia, D. Link, A. Shahbazian, and N. Medvidovic, “An empirical study of architectural change in opensource software systems,” in 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, 2015, pp. 235–245.
[10] B. Pourasghar, H. Izadkhah, A. Isazadeh, and S. Lotfi, “A graph-based clustering algorithm for software systems modularization,” Information and Software Technology, vol. 133, p. 106469, 2021. [Online]. Available:
[11] W. Jin, T. Liu, Q. Zheng, D. Cui, and Y. Cai, “Functionality-Oriented Microservice Extraction Based on Execution Trace Clustering,” in 2018 IEEE International Conference on Web Services (ICWS), no. October. IEEE, jul 2018, pp. 211–218. [Online]. Available:
[12] Y. Zhang, B. Liu, L. Dai, K. Chen, and X. Cao, “Automated Microservice Identification in Legacy Systems with Functional and Non-Functional Metrics,” in 2020 IEEE International Conference on Software Architecture (ICSA). IEEE, mar 2020, pp. 135–145. [Online]. Available:
[13] J. Garcia, I. Krka, C. Mattmann, and N. Medvidovic, “Obtaining groundtruth software architectures,” in 2013 35th International Conference on Software Engineering (ICSE), 2013, pp. 901–910.
[14] C. Pahl and P. Jamshidi, “Microservices: A Systematic Mapping Study,” in Proceedings of the 6th International Conference on Cloud Computing and Services Science, M. Cardoso, J and Ferguson, D and Munoz, VM and Helfert, Ed. SCITEPRESS – Science and and Technology Publications, 2016, pp. 137–146.
[15] P. D. Francesco, I. Malavolta, and P. Lago, “Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption,” in 2017 IEEE International Conference on Software Architecture (ICSA), IEEE; Goteborgs Stad; Chalmers Univ Technol, Prod; Software Ctr; IEEE Comp Soc; Chalmers Univ Technol, Informat & Commun Technol; Chalmers Univ Technol, Energy; Chalmers Univ Technol, Transport; Systemite; Google; Jeppesen. IEEE, apr 2017, pp. 21–30. [Online]. Available:
[16] J. Fritzsch, J. Bogner, A. Zimmermann, and S. Wagner, “From monolith to microservices: A classification of refactoring approaches,” in Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment – First International Workshop, DEVOPS 2018, Chateau de Villebrumier, France, March 5-6, 2018, Revised Selected Papers, ser. Lecture Notes in Computer Science, J. Bruel, M. Mazzara, and B. Meyer, Eds., vol. 11350. Springer, 2018, pp. 128–141. [Online]. Available: 10
[17] D. Escobar, D. Cardenas, R. Amarillo, E. Castro, K. Garces, C. Parra, and R. Casallas, “Towards the understanding and evolution of monolithic applications as microservices,” in 2016 XLII Latin American Computing Conference (CLEI). IEEE, oct 2016, pp. 1–11. [Online]. Available:
[18] L. Nunes, N. Santos, and A. Rito Silva, “From a monolith to a microservices architecture: An approach based on transactional contexts,” in Software Architecture, T. Bures, L. Duchien, and P. Inverardi, Eds. Cham: Springer International Publishing, 2019, pp. 37–52.
[19] A. Levcovitz, R. Terra, and M. T. Valente, “Towards a Technique for Extracting Microservices from Monolithic Enterprise Systems,” CoRR, vol. abs/1605.0, may 2016. [Online]. Available:
[20] A. Selmadji, A. Seriai, H. Bouziane, R. O. Mahamane, P. Zaragoza, and C. Dony, “From monolithic architecture style to microservice one based
on a semi-automatic approach,” in 2020 IEEE International Conference on Software Architecture, ICSA 2020, Salvador, Brazil, March 16-20, IEEE, 2020, pp. 157–168.

More ...

Scroll to Top