‫ﺍلجمهوﺭ ية ﺍلشعبية ﺍلديمقرﺍطية ﺍلجزﺍئر ية‬

République Algérienne Démocratique et Populaire

‫وﺯﺍﺭﺓ ﺍلتعليم ﺍلعالي و ﺍلبحث ﺍلعلمي‬
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
‫ بسيدي بلعباﺱ‬.5491 ‫ ماي‬٠80 ‫ﺍلمدﺭسة ﺍلعليا للإعلام ﺍلآلي‬
École Supérieure en Informatique
-08 Mai 1945- Sidi Bel Abbès

MEMOIRE
En vue de l’obtention du diplôme de Master
Filière: Informatique
Spécialité: Système D’information et Web (SIW)

Thème

Stratégies et Méthodologies pour la Migration vers

l’Architecture Microservices

Présenté par:
AOUADJ Moncef

Date de soumission: Sept, 2023

Devant le jury composé de:

Mr. Someone President

Ms. Someone Co-Supervisor
Ms. someone Supervisor
Mr. Someone Examiner

Année Universitaire : 2023/2024

 Remerciements

Je tiens tout d’abord à exprimer ma profonde gratitude à ALLAH le Tout-Puissant, qui

m’a accordé la volonté, la patience, et la lumière nécessaires pour mener à bien ce travail de
mémoire.
Je souhaite également remercier chaleureusement mes encadrants de mémoire, M. Chouki
Tibermacine, M. Vincent Berry du LIRMM et M. Malki Abdelhamid de l’ESI-SBA.
Leur guidance précieuse, leurs encouragements constants, et leurs conseils avisés ont été in-
dispensables à l’aboutissement de ce projet. Je les remercie sincèrement pour le temps et
l’attention qu’ils m’ont consacrés.
Mes remerciements vont également à toute l’équipe du département d’informatique de
l’ESI-SBA, ainsi qu’à l’équipe du LIRMM. Leur soutien pédagogique et leur disponibilité
ont grandement facilité mon parcours.
Je tiens à exprimer ma reconnaissance aux membres du jury pour l’honneur qu’ils m’ont
fait en acceptant de juger et d’évaluer mon travail. Leurs retours seront pour moi une source
précieuse d’amélioration.
Je n’oublie pas de remercier tous ceux qui m’ont aidé, de près ou de loin, dans la réalisation
de ce mémoire. Leur aide a été précieuse et je leur en suis profondément reconnaissant.
Enfin, j’adresse mes remerciements les plus sincères à ma famille et à mes amis, qui m’ont
accompagné, soutenu et encouragé tout au long de cette aventure académique. Leur présence
à mes côtés a été une source inestimable de force et de motivation.

1
 Resumé

Au cours de la dernière décennie, le développement des applications web a connu des avancées
significatives, stimulé par l’émergence de nouvelles techniques et architectures visant à améliorer
l’efficacité, la scalabilité et l’agilité. Ces développements ont été largement propulsés par
l’adoption généralisée du cloud computing et de DevOps, qui sont devenus des pratiques
fondamentales dans l’ingénierie logicielle moderne. En particulier, l’architecture des mi-
croservices a gagné en importance pour son efficacité dans ces environnements.

L’architecture microservices, souvent simplement appelée microservices, structure une

application comme une collection de services faiblement couplés. Chaque service, ou mi-
croservice, fonctionne comme une mini-application capable de fonctionner indépendamment,
de choisir sa propre pile technologique et d’adopter son propre cycle de vie de développement.
Cette indépendance permet à chaque microservice d’être développé, déployé et mis à l’échelle
sans impacter les autres composants du système.

L’un des défis majeurs en développement logiciel aujourd’hui est la migration des archi-
tectures traditionnelles, ou ce qu’on appelle les architectures monolithiques, vers des archi-
tectures microservices. Cette transition implique de passer d’un modèle unifié, où les appli-
cations sont développées comme une entité unique, à un modèle microservices décentralisé.
Pour faciliter cela, diverses méthodologies ont été développées, généralement catégorisées
en deux types principaux : les approches techniques et les approches basées sur le retour
d’expérience. Les approches techniques reposent sur des méthodologies définies et des pro-
cessus qui spécifient des objectifs clairs, nécessitent des informations d’entrée spécifiques et
visent à atteindre des résultats précis. Les approches basées sur le retour d’expérience s’ap-
puient sur les expériences pratiques et les insights acquis lors de migrations passées, offrant
une perspective réelle sur les défis et les solutions pour adopter les architectures microservices.

2
 Mots-clés :— Applications Web, Cloud Computing, DevOps, Architecture Microservices, Mi-
gration Logicielle, Architectures Monolithiques, Approches Techniques, Approches basées sur le
Retour d’Expérience

3
 Abstract

Over the past decade, the development of web applications has significantly advanced, driven by the
emergence of new techniques and architectures aimed at enhancing efficiency, scalability, and agility.
These developments have been largely propelled by the widespread adoption of Cloud computing
and DevOps, which have become cornerstone practices in modern software engineering. Particularly,
the microservices architecture has gained prominence for its effectiveness in these environments.

Microservices architecture, often simply referred to as microservices, structures an application as

a collection of loosely coupled services. Each service, or microservice, functions as a mini-application
capable of operating independently, selecting its own technology stack, and adopting its own devel-
opment lifecycle. This independence allows for individual microservices to be developed, deployed,
and scaled without impacting other components of the system.

One of the significant challenges in software development today is migrating from traditional,
monolithic architectures to microservices. This transition involves moving from a unified model,
where applications are developed as a single entity, to a decentralized microservices model. To fa-
cilitate this, various methodologies have been developed, generally categorized into two main types:
technical approaches and feedback approaches. Technical approaches rely on defined methodologies
and processes that specify clear objectives, require specific input information, and aim to achieve
precise outputs. Feedback approaches draw upon the practical experiences and insights gained from
past migrations, offering a real-world perspective on the challenges and solutions in adopting mi-
croservices architectures.

Mots-clés :— Web Applications, Cloud Computing, DevOps, Microservices Architecture, Soft-

ware Migration, Monolithic Architectures, Technical Approaches, Feedback Approaches

4
 CONTENTS

I Introduction 11
1 Introduction 12
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Problématique et Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

II Background 14
2 Architecture Monolithique 15
2.1 Introduction à l’Architecture Monolithique . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Structure et Composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Avantages et Utilisation Initiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Défis et Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Pile Technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Gestion des Changements et Maintenance . . . . . . . . . . . . . . . . . . . . 17
2.4.4 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.5 Dette Architecturale et Silos de Données . . . . . . . . . . . . . . . . . . . . . 18

3 Architecture SOA 19
3.1 Principes et Pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Caractéristiques de SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Pratiques Courantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Catégories de Services en SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Architecture Microservices 21
4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Les Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5
 4.3 Avantages et Inconvénients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Comparaison Entre Monolithique, SOA et Microservices 23

6 Les Patterns des Microservices 25

6.1 Les Patterns de Décomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1 Pattern de Décomposition par Capacité Commerciale . . . . . . . . . . . . . 25
6.1.2 Pattern de Décomposition par Sous-Domaine . . . . . . . . . . . . . . . . . . 25
6.1.3 Nouveaux Patterns de Décomposition . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Les Patterns De Messagerie Transactionnelle . . . . . . . . . . . . . . . . . . . . . . 26
6.2.1 Pattern Boîte D’envoi Transactionnelle . . . . . . . . . . . . . . . . . . . . . . 26
6.2.2 Pattern Journal Des Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.3 Pattern Éditeur De Sondage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3 Les Patterns de Gestion de Données . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3.1 Pattern de Base de Données pour Chaque Service . . . . . . . . . . . . . . . . 27
6.3.2 Pattern de Base de Données Partagée . . . . . . . . . . . . . . . . . . . . . . 27
6.3.3 Pattern SAGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.4 Pattern CQRS (Command Query Responsibility Segregation) . . . . . . . . . 28
6.3.5 Pattern API Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4 Les Patterns de Découverte de Service . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.1 Pattern de Découverte Côté Client . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.2 Pattern de Découverte Côté Serveur . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.3 Pattern Registre de Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.5 Les Patterns d’API Externes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.5.1 API-Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.5.2 API-Gateway / Backends Pour Frontends (BFF) . . . . . . . . . . . . . . . . 31
6.6 Les Patterns de Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.6.1 Pattern d’Authentification par Jeton . . . . . . . . . . . . . . . . . . . . . . . 32
6.6.2 Pattern de Porte de Sécurité (Security Gateway) . . . . . . . . . . . . . . . . 32
6.6.3 Pattern de Chiffrement des Données . . . . . . . . . . . . . . . . . . . . . . . 33
6.6.4 Pattern d’Audit et de Suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.7 Les Patterns de Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.7.1 Pattern Multi-Service par Hôte . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.7.2 Pattern Un Seul Service par Hôte . . . . . . . . . . . . . . . . . . . . . . . . . 34

III State of Art 36

7 Introduction 37

6
8 Approches Techniques 38
8.1 Approche pilotée par le domaine (Domain-Driven Design - DDD) : Une approche
stratégique pour la migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1.1 DDD et la décomposition du monolithe . . . . . . . . . . . . . . . . . . . . . 38
8.1.2 Exemple : le système de gestion des commandes . . . . . . . . . . . . . . . . 38
8.1.3 Identification des agrégats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.4 Migration progressive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.5 Avantages de l’approche DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1.6 Défis de l’approche DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2 Approche centrée sur les données pour l’identification des microservices : Une per-
spective nouvelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2.3 Processus d’identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2.3.1 Analyse du modèle de données . . . . . . . . . . . . . . . . . . . . . 42
8.2.3.2 Construction et prétraitement des documents . . . . . . . . . . . . . 42
8.2.3.3 Enrichissement sémantique des documents . . . . . . . . . . . . . . . 42
8.2.3.4 Classification (clustering) . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2.3.4.1 La vectorisation TF-IDF: . . . . . . . . . . . . . . . . . . . 43
8.2.3.4.2 Détermination du nombre optimal de clusters: . . . . . . . 43
8.2.3.5 Attribution des tables et inférence des noms de microservices . . . . 43
8.3 Approches Automatisées par l’Intelligence Artificielle . . . . . . . . . . . . . . . . . . 45
8.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.2 Approches proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.2.1 Approche naïve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.2.2 Approche basée sur les appels co-dépendants . . . . . . . . . . . . . 45
8.3.2.3 Approche basée sur la théorie des graphes . . . . . . . . . . . . . . . 46
8.4 Approche basée sur les processus métier et les objets de données . . . . . . . . . . . 48
8.4.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.4.2 Algorithme d’identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.5 Etude Comparative Entre Les Approches . . . . . . . . . . . . . . . . . . . . . . . . 50
8.5.1 Introduction à l’Étude Comparative . . . . . . . . . . . . . . . . . . . . . . . 50
8.5.2 Critères de Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.5.3 Analyse Approfondie des Approches . . . . . . . . . . . . . . . . . . . . . . . 50
8.5.3.1 Approche Pilotée par le Domaine (Domain-Driven Design - DDD) . 50
8.5.3.1.1 Adaptabilité : . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.5.3.1.2 Complexité : . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3.1.3 Performance : . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3.1.4 Maintenance : . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3.1.5 Automatisation : . . . . . . . . . . . . . . . . . . . . . . . . 51

7
 8.5.3.2 Approche Centrée sur les Données (Data-Centric Process for Mi-
croservice Identification) . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3.2.1 Adaptabilité : . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3.2.2 Complexité : . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3.2.3 Performance : . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3.2.4 Maintenance : . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3.2.5 Automatisation : . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3.3 Approches Automatisées par l’Intelligence Artificielle . . . . . . . . . 52
8.5.3.3.1 Adaptabilité : . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3.3.2 Complexité : . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3.3.3 Performance : . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3.3.4 Maintenance : . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3.3.5 Automatisation : . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3.4 Approche Basée sur les Processus Métier et les Objets de Données . 53
8.5.3.4.1 Adaptabilité : . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.3.4.2 Complexité : . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.3.4.3 Performance : . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.3.4.4 Maintenance : . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.3.4.5 Automatisation : . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.4 Tableau Comparatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

IV Conclusion 55
9 Conclusion 56

Bibliography 60

8
 LIST OF FIGURES

2.1 Modèle générique d’architecture monolithique . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Scalabilité horizontale d’un monolithe . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Architecture SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Exemple d’une architecture Microservices . . . . . . . . . . . . . . . . . . . . . . . . 21

6.1 Résumé de tous les patterns de microservices . . . . . . . . . . . . . . . . . . . . . . 35

8.1 Les contextes délimités et les relations entre eux . . . . . . . . . . . . . . . . . . . . 39

8.2 Processus proposé pour l’identification des microservices . . . . . . . . . . . . . . . . 41
8.3 Diagramme de relation d’entité de l’application de pièces automobiles . . . . . . . . 42
8.4 Résultat de la méthode Elbow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.5 Exemple illustratif de la métrique considérée . . . . . . . . . . . . . . . . . . . . . . 46

9
 LIST OF TABLES

5.1 Comparaison des architectures Monolithique, SOA et Microservices . . . . . . . . . . 24

8.1 Résultats du Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

8.2 Comparaison des différentes approches . . . . . . . . . . . . . . . . . . . . . . . . . . 53

10
 Part I

Introduction

11
Section 1

Introduction

1.1 Contexte
L’évolution rapide des technologies de l’information a entraîné une transformation significative
des méthodes de développement et de déploiement des applications. Traditionnellement dominées
par des architectures monolithiques, les entreprises sont aujourd’hui confrontées à des défis d’agilité
et d’évolutivité qui remettent en question les anciennes pratiques. L’essor des technologies cloud
et des approches basées sur les microservices offre de nouvelles opportunités pour surmonter ces
obstacles, en permettant des déploiements flexibles et une scalabilité accrue.
Les architectures de microservices, en particulier, offrent une granularité fine et une possibilité
de déploiement indépendant, ce qui les rend idéales pour les environnements dynamiques et évolutifs.
Cette approche favorise également l’adoption de pratiques DevOps, en soutenant un cycle de vie
d’application continu de la conception au déploiement.

1.2 Problématique et Objectif

La migration d’applications monolithiques vers des architectures microservices représente une
étape critique pour les entreprises qui souhaitent bénéficier de la flexibilité et de l’efficacité du
cloud computing et des modernes pratiques de développement. Cette transition n’est pas sans défis,
car elle implique de repenser l’architecture applicative à un niveau fondamental pour exploiter
pleinement les avantages des microservices.
L’objectif principal de cette recherche est d’explorer les stratégies efficaces pour la transition des
architectures monolithiques vers les microservices. Nous nous concentrerons sur les méthodologies
permettant d’identifier et de décomposer une application monolithique en services indépendants,
tout en garantissant la cohérence, la performance, et l’adaptabilité aux environnements cloud.

12
1.3 Organisation
Le mémoire est structuré de manière à couvrir de manière exhaustive le sujet étudié à travers
plusieurs chapitres détaillés :

• Part 2 : Background – Ce chapitre établit le cadre théorique de la recherche, introduit les

concepts clés des architectures monolithiques, SOA et microservices, et présente une analyse
comparative de ces modèles.

• Part 3 : État de l’Art – Analyse approfondie des travaux existants relatifs à la migration
des systèmes monolithiques vers des architectures basées sur les microservices. Ce chapitre
inclut également une revue de la littérature sur les défis, les stratégies, et les résultats obtenus
dans des études de cas pertinentes.

• Part 4 : Conclusion et Perspectives – Résume les contributions principales de la

recherche et propose des orientations pour des travaux futurs, soulignant les opportunités
d’approfondissement des méthodologies de migration et d’optimisation des architectures mi-
croservices.

13
 Part II

Background

14
Section 2

Architecture Monolithique

2.1 Introduction à l’Architecture Monolithique

L’architecture monolithique, ou ”monolithe”, décrit un style architectural où la modularité
n’est pas considérée comme un principe de conception fondamental. Initialement, ce terme a été
utilisé pour désigner des applications lourdes sur mainframe, autonomes et devenant de plus en plus
complexes à maintenir à mesure que le nombre de fonctionnalités augmente avec les mises à jour
des versions [1].

2.2 Structure et Composants

Une architecture monolithique se base généralement sur un modèle en couches, où chaque couche
est fortement couplée et centralisée. Elle comprend typiquement une couche d’interface utilisateur,
une couche de logique métier et une couche d’accès aux données [2]. Toutes les fonctionnalités de
l’application sont regroupées dans un seul bloc de code, ce qui simplifie initialement le développe-
ment, le déploiement et la mise à l’échelle tant que la taille du code reste gérable [3].
La figure ci-dessous (figure 2.1) montre un modèle générique d’architecture monolithique, inclu-
ant ses composants clés pour la logique, l’interface utilisateur et la communication avec une base
de données.

2.3 Avantages et Utilisation Initiale

Malgré ses limitations, l’architecture monolithique reste populaire, notamment pour les petits
projets et les preuves de concept, grâce à sa simplicité initiale et à la rapidité de mise sur le
marché qu’elle offre [4]. Elle permet de centraliser les composants et de bénéficier d’une vitesse de
développement initiale avant que la complexité et les défis de maintenance ne deviennent apparents
[1].

15
 Figure 2.1: Modèle générique d’architecture monolithique

2.4 Défis et Limitations

2.4.1 Pile Technologique

Un des principaux inconvénients des applications monolithiques est leur dépendance à une seule
pile technologique. Par exemple, une application écrite en Java devra continuer à utiliser Java pour
toute extension future, ce qui limite l’utilisation de nouveaux frameworks ou langages adaptés au
déploiement dans le cloud.

2.4.2 Scalabilité
La scalabilité d’une architecture monolithique est limitée. Toutes les fonctionnalités partagent
les ressources (CPU et mémoire) d’un même système hôte, ce qui peut conduire à une saturation
des ressources en cas de forte demande pour une fonctionnalité particulière. La mise à l’échelle
verticale, en augmentant la mémoire, est souvent insuffisante, et la mise à l’échelle horizontale, en

16
ajoutant des serveurs redondants, est coûteuse et complexe à gérer [1, 5].
Par conséquent, la mise à l’échelle horizontale, illustrée à la figure 2.2, est la seule solution
réaliste pour augmenter la capacité des monolithes. Cela implique d’ajouter plus d’instances de
l’application entière sur de nouveaux serveurs redondants jusqu’à ce que la capacité soit suffisante
pour traiter les demandes provenant de l’interface utilisateur graphique. Il est également nécessaire
d’utiliser un équilibreur de charge pour distribuer les requêtes entrantes entre les serveurs. La
réplication des sessions est nécessaire pour distribuer les sessions entre les serveurs afin qu’une
session utilisateur puisse être traitée sur plusieurs serveurs. Comme l’illustre la figure 3, il n’y a pas
de base de données partagée entre les instances fonctionnant sur des serveurs distincts. Il est donc
nécessaire de répliquer la base de données pour garantir des instances actuelles et redondantes de
la base de données. Cette technique de mise à l’échelle est coûteuse et ajoute de la complexité au
système exécutant les instances, et n’est pas bien adaptée au déploiement dans le cloud [1].

Figure 2.2: Scalabilité horizontale d’un monolithe

2.4.3 Gestion des Changements et Maintenance

Avec l’augmentation du nombre de fonctionnalités, un monolithe devient de plus en plus com-
plexe à maintenir. Les fonctionnalités sont fortement couplées et interdépendantes, rendant chaque
changement potentiellement risqué pour l’ensemble du système. Tester une fonctionnalité modifiée
nécessite souvent de re-tester l’application entière, augmentant le temps et les coûts de maintenance

17
[5, 6].

2.4.4 Déploiement
Le déploiement d’une application monolithique est un autre défi majeur. Il n’est pas possible
de déployer des fonctionnalités individuelles de manière indépendante ; c’est toujours l’application
entière qui doit être déployée. Cela implique souvent des temps d’arrêt pendant le redémarrage de
l’application, à moins d’utiliser des configurations de haute disponibilité qui peuvent être coûteuses
[5, 7].

2.4.5 Dette Architecturale et Silos de Données

Les systèmes monolithiques souffrent souvent de ”dette architecturale” due à la complexité
croissante et aux solutions sous-optimales adoptées au fil du temps. Les architectures basées sur
des silos de données créent des couplages serrés et des dépendances, rendant les changements difficiles
et risqués. Cette complexité accrue peut freiner l’innovation et le développement commercial [8, 9].

18
Section 3

Architecture SOA

3.1 Principes et Pratiques

L’Architecture Orientée Services, ou SOA, est un modèle architectural qui a gagné en popularité
au début des années 2000 [10]. Cette architecture répond à un besoin croissant d’agilité dans les
entreprises, permettant une réponse rapide et flexible aux exigences commerciales changeantes.
Dans SOA, les applications sont décomposées en petits composants fonctionnels, appelés services,
qui peuvent être assemblés et réassemblés pour former des applications complètes [11]. Ces services
sont indépendants mais peuvent interagir via des protocoles de communication bien définis, souvent
implémentés sur des réseaux.

Figure 3.1: Architecture SOA

3.1.1 Caractéristiques de SOA

SOA est basée sur quelques principes clés qui visent à améliorer la flexibilité et la réutilisabilité
des ressources informatiques [12]:

19
 • Réutilisation des services: Les services dans une architecture SOA sont conçus pour être
réutilisés dans différents contextes et applications. Cela permet de réduire les coûts et le temps
de développement en réutilisant des fonctionnalités existantes plutôt que de les reconstruire
à chaque fois.

• Modularité: Chaque service est un module indépendant qui peut être développé, déployé,
maintenu et mis à jour indépendamment des autres services.

• Abstraction: Les détails de l’implémentation des services sont cachés derrière des interfaces
bien définies. Cela permet aux utilisateurs des services de se concentrer sur l’utilisation de
leurs fonctionnalités sans se préoccuper de leur fonctionnement interne.

3.1.2 Pratiques Courantes

L’un des composants les plus courants dans les architectures SOA est le Bus de Services d’En-
treprise (ESB). L’ESB facilite la communication entre les services en agissant comme un intermé-
diaire, gérant la transformation et le routage des messages entre les services [13]. Cela simplifie
l’intégration et assure une communication fluide malgré les différences dans les technologies ou les
protocoles utilisés par les services individuels.

3.2 Catégories de Services en SOA

SOA classifie les services en plusieurs catégories, chacune répondant à des besoins spécifiques:

• Services d’entreprise: Ce sont des services de haut niveau qui sont souvent réutilisables à
travers plusieurs applications et processus métier. Ils sont alignés avec les modèles d’infor-
mation de l’entreprise et fournissent des fonctionnalités essentielles.

• Services internes: Ces services sont généralement conçus pour des besoins spécifiques à
une unité d’affaires et ne sont pas destinés à la réutilisation à l’échelle de l’entreprise.

• Services de produits: Fournis par des fournisseurs externes ou par des produits spécifiques,
ces services sont intégrés dans les solutions SOA pour fournir des fonctionnalités spécialisées.

L’architecture SOA offre une grande flexibilité et peut contribuer à une plus grande agilité
dans les entreprises, mais elle peut aussi introduire des complexités, notamment dans la gestion et
l’orchestration des services. Son succès dépend de la capacité à bien concevoir et implémenter ses
composants, ainsi que de l’adoption de bonnes pratiques en matière de gouvernance et de gestion
des services.

20
Section 4

Architecture Microservices

4.1 Définition
L’architecture des microservices est une approche de conception d’applications comme un en-
semble de services petits, autonomes, et déployables indépendamment. Chaque microservice exécute
un processus d’affaires spécifique et communique via des interfaces légères, typiquement des API
HTTP. Cette architecture se distingue des architectures monolithiques et SOA par sa capacité à
fonctionner indépendamment en choisissant ses propres technologies et plateformes, ce qui permet
une évolutivité et une maintenance améliorées. Selon Newman (2015), les microservices peuvent
être envisagés comme des applications indépendantes qui coopèrent pour former une application
globale plus grande [14].

Figure 4.1: Exemple d’une architecture Microservices

21
4.2 Les Caractéristiques
Les caractéristiques principales des microservices comprennent:

• Autonomie : Chaque service fonctionne indépendamment des autres, ce qui facilite le

développement, les tests, le déploiement et la mise à l’échelle. Cette autonomie permet
également à des équipes distinctes de travailler sur différents services simultanément sans
interférence.

• Décentralisation : Les microservices favorisent la décentralisation de la gestion des données.

Chaque service gère sa propre base de données, ce qui élimine la dépendance à une base de
données monolithique centrale et améliore les performances et la sécurité [15].

• Tolérance aux pannes : Ils sont conçus pour être résilients ; l’échec d’un microservice
n’impacte pas directement les autres. Des stratégies comme les circuits breakers sont souvent
utilisées pour gérer les échecs et maintenir la disponibilité du système [16].

4.3 Avantages et Inconvénients

Avantages :

• Agilité et flexibilité : Les microservices permettent des itérations rapides et des mises à
jour fréquentes, soutenant l’agilité des entreprises dans des environnements compétitifs.

• Scalabilité : Ils peuvent être scalés indépendamment, ce qui est particulièrement bénéfique
dans des environnements cloud où les ressources peuvent être ajustées dynamiquement pour
répondre à la demande [17].

• Diversité technologique : Chaque microservice peut être développé en utilisant la tech-

nologie la mieux adaptée à ses besoins, favorisant l’innovation et l’efficacité.

Inconvénients :

• Complexité de gestion : La gestion de multiples services autonomes nécessite des outils

sophistiqués pour la surveillance, le déploiement et l’orchestration, augmentant la complexité
opérationnelle.

• Défis de monitoring : La surveillance de nombreux services distribués nécessite des solu-

tions avancées pour assurer une visibilité et un contrôle efficaces.

• Consistance des données : Assurer la consistance des données à travers des services
distribués pose des défis particuliers, souvent gérés par des techniques comme les transactions
compensatoires ou les événements asynchrones [18].

22
Section 5

Comparaison Entre Monolithique, SOA

et Microservices

Les architectures logicielles jouent un rôle crucial dans la manière dont les applications sont
conçues, développées et maintenues. Les modèles monolithiques, SOA (Service-Oriented Archi-
tecture) et microservices offrent des approches distinctes avec des avantages et des inconvénients
spécifiques. Cette section fournit une analyse critique de ces architectures, en se concentrant sur
plusieurs aspects clés qui influencent leur adoption et leur efficacité dans différents environnements
de développement. Les facteurs utilisés pour cette comparaison comprennent :

• Conception: Évalue comment chaque architecture organise et structure ses composants et

services. Cela inclut la manière dont les fonctionnalités sont encapsulées et interagissent au
sein de l’application.

• Scalabilité: Examine la capacité de chaque architecture à s’adapter à des charges de travail

croissantes, soit par l’ajout de ressources au même système (scalabilité verticale), soit par
l’ajout de plus de systèmes (scalabilité horizontale).

• Maintenance: Considère la facilité avec laquelle chaque architecture peut être mise à jour
et maintenue, en tenant compte de la complexité des mises à jour et de l’impact potentiel des
changements sur l’ensemble du système.

• Déploiement: Aborde la facilité de déploiement des modifications, la fréquence des mises à

jour et la manière dont les architectures supportent le déploiement continu et indépendant.

• Gestion des données: Discute de la manière dont chaque architecture gère les données,
notamment en termes de centralisation versus décentralisation et de gestion de la cohérence
des données.

• Sécurité: Analyse les défis et les approches de la sécurité dans chaque architecture, y compris
la gestion des risques de sécurité liés à la distribution et à l’intégration des services.

• Intégration technologique: Évalue la capacité de chaque architecture à intégrer de nou-

velles technologies et à supporter des environnements hétérogènes.

23
 Ces critères sont essentiels pour comprendre les implications pratiques de choisir une architecture
sur une autre en fonction des besoins spécifiques d’un projet ou d’une organisation. Le tableau
suivant résume et compare ces architectures selon ces dimensions clés.

Critère Monolithique SOA Microservices

Conception Unité indivisible Ensemble de Collection de ser-
avec toutes les services inter- vices indépendants
fonctionnalités dépendants et autonomes
intégrées
Scalabilité Scalabilité verticale Scalabilité horizon- Excellente scala-
principalement, né- tale possible mais bilité horizontale,
cessite la duplica- gestion complexe chaque service est
tion complète de due aux dépen- indépendant
l’application dances
Maintenance Peut être com- Amélioration grâce Plus facile et
plexe, car une à la modularité des rapide, chaque ser-
modification né- services mais coor- vice est mis à jour
cessite souvent le dination nécessaire indépendamment
redéploiement de
tout le système
Déploiement Risqué et poten- Moins risqué que le Simplifié et con-
tiellement instable, monolithique, peut tinu, avec des
affecte toute l’ap- nécessiter une ges- déploiements
plication tion complexe des indépendants min-
versions imisant les risques
d’interruption
Gestion des données Centralisée, ce Peut être décentral- Complètement dé-
qui peut créer des isée mais souvent centralisée, chaque
goulots d’étrangle- synchronisée via service gère ses pro-
ment des services d’en- pres données, ce qui
treprise améliore la perfor-
mance
Sécurité Un seul point de Nécessite une sécu- Défis en termes de
sécurité, plus facile rité coordonnée à sécurité distribuée,
à gérer mais risque travers les services, chaque service doit
plus élevé en cas de complexe à gérer implémenter ses
compromission propres mesures
Intégration technologique Limitée à une stack Permet une cer- Très flexible, per-
technologique, dif- taine hétérogénéité met l’utilisation
ficile d’intégrer de mais peut être de différentes tech-
nouvelles technolo- limitée par des nologies et stacks
gies sans une re- contraintes d’in- pour chaque service
fonte complète teropérabilité

Table 5.1: Comparaison des architectures Monolithique, SOA et Microservices

24
Section 6

Les Patterns des Microservices

L’architecture des microservices n’est pas simplement un style architectural, mais une suite de
patterns stratégiques et opérationnels qui aident à décomposer une application en services plus petits
et gérables. Ces patterns ont pour double objectif de déterminer la pertinence des microservices
pour une application spécifique et de faciliter une implémentation efficace de cette architecture,
comme le soutiennent [19, 20].

6.1 Les Patterns de Décomposition

Les patterns de décomposition dans l’architecture des microservices sont cruciaux pour struc-
turer les applications en services plus petits et gérables qui correspondent directement aux besoins
commerciaux de l’entreprise. Ces patterns facilitent la gestion, la maintenance, et l’évolution des
systèmes en alignant étroitement les services avec les fonctions commerciales.

6.1.1 Pattern de Décomposition par Capacité Commerciale

Ce pattern organise les microservices selon les capacités fonctionnelles de l’entreprise, souvent en
reflétant une structure organisationnelle hiérarchique. Par exemple, des niveaux distincts pourraient
être dédiés à la gestion des commandes de produits, à la facturation, et à la logistique. Cette
structuration aide à isoler les fonctions dans des services dédiés qui supportent efficacement les
opérations commerciales, permettant des mises à jour indépendantes et minimisant les interférences
entre services [21].

6.1.2 Pattern de Décomposition par Sous-Domaine

Basé sur le Domain-Driven Design (DDD), ce pattern divise le domaine d’affaires complexe en
sous-domaines plus petits et gérables, facilitant la gestion et le développement ciblé des fonction-
nalités [19]. Les sous-domaines sont généralement classifiés comme suit:

• Noyau: Le cœur des stratégies commerciales et le différentiateur clé de l’entreprise.

25
 • Soutien: Fonctions qui supportent le noyau mais peuvent être externalisées ou internalisées
selon les besoins.

• Générique: Fonctions standard gérées par des solutions logicielles standards.

Cette segmentation permet à chaque service de se concentrer sur des responsabilités claires et bien
définies, améliorant ainsi la cohérence et la qualité du service [22].

6.1.3 Nouveaux Patterns de Décomposition

• Pattern de Service Autonome: Chaque service opère de manière indépendante avec sa
propre base de données et logique métier, réduisant les dépendances et améliorant la résilience
et l’évolutivité [19].

• Pattern de Service par Équipe: Services développés par des équipes dédiées, respons-
ables de l’intégralité du cycle de vie du service. Cette approche renforce la propriété et la
responsabilité, accélérant le développement et améliorant la qualité [20].

6.2 Les Patterns De Messagerie Transactionnelle

Les patterns de messagerie transactionnelle jouent un rôle crucial dans les architectures mi-
croservices, en assurant la cohérence des données et en facilitant la gestion des transactions dans
des systèmes distribués. Ces patterns permettent des communications fiables entre services indépen-
dants [22]. Nous détaillons ici trois patterns principaux utilisés couramment.

6.2.1 Pattern Boîte D’envoi Transactionnelle

Ce pattern est utilisé principalement avec les bases de données relationnelles pour gérer les
transactions. Il consiste à insérer un message ou un événement dans une ‘boîte d’envoi” au sein de
la base de données lorsqu’une transaction locale est effectuée. Ce mécanisme garantit que chaque
transaction est accompagnée d’un message qui peut être utilisé pour déclencher d’autres processus
ou opérations [20]. Pour les bases de données NoSQL, ce pattern est adapté pour ajouter les
messages ou événements directement à l’attribut de l’enregistrement mis à jour [19].

6.2.2 Pattern Journal Des Transactions

Ce pattern implique l’enregistrement de chaque transaction dans un journal de la base de don-
nées. Par exemple, MySQL utilise le mécanisme de binlog et PostgreSQL utilise le Write-Ahead
Logging (WAL). Ces journaux sont ensuite traités et envoyés à une file d’attente pour être gérés de
manière asynchrone, facilitant ainsi la réplication des données ou la synchronisation entre différents
services [23].

26
6.2.3 Pattern Éditeur De Sondage
Dans ce pattern, les messages ne sont pas insérés directement dans la file d’attente au moment
de la transaction. Au lieu de cela, une tâche périodique sonde la base de données pour détecter les
nouvelles entrées ou les modifications non traitées. Ce pattern est utilisé lorsque les mécanismes de
push direct ne sont pas disponibles ou souhaitables, assurant que tous les événements sont capturés
et traités, même si cela peut introduire un délai.

6.3 Les Patterns de Gestion de Données

Les patterns de gestion de données dans les architectures microservices sont essentiels pour
optimiser la cohérence, l’efficacité et la scalabilité tout en minimisant les dépendances entre les
services [22]. Ces patterns facilitent également la maintenance et l’évolution des systèmes. Voici
une exploration détaillée de trois patterns primordiaux :

6.3.1 Pattern de Base de Données pour Chaque Service

Chaque microservice dans ce modèle opère avec sa propre base de données, permettant une
complète autonomie en termes de gestion des données. Ce cloisonnement favorise l’indépendance
des services, ce qui est crucial pour le déploiement et la mise à jour sans interruption des autres
composants du système [19].

• Avantages :

– Scalabilité accrue : Chaque service peut être scalé indépendamment en fonction de ses
besoins en ressources.
– Développement isolé : Les développeurs peuvent mettre à jour ou modifier la base de
données d’un service sans impacter les autres, ce qui accélère les cycles de développement
[20].
– Maintenance simplifiée : Les problèmes de données sont isolés au service concerné,
facilitant les diagnostics et les corrections.

6.3.2 Pattern de Base de Données Partagée

Ce pattern implique que plusieurs microservices partagent la même base de données. Bien
que cela puisse simplifier la migration des architectures monolithiques et réutiliser les schémas de
données existants, il introduit un niveau de couplage qui peut compromettre l’indépendance des
services [22].

• Avantages :

– Migration facilitée : Les entreprises peuvent migrer vers des microservices sans redéfinir
entièrement leur modèle de données [19].

27
 – Réutilisation des schémas : Économise le temps et les ressources en évitant de redévelop-
per les schémas de base de données [20].

6.3.3 Pattern SAGA

Le pattern SAGA est une approche pour gérer les transactions qui s’étendent sur plusieurs
microservices, en les décomposant en transactions locales plus petites. Chaque action locale publie
des événements qui déclenchent la prochaine action dans la séquence de transactions. En cas d’échec,
des actions compensatoires sont déclenchées pour revenir à un état cohérent [20].

• Utilisation :

– Gestion des échecs : Permet de rétablir la cohérence après un échec transactionnel en

exécutant des transactions compensatoires [22].

– Maintien de la cohérence : Assure que l’ensemble du système reste cohérent même en

cas de défaillances partielles.

6.3.4 Pattern CQRS (Command Query Responsibility Segrega-

tion)
Le pattern CQRS (Command Query Responsibility Segregation) est une approche architec-
turalement distincte pour la gestion des commandes et des requêtes dans une application. Dans
ce modèle, les opérations de lecture (requêtes) et d’écriture (commandes) sont séparées en deux
interfaces distinctes, permettant une meilleure optimisation et gestion des performances [23].

• Optimisation des performances : Séparer les lectures et les écritures permet d’optimiser
chaque côté individuellement, rendant possible l’utilisation de bases de données optimisées
pour les lectures (comme Elasticsearch) et d’autres pour les écritures (comme PostgreSQL)
[22].

• Flexibilité accrue : Les microservices peuvent évoluer plus facilement en adaptant spéci-
fiquement leurs modèles de données pour répondre aux besoins des requêtes ou des comman-
des, sans compromettre l’efficacité.

• Scalabilité : Les lectures étant souvent plus fréquentes que les écritures, CQRS permet de
scaler les opérations de lecture de manière indépendante pour s’adapter aux fortes demandes
de lecture [20].

Exemple d’utilisation : Dans un système de gestion de commandes, les informations d’in-

ventaire sont souvent consultées (lecture), tandis que les mises à jour d’inventaire (écriture) sont
effectuées moins fréquemment. En utilisant CQRS, ces deux aspects peuvent être optimisés séparé-
ment, rendant le système plus performant [20].

28
6.3.5 Pattern API Composition
Dans une architecture microservices, il est souvent nécessaire d’agréger les données provenant de
plusieurs services pour répondre à une requête utilisateur. Le pattern API Composition est utilisé
pour résoudre ce problème en regroupant les réponses de plusieurs microservices via un compositeur
d’API qui combine les résultats et les retourne sous forme d’une réponse unique [19].

• Réduction du couplage : L’API Composition permet aux microservices de rester indépen-

dants tout en offrant une vue consolidée des données sans nécessiter de dépendances fortes
entre eux [22].

• Flexibilité : Il devient plus simple d’ajouter ou de modifier des microservices sans affecter
les clients de l’API puisque les changements peuvent être absorbés par le compositeur.

• Simplification côté client : Au lieu que le client fasse plusieurs appels aux différents
microservices, un seul appel au compositeur d’API suffit pour obtenir toutes les informations
nécessaires, améliorant ainsi la performance perçue par l’utilisateur.

Exemple d’utilisation : Supposons qu’une interface utilisateur doit afficher les informations
détaillées d’un produit, ainsi que les avis des clients. Ces informations pourraient être réparties
entre deux microservices différents. Le compositeur d’API agrège les réponses de ces services et
renvoie une seule réponse intégrée [23].
Note complémentaire : L’utilisation combinée de CQRS et d’API Composition dans une
architecture microservices peut grandement améliorer l’efficacité du système. CQRS optimise les
performances de lecture et d’écriture, tandis que l’API Composition permet d’agréger les réponses
des microservices, rendant l’architecture plus réactive et facile à maintenir [22].

6.4 Les Patterns de Découverte de Service

Les Patterns de Découverte de Service dans les architectures microservices sont cruciaux pour
la gestion dynamique de la localisation et la communication entre services distribués. Ils garantis-
sent que les instances de service peuvent être découvertes et communiquer efficacement malgré les
déploiements fréquents dans des environnements évolutifs comme le cloud [20]. Voici les principaux
patterns utilisés pour la découverte de service :

6.4.1 Pattern de Découverte Côté Client

Ce pattern confère au client la responsabilité de découvrir les services. Le client, connaissant
l’adresse de chaque instance de service ou utilisant un algorithme d’équilibrage de charge, sélectionne
directement l’instance à utiliser [19].
Avantages:

• Autonomie du client, réduisant la latence et simplifiant la configuration.

29
 • Flexibilité accrue avec moins de dépendance à un service centralisé.

Inconvénients:

• Augmentation du couplage entre le client et les services.

• Complexité accrue dans la gestion de la logique de découverte et d’équilibrage.

6.4.2 Pattern de Découverte Côté Serveur

Un registre de services central joue le rôle de médiateur pour résoudre les adresses des services,
à la manière d’un serveur DNS pour les adresses IP [20].
Avantages:

• Simplification de la configuration des clients.

• Gestion centralisée de la santé des services, éliminant les instances défaillantes du pool.

Inconvénients:

• Risque de point unique de défaillance avec le registre.

• Nécessité d’une gestion opérationnelle constante du registre.

6.4.3 Pattern Registre de Services

Ce pattern implique un registre actif où chaque service s’enregistre à son démarrage et se retire
à son arrêt, permettant une interrogation efficace par les clients ou un intermédiaire [19].
Avantages:

• Liste toujours actualisée des services disponibles.

• Efficacité améliorée lors de l’interrogation pour les adresses des services.

Inconvénients:

• Gestion complexe de l’état du registre pour éviter des données obsolètes.

Applications typiques: Des systèmes tels qu’Eureka Server et Apache ZooKeeper sont sou-
vent utilisés pour implémenter ces patterns, offrant des fonctionnalités avancées pour la gestion des
dynamiques de service dans des environnements distribués [22].

6.5 Les Patterns d’API Externes

6.5.1 API-Gateway
L’API-Gateway est un élément central dans les architectures modernes de microservices, agissant
comme intermédiaire entre les clients externes et les services internes. Inspiré des principes de

30
l’architecture orientée services (SOA), il remplace les architectures traditionnelles basées sur un bus
de services d’entreprise (ESB). L’API-Gateway simplifie les interactions client-service, en gérant
l’acheminement des requêtes, la transformation des protocoles, et la mise en œuvre de logiques
communes telles que l’authentification.
Fonctionnalités clés de l’API-Gateway :

• Routage des demandes: Oriente les requêtes clients vers les microservices appropriés.

• Agrégation des réponses: Combine les réponses de divers microservices pour fournir une
réponse unifiée.

• Transformation des protocoles: Adapte les formats de données pour assurer la compati-
bilité inter-systèmes.

• Sécurité: Centralise la gestion des identités et des accès pour sécuriser les services.

• Équilibrage de charge: Répartit la charge de travail de manière équilibrée entre les services
disponibles.

Avantages :

• Flexibilité d’intégration, scalabilité accrue et personnalisation des API.

Inconvénients :

• Risque de goulot d’étranglement et complexité accrue de la gestion.

6.5.2 API-Gateway / Backends Pour Frontends (BFF)

Cette variante de l’API-Gateway propose des gateways dédiés à chaque type de client, optimisant
les interactions spécifiques à chaque plateforme (web, mobile, etc.). Chaque BFF est conçu pour
améliorer l’expérience utilisateur par une personnalisation profonde des interactions client-service.
Avantages :

• Meilleure expérience utilisateur par des optimisations spécifiques et une réduction de la charge
sur les clients.

Inconvénients :

• Duplication des fonctionnalités et complexité opérationnelle accrue.

Remarque : Vous pourriez envisager d’inclure une illustration ici pour montrer comment ces
patterns fonctionnent au sein d’une architecture de microservices.

31
6.6 Les Patterns de Sécurité
Les patterns de sécurité dans les architectures microservices sont cruciaux pour assurer la pro-
tection des données, l’authentification des utilisateurs, et la gestion des autorisations dans un envi-
ronnement distribué. Ces patterns facilitent la mise en place de mesures de sécurité robustes tout
en maintenant la flexibilité et l’évolutivité des services [19, 20].

6.6.1 Pattern d’Authentification par Jeton

Ce pattern utilise des jetons, souvent des JWT (JSON Web Tokens), pour authentifier les
utilisateurs et transmettre des informations sécurisées entre les services [22].
Avantages:

• Sécurité renforcée: Les jetons peuvent être chiffrés pour assurer la confidentialité des données.

• Sans état: Idéal pour les architectures distribuées car ils ne nécessitent pas de stockage de
session côté serveur.

• Interopérabilité: Facilité d’utilisation à travers différents langages et plateformes.

Inconvénients:

• Gestion des jetons: Nécessite un système robuste pour émettre, renouveler et révoquer les
jetons efficacement.

• Complexité: La mise en œuvre de la logique de validation des jetons peut être complexe [19].

6.6.2 Pattern de Porte de Sécurité (Security Gateway)

Similaire à l’API Gateway, le Security Gateway gère toutes les requêtes entrantes pour l’authen-
tification et l’autorisation avant qu’elles atteignent les microservices.
Avantages:

• Point de contrôle centralisé: Simplifie la gestion de la sécurité en concentrant les politiques

de sécurité à un seul point.

• Réduction des vulnérabilités: Minimise le risque d’attaques directes sur les microservices.

Inconvénients:

• Point de défaillance unique: Si le gateway tombe en panne, l’accès à tout le système peut
être compromis.

• Latence accrue: Peut introduire un délai supplémentaire dans le traitement des demandes
[20].

32
6.6.3 Pattern de Chiffrement des Données
Ce pattern implique le chiffrement des données sensibles à la source avant leur stockage ou leur
transmission [22].
Avantages:

• Protection des données: Assure que les données compromises restent indéchiffrables sans la
clé appropriée.

• Conformité réglementaire: Aide à répondre aux exigences de protection des données person-
nelles.

Inconvénients:

• Performance: Le processus de chiffrement et de déchiffrement peut introduire une latence

significative.

• Gestion des clés: Nécessite une gestion sécurisée des clés de chiffrement, ajoutant à la com-
plexité et au coût.

6.6.4 Pattern d’Audit et de Suivi

Ce pattern garantit que toutes les actions critiques ou accès aux données sensibles sont enreg-
istrés [19].
Avantages:

• Traçabilité: Permet de retracer les actions en cas de problème de sécurité ou pour des audits
réglementaires.

• Détecter les anomalies: Les logs peuvent être analysés pour détecter des comportements
inhabituels ou malveillants.

Inconvénients:

• Volume de données: Peut générer un volume énorme de données à stocker et analyser.

• Performance: Peut impacter les performances du système si non optimisé correctement.

6.7 Les Patterns de Déploiement

Les patterns de déploiement pour les architectures de microservices sont cruciaux pour assurer
une distribution efficace et fiable des services dans un environnement de production. Ces patterns
aident à optimiser l’utilisation des ressources, à améliorer la fiabilité du système, et à faciliter le
scaling horizontal.

33
6.7.1 Pattern Multi-Service par Hôte
Ce pattern implique l’exécution de plusieurs services sur un seul hôte, comme une machine
virtuelle dédiée. Cette approche est particulièrement utile dans des environnements où les ressources
de calcul sont abondantes et peu coûteuses.
Avantages :

• Utilisation optimisée des ressources : Les ressources de l’hôte sont pleinement utilisées, ce qui
peut réduire les coûts d’infrastructure.

• Déploiement simplifié : Moins de machines à gérer peut simplifier le processus de déploiement

et de maintenance.

• Scalabilité horizontale : Permet de scaler plus facilement en ajoutant plus de services sur le
même hôte ou en augmentant le nombre d’hôtes.

Inconvénients :

• Couplage potentiel : La défaillance d’un hôte peut affecter plusieurs services, augmentant le
risque de points de défaillance uniques.

• Conflits de ressources : Les services partageant un même hôte peuvent entrer en compétition
pour les ressources, ce qui peut entraîner des problèmes de performance.

6.7.2 Pattern Un Seul Service par Hôte

Dans ce modèle, chaque service est isolé dans son propre hôte, souvent une machine virtuelle
ou un conteneur. Cette approche maximise l’isolation entre les services.
Avantages :

• Isolation complète : Chaque service fonctionne dans un environnement cloisonné, ce qui

minimise les interférences et maximise la sécurité.

• Réduction des conflits de ressources : Aucun service ne partage ses ressources, ce qui élimine
les conflits potentiels et garantit une performance plus prévisible.

• Facilité de monitoring et de maintenance : L’isolation facilite le suivi et la maintenance de

chaque service individuellement.

Inconvénients :

• Utilisation inefficace des ressources : Peut entraîner une sous-utilisation des ressources,
surtout si les services ne nécessitent pas les capacités complètes de l’hôte.

• Coûts plus élevés : Nécessite potentiellement plus d’hôtes, ce qui peut augmenter les coûts
d’infrastructure.

On peut résumer tous les patterns selon le schéma suivant ( 6.1):

34
Figure 6.1: Résumé de tous les patterns de microservices

35
 Part III

State of Art

36
Section 7

Introduction

La transition d’une application monolithique volumineuse vers une architecture microservices

est souvent perçue comme une démarche moins intimidante que la construction d’une application
ex nihilo. La connaissance préexistante des règles de gestion, des interactions entre services et de
la complexité globale de l’application existante facilite la migration. Cette familiarité permet une
transition plus maîtrisée et ciblée vers les microservices, dont l’objectif principal est de simplifier et
modulariser la complexité existante. Le processus de migration se décompose typiquement en deux
étapes principales : l’identification des composants appropriés pour la migration et leur intégration
dans des environnements isolés, souvent facilitée par des conteneurs comme Docker.
Cette recherche se concentre particulièrement sur l’identification des microservices, un aspect
crucial et complexe du processus de migration. Une identification inadéquate peut limiter signi-
ficativement les avantages attendus des architectures de microservices, tels que la modularité et
l’autonomie opérationnelle.
Différentes stratégies de migration ont été proposées et peuvent être classées en deux catégories
principales :

1. Approches Techniques : Ces méthodes visent à décomposer l’application en services dis-

tincts selon des critères techniques prédéfinis. Elles définissent les processus nécessaires pour
obtenir les résultats souhaités en optimisant l’utilisation et la fonctionnalité des microservices.

2. Approches de Feedback : Basées sur des retours d’expérience et des enseignements tirés
de migrations antérieures, ces approches utilisent les connaissances pratiques pour ajuster
les stratégies de migration selon les défis réellement rencontrés lors de la transformation de
systèmes monolithiques en architectures de microservices.

L’objectif de ce travail est de réaliser une analyse comparative des différentes méthodes tech-
niques tout en intégrant des perspectives issues des retours d’expérience. Cette analyse vise à fournir
une vision complète et nuancée qui aidera les organisations à choisir l’approche de migration la plus
adaptée à leurs besoins spécifiques.

37
Section 8

Approches Techniques

8.1 Approche pilotée par le domaine (Domain-Driven

Design - DDD) : Une approche stratégique pour la
migration
Le Domain-Driven Design (DDD) est une approche de conception logicielle qui met l’accent sur
la compréhension approfondie du domaine métier pour lequel le logiciel est conçu. Dans le contexte
de la migration vers les microservices, le DDD offre un cadre stratégique puissant pour décomposer
un monolithe en services cohérents et faiblement couplés. Cette approche est mise en avant par [14]
dans son ouvrage Monolith to Microservices, où il explore les patterns évolutifs pour décomposer
un monolithe en microservices, en utilisant le DDD comme base.

8.1.1 DDD et la décomposition du monolithe

Le DDD propose une méthodologie pour identifier les contextes bornés (Bounded Contexts) au
sein du monolithe. Un contexte borné est une partie du système qui possède son propre modèle
de domaine, son propre langage et ses propres règles métier. Chaque contexte borné peut être
considéré comme un candidat potentiel pour devenir un microservice.
Au sein de chaque contexte borné, le DDD identifie les agrégats (Aggregates), qui sont des
groupes d’objets du domaine étroitement liés et cohérents. Les agrégats encapsulent l’état et le
comportement de ces objets, et ils sont responsables de maintenir l’intégrité des données. Lors
de la migration, les agrégats peuvent être extraits du monolithe et transformés en microservices
indépendants.

8.1.2 Exemple : le système de gestion des commandes

Prenons l’exemple d’un système de gestion des commandes dans un site e-commerce. Le DDD
permettrait d’identifier plusieurs contextes bornés, tels que :

38
 Figure 8.1: Les contextes délimités et les relations entre eux

• Catalogue de produits : Ce contexte est responsable de la gestion des informations sur

les produits, telles que le nom, la description, le prix, etc. Il pourrait être décomposé en un
microservice dédié.

• Gestion des commandes : Ce contexte gère le cycle de vie des commandes, de la création
à la livraison. Il pourrait également être un microservice distinct.

• Gestion des paiements : Ce contexte est responsable du traitement des paiements, de la

vérification des informations de paiement à la confirmation du paiement. Il pourrait être un
autre microservice.

8.1.3 Identification des agrégats

Au sein de chaque contexte borné, il est important d’identifier les agrégats. Par exemple, dans le
contexte de gestion des commandes, une commande (Order) pourrait être un agrégat. Cet agrégat
encapsulerait les informations sur la commande, telles que les articles commandés, l’adresse de
livraison, etc., ainsi que les comportements associés, tels que l’ajout d’un article à la commande, la
modification de l’adresse de livraison, etc.

8.1.4 Migration progressive

La migration d’un monolithe vers une architecture de microservices basée sur le DDD peut être
réalisée de manière progressive. On peut commencer par extraire un contexte borné à la fois, en le
transformant en un microservice indépendant. Cette approche permet de minimiser les risques et
de valider chaque étape de la migration avant de passer à la suivante.

39
8.1.5 Avantages de l’approche DDD
L’approche DDD offre plusieurs avantages pour la migration vers les microservices :

• Alignement sur le métier : Le DDD garantit que l’architecture des microservices reflète
fidèlement le domaine métier, ce qui facilite la communication, la compréhension et l’évolution
du système.

• Décomposition guidée par le domaine : Le DDD fournit des outils et des concepts (tels
que le contexte borné et les agrégats) pour décomposer le monolithe de manière logique et
cohérente.

• Microservices cohérents : Les microservices résultant de la décomposition DDD sont plus

cohérents, car ils encapsulent des concepts métier bien définis et ont des responsabilités claires.

• Évolutivité et maintenabilité : L’approche DDD favorise la création de microservices

faiblement couplés, ce qui facilite l’évolution et la maintenance indépendantes de chaque
service.

8.1.6 Défis de l’approche DDD

• Courbe d’apprentissage : Le DDD introduit de nouveaux concepts et une nouvelle façon
de penser la conception logicielle, ce qui peut nécessiter un certain temps d’apprentissage
pour les équipes de développement.

• Collaboration étroite : Le DDD nécessite une collaboration étroite entre les experts du
domaine et les développeurs pour construire un modèle de domaine précis et partagé.

Malgré ces défis, le Domain-Driven Design offre une approche stratégique précieuse pour la
migration vers les microservices. En se concentrant sur la compréhension du domaine métier et en
utilisant les concepts clés du DDD, les équipes de développement peuvent créer des architectures
de microservices plus robustes, évolutives et maintenables.

8.2 Approche centrée sur les données pour l’identifica-

tion des microservices : Une perspective nouvelle
Alors que les approches traditionnelles de migration d’applications monolithiques vers des ar-
chitectures microservices se concentrent principalement sur la décomposition de la logique métier,
une approche alternative de [24] consiste à adopter une perspective centrée sur les données. Cette
approche part du principe que la conception des modèles de données est souvent l’une des premières
étapes du développement d’une application. En considérant ces modèles de données comme point
de départ, il devient plus aisé de piloter le reste du processus de découplage du système.

40
8.2.1 Principe
L’approche centrée sur les données pour l’identification des microservices se concentre sur la
division du modèle de données (par exemple, un schéma de base de données) en sous-modèles
cohérents et sémantiquement liés. Chaque sous-modèle, composé d’un ensemble de tables ou de
documents, est ensuite associé à la logique métier correspondante pour former un microservice.
Cette méthode permet une meilleure modularisation du système, chaque microservice ayant ses
propres données et pouvant être hébergé, implémenté ou migré indépendamment.

8.2.2 Avantages
L’un des principaux avantages de cette approche est qu’elle permet d’obtenir un ensemble de
microservices autonomes en termes de données. Cela signifie que chaque microservice peut utiliser
le service de stockage le plus approprié, qu’il soit relationnel (SQL) ou non relationnel (NoSQL),
et peut être alimenté par différentes sources de données. Cette flexibilité facilite l’évolution et la
maintenance de chaque microservice de manière indépendante.

8.2.3 Processus d’identification

[24] proposent un processus d’identification de microservices centré sur les données qui comprend
les étapes suivantes :

Figure 8.2: Processus proposé pour l’identification des microservices

41
8.2.3.1 Analyse du modèle de données

Le schéma de la base de données monolithique est analysé pour identifier les tables et leurs
relations, comme le montre la figure 8.3.

Figure 8.3: Diagramme de relation d’entité de l’application de pièces automobiles

8.2.3.2 Construction et prétraitement des documents

Chaque table est considérée comme un document et l’ensemble des tables comme une collection
de documents. Les symboles (noms de tables, attributs, relations) sont extraits, nettoyés et nor-
malisés. Les noms de tables sont dupliqués pour leur donner plus de poids dans l’analyse, et les
relations entre tables sont modélisées en fonction de leur type (singleton ou non singleton).

8.2.3.3 Enrichissement sémantique des documents

Comme nous utilisons l’apprentissage automatique non supervisé, qui nécessite une grande
quantité de données pour produire de bons résultats, nous devons étendre nos documents par une
technique connue sous le nom d’« augmentation de données ». Cela consiste à les enrichir avec
des symboles sémantiquement liés. Ces symboles sont liés à nos symboles par les deux relations
suivantes : «part of» et «type of», qui sont les relations de symboles les plus pertinentes pour
notre problématique de modélisation des données. Cette étape d’enrichissement utilise une base de
données lexicale, comme WordNet.

42
8.2.3.4 Classification (clustering)

Les symboles enrichis sont regroupés en clusters en fonction de leur similarité sémantique.
Chaque cluster représente un sujet potentiel pour un microservice.

8.2.3.4.1 La vectorisation TF-IDF: La vectorisation TF-IDF est utilisée pour transformer

les documents en vecteurs. Le TF-IDF est mesuré à l’aide de deux scores :

Nombre de fois que le terme/symbole t apparaît dans un document

TF(t) =
Nombre total de termes dans le document

Nombre total de documents

 
IDF(t) = loge
Nombre de documents contenant le terme t
Ensuite, le TF-IDF est calculé comme suit :

TF-IDF(t) = TF(t) × IDF(t)

Enfin, nous obtenons un ensemble de vecteurs qui représentent les poids des termes dans chaque
document.

8.2.3.4.2 Détermination du nombre optimal de clusters: À ce stade, la méthode

Elbow est employée pour déterminer le nombre optimal de clusters. Ensuite, l’algorithme K-means
est appliqué pour regrouper les documents en clusters.

8.2.3.5 Attribution des tables et inférence des noms de microservices

Dans cette dernière étape, les tables de la base de données sont assignées aux clusters corre-
spondants, et le nom de chaque microservice est déduit du sujet dominant de son cluster.

Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5

First three country, user, role, order, detail, cart, category,
topics customer, customer commercial shopping, make,
region item product
Tables customer user order cart item product
country role order detail shopping category
customer cart make
role model
user role
Microser- Customer User Order Cart Product
vice Name Management Management Management Management Management
Service Service Service Service Service

Table 8.1: Résultats du Clustering

43
Figure 8.4: Résultat de la méthode Elbow

44
8.3 Approches Automatisées par l’Intelligence Artifi-
cielle
L’utilisation de l’intelligence artificielle (IA) et de l’apprentissage automatique (ML) pour au-
tomatiser la migration d’applications monolithiques vers des architectures de microservices est une
voie de recherche prometteuse. [25] proposent une approche novatrice basée sur le clustering thé-
matique pour identifier les microservices potentiels au sein d’une application monolithique.

8.3.1 Principe
L’approche proposée considère le problème de la migration comme un problème de regroupement
(clustering) de classes. L’objectif est de regrouper les classes du monolithe en clusters cohérents,
chaque cluster représentant potentiellement un microservice. Pour ce faire, les auteurs utilisent
des techniques d’apprentissage automatique, notamment le traitement du langage naturel (NLP) et
l’analyse statique du code source.

8.3.2 Approches proposées

L’article [25] présente trois approches différentes pour identifier les microservices potentiels :

8.3.2.1 Approche naïve

L’approche naïve est la plus simple des trois. Elle se concentre uniquement sur les dépendances
structurelles entre les classes, c’est-à-dire les appels de méthodes d’une classe à l’autre. L’idée
sous-jacente est que les classes qui interagissent fortement devraient être regroupées dans le même
microservice afin de minimiser les interactions entre différents microservices.
Les étapes clés de cette approche :

• Représentation des classes : Chaque classe est représentée par un tuple de deux valeurs :

– Xcall-in : le nombre d’appels entrants à la classe (c’est-à-dire le nombre de fois où les

méthodes de cette classe sont appelées par d’autres classes).
– Xcall-out : le nombre d’appels sortants de la classe (c’est-à-dire le nombre de fois où les
méthodes de cette classe appellent des méthodes d’autres classes).

• Algorithme de clustering : Un algorithme comme DBSCAN ou BMSC est utilisé pour

regrouper les classes en microservices potentiels. DBSCAN est efficace pour identifier des
clusters de formes arbitraires et est robuste aux outliers.

8.3.2.2 Approche basée sur les appels co-dépendants

Cette approche affine l’approche naïve en prenant en compte non seulement les dépendances
directes entre classes, mais aussi les dépendances indirectes, appelées co-dépendances. Deux classes

45
sont considérées comme co-dépendantes si elles sont appelées par un ensemble commun d’autres
classes. L’idée est que si deux classes sont souvent utilisées ensemble par d’autres parties de l’ap-
plication, elles devraient probablement être regroupées dans le même microservice.

Figure 8.5: Exemple illustratif de la métrique considérée

Les étapes clés sont :

• Définition de la co-dépendance : Deux classes sont co-dépendantes si elles sont appelées

par un ensemble commun d’autres classes.

• Calcul des tuples : Chaque classe est représentée par un tuple de deux valeurs :

– Xcall-i : le nombre d’appels entrants provenant de classes co-dépendantes.

– Xcall-inA ∩Xcall-inB : l’intersection des ensembles d’appels entrants de la classe en question

(A) et de la classe avec laquelle elle a le plus de co-dépendances (B).

• Clustering : L’algorithme de clustering est ensuite appliqué pour former des clusters en
prenant en compte ces dépendances complexes.

8.3.2.3 Approche basée sur la théorie des graphes

Cette approche modélise l’application monolithique comme un graphe, où chaque nœud représente
une classe et chaque arête une relation (appel de méthode) entre deux classes. La similarité entre
deux classes est déterminée à la fois par la structure du graphe (combien de fois les classes s’appel-
lent mutuellement) et par la sémantique du code (le vocabulaire utilisé dans les noms de classes, de
méthodes et de variables).
Les étapes comprennent :

46
 • Similarité structurelle : Basée sur les appels de méthodes.

call(ci , cj ) call(ci , cj )
 " ! #
1

simstr (ci , cj ) = +
2 callin (cj ) callin (ci )

où :

– call(ci , cj ) est le nombre de fois qu’une méthode de la classe ci appelle une méthode de
la classe cj .

– callin (ci ) est le nombre total d’appels entrants à la classe ci .

• Similarité sémantique : Basée sur le vocabulaire utilisé dans les noms de classes, méth-
odes, et variables. Cette similarité est calculée en utilisant la similarité cosinus entre les
vecteurs TF-IDF des classes. Le TF-IDF (Term Frequency-Inverse Document Frequency) est
une mesure numérique qui évalue l’importance d’un terme dans un document au sein d’une
collection de documents.
−
→
ci · −→
cj
!
simsem (ci , cj ) =
||−
→
c || · ||−
i
→
c || j

• Similarité de classe (CS) : La similarité globale entre deux classes est une combinaison
pondérée de la similarité structurelle et de la similarité sémantique :

CS(ci , cj ) = α · simstr (ci , cj ) + β · simsem (ci , cj )

où α et β sont des poids qui déterminent l’importance relative de chaque type de similarité.

Une fois le graphe construit et les similarités calculées, des algorithmes de détection de commu-
nautés, tels que Girvan-Newman ou Louvain, sont appliqués pour identifier les groupes de classes
fortement connectées, qui sont considérés comme des candidats pour les microservices.

47
8.4 Approche basée sur les processus métier et les ob-
jets de données
Cette approche, proposée par Amiri [26], vise à identifier les microservices en analysant les
processus métier d’un système et les dépendances entre les activités de ces processus, tant au
niveau structurel qu’au niveau des données manipulées. L’idée est de regrouper les activités qui
sont fortement liées, que ce soit par leur séquence d’exécution ou par les objets de données qu’elles
partagent, au sein d’un même microservice.

8.4.1 Principe
Voici les éléments clés de ce modèle :

• N : l’ensemble des nœuds (ou activités) dans le processus.

• s : l’activité de début du processus.

• f : l’activité de fin du processus.

• F : l’ensemble des arcs ou relations entre les activités, indiquant la séquence d’exécution.

• O : l’ensemble des objets de données utilisés dans le processus.

• ρ(a) : la fonction qui associe chaque activité a aux objets qu’elle lit.

• ω(a) : la fonction qui associe chaque activité a aux objets qu’elle écrit.

Deux types de relations sont considérées :

1. Relation TP (dépendance structurelle) : Cette relation indique si deux activités sont

interconnectées (valeur 1) ou non (valeur 0) en fonction de la présence d’un chemin direct ou
indirect entre elles dans le modèle de processus. Formellement, étant donné un schéma de
processus P = (N, s, f, F, O, ρ, ω), pour chaque paire d’activités ai , aj ∈ N , si (ai , aj ) ∈ F ou
s’il existe un chemin (ai , n1 , ..., np , aj ) dans P tel que ∀k ∈ [1...p] : nk est une passerelle, alors
T P (ai , aj ) = 1, sinon T P (ai , aj ) = 0.

2. Relation TD (dépendance de données) : Cette relation mesure le niveau de dépendance

entre les activités en fonction des objets de données qu’elles utilisent. Un poids est attribué à
chaque objet : 1 pour les objets écrits par les deux activités, 0,5 pour les objets écrits par une
activité et lus par l’autre, et 0,25 pour les objets lus par les deux activités. Formellement,
étant donné un schéma P = (N, s, f, F, O, ρ, ω), pour chaque paire d’activités ai , aj ∈ N ,

T D(ai , aj ) = |ω(ai ) ∩ ω(aj )| + 0.5 × |(ρ(ai ) ∩ ω(aj )) ∪ (ω(ai ) ∩ ρ(aj ))| + 0.25 × |ρ(ai ) ∩ ρ(aj )|.

48
 Ces deux relations sont ensuite agrégées pour définir la relation finale T , qui combine les dépen-
dances structurelles et de données. Formellement, étant donné un schéma P = (N, s, f, F, O, ρ, ω),
pour chaque paire d’activités ai , aj ∈ N , T (i, j) = T P (i, j) + T D(i, j).

8.4.2 Algorithme d’identification

Un microservice est composé d’un ensemble d’opérations, où chaque opération correspond à un
nœud d’activité dans le schéma de processus. Pour identifier les microservices, la relation finale
T est regroupée à l’aide d’un algorithme génétique et d’une fonction de fitness appelée Turbo-
MQ. L’algorithme commence par partitionner aléatoirement les activités en K groupes et utilise
Turbo-MQ pour mesurer la qualité des clusters identifiés. À chaque itération, l’algorithme cherche
à améliorer la fitness en modifiant les partitions précédentes. Ce processus se poursuit jusqu’à ce
que la fitness converge. Pour calculer Turbo-MQ, le facteur de cluster pour chaque cluster k (CFk )
est résumé comme suit :

K  0
 si µ = 0
Turbo-MQ =
X
CFk , CFk =
 PK 2µi
sinon
k=1  2µi + (δi,j +δj,i )
i=1,i6=j

Dans cette relation, CFi représente le facteur du cluster i, µi indique le nombre d’intra-relations
entre les activités au sein du cluster i, et δi,j représente le nombre d’inter-relations entre les activités
du cluster i et du cluster j.

49
8.5 Etude Comparative Entre Les Approches

8.5.1 Introduction à l’Étude Comparative

L’évolution des architectures logicielles vers des microservices représente un enjeu majeur pour
les entreprises souhaitant améliorer la scalabilité, la flexibilité et la résilience de leurs systèmes
informatiques. Cependant, la migration depuis une architecture monolithique existante vers une
architecture microservices n’est pas sans défis. Plusieurs approches techniques peuvent être adop-
tées pour guider cette transformation, chacune présentant ses propres avantages, inconvénients, et
domaines d’application.
Cette étude se propose d’analyser en profondeur quatre approches distinctes de migration vers
les microservices : l’Approche Pilotée par le Domaine (Domain-Driven Design - DDD), l’Approche
Centrée sur les Données, les Approches Automatisées par l’Intelligence Artificielle, et l’Approche
Basée sur les Processus Métier et les Objets de Données. En comparant ces approches selon plusieurs
critères clés, tels que l’adaptabilité, la complexité, la performance, la maintenance, et l’automatisa-
tion, cette étude vise à identifier l’approche la plus adaptée aux besoins spécifiques de la migration
étudiée.
L’objectif final est de fournir une recommandation éclairée, soutenue par une analyse rigoureuse,
pour guider le choix de l’approche de migration la plus pertinente dans un contexte donné.

8.5.2 Critères de Comparaison

• Adaptabilité : Capacité de l’approche à être appliquée à différents types de systèmes hérités.

• Complexité : Niveau de difficulté associé à la mise en œuvre de l’approche.

• Performance : Impact de l’approche sur les performances du système après migration.

• Maintenance : Facilité de maintenance des microservices une fois la migration effectuée.

• Automatisation : Mesure dans laquelle l’approche peut être automatisée, réduisant ainsi
l’intervention manuelle.

8.5.3 Analyse Approfondie des Approches

8.5.3.1 Approche Pilotée par le Domaine (Domain-Driven Design - DDD)

8.5.3.1.1 Adaptabilité : L’approche DDD est particulièrement adaptée aux systèmes com-
plexes où le domaine métier est central. Elle permet une segmentation du système en sous-domaines,
chacun étant géré par un microservice distinct. Cette granularité permet une adaptation facile aux
évolutions des exigences métier sans affecter l’ensemble du système. Toutefois, elle est moins adaptée
aux systèmes où les frontières des domaines sont floues ou mal définies.

50
8.5.3.1.2 Complexité : L’adoption de DDD nécessite une profonde compréhension du do-
maine métier ainsi qu’une collaboration étroite entre les développeurs et les experts du domaine. La
complexité réside dans la définition des « bounded contexts » et des entités métier, qui doivent être
soigneusement délimités pour éviter les chevauchements et les dépendances non souhaitées entre les
microservices.

8.5.3.1.3 Performance : DDD permet d’améliorer les performances du système en réduisant

les dépendances entre les modules, ce qui facilite le déploiement indépendant et l’évolution des
microservices. Les microservices peuvent être optimisés pour leur domaine spécifique, ce qui peut
améliorer l’efficacité globale du système.

8.5.3.1.4 Maintenance : La modularité offerte par DDD simplifie grandement la mainte-

nance, car chaque microservice est autonome et peut être mis à jour ou remplacé sans impacter
les autres parties du système. Cependant, cette autonomie nécessite une gestion rigoureuse des
contrats d’interface entre les microservices pour éviter les incompatibilités.

8.5.3.1.5 Automatisation : L’automatisation dans une approche DDD est souvent limitée.
La conception nécessite une analyse et une intervention manuelle approfondie, bien que certains
aspects comme les tests unitaires et l’intégration continue puissent être automatisés. Les outils
d’automatisation doivent être alignés avec les principes DDD pour être efficaces.

8.5.3.2 Approche Centrée sur les Données (Data-Centric Process for Microser-
vice Identification)

8.5.3.2.1 Adaptabilité : Cette approche est particulièrement efficace pour les systèmes où
la structure des données est complexe et centrale aux opérations du système. Elle est adaptée aux
systèmes qui manipulent de grandes quantités de données ou où les données dictent les processus
métier. Cependant, son adaptabilité peut être limitée dans des systèmes où les processus métier
sont plus importants que les données elles-mêmes.

8.5.3.2.2 Complexité : La complexité de cette approche réside dans l’identification et la

segmentation des ensembles de données pertinents pour chaque microservice. Cela nécessite une
analyse approfondie des schémas de base de données existants et une réorganisation potentielle des
données pour éviter la redondance et la duplication entre les microservices.

8.5.3.2.3 Performance : En alignant les microservices sur des ensembles de données spéci-
fiques, cette approche peut améliorer les performances, notamment en optimisant les requêtes et en
réduisant les transferts de données inutiles entre les services. Cependant, cela dépend fortement de
la qualité de l’architecture de la base de données et de la gestion des transactions distribuées.

51
8.5.3.2.4 Maintenance : La maintenance est facilitée par une séparation claire des respons-
abilités liées aux données. Chaque microservice gère ses propres données, ce qui simplifie les mises
à jour et les migrations de données. Toutefois, cette séparation doit être soigneusement gérée pour
éviter la fragmentation des données et la complexité accrue des transactions inter-services.

8.5.3.2.5 Automatisation : Cette approche peut bénéficier d’une certaine automatisation,

notamment dans l’identification des microservices basés sur des schémas de données existants. Des
outils peuvent être utilisés pour générer des modèles de microservices à partir des schémas de
données, mais l’ajustement et l’optimisation de ces modèles nécessiteront souvent une intervention
manuelle.

8.5.3.3 Approches Automatisées par l’Intelligence Artificielle

8.5.3.3.1 Adaptabilité : Les approches automatisées par l’IA sont très flexibles et peuvent
être adaptées à une grande variété de systèmes hérités. L’IA peut analyser les systèmes existants
pour identifier des motifs et des dépendances qui ne sont pas évidents, facilitant ainsi une migration
plus efficace. Cependant, l’efficacité de cette approche dépend de la qualité et de la quantité de
données disponibles pour entraîner les modèles d’IA.

8.5.3.3.2 Complexité : L’intégration de techniques de machine learning dans le processus

de migration ajoute une couche de complexité supplémentaire. Les équipes doivent non seulement
comprendre les concepts traditionnels de migration, mais aussi être compétentes en IA et en machine
learning, ce qui peut nécessiter des compétences spécialisées et des ressources supplémentaires.

8.5.3.3.3 Performance : L’IA peut potentiellement optimiser les performances en identifi-

ant les meilleures pratiques de migration et en ajustant automatiquement les microservices pour
maximiser l’efficacité. Toutefois, les résultats peuvent varier en fonction des algorithmes utilisés
et de la qualité des données d’entraînement, et il peut être nécessaire d’affiner manuellement les
recommandations de l’IA.

8.5.3.3.4 Maintenance : Les systèmes basés sur l’IA peuvent poser des défis uniques en
termes de maintenance, en particulier si les modèles d’IA doivent être mis à jour ou ajustés en
fonction de nouvelles données ou de changements dans l’environnement du système. Cependant,
une fois bien configurée, l’IA peut faciliter la maintenance en prédisant les besoins en mise à jour
et en optimisant automatiquement les microservices.

8.5.3.3.5 Automatisation : L’un des plus grands avantages de cette approche est le poten-
tiel élevé d’automatisation. L’IA peut automatiser de nombreuses étapes du processus de migration,
de l’identification des microservices à leur déploiement et à leur optimisation. Cela peut consid-
érablement réduire le temps et les efforts nécessaires pour effectuer la migration.

52
8.5.3.4 Approche Basée sur les Processus Métier et les Objets de Données

8.5.3.4.1 Adaptabilité : Cette approche est particulièrement bien adaptée aux systèmes où
les processus métier sont clairement définis et bien documentés. Elle permet d’aligner les microser-
vices directement sur les processus métier, ce qui assure une correspondance étroite entre la logique
métier et l’architecture du système. Cependant, elle peut être moins efficace dans les systèmes où
les processus métier ne sont pas bien définis ou sont en constante évolution.

8.5.3.4.2 Complexité : La complexité de cette approche réside dans l’analyse et la modélisa-

tion des processus métier. Il est crucial de comprendre en détail comment chaque processus interagit
avec les objets de données pour créer des microservices qui capturent efficacement ces interactions.
Cela peut nécessiter des efforts substantiels en termes de modélisation et de documentation.

8.5.3.4.3 Performance : En alignant les microservices sur les processus métier, cette ap-
proche peut améliorer la performance en minimisant les interconnexions et en facilitant le traitement
en parallèle des différents processus. Toutefois, la performance peut être affectée si les processus
métier sont trop fortement couplés ou si des objets de données sont partagés de manière intensive
entre les microservices.

8.5.3.4.4 Maintenance : Cette approche simplifie la maintenance en alignant les microser-

vices sur les processus métier bien définis, ce qui facilite l’identification des impacts des changements
de processus. Cependant, si les processus métier évoluent fréquemment, la maintenance peut devenir
complexe, nécessitant des ajustements réguliers des microservices.

8.5.3.4.5 Automatisation : Le niveau d’automatisation dépend de la clarté et de la for-

malisation des processus métier. Des outils peuvent être utilisés pour automatiser la création de
microservices à partir de modèles de processus métier, mais la personnalisation et l’ajustement des
microservices nécessiteront probablement une intervention manuelle.

8.5.4 Tableau Comparatif

Critères Approche Approche Approches Approche

DDD Centrée sur Automatisées basée sur
les Données par l’IA les processus
métier
Adaptabilité Haute Moyenne Haute Moyenne
Complexité Élevée Moyenne Élevée Moyenne
Performance Élevée Moyenne Élevée Moyenne
Maintenance Élevée Moyenne Moyenne Moyenne
Automatisation Faible Moyenne Élevée Moyenne

Table 8.2: Comparaison des différentes approches

53
8.5.5 Conclusion
À la lumière de l’analyse comparative des différentes approches de migration vers les microser-
vices, il apparaît que chaque méthode possède ses propres avantages et limitations en fonction des
spécificités du système hérité et des objectifs de la migration.
L’Approche Pilotée par le Domaine (DDD) se distingue par sa capacité à structurer et
segmenter les systèmes complexes en domaines distincts, facilitant ainsi une gestion modulaire et
une maintenance simplifiée des microservices. Cette approche excelle dans les environnements où
le domaine métier est central et bien défini, permettant une transformation progressive et contrôlée
du monolithe vers une architecture microservices. Toutefois, la complexité inhérente à la mise en
œuvre de DDD exige une compréhension approfondie du domaine métier et une collaboration étroite
entre les équipes techniques et les experts du domaine.
En complément de l’approche DDD, l’utilisation d’une analyse statique du code peut
grandement renforcer le processus de migration. L’analyse statique permet de cartographier au-
tomatiquement les dépendances entre les modules, d’identifier les zones critiques de complexité et
de repérer les ”points chauds” dans le code qui nécessitent une attention particulière lors de la
refactorisation en microservices. Cela permet d’optimiser la phase de découpage du monolithe, en
alignant les frontières des microservices avec les « bounded contexts » identifiés par DDD.
Les autres approches, bien que puissantes dans des contextes spécifiques, présentent des dé-
fis qui peuvent limiter leur efficacité dans des projets où la complexité du domaine métier et la
nécessité d’une transition contrôlée sont des priorités. L’approche centrée sur les données, bien
qu’efficace pour les systèmes axés sur les données, peut entraîner une fragmentation des données
et complexifier les transactions inter-services. Les approches automatisées par l’IA, bien qu’offrant
un potentiel d’automatisation significatif, nécessitent une expertise avancée en machine learning et
peuvent introduire des incertitudes dans la migration. Enfin, l’approche basée sur les processus
métier, tout en étant efficace pour les systèmes bien documentés, peut manquer de flexibilité dans
des environnements en constante évolution.
Recommandation : l’approche DDD associée à une analyse statique du code est la
plus adaptée. Cette combinaison permet non seulement de structurer la migration de manière
méthodique et cohérente, mais aussi de minimiser les risques liés à la refactorisation et à la recon-
figuration du système. Elle offre un cadre robuste pour une transition progressive, tout en assurant
une maintenance facilitée et une évolutivité continue des microservices.

54
 Part IV

Conclusion

55
Section 9

Conclusion

Cette thèse a approfondi l’étude de la transition des systèmes monolithiques vers des architec-
tures microservices, en commençant par établir le contexte théorique et les principes de base du
domaine. En explorant les travaux existants, nous avons distingué deux grandes catégories d’ap-
proches : techniques et basées sur le retour d’expérience. Cette distinction a permis une analyse
critique et comparative, où les approches ont été évaluées selon leurs objectifs, les inputs nécessaires,
les processus implémentés, et les résultats attendus.
Plusieurs exemples de feedback ont été présentés, offrant un aperçu pratique des méthodes
actuellement utilisées pour gérer la migration. À partir de cette analyse, plusieurs constatations et
pistes de réflexion se dégagent pour orienter les recherches futures :

Autonomie des Données

Il est observé que nombre d’approches d’identification des microservices négligent l’aspect crucial
de l’autonomie des données. Ce manque peut limiter l’efficacité des architectures de microservices,
particulièrement lorsque l’identification est dérivée directement du code source.

Algorithme de Clustering
Les méthodes de clustering sont fréquemment utilisées pour découper les applications mono-
lithiques en microservices. Ces techniques ont démontré leur capacité à simplifier la gestion et à
augmenter la modularité des systèmes informatiques.

Évolution de la Recherche
Le champ de la migration vers les microservices est en constante évolution, avec une recherche
dynamique et de nombreuses nouvelles approches qui émergent régulièrement. Cela souligne l’im-
portance de suivre activement les derniers développements pour rester à la pointe de la technologie.

56
 En conclusion, cette thèse pave la voie à des études futures et à des applications pratiques, en
particulier dans le cadre de notre projet de fin d’études qui envisage de transformer une architecture
monolithique d’entreprise en une configuration basée sur les microservices. Cette transformation
est perçue non seulement comme une amélioration technique, mais aussi comme une opportunité de
restructurer les pratiques informatiques pour mieux répondre aux exigences actuelles de flexibilité,
d’évolutivité, et d’efficacité.

57
Bibliography

[1] A. Megargel and V. Shankararaman. “Migrating from Monoliths to Cloud-Based Mi-

croservices: A Banking Industry Example.” In: Software Engineering in the Era of Cloud
Computing. Research Collection School Of Information Systems, 2020, pp. 85–108.
[2] Gustav Johansson. “Investigating differences in response time and error rate between a
monolithic and a microservice based architecture.” MA thesis. KTH, School of Electrical
Engineering and Computer Science (EECS), 2019, p. 13.
[3] Miika Kalske. “Transforming monolithic architecture towards microservice architec-
ture.” MA thesis. 2018.
[4] M. Fowler. Monolith First. martinfowler.com. June 2015. url: https://martinfowler.
com/bliki/MonolithFirst.html.
[5] Alan Megargel, Venky Shankararaman, and David K. Walker. “Migrating from Mono-
liths to Cloud-Based Microservices: A Banking Industry Example.” In: Software Engi-
neering in the Era of Cloud Computing. Ed. by Muthu Ramachandran and Zaigham
Mahmood. Cham: Springer International Publishing, 2020, pp. 85–108. isbn: 978-3-
030-33624-0. doi: 10.1007/978-3-030-33624-0_4. url: https://doi.org/10.1007/
978-3-030-33624-0_4.
[6] A. Martini and J. Bosch. “On the interest of architectural technical debt: Uncovering
the contagious debt phenomenon.” In: Software: Practice and Experience 47 (2017),
e1877. doi: 10.1002/smr.1877.
[7] Z. Dehghani. Data Monolith to Mesh. Martin Fowler. May 2019. url: https : / /
martinfowler.com/articles/data-monolith-to-mesh.html.
[8] M. Mazzara et al. “Microservices: Migration of a Mission Critical System.” In: IEEE
Transactions on Services Computing 14.5 (Sept. 2021).
[9] M. Li. IN5320: Lecture 2: Information systems and complexity. Oslo, Apr. 2020.

58
[10] Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice
Hall, 2005.
[11] Nicolai M Josuttis. SOA in Practice: The Art of Distributed System Design. O’Reilly
Media, 2007.
[12] Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA: Service-Oriented Archi-
tecture Best Practices. Prentice Hall, 2004.
[13] Michael P Papazoglou and Willem-Jan van den Heuvel. “Service-oriented architectures:
approaches, technologies and research issues.” In: The VLDB Journal—The Interna-
tional Journal on Very Large Data Bases 16.3 (2007), pp. 389–415.
[14] Sam Newman. Monolith to Microservices Evolutionary Patterns to Transform Your
Monolith. O’Reilly Media, 2022.
[15] Martin Fowler and James Lewis. “Microservices: a definition of this new architec-
tural term.” In: ThoughtWorks (2014). url: https://martinfowler.com/articles/
microservices.html.
[16] James Lewis and Martin Fowler. “Microservices.” In: ThoughtWorks (2014). url: https:
//martinfowler.com/microservices/.
[17] Nicola Dragoni et al. Microservices: Yesterday, Today, and Tomorrow. Springer, 2017.
[18] Martin Kleppmann. Designing Data-Intensive Applications: The Big Ideas Behind Re-
liable, Scalable, and Maintainable Systems. O’Reilly Media, Inc., 2017.
[19] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. “Architectural Patterns for Mi-
croservices: A Systematic Mapping Study.” In: Proceedings of the 6th International
Conference on Model-Driven Engineering and Software Development (Mar. 2018). doi:
10.5220/0006798302210232.
[20] Chris Richardson. Microservices Patterns: With examples in Java. Manning Publi-
cations, 2018. isbn: 9781617294549. url: https : / / books . google . dz / books ? id =
UeK1swEACAAJ.
[21] Chris Richardson. Microservices Patterns: With examples in Java. Manning Publi-
cations, 2018. isbn: 9781617294549. url: https : / / books . google . dz / books ? id =
UeK1swEACAAJ.
[22] Sam Newman. Building Microservices: Designing Fine-Grained Systems. O’Reilly Me-
dia, 2015. isbn: 978-1491950357.
[23] Martin Fowler. Microservices - a definition of this new architectural term. martin-
fowler.com. 2016. url: https://martinfowler.com/articles/microservices.html.

59
[24] Yamina Romani, Okba Tibermacine, and Chouki Tibermacine. “Towards Migrating
Legacy Software Systems to Microservice-based Architectures: a Data-Centric Process
for Microservice Identification.” In: IEEE, 2022.
[25] Chaieb M Saied M A. “Automate migration to microservices architecture using Machine
Learning techniques.” In: arXiv:2301.06508v1 [cs.SE] (2023).
[26] M. J Amiri. “Object-aware Identification of Microservices.” In: IEEE, 2018.

60