Backend monolithic app to microservices architecture migration – 2nd part

Find the first part of the article by following this link

In the first part article, we’ve explained how to identify microservices candidates by extracting the layered architecture artifacts from the existing code of a monolithic application. Several approaches address this first step, though they either do not address the materialization step or complete this step manually. Although the recovered clusters help understand the target MSA, the source code must be transformed to conform to the MSA style (service-based, message-oriented communication, etc.). In this second part, we’ll explain the materialization of the existing source code to one implementing the identified MSA by using an Ad Hoc Transformation Approach.

Concretely, the goal of the materialization step is to transform the existing monolithic source code to create functional microservices that conform to
the recovered microservice architecture, while preserving the business logic of the application. With regards to monolithic applications following the object-
oriented paradigm, the difficulty of the materialization step is to transform the OO dependencies present between the identified clusters of classes into MSA-
type dependencies (i.e. services). In addition, these transformation must adhere to the refactoring principles (i.e. preserve the business-logic) without degrading the performance of the overall system. However, despite the importance of the second step of the migration, and to the best of our knowledge, no approach have been proposed to automate it.
In this article, we propose a systematic approach to transform an OO application from the monolithic style to an MSA one based on a set of transformation patterns. This set of transformation patterns create microservice-based communication mechanisms that preserve the semantic of the monolith while conforming to the principles of the MSA (e.g. message-based and data-oriented). Furthermore, we propose an automated process, and a tool, that applies our systematic transformation approach.

OO Source Code Transformation Towards an MSA One

The architecture recovery step’s identified MSA is materialized in the transformation step. It entails converting object-oriented source code into MSA source code. Each recovered cluster of classes is then deployed into its own microservice during this step (i.e., microservice encapsulation). Yet, edge classes by definition have dependencies with classes belonging to another cluster. These direct structural dependencies between the classes of different microservices are called microservice encapsulation violations, and they must be handled before a microservice can be fully encapsulated.

Indeed, all violations must be handled by refactoring methods that convert all OO-type dependencies into MS-type dependencies before a microservice can be generated. During this step, the operational characteristic of an MSA to use message-oriented communication between different microservices is considered. In other words, method invocations between classes belonging to different clusters (e.g.the method calls between DisplayManager and ContentProvider) must be restricted to a set of provided and required interfaces that define both the web services it provides and those it consumes. In addition, inter-process communications (IPC) calls between microservices are limited to value-based communication. In other words, only primitives and serialized data are exchanged between microservices. However, a procedural call in an OO system may pass object references between the invoking object and the invoked one. To encapsulate microservices, the instance sharing mechanism between microservice candidates must be resolved.
Besides these explicit OO dependencies, implicit dependencies between clusters must be addressed to fully encapsulate the microservice candidates. Inheritance mechanism and exception handling are the two main implicit OO mechanisms must be addressed. Particularly, an inheritance violation is defined as a class that has a super-class that belongs to another clusters (e.g, between Message and Content). The exception handling violation is defined as a class
throwing an exception that is caught by a class belonging to another cluster. Both of these OO mechanisms must be addressed and transformed into MS-type dependencies.
Lastly, MSA generated after the transformation step must adhere to 2 additional operational characteristics:

1. Microservices must run on their own process
2. They must be automatically deployable

To conform to these operational characteristics, each microservice must define an independent project that must be configured for Cloud deployment. Both of these characteristics must be addressed during the generation of the source code for each microservice.

MonoToMicro: A semi-automated refactoring approach

In this paper, we propose a systematic way of transforming a monolithic OO application into an MSA application with a set of transformation patterns. The purpose of this approach is to transform monolithic object-oriented source code into an MSA by encapsulating the clusters discovered during the initial migration step. To do so, we define a process composed of four steps as presented in Figure 2 which consist of:

1. Detecting encapsulation violations,
2. Healing encapsulation violations,
3. Packaging microservices,
4. Deploying and containerizing microservices

Detecting Encapsulation Violations

Each recovered cluster of classes is encapsulated in its own microservice to materialize the recovered microservice candidates from the source of object-oriented software. On the other hand, encapsulation prevents OO dependencies between clusters (i.e., encapsulation violations). Therefore, they must be transformed into MS-type dependencies. However, before the transformation can take place these encapsulation violations must be identified. To facilitate the detection of these encapsulation violations, a set of encapsulation violation rules are proposed to analyze the monolith:

• (Rule 1): if a cluster’s method invokes a method belonging to a class from another cluster then it is a method invocation violation.
• (Rule 2): if a cluster’s method accesses an attribute belonging to a class from another cluster then it is an access violation.
• (Rule 3): if a cluster’s class contains a reference targeting a class from another cluster then it is an instance violation.
• (Rule 4): if a cluster’s class inherits a class belonging to another cluster then it is an inheritance violation.
• (Rule 5): if a cluster’s method throws, catches or declares an exception defined in another cluster then it is a thrown exception violation.

These rules are applied to the AST representation of the OO source code.
Initially, the target architecture description is used to partition the AST nodes that represent the classes in the OO source into clusters. Then, each node is
parsed for references towards class nodes belonging to another cluster using the aforementioned detection rules. After all the violations have been detected, the process of resolving all these violations can take.

Healing Encapsulation Violations

The violations detected in the preceding step must be healed using transformation rules in order to encapsulate the microservices. These transformations must either fully heal or reduce a violation to a solvable type. Previously, the identification of encapsulation violation covered:

1. Method invocation
2. Attribute access
3. Instance handling
4. Inheritance
5. Exception handling

In this article, we present a set of transformation rules to heal the encapsulation violations identified in the first step. Particularly, we separate these violations into two categories: explicit and implicit. As a general rule, microservice should obfuscate their internal structure and behavior while exposing a clearly defined interface. Violations that break this rule are considered explicit (e.g, attribute access, instance handling, and method invocation). While implicit violations are related to the implicit dependency between microservices caused by OO mechanism (e.g., inheritance and exception handling).

Packaging and Deployment of an MSA

Once the MSA source code has been generated, it must be packaged and made deployable. In step the semi-automated refactoring approach, the violation-free microservices are packaged. To accomplish this, each microservice has its own project where the source code is generated. The file structures and project dependencies are then automatically constructed. The microservice projects are then containerized in the encapsulation violation resolution step by generating instantiable images. An image description file is created for each microservice. A composition file is also created, which arranges and delivers all of the microservices at the same time.
In this work, we concentrate on the first two steps of the transformation phase, which comprise the major scientific roadblocks previously highlighted,
and leave the last two steps for the implementation as they comprise more technical roadblocks.

To be continued…

References

[1] Allier, S., Sadou, S., Sahraoui, H.A., Fleurquin, R.: From object-oriented applications to component-oriented applications via component-oriented architecture. In: 9th Working IEEE/IFIP Conference on Software Architecture, WICSA 2011, Boulder, Colorado, USA, June 20-24, 2011. pp. 214- IEEE Computer Society (2011). https://doi.org/10.1109/WICSA.2011.35, https://doi.org/10.1109/WICSA.2011.35
[2] Alshara, Z., Seriai, A., Tibermacine, C., Bouziane, H., Dony, C., Shatnawi, A.: Migrating large object-oriented applications into component-based ones: instantiation and inheritance transformation. In: International Conference on Generative Programming: Concepts and Experiences, GPCE pp. 55-64. ACM (2015). https://doi.org/10.1145/2814204.2814223,https://doi.org/10.1145/2814204.2814223
[3] Alshara, Z., Seriai, A., Tibermacine, C., Bouziane, H., Dony, C., Shatnawi, A.: Materializing architecture recovered from object-oriented source code in component-based languages. In: Tekinerdogan, B., Zdun, U., Babar, M.A. (eds.) Software Architecture – 10th European Conference, ECSA 2016, Copenhagen, Denmark, November 28 – December 2, 2016, Proceedings. Lecture Notes in Computer Science, vol. 9839, pp. 309-325 (2016). https://doi.org/10.1007/978-3-319-48992-6 23, https://doi.org/10.1007/978-3-319-48992-6 23
[4] Amiri, M.J.: Object-Aware Identification of Microservices. In: 2018 IEEE SCC. pp. 253-256. IEEE (jul 2018). https://doi.org/10.1109/SCC.2018.00042,
https://ieeexplore.ieee.org/document/8456428/
[5] Baresi, L., Garriga, M., De Renzis, A.: Microservices Identification through interface analysis. In: De Paoli, F., Schulte, S., Broch Johnsen, E. (eds.) Service-
Oriented and Cloud Computing. pp. 19-33. Springer International Publishing, Cham (2017) Materializing Microservice-Oriented Architecture 25
[6] Baskarada, S., Nguyen, V., Koronios, A.: Architecting microservices: Practical opportunities and challenges. Journal of Computer Information Systems 60, 428 -436 (2020)
[7] Birkmeier, D., Overhage, S.: On component identification approaches – classification, state of the art, and comparison. In: Lewis, G.A., Poernomo, I., Hofmeister, C. (eds.) Component-Based Software Engineering, 12th International Symposium, CBSE 2009. Lecture Notes in Computer Science, vol. 5582, pp. 1-18. Springer (2009). https://doi.org/10.1007/978-3-642-02414-6 1, https://doi.org/10.1007/978-3-642-02414-6 1
[8] Chardigny, S., Seriai, A.: Software architecture recovery process based on object oriented source code and documentation. In: Babar, M.A., Gorton, I. (eds.) Software Architecture, 4th European Conference, ECSA 2010, Copenhagen, Denmark, August 23-26, 2010. Proceedings. Lecture Notes in Computer Science,
vol. 6285, pp. 409-416. Springer (2010). https://doi.org/10.1007/978-3-642-15114-9 35, https://doi.org/10.1007/978-3-642-15114-9 35
[9] Chardigny, S., Seriai, A., Tamzalit, D., Oussalah, M.: Quality-driven extraction of a component-based architecture from an object-oriented system. In: 12th European Conference on Software Maintenance and Reengineering, CSMR 2008, April 1-4, 2008, Athens, Greece. pp. 269-273.IEEE Computer Society (2008). https://doi.org/10.1109/CSMR.2008.4493324, https://doi.org/10.1109/CSMR.2008.4493324
[10] Chen, R., Li, S., Li, Z.: From Monolith to Microservices: A Dataflow-Driven Approach. Proceedings – Asia-Pacic Software Engineering Conference, APSEC pp.
466-475 (2018). https://doi.org/10.1109/APSEC.2017.53
[11] De Alwis, A.A.C., Barros, A., Polyvyanyy, A., Fidge, C.: Function-splitting heuristics for discovery of microservices in enterprise systems. In: Pahl, C., Vukovic, M., Yin, J., Yu, Q. (eds.) Service-Oriented Computing. pp. 37-53. Springer International Publishing, Cham (2018)
[12] Ducasse, S., Pollet, D.: Software architecture reconstruction: A process-oriented taxonomy. IEEE Transactions on Software Engineering 35(4), 573-591 (2009). https://doi.org/10.1109/TSE.2009.19
[13] Fan, C., Ma, S.: Migrating Monolithic Mobile Application to Microservice Architecture: An Experiment Report. In: 2017 IEEE AIMS. pp. 109-112 (jun 2017).
https://doi.org/10.1109/AIMS.2017.23
[14] Francesco, P.D., Malavolta, I., Lago, P.: Research on architecting microservices: Trends, focus, and potential for industrial adoption. In: 2017 IEEE ICSA. pp.
21-30 (2017). https://doi.org/10.1109/ICSA.2017.24
[15] Fritzsch, J., Bogner, J., Zimmermann, A., Wagner, S.: From monolith to microservices: A classification of refactoring approaches. CoRR abs/1807.10059 (2018), http://arxiv.org/abs/1807.10059
[16] Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc., USA (1995)
[17] Gysel, M., Kolbener, L., Giersche, W., Zimmermann, O.: Service cutter: A systematic approach to service decomposition. In: Aiello, M., Johnsen, E.B., Dustdar, S., Georgievski, I. (eds.) Service-Oriented and Cloud Computing. pp. 185-200.Springer International Publishing, Cham (2016)
[18] Jin, W., Liu, T., Zheng, Q., Cui, D., Cai, Y.: Functionality-oriented microservice extraction based on execution trace clustering. In: 2018 IEEE ICWS. pp. 211-218 (July 2018). https://doi.org/10.1109/ICWS.2018.00034
[19] Levcovitz, A., Terra, R., Valente, M.T.: Towards a technique for extracting microservices from monolithic enterprise systems. CoRR abs/1605.03175 (2016), http://arxiv.org/abs/1605.03175
[20] Lewis, J., Fowler, M.: Microservices: a definition of this new architectural term (2014), https://martinfowler.com/articles/microservices.html
[21] Mazlami, G., Cito, J., Leitner, P.: Extraction of Microservices from Monolithic Software Architectures. In: 2017 IEEE ICWS. pp. 524-531. IEEE (jun 2017). https://doi.org/10.1109/ICWS.2017.61, http://ieeexplore.ieee.org/document/8029803/
[22] Monaghan, B.D., Bass, J.M.: Redening legacy: A technical debt perspective. In: Morisio, M., Torchiano, M., Jedlitschka, A. (eds.) Product-Focused Software Process Improvement. pp. 254-269. Springer International Publishing, Cham (2020)
[23] Newman, S.: Building microservices: designing fine-grained systems. O’Reilly Media (2019)
[24] Nunes, L., Santos, N., Rito Silva, A.: From a monolith to a microservices architecture: An approach based on transactional contexts. In: Bures, T., Duchien, L., Inverardi, P. (eds.) Software Architecture. ECSA 2019. pp. 37-52. Springer International Publishing, Cham (2019)
[25] Pahl, C., Jamshidi, P.: Microservices: A systematic mapping study. In: Proceedings of the 6th CLOSER – Volume 1 and 2. p. 137-146. CLOSER 2016, SCITEPRESS – Science and Technology Publications, Lda, Setubal, PRT (2016). https://doi.org/10.5220/0005785501370146, https://doi.org/10.5220/0005785501370146
[26] Ponce, F., Marquez, G., Astudillo, H.: Migrating from monolithic architecture to microservices: A rapid review. In: 2019 38th International Conference
of the Chilean Computer Science Society (SCCC). pp. 1-7 (2019). https://doi.org/10.1109/SCCC49216.2019.8966423
[27] Richardson, C.: Microservices Patterns. O’Reilly Media (2018)
[28] Selmadji, A., Seriai, A.D., Bouziane, H.L., Dony, C., Mahamane, R.O.: Rearchitecting oo software into microservices. In: Kritikos, K., Plebani, P., de Paoli,
F. (eds.) Service-Oriented and Cloud Computing. pp. 65-73. Springer International Publishing, Cham (2018)
[29] Selmadji, A., Seriai, A.D., Bouziane, H.L., Mahamane, R., Zaragoza, P., Dony, C.: From monolithic architecture style to microservice one based on a semi-automatic approach. 2020 IEEE International Conference on Software Architecture (ICSA) pp. 157-168 (2020)
[30] Soldani, J., Tamburri, D.A., Van Den Heuvel, W.J.: The pains and gains of microservices: A systematic grey literature review. Journal of Systems and Software 146, 215-232 (2018). https://doi.org/https://doi.org/10.1016/j.jss.2018.09.082, https://www.sciencedirect.com/science/article/pii/S0164121218302139
[31] Terra, R., Valente, M., Bigonha, R.: An approach for extracting modules from monolithic software architectures. In: . pp. 1-8 (01 2012)
[32] Waseem, M., Liang, P., Shahin, M.: A systematic mapping study on microservices architecture in devops. Journal of Systems and Software 170 (2020). https://doi.org/https://doi.org/10.1016/j.jss.2020.110798, https://www.sciencedirect.com/science/article/ pii/S0164121220302053
[33] Zaragoza., P., Seriai., A., Seriai., A., Bouziane., H., Shatnawi., A., Derras., M.: Refactoring monolithic object-oriented source code to materialize microserviceoriented architecture. In: Proceedings of the 16th International Conference on Software Technologies – ICSOFT,. pp. 78-89. INSTICC, SciTePress (2021). https://doi.org/10.5220/0010557800780089