En général, les logiciels d'entreprise sont construits dans un système à trois parties : un côté client/interface utilisateur, une base de données et une application côté serveur appelée monolithe. Les monolithes sont souvent construits comme un seul exécutable logique, à un seul niveau avec plusieurs couches : présentation, logique métier et accès aux données. Ces applications sont faciles à concevoir et à développer, mais elles sont difficiles à maintenir et à faire évoluer, ce qui les rend technologiquement verrouillées et inadaptées au cloud. Pour suivre l'évolution du Cloud Computing et de l'architecture orientée services (SOA), les microservices (MS) se sont naturellement imposés comme la prochaine tendance en raison des avantages qu'ils offrent. Ces Les avantages comprennent une meilleure maintenabilité, une meilleure évolutivité et une meilleure synergie globale. avec les techniques DevOps. La migration des logiciels existants vers une architecture orientée microservices (MSA) est donc une perspective intéressante pour les organisations.
Que sont les microservices ?
L'architecture orientée microservices est un style d'architecture permettant de développer une application unique comme une suite de petits services, chacun s'exécutant dans son propre processus et communiquant avec des mécanismes légers (ressource HTTP, API). Ces services sont construits autour des capacités de l'entreprise et peuvent être déployés indépendamment par des mécanismes de déploiement entièrement automatisés. Il y a un strict minimum de gestion centralisée de ces services, qui peuvent être écrits dans différents langages de programmation et utiliser différentes technologies de stockage de données.
Les MSA peuvent être plus complexes à organiser et peuvent augmenter les exigences technologiques et l'utilisation des réseaux, mais ils présentent une grande adaptabilité technologique, une modularité, une grande évolutivité, une réutilisabilité et peuvent être développés indépendamment par de petites équipes.
L'architecture des microservices est plus complexe à organiser et les exigences technologiques accrues et l'utilisation du réseau, mais elle présente une grande adaptabilité technologique, une modularité et un couplage lâche, elle est hautement évolutive, réutilisable et peut être développée indépendamment par une petite équipe..
Comment évoluer vers les microservices ?
L'architecture de migration d'une application monolithique vers des microservices peut être divisée en deux étapes.
La première étape consiste à identifier une architecture orientée microservices à partir du code source du monolithe. Son objectif principal est d'extraire l'architecture applicative cible pour aider les architectes à moderniser leur application.
La deuxième étape consiste à transformer le code source existant en un code mettant en œuvre la MSA identifiée. C'est la matérialisation.
Phase de récupération : Approche d'identification en couches
Cette première étape consiste à identifier et réorganiser les fonctionnalités du monolithe en classes afin de proposer un ensemble de candidats microservices pour guider la phase de transformation. Cependant, toutes les classes ne sont pas égales, certaines sont structurelles et d'autres orientées données. Nous proposons une approche d'identification qui prend en compte ces deux rôles.
L'approche d'identification en couches s'appuie sur des patrons et des anti-patrons de conception bien établis pour guider le processus d'identification des microservices. Notre approche prend en considération ces patrons et anti-patrons de conception et propose une méthode d'identification en couches. processus d'identification en trois étapes:
- Récupérer les artefacts OO à partir de la source OO.
- Catégorisation des artefacts OO en différentes couches de l'architecture (présentation, métier et accès aux données).
- À partir des artefacts extraits de l'architecture interne en couches, les candidats microservices sont identifiés par une approche de regroupement automatique.
Nous analysons la couche de présentation du monolithe pour déterminer le point d'arrivée de chaque fonctionnalité métier, puis nous appliquons une décomposition verticale à ces points d'arrivée afin de trouver les classes nécessaires pour implémenter chaque fonctionnalité en tant que microservice. Au cours de ce processus, nous définissons également un contexte délimité de la couche d'accès aux données pour chaque microservice.
Récupération de l'architecture en couches par rétro-ingénierie
Pour identifier les candidats aux microservices, nous devons extraire les artefacts de l'architecture en couches du code existant de l'application monolithique. Il s'agit d'identifier ses éléments structurels et les relations entre eux en analysant le code source existant. A partir de ces artefacts, l'architecture en couches peut être révélée par des techniques de rétro-ingénierie. Pour faciliter le processus d'étiquetage et pour représenter l'architecture en couches extraite, nous proposons le métamodèle d'architecture en couches (LAMM) présenté dans la figure ci-dessous.
Ce métamodèle peut être divisé en trois points de vue :
- Architecture en couches : responsable de la représentation de l'architecture typique en 3 couches (présentation, logique d'entreprise et accès aux données).
- DI/IoC : responsable de la représentation du mécanisme de découplage pour créer des artefacts de couche à forte cohésion.
- Persistance des données : responsable de la représentation des différents types de données présents dans les applications web.
Un processus semi-automatique est appliqué pour placer les classes de l'application dans l'une de ces trois catégories en les faisant correspondre à l'une des entités LAMM. Une fois que nous avons mappé les classes dans l'entité appropriée, nous analysons les dépendances avec leurs homologues de couche. Une fois que toutes les entités et leurs relations ont été mises en correspondance avec le modèle LAMM, l'étape d'identification des microservices commence.
Processus d'identification des microservices à l'aide des artefacts extraits
Nous utilisons un algorithme de clustering hiérarchique pour créer un dendrogramme qui est découpé selon un algorithme de type "depth-first" et présenté à l'utilisateur pour validation.
Pour guider le clustering, nous combinons deux mesures de similarité. La première mesure calcule la cohésion structurelle entre les classes d'un candidat microservice et produit une similarité qui favorise la cohésion structurelle en récompensant les clusters dans lesquels il y a plus de relations internes. Appliquée à notre modèle LAMM, elle proposera idéalement une décomposition qui favorise les microservices verticaux centrés sur les capacités métier et limitera le risque de créer de mauvaises coupes. La seconde mesure calcule la cohésion des données d'un candidat microservice pour favoriser les clusters dont les classes manipulent la même classe et promouvoir les clusters qui sont autonomes en données. Appliquée à un algorithme de clustering, elle proposera idéalement une décomposition qui favorise le regroupement des classes manipulant les mêmes données et limitera le risque de créer une persistance partagée entre microservices en créant une propriété des données.
La principale contribution de cette approche dirigée par les modèles est l'identification des microservices à partir du code source original. L'approche proposée exploite l'architecture interne en couches des applications monolithiques tout en fournissant un outil de visualisation pour aider les experts à valider l'identification.
L'architecture interne est souvent détaillée dans le code source par le biais d'annotations de classes, d'espaces de noms et de fichiers de configuration. L'approche proposée utilise l'architecture en couches pour décomposer verticalement un monolithe tout en minimisant le couplage entre les microservices.. En particulier, nous avons pu démontrer que l'ajout d'artefacts sur l'architecture en couches de l'application monolithique avait un impact positif sur le processus d'identification.
Dans les travaux futurs, nous avons l'intention d'étendre notre approche d'identification pour intégrer le remaniement, le conditionnement et le déploiement de la MSA identifiée. Pour renforcer encore notre validation, nous avons l'intention d'utiliser cette approche de migration de bout en bout pour générer et évaluer la qualité de notre MSA à l'exécution.
Références
[1] J. Lewis et M. Fowler, "Microservices : une définition de ce nouveau terme architectural", https://martinfowler.com/articles/microservices.html,
2014, consulté le : 2020-06-20.
[2] L. Bass, I. Weber et 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 et L. Safina, Microservices : Yesterday, Today, and Tomorrow. Cham : Springer International Publishing, 2017, pp. 195- [En ligne]. Disponible à l'adresse suivante : https://doi.org/10.1007/978-3-319-67425-4 12
[4] C. Richardson, Microservices Patterns : Avec des exemples en Java. Manning Publications, 2018. [En ligne]. Disponible à l'adresse suivante : https://books.google.de/books?id=UeK1swEACAAJ
[5] D. Taibi, V. Lenarduzzi et C. Pahl, Microservices Anti-patterns : A Taxonomy. Cham : Springer International Publishing, 2020, pp. 111- [En ligne]. Disponible : https://doi.org/10.1007/978-3-030-31646-4 5
[6] O. Al-Debagy et 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. [En ligne]. Disponible à l'adresse suivante : https://www.scpe.org/index.php/scpe/article/view/1836
[7] T. Lutellier, D. Chollak, J. Garcia, L. Tan, D. Rayside, N. Medvidovic et R. Kroeger, " Comparing software architecture recovery techniques using accurate dependencies ", dans 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 2, 2015, pp. 69-78.
[8] Z. Wen et V. Tzerpos, " An effectiveness measure for software clustering algorithms ", dans 12th International Workshop on Program Comprehension (IWPC 2004), 24-26 juin 2004, Bari, Italie. IEEE Computer Society, 2004, pp. 194-203. [En ligne]. Available: https://doi.org/10.1109/WPC.2004.1311061
[9] D. M. Le, P. Behnamghader, J. Garcia, D. Link, A. Shahbazian et 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 et S. Lotfi, "A graph-based clustering algorithm for software systems modularization", Information and Software Technology, vol. 133, p. 106469, 2021. [En ligne]. Disponible à l'adresse suivante : https://www.sciencedirect.com/science/article/pii/S0950584920302147
[11] W. Jin, T. Liu, Q. Zheng, D. Cui et Y. Cai, " Functionality-Oriented Microservice Extraction Based on Execution Trace Clustering ", dans 2018 IEEE International Conference on Web Services (ICWS), no. Octobre. IEEE, jul 2018, p. 211-218. [En ligne]. Disponible : https://ieeexplore.ieee.org/document/8456351/
[12] Y. Zhang, B. Liu, L. Dai, K. Chen et X. Cao, " Automated Microservice Identification in Legacy Systems with Functional and Non-Functional Metrics ", dans 2020 IEEE International Conference on Software Architecture (ICSA). IEEE, mars 2020, pp. 135-145. [En ligne]. Disponible à l'adresse suivante : https://ieeexplore.ieee.org/document/9101217/
[13] J. Garcia, I. Krka, C. Mattmann et N. Medvidovic, "Obtaining groundtruth software architectures," in 2013 35th International Conference on Software Engineering (ICSE), 2013, pp. 901-910.
[14] C. Pahl et P. Jamshidi, " Microservices : A Systematic Mapping Study ", in Proceedings of the 6th International Conference on Cloud Computing and Services Science, M. Cardoso, J et Ferguson, D et Munoz, VM et Helfert, Ed. SCITEPRESS - Publications scientifiques et technologiques, 2016, p. 137-146.
[15] P. D. Francesco, I. Malavolta et 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, avril 2017, p. 21-30. [En ligne]. Disponible à l'adresse suivante : http://ieeexplore.ieee.org/document/7930195/
[16] J. Fritzsch, J. Bogner, A. Zimmermann et 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 et B. Meyer, Eds, vol. 11350. Springer, 2018, p. 128-141. [En ligne]. Disponible : https://doi.org/10.1007/978-3-030-06019-0 10
[17] D. Escobar, D. Cardenas, R. Amarillo, E. Castro, K. Garces, C. Parra et 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. [En ligne]. Disponible à l'adresse suivante : http://ieeexplore.ieee.org/document/7833410/
[18] L. Nunes, N. Santos, et 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, p. 37-52.
[19] A. Levcovitz, R. Terra et M. T. Valente, "Towards a Technique for Extracting Microservices from Monolithic Enterprise Systems", CoRR, vol. abs/1605.0, mai 2016. [En ligne]. Disponible à l'adresse suivante : http://arxiv.org/abs/1605.03175
[20] A. Selmadji, A. Seriai, H. Bouziane, R. O. Mahamane, P. Zaragoza et C. Dony, "From monolithic architecture style to microservice one based".
on a semi-automatic approach", dans 2020 IEEE International Conference on Software Architecture, ICSA 2020, Salvador, Brésil, 16-20 mars, IEEE, 2020, pp. 157-168.
