J'en prote aussi pour remercier Jean-Louis Pazat qui, dans ces conditions peu communes, a accepté de prendre le relais de Françoise.

Transcription

1

2

3 Remerciements Coming Soon Les recherches menant aux présents résultats ont bénécié d'un nancement du Programme de la Communauté européenne septième programme-cadre FP7/ sous convention de subvention (S-Cube).

4 1 Avant d'entrer dans le vif du sujet, j'ai une pensée pour Françoise André avec qui j'ai eu l'honneur de débuter cette thèse et qui, malheureusement, n'est plus là pour la conclusion. En tant que directrice, elle était exigeante et passionnée. Elle était aussi dicile à convaincre, mais toujours prête à changer d'avis pour peu que vous soyez capable de vous justier. J'ai apprécié nos discussions qui, avec nos caractères bien trempés, étaient parfois animées, mais surtout toujours intéressantes. Merci. J'en prote aussi pour remercier Jean-Louis Pazat qui, dans ces conditions peu communes, a accepté de prendre le relais de Françoise.

5

6

7 Table des matières Table des matières 5 I Introduction 7 Introduction 9 Problématique Contribution Organisation du document II État de l'art 15 1 Contexte Cloud Computing Adaptation Adaptation et Cloud : un besoin d'abstraction État de l'art Les caractéristiques d'une abstraction pour administrer le Cloud Cas d'usage Les abstractions pour l'adaptation logicielle Les langages réexifs Les architectures réexives Approche à composants Architecture orientée Service Modèle à l'exécution Les abstractions pour le Cloud Les solutions académiques Les solutions commerciales Infrastructure Plate-forme Application GCM : une abstraction pour grille Synthèse

8 4 TABLE DES MATIÈRES 3 Kevoree Les caractéristiques de Kevoree Les concepts de Kevoree Paradigmes de modélisation Paradigmes du framework Kevoree et ses outils Un langage graphique KevScript : un langage textuel Les frameworks de conception Extensibilité de Kevoree Délégation de l'exécution de l'adaptation Délégation de la planication de l'adaptation III Contribution 63 4 KevoreeKloud : Une extension de Kevoree pour le Cloud Dénition d'un Cloud L'abstraction du support d'exécution : la notion d'hébergement Héritage et composition : mutualiser la conception de type Les caractéristiques pour un type de n ud hébergeant des n uds Les caractéristiques communes des types de n uds pour le Cloud Les caractéristiques pour un n ud d'infrastructure Les caractéristiques pour un n ud de plate-forme Extension possible pour les types de n uds Cloud Dénition de systèmes d'adaptation Kevoree et la planication F4Plan Vue globale ou vue partielle du système Synthèse Validation Évaluation 1 : Est-ce extensible et générique? Protocole expérimental Implémentation du cas d'étude Infrastructure d'espace utilisateur Proxy pour infrastructure EC Évaluation Évaluation 2 : Est-ce utilisable pour des Clouds? Protocole expérimental Implémentation du cas d'étude Plate-forme de déploiement de tests unitaires

9 Table des matières Résultat sur un projet concret : Apache Camel Évaluation Impact sur le déploiement Impact sur l'utilisation mémoire Complexité de l'implémentation de nouveaux types et gestionnaire Évaluation 3 : Est-ce utilisable pour de l'adaptation multi-niveaux? Protocole expérimental Implémentation du cas d'étude Dénition du serveur web distribué Évaluation Synthèse IV Conclusion Conclusion et Perspectives Conclusion Perspectives à court terme Modèle de contexte Test d'applications distribuées Extension vers d'autres technologies et utilisation dans des projets de recherches Perspectives à long terme Gestion du Big Data Sécurité et abstraction globale Publications liées à cette thèse Bibliographie 130 Table des gures 131 Liste des algorithmes 133

10

11 Première partie Introduction 7

12

13 Introduction En 1969, l'ucla (University of California, Los Angeles) annonçait l'arrivée imminente de l'internet (connu à l'origine sous le nom d'arpanet). Dans cette annonce, Leonard Kleinrock, l'un des scientiques à l'origine de ce projet disait [89] : As of now, computer networks are still in their infancy, but as they grow up and become sophisticated, we will probably see the spread of 'computer utilities' which, like present electric and telephone utilities, will service individual homes and oces across the country. Cette vision de l'informatique utilitaire prédisait l'évolution majeure de l'industrie informatique de ce début de siècle. Basé sur le principe de fournir les ressources informatiques sous forme de services et de facturer leur utilisation en fonction de leur usage (pay as you go en anglais), le Cloud Computing permet d'eectuer des économies d'échelle grâce à l'externalisation de ces ressources vers des fournisseurs spécialisés. Ainsi, de nombreuses ores de Cloud ont vu le jour. C'est le cas par exemple de Google App Engine [13], Amazon EC2 [1] ou Microsoft Azure [36], les ores permettant d'utiliser les infrastructures de calcul et de communication de Google, Amazon ou Microsoft comme des services utilitaires. Ces ores proposent diérents types de service généralement spéciques à l'usage que les utilisateurs peuvent en faire. Une architecture en couches a été proposée pour catégoriser les diérents types de services et les usages correspondants. Cette architecture est aussi appelée modèle SPI [40] (Software / Platform / Infrastructure voir Figure 1) : Infrastructure (Infrastructure as a Service (IaaS)) : cette couche ore un niveau d'abstraction par rapport aux infrastructures disponibles. Il est alors possible de déployer des instances de systèmes virtualisés personnalisés (plate-forme) selon les besoins de l'utilisateur. L'une des solutions les plus connues est celle proposée par Amazon [1] qui permet de déployer des machines virtuelles personnalisées. Plate-forme (Platform as a Service (PaaS)) : cette couche ore un niveau d'abstraction vis-à-vis de la plate-forme d'exécution applicative. La plate-forme d'exécution applicative a pour but de simplier la conception, mais aussi le déploiement d'applications en simpliant voire en minimisant l'interaction avec l'infrastructure et en orant un ensemble de fonctionnalités directement intégrées. Parmi les ores de PaaS existantes, nous pouvons citer Google App Engine [13] qui permet de déployer des applications web et qui ore un ensemble d'apis pour simplier l'interaction avec diérents éléments tels que les bases de données ou encore le 9

14

15 Introduction 11 Problématiques De nombreuses problématiques de recherche sont encore ouvertes pour conforter ce modèle de l'informatique utilitaire. Par exemple, au niveau infrastructure, fournir des couches de virtualisation de plus en plus ecaces reste un dé en constante étude. Orir des capacités d'observation nes des ressources consommées au niveau de l'infrastructure est là aussi une problématique scientique non encore complètement résolue. Au niveau plate-forme, fournir une couche ecace de support de l'applicatif, prenant en charge de manière transparente ou déclarative de nombreux services techniques en limitant les hypothèses faites sur l'infrastructure est aussi un domaine de recherche toujours d'actualité. Au niveau applicatif, adapter les techniques de conception logiciel au développement d'applications pour le Cloud en bénéciant au mieux des fonctionnalités oertes par la plate-forme ou migrer automatiquement des applications existantes sur le Cloud sont aussi des sujets toujours en cours d'étude. Outre ces problématiques que l'on peut isoler par couche dans le modèle SPI, d'autres problématiques s'étudient de manière transverse. Pour pouvoir faire de la tolérance aux pannes, de l'élasticité de ressources et du green computing, des systèmes d'adaptation sont généralement utilisés an de recongurer pendant son exécution le système qui dans notre cas correspond à une infrastructure, une plate-forme ou une application. Les mécanismes d'adaptation au niveau infrastructure utilisent les capacités de celuici pour le recongurer (migration de machine virtuelle, arrêt de serveur,...). Pour les autres niveaux, ceux-ci utilisent des capacités qui leur sont propres, mais aussi les fonctionnalités oertes par le niveau sous-jacent. Par exemple, la plate-forme peut, par l'intermédiaire de l'infrastructure, créer de nouvelles machines virtuelles. La manière d'utiliser ces mécanismes de reconguration fournis par chacune des ores et chacun des niveaux du modèle SPI est souvent propre à chacune d'elles. Par exemple, l'api EC2 pour Amazon EC2 ou les APIs Google pour Google App Engine sont dédiés à ces ores. Ce sont ces spécicités qui font le vendor locking et qui rendent dicile la collaboration des infrastructures, des plates-formes ou des applications. Cependant, outre ce vendor locking, même si les diérents niveaux peuvent interagir entre eux, chaque niveau est indépendant des autres et les recongurations de chacun des niveaux ne tiennent pas compte de l'évolution des autres alors que l'adaptation devrait être une préoccupation transverse. En eet, dans [84], les auteurs dénissent plusieurs modes d'adaptation (conguration, optimisation, réparation, protection) et expliquent que ce sont des modes indépendants les uns des autres, mais que de manière optimale il serait préférable de pouvoir les intégrer les uns aux autres. De la même façon, il est nécessaire d'envisager l'adaptation comme une problématique globale à l'ensemble des niveaux. C'est ce que Google a mis en place pour son service de messagerie (Gmail) [15] avec une infrastructure, une plate-forme et une application spécialisées et optimisées pour s'exécuter ensemble. C'est la maîtrise totale de son système informatique qui permet à Google de mettre en place ce genre de solution lui permettant de faire cohabiter l'infrastructure, la plateforme et l'application an d'assurer une adaptation globale cohérente et ecace. Mais la majorité des utilisateurs de Cloud n'ont pas la possibilité d'avoir une maîtrise totale

16 12 Introduction des solutions techniques. Par exemple si nous prenons CloudBees [3] qui propose de concevoir des plates-formes spécialisées selon les besoins des applications, CloudBees utilise l'infrastructure Amazon EC2 et ne peut donc pas gérer celle-ci pour eectuer de l'adaptation cohérente et ecace et est seulement capable d'utiliser l'infrastructure pour adapter ces plates-formes. C'est pourquoi il est nécessaire de disposer d'abstractions pour regrouper susamment d'informations sur l'ensemble des niveaux pour tirer parti des autres niveaux, mais aussi pour coordonner les adaptations entre les niveaux. C'est la problématique principale visée par cette thèse, comment orir aux fournisseurs de services de Cloud une vue cohérente de l'ensemble des niveaux du modèle SPI leur permettant de concevoir ecacement leurs services et de raisonner de manière ecace sur leur système, c'est-à-dire l'ensemble des niveaux du modèle SPI, lui permettant aussi de recongurer de manière cohérente l'infrastructure, la plate-forme et les applications en fonction des besoins de ces derniers. Contribution Cette thèse propose une abstraction permettant de gérer/coordonner l'adaptation entre les diérents niveaux, mais aussi permettant la collaboration entre des solutions techniques de même niveau. Cette abstraction sert aussi de support à la conception de nouvelles solutions de Cloud que ce soit pour l'infrastructure, la plate-forme ou les applications. Une abstraction regroupe un ensemble d'information correspondant à un point de vue particulier d'un système. Ici ce système correspond à l'ensemble des diérents niveaux qui existent dans un Cloud et le point de vue qui nous intéresse correspond à la conguration architecturale de ces niveaux avec par exemple la représentation de l'ensemble des ressources matérielles de l'infrastructure, l'ensemble des environnements d'exécution d'une plate-forme et les diérents éléments correspondants aux applications. L'intérêt d'avoir une abstraction de la conguration architecturale réside dans la possibilité de se servir de cette abstraction comme support de communication dans le cadre de la coordination de l'adaptation [61]. En eet, chacun des systèmes d'adaptation peut utiliser cette abstraction pour proposer des recongurations et ces recongurations seront comprises par n'importe quels systèmes d'adaptation si lui-même utilise cette abstraction. De la même manière, l'utilisation de cette abstraction comme support de raisonnement pour les systèmes d'adaptation permet la portabilité des systèmes de raisonnement sur diérentes implémentations d'infrastructures, de plates-formes ou d'applications équivalentes dans cette abstraction. Au sein de cette abstraction sont dénis les diérents concepts permettant de spécier les services présents aux diérents niveaux. Ainsi, cette abstraction permet de représenter les diérents niveaux, mais est aussi capable de modéliser la distribution de chacun des niveaux, avec par exemple le nombre de machines virtuelles faisant parties d'une plate-forme. Cette abstraction est construite de manière extensible an de faciliter l'intégration de futures caractéristiques pouvant être importantes dans la représentation d'un Cloud. C'est aussi cette extensibilité qui permet de représenter l'hétérogénéité des

17 Introduction 13 implémentations que ce soit au niveau infrastructure, plate-forme ou application en permettant de représenter les caractéristiques spéciques à chacune des implémentations. De cette façon, il est possible de représenter des Clouds hétérogènes et d'envisager des recongurations coordonnées entre les diérentes implémentations. Cette abstraction est fondée sur des concepts et outils issus de l'ingénierie Dirigée par les Modèles (IDM) ou Model Driven Engineering (MDE) [110] et plus particulièrement des travaux autour des modèles à l'exécution ou Model at Runtime [44]. L'IDM prône le développement logiciel par l'intermédiaire d'abstractions appelées modèles représentant les diérentes vues d'un système et permettant de générer un système concret à partir des dénitions de ces diérentes vues. Le quant à lui propose de porter, à l'exécution, les techniques et outils de l'idm utilisés normalement durant la phase de conception. Ainsi, il est possible de modier les modèles représentant le système et impacter ces changements sur le système en cours d'exécution tout en bénéciant des outils de validation existants (l'analyse statique par exemple) autour des modèles an d'assurer la cohérence du nouveau modèle. J'ai utilisé l'approche appelée Kevoree 1 qui proposait déjà de nombreuses propriétés pour représenter les diérents niveaux de Cloud et notamment les applications et les plates-formes. J'ai étendu cette approche dans une extension appelée KevoreeKloud an d'y intégrer les concepts nécessaires à la gestion des diérents niveaux de Cloud et notamment nécessaires à la représentation du niveau infrastructure et aux relations entre les niveaux. Ces concepts gravitent autour de l'idée de n ud qui représente un conteneur d'exécution. Ces conteneurs d'exécution peuvent être, au niveau de l'infrastructure, des conteneurs de machines virtuelles correspondant à une ou plusieurs plates-formes ou au niveau Plate-forme, des conteneurs d'applications. Ces n uds sont les supports de l'adaptation en fournissant les primitives d'adaptation nécessaires à la reconguration de leur contenu. Ils fournissent aussi les outils permettant d'assurer la validité des adaptations avec notamment la planication de l'exécution des adaptations pour assurer que l'adaptation soit ecace et surtout cohérente. En plus des outils utilisés à l'exécution, Kevoree propose aussi un ensemble de framework pour la conception de nouvelles solutions logicielles que j'ai utilisé et étendu pour faciliter la conception de nouvelles implémentations de Cloud que ce soit pour le niveau infrastructure ou plate-forme. Organisation du document Ce document est organisé comme suit. Tout d'abord, le chapitre 1 présente le contexte dans lequel s'inscrivent les travaux présentés dans cette thèse. Ce contexte concerne le domaine du Cloud Computing avec ses origines depuis l'informatique utilitaire en passant par les grilles de calculs, les diérents types de Cloud qui existent à l'heure actuelle ainsi que les diérents types d'utilisateurs visés par les solutions de Cloud Computing et les besoins qui leur sont reliés. La gestion de ces besoins se fait généralement de manière dynamique et nécessite 1.

18 14 Introduction de pouvoir recongurer le Cloud et ses diérents éléments. Ainsi, le contexte concerne aussi le domaine de l'adaptation logicielle pour lequel est proposé une dénition de ce qu'est l'adaptation et comment celle-ci doit être prise en compte. Le chapitre 2 présente l'état de l'art des frameworks et des modèles permettant de modéliser et piloter des systèmes logiciels. L'étude de ces frameworks et modèles se fera par rapport à un ensemble de critères permettant la représentation des diérents éléments d'un Cloud et orant une abstraction permettant de gérer l'adaptation de manière transverse aux diérents éléments du Cloud. Le chapitre 3 présente en détails une abstraction appelée Kevoree et utilisant les principes de modèles à l'exécution pour la conception et l'adaptation de systèmes distribués large échelle. Les travaux de cette thèse ont été intégrés à cette abstraction an de pouvoir modéliser un système de Cloud. Le chapitre 4 présente les travaux de cette thèse autour d'une abstraction pour faire de l'adaptation multi-niveaux sur du Cloud. Ces travaux sont présentés sous la forme d'une extension à Kevoree permettant de modéliser l'ensemble des éléments d'un Cloud, d'un framework de développement facilitant la conception de solution de Cloud ainsi que l'intégration d'implémentations existantes et facilitant la réutilisation de diérents algorithmes nécessaires à la gestion d'un Cloud. Le chapitre 5 présente la validation de cette abstraction au travers de cas d'études. Le premier concerne l'implémentation d'un Cloud hybride an de montrer l'intérêt de KevoreeKloud, de son extension et du framework associé pour la conception de nouvelle solution de Cloud. Le second cas d'étude permet d'observer l'impact en terme de temps de l'utilisation de KevoreeKloud dans le cadre de la reconguration d'un Cloud ainsi que l'impact sur l'utilisation mémoire. Enn, le dernier cas d'étude permet de montrer comment notre abstraction permet de partager une vision globale du Cloud entre les diérents niveaux de celui-ci facilitant la coopération entre les systèmes d'adaptations an d'eectuer de l'adaptation cohérente et ecace. Enn, le chapitre 6 conclut ce document et présente les perspectives des travaux présentés.

19 Deuxième partie État de l'art 15

20

21 Chapitre 1 Contexte Ce chapitre présente plus en détail les deux domaines dans lesquels s'intègrent les travaux de cette thèse. Tout d'abord, en section 1.1, nous dénissons ce qu'est le Cloud Computing et les nombreuses solutions existantes montrant l'importance et la diversité que l'on peut y trouver. Ensuite, la section 1.2 présente le domaine de l'adaptation devenue une caractéristique fondamentale des systèmes informatiques actuels. 1.1 Cloud Computing Le concept de Cloud Computing ou informatique dans les nuages consiste à fournir les ressources informatiques sous forme de services pour lesquels l'utilisateur paie pour ce qu'il utilise. Ce concept est apparu dans les années 60 notamment avec McCarthy [69] ou encore Kleinrock [89] sous le nom d'informatique utilitaire. C'est ensuite vers la n des années 90 que ce concept a réellement pris de l'importance avec tout d'abord le Grid Computing [66]. Ce terme est une métaphore exprimant la similarité avec le réseau électrique dans lequel l'électricité est produite dans de grandes centrales puis disséminée au travers d'un réseau jusqu'aux utilisateurs naux. Ici les grandes centrales sont les DataCenters, le réseau est le plus souvent celui d'internet et l'électricité correspond aux ressources informatiques. Le terme Cloud Computing n'est véritablement apparu qu'au cours des années [116] avec l'apparition d'amazon EC2 [1] ou encore la collaboration d'ibm et Google [11, 12] ainsi que l'annonce d'ibm concernant 'Blue Cloud' [17]. Par la suite de nombreuses solutions open source ont aussi vu le jour avec par exemple OpenShift [27] de RedHat, ou encore OpenStack [28] de RackSpace et en collaboration avec la NASA. Le marché du Cloud Computing n'en est encore qu'à ces débuts et d'après une étude menée par Forrester [106], alors que le marché du Cloud Computing s'élevait à environ 5,5 milliards de dollars en 2008, à un peu plus de 23 milliards en 2011, il devrait atteindre plus de 150 milliards d'ici 2020 (voir gure 1.1). Il existe diérents types de Cloud (voir gure 1.2) : les Clouds publics correspondent à des solutions de Cloud proposées par des prestataires de services. Ces solutions sont le plus souvent accessibles par un modèle de paiement en fonction de l'utilisation. Nous pouvons citer parmi les 17

22

23 Cloud Computing 19 Figure 1.2 Les diérents types de Cloud comme celle de Google voir d'utiliser les deux en même temps. Dans [83], les auteurs expliquent que les des de ce genre de solution concernent entre autres l'interopérabilité des solutions de Cloud ainsi que la création de réseaux d'interconnexion sûrs et performants entre machines virtuelles. Outre les diérents types de Cloud, le Cloud Computing a entrainé une évolution des rôles des personnes interagissant avec ce nouveau type de système d'information. Plusieurs personnes de chez IBM ont proposé une dénition des interactions possibles et des rôles associés [45]. Ces rôles sont catégorisés par trois ensembles. Cette approche dénit tout d'abord la catégorie des concepteurs qui dénissent et construisent des services. Ces services peuvent être de niveau Infrastructure, Plate-forme ou Application et leurs dénitions correspondent non seulement à la dénition des fonctionnalités, mais aussi à leurs caractéristiques non fonctionnelles comme le prix auquel ces services seront proposés. C'est aussi dans cette catégorie que l'on retrouve le rôle de composition de service pour former un service de plus haut niveau. Cette approche introduit ensuite la catégorie des utilisateurs qui consomment les services proposés par un Cloud que ce soit en tant qu'application à part entière comme les services de messagerie ou en tant que services intégrés dans des applications non- Cloud par exemple un service de stockage de données ou un service de base de données. Cette catégorie regroupe aussi les acteurs chargés du lien entre fournisseurs et utilisa-

24 20 Contexte teurs naux par exemple dans le cadre de l'évaluation de la sécurité des services fournis. Enn, cette approche introduit la catégorie des fournisseurs qui mettent en place les services et assurent leur disponibilité ainsi que leur bon fonctionnement. Sont regroupées dans cette catégorie, les personnes chargées de faire le lien entre les concepteurs et les utilisateurs que ce soit pour le déploiement des services, la gestion du paiement à l'usage, l'assistance aux utilisateurs dans le cadre de l'évaluation des services à utiliser selon leurs besoins, la gestion du matériel physique (machines, câble, système de refroidissement,...), la gestion des défaillances, la surveillance des services pour évaluer leurs usages et informer des défaillances, la gestion des aspects techniques qui ne sont pas reliés aux services (le réseau par exemple), la gestion de l'énergie. De manière générale, ce sont les fournisseurs qui sont chargés de la gestion des propriétés non fonctionnelles liées aux services. C'est la gestion de ces propriétés non fonctionnelles qui fait l'intérêt du Cloud Computing et notamment la gestion de l'élasticité. L'élasticité consiste à pouvoir ajouter ou supprimer dynamiquement des ressources en fonction des besoins. En eet, Armbrust et al. expliquent dans [40] que dans le cadre d'un système informatique standard, l'entreprise se doit d'estimer la charge possible que va subir son système an de pouvoir estimer au plus près la taille des ressources nécessaires. Cependant, cette estimation qui tient compte de la charge maximale signie que hormis lors des pics d'utilisation, les ressources prévues ne seront pas utilisées d'où une perte économique pour l'entreprise. De la même façon si la charge maximale a été sous-estimée, certains utilisateurs ne pourront pas accéder aux services fournis par l'entreprise ce qui peut avoir un eet néfaste sur les revenus de celle-ci non seulement à court terme, car les utilisateurs ne peuvent pas utiliser les services, mais aussi à long terme, car ils ne voudront plus utiliser ces services. Le fait de pouvoir dynamiquement faire évoluer les ressources informatiques utilisées an de cadrer au maximum avec les besoins réels permet ainsi de limiter les coûts inutiles dus au surdimensionnement des ressources. Cela permet d'éviter des pertes de bénéces qui pourraient être dues à un sous-dimensionnement des ressources. Cette capacité s'est révélée très utile dans le cadre de certaines startups ou petites entreprises souhaitant lancer un nouveau service, car il est dicile de prévoir l'engouement que peut produire un nouveau produit sur les consommateurs. Ce fut par exemple le cas avec l'entreprise Animoto [2] qui en l'espace d'un mois a vu son nombre d'utilisateurs passer de à et qui grâce à l'utilisation d'amazon EC2 a pu supporter cette montée en charge sans pour autant investir dans des infrastructures grâce à la gestion de l'élasticité fournie par Amazon EC2. Même si ces rôles sont distincts, dans la réalité, une personne endosse généralement plusieurs rôles. Par exemple, la gestion des propriétés non fonctionnelles telles que l'élasticité des services applicatifs dépend de la conception des services sous-jacents c'est-à-dire des services de la plate-forme voire des services de l'infrastructure. De ce fait, un fournisseur est souvent aussi un concepteur. Dans cette thèse ce sont les rôles de concepteur et de fournisseur qui nous intéressent et pour lesquelles nous souhaitons fournir des solutions concernant la gestion de l'adaptation dans un Cloud.

25 Adaptation Adaptation Dans le début des années 2000, IBM a publié un manifeste indiquant que l'obstacle à la progression de l'industrie du logiciel correspondait à la gestion de la complexité des systèmes logiciels [80]. Dans ce document, les auteurs pointaient du doigt la diculté de gérer les systèmes informatiques en tant qu'ensemble d'applications distinctes, car celles-ci interagissaient de plus en plus entre elles. Les systèmes devenant de plus en plus interconnectés, il devenait compliquer pour les architectes logiciels de prévoir et de dénir ces interactions. De la même façon, les systèmes étant de plus en plus importants et complexes, il devenait dicile de les installer, de les congurer, de les optimiser et de les maintenir. Enn, l'évolution des besoins sur ces systèmes évoluant rapidement, il devenait dicile de les faire évoluer rapidement pour répondre à ces besoins. Dans le but de pallier cette complexité, le concept d'adaptation d'entités logicielles a été introduit [51, 107]. L'idée de l'adaptation dynamique est de pouvoir modié à l'exécution, un logiciel en fonction de l'évolution de l'environnement dans lequel il s'exécute. Il existe diérents types d'actions d'adaptation selon leur impact sur l'entité à adapter. Tout d'abord l'adaptation paramétrique qui modie un ou plusieurs paramètres de l'entité (par exemple, modication du niveau de log dans une application). L'adaptation fonctionnelle permet quant à elle de remplacer le code d'une fonction de l'entité par une autre sans pour autant changer son comportement (par exemple, remplacement d'une fonction de tri à bulles par une fonction de tri rapide). À l'inverse, l'adaptation comportementale consiste à changer le comportement de l'entité (par exemple, ajouter une fonctionnalité à l'entité). Enn, l'adaptation environnementale permet de modier l'environnement d'exécution de l'entité (par exemple, migrer l'entité d'une machine à une autre). Le modèle MAPE pour Monitoring, Analysis, Planning, Execution [84] est une abstraction proposée par Jerey O. Kephart et David M. Chess qui formalise la conception d'un système d'adaptation. Il introduit dans l'entité à adapter un gestionnaire d'adaptation qui est chargé d'observer l'entité et ses relations an de l'adapter. Figure 1.3 Boucle autonomique correspondant au modèle MAPE