Migration d'une application monolithique backend vers une architecture microservices - 2ème partie

Retrouvez la première partie de l'article en en suivant ce lien

Dans la première partie de l'article, nous avons expliqué comment identifier les candidats aux microservices en extrayant les artefacts de l'architecture en couches du code existant d'une application monolithique. Plusieurs approches abordent cette première étape, bien qu'elles n'abordent pas l'étape de matérialisation ou qu'elles complètent cette étape manuellement. Bien que les clusters récupérés aident à comprendre la MSA cible, le code source doit être transformé pour se conformer au style de la MSA (communication basée sur les services, orientée message, etc.). Dans cette deuxième partie, nous expliquerons la matérialisation du code source existant en un code implémentant le MSA identifié en utilisant une approche de transformation ad hoc.

Concrètement, l'objectif de l'étape de matérialisation est de transformer le code source monolithique existant pour créer des microservices fonctionnels qui se conforment aux critères suivants
l'architecture de microservices récupérée, tout en préservant la logique métier de l'application. En ce qui concerne les applications monolithiques suivant la méthode objet-
La difficulté de l'étape de matérialisation consiste à transformer les dépendances OO présentes entre les clusters de classes identifiés en dépendances MSA.
les dépendances de type (c'est-à-dire les services). De plus, ces transformations doivent respecter les principes de refactoring (i.e. préserver la logique métier) sans dégrader les performances du système global. Cependant, malgré l'importance de la deuxième étape de la migration, et à notre connaissance, aucune approche n'a été proposée pour l'automatiser.
Dans cet article, nous proposons une approche systématique pour transformer une application OO du style monolithique en une application MSA en nous appuyant sur un ensemble de modèles de transformation.. Cet ensemble de patrons de transformation crée des mécanismes de communication basés sur des microservices qui préservent la sémantique du monolithe tout en se conformant aux principes du MSA (par exemple, basé sur les messages et orienté vers les données). En outre, nous proposons un processus automatisé, et un outil, qui applique notre approche de transformation systématique.

Transformation du code source OO vers un code MSA

La MSA identifiée par l'étape de récupération de l'architecture est matérialisée dans l'étape de transformation. Elle consiste à convertir le code source orienté objet en code source MSA. Chaque cluster de classes récupéré est ensuite déployé dans son propre microservice au cours de cette étape (c'est-à-dire l'encapsulation du microservice). Cependant, les classes périphériques ont par définition des dépendances avec les classes appartenant à un autre cluster. Ces dépendances structurelles directes entre les classes de différents microservices sont appelées violations de l'encapsulation des microserviceset ils doivent être traités avant qu'un microservice puisse être entièrement encapsulé.

En effet, toutes les violations doivent être traitées par des méthodes de refactoring qui convertissent toutes les dépendances de type OO en dépendances de type MS avant qu'un microservice puisse être généré. Au cours de cette étape, la caractéristique opérationnelle d'un MSA d'utiliser la communication orientée message entre différents microservices est considérée. En d'autres termes, les invocations de méthodes entre les classes appartenant à différents clusters (par exemple, les appels de méthodes entre DisplayManager et ContentProvider) doivent être limitées à un ensemble d'interfaces fournies et requises qui définissent à la fois les services Web qu'il fournit et ceux qu'il consomme. En outre, les appels de communication interprocessus (IPC) entre microservices sont limités à la communication basée sur la valeur. En d'autres termes, seules les primitives et les données sérialisées sont échangées entre les microservices. Cependant, un appel procédural dans un système OO peut transmettre des références d'objets entre l'objet qui invoque et celui qui est invoqué. Pour encapsuler les microservices, le mécanisme de partage d'instance entre les candidats microservices doit être résolu.
Outre ces dépendances OO explicites, les dépendances implicites entre les clusters doivent être traitées pour encapsuler complètement les candidats microservices. Le mécanisme d'héritage et la gestion des exceptions sont les deux principaux mécanismes OO implicites à prendre en compte. En particulier, une violation d'héritage est définie comme une classe dont la super-classe appartient à un autre cluster (par exemple, entre Message et Content). La violation de la gestion des exceptions est définie comme une classe
lancer une exception qui est attrapée par une classe appartenant à un autre cluster. Ces deux mécanismes OO doivent être traités et transformés en dépendances de type MS.
Enfin, les MSA générés après l'étape de transformation doivent respecter 2 caractéristiques opérationnelles supplémentaires :

1. Les microservices doivent fonctionner sur leur propre processus
2. Ils doivent pouvoir être déployés automatiquement

Pour se conformer à ces caractéristiques opérationnelles, chaque microservice doit définir un projet indépendant qui doit être configuré pour le déploiement dans le Cloud. Ces deux caractéristiques doivent être prises en compte lors de la génération du code source de chaque microservice.

MonoToMicro : Une approche de refactoring semi-automatique

Dans cet article, nous proposons une méthode systématique de transformation d'une application OO monolithique en une application MSA à l'aide d'un ensemble de patrons de transformation. L'objectif de cette approche est de transformer un code source orienté objet monolithique en un MSA en encapsulant les clusters découverts lors de l'étape initiale de migration.. Pour ce faire, nous définissons un processus composé de quatre étapes, comme indiqué dans le document suivant Figure 2 qui consistent en :

1. Détection des violations d'encapsulation,
2. Guérir les violations d'encapsulation,
3. Conditionnement des microservices,
4. Déploiement et conteneurisation de microservices

Détection des violations d'encapsulation

Chaque cluster de classes récupéré est encapsulé dans son propre microservice pour matérialiser les candidats microservices récupérés à partir de la source du logiciel orienté objet. D'autre part, l'encapsulation empêche les dépendances OO entre les clusters (c'est-à-dire les violations d'encapsulation). Par conséquent, elles doivent être transformées en dépendances de type MS. Cependant, avant que la transformation puisse avoir lieu, ces violations d'encapsulation doivent être identifiées. Pour faciliter la détection de ces violations d'encapsulation, un ensemble de règles de violation d'encapsulation est proposé pour analyser le monolithe :

• (Règle 1) : si une méthode d'un cluster invoque une méthode appartenant à une classe d'un autre cluster, il s'agit d'une violation d'invocation de méthode.
• (Règle 2) : si une méthode d'un cluster accède à un attribut appartenant à une classe d'un autre cluster, il y a violation d'accès.
• (Règle 3) : si une classe d'un cluster contient une référence ciblant une classe d'un autre cluster, il s'agit d'une violation d'instance.
• (Règle 4) : si une classe d'un cluster hérite d'une classe appartenant à un autre cluster, il s'agit d'une violation d'héritage.
• (Règle 5) : si une méthode d'un cluster lance, attrape ou déclare une exception définie dans un autre cluster, il s'agit d'une violation d'exception lancée.

Ces règles sont appliquées à la représentation AST du code source OO.
Initialement, la description de l'architecture cible est utilisée pour partitionner les nœuds AST qui représentent les classes dans la source OO en clusters. Ensuite, chaque nœud est
analysé pour trouver des références vers des nœuds de classe appartenant à un autre cluster en utilisant les règles de détection susmentionnées. Une fois que toutes les violations ont été détectées, le processus de résolution de toutes ces violations peut prendre place.

Guérir les violations de l'encapsulation

Les violations détectées à l'étape précédente doivent être guéries à l'aide de règles de transformation afin d'encapsuler les microservices. Ces transformations doivent soit guérir complètement, soit réduire une violation à un type solvable. Auparavant, l'identification de la violation d'encapsulation couvrait :

1. Invocation de la méthode
2. Accès aux attributs
3. Traitement des instances
4. Héritage
5. Traitement des exceptions

Dans cet article, nous présentons un ensemble de règles de transformation pour guérir les violations d'encapsulation identifiées dans la première étape. En particulier, nous séparons ces violations en deux catégories : explicites et implicites.. En règle générale, les microservices doivent obscurcir leur structure et leur comportement internes tout en exposant une interface clairement définie. Les violations qui enfreignent cette règle sont considérées comme explicites (par exemple, l'accès aux attributs, la gestion des instances et l'invocation de méthodes). Alors que les violations implicites sont liées à la dépendance implicite entre les microservices causée par le mécanisme OO (par exemple, l'héritage et la gestion des exceptions).

Emballage et déploiement d'un MSA

Une fois que le code source du MSA a été généré, il doit être emballé et rendu déployable. Au fur et à mesure de l'approche de refactoring semi-automatique, les microservices sans violation sont empaquetés. Pour ce faire, chaque microservice a son propre projet dans lequel le code source est généré. Les structures de fichiers et les dépendances du projet sont ensuite construites automatiquement. Les projets de microservices sont ensuite conteneurisés dans l'étape de résolution des violations d'encapsulation en générant des images instanciables. Un fichier de description d'image est créé pour chaque microservice. Un fichier de composition est également créé, qui organise et fournit tous les microservices en même temps.
Dans ce travail, nous nous concentrons sur les deux premières étapes de la phase de transformation, qui comprennent les principaux obstacles scientifiques mis en évidence précédemment,
et laisser les deux dernières étapes pour la mise en œuvre, car elles comportent des obstacles plus techniques.

A suivre...

Références

[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 et expériences, 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. : Identification des microservices en fonction des objets. 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-
Orienté et informatique en nuage. pp. 19-33. Springer International Publishing, Cham (2017) Matérialiser l'architecture orientée microservices 25.
[6] Baskarada, S., Nguyen, V., Koronios, A. : Architecting microservices : Opportunités et défis pratiques. 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. : Processus de récupération d'architecture logicielle basé sur le code source et la documentation orientés objet. 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, p. 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. Actes - Conférence Asie-Pacifique sur le génie logiciel, 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 : Un rapport d'expérience. Dans : 2017 IEEE AIMS. pp. 109-112 (jun 2017).
https://doi.org/10.1109/AIMS.2017.23
[14] Francesco, P.D., Malavolta, I., Lago, P. : Recherche sur l'architecture des microservices : Tendances, focus, et potentiel pour l'adoption industrielle. Dans : 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 : Une classification des approches de refactoring. 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. : Extraction de microservices orientée fonctionnalité basée sur le clustering de traces d'exécution. Dans : 2018 IEEE ICWS. pp. 211-218 (juillet 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 : une définition de ce nouveau terme architectural (2014), https://martinfowler.com/articles/microservices.html.
[21] Mazlami, G., Cito, J., Leitner, P. : Extraction de microservices à partir d'architectures logicielles monolithiques. Dans : 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 : Une approche basée sur les contextes transactionnels. 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 : Actes de la 6ème édition de CLOSER - Volume 1 et 2. p. 137-146. CLOSER 2016, SCITEPRESS - Publications scientifiques et technologiques, 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 : Une revue rapide. Dans : 2019 38e conférence internationale.
de la Société chilienne des sciences informatiques (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. : Réarchitecture de logiciels oo en 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. : Du style d'architecture monolithique à celui de microservice basé sur une approche semi-automatique. 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. : Une approche pour l'extraction de modules à partir d'architectures logicielles monolithiques. In : . pp. 1-8 (01 2012)
[32] Waseem, M., Liang, P., Shahin, M. : Une étude de cartographie systématique sur l'architecture des microservices dans les 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