Gestion autonomique d'applications dynamiques sûres et résilientes

Autonomic Management of Reliable and Resilient Dynamic Applications

• Auteur / Autrice : Thomas Calmant
• Direction : Didier Donsez, Olivier Gattaz
• Type : Thèse de doctorat
• Discipline(s) : Informatique
• Date : Soutenance le 19/10/2015
• Etablissement(s) : Université Grenoble Alpes (ComUE)
• Ecole(s) doctorale(s) : École doctorale Mathématiques, sciences et technologies de l'information, informatique (Grenoble ; 1995-....)
• Partenaire(s) de recherche : Laboratoire : Laboratoire d'informatique de Grenoble (2007-....)
• Partenaire(s) de recherche : Equipe de recherche : Efficient and Robust Distributed Systems
• Jury : Président / Présidente : Vivien Quéma
• Jury : Examinateurs / Examinatrices : Didier Donsez, Olivier Gattaz, Walter Rudametkin, Sonia Ben Mokhtar
• Jury : Rapporteurs / Rapporteuses : Lionel Seinturier, Gaël Thomas

Mots clés

Mots clés contrôlés

Programmation (informatique)

Méthodes agiles (informatique)

Informatique -- Recherche

Génie logiciel

Mots clés libres

Évolution du logiciel

Sûreté de fonctionnement

Qualité des logiciels

Adaptation dynamique

Gestion autonomique

Software evolution

Reliability

Software quality

Dynamic adaptation

Autonomic computing

Résumé

Les architectures orientées services (SOA) sont considérées comme le moyen le plus avancé pour réaliser et intégrer rapidement des applications modulaires et flexibles.Dans ce domaine, les plates-formes SOA à disposition des développeurs et des architectes de produits logiciels sont multiples; les deux plus évoluées d'entre elles étant SCA et OSGi.Une application s'appuyant sur l'une de ces plates-formes peut ainsi être assemblée avec le minimum de composants nécessaires à la réalisation de ses tâches, afin de réduire sa consommation de ressources et d'augmenter sa maintenabilité.De plus, ces plates-formes autorisent l'ajout de composants greffons qui n'étaient pas connus lors des phases initiales de la réalisation du produit.Elles permettent ainsi de mettre à jour, d'étendre et d'adapter continuellement les fonctionnalités du produit de base ou des services techniques nécessaires à sa mise en production, sans interruption de service.Ces capacités sont notamment utilisées dans le cadre du paradigme DevOps et, plus généralement, pour mettre en œuvre le déploiement continu d'artefacts.Cependant, l'extensibilité offerte par ces plates-formes peut diminuer la fiabilité globale du système: une tendance forte pour développer un produit est l'assemblage de composants provenant de tierces-parties. De tels composants peuvent être d'une qualité inconnue voire douteuse.En cas d'erreur, de détérioration des performances, etc., il est difficile de diagnostiquer les composants ou combinaisons de composants incriminés.Il devient indispensable pour le producteur d'un logiciel de déterminer la responsabilité des différents composants impliqués dans un dysfonctionnement.Cette thèse a pour objectif de fournir une plate-forme, Cohorte, permettant de concevoir et d'exécuter des produits logiciels extensibles et résilients aux dysfonctionnements d'extensions non qualifiées.Les composants de tels produits pourront être développés dans différents langages de programmation et être déployés (ajout, mise à jour et retrait) en continu et sans interruption de service.Notre proposition adopte pour principe d'isoler les composants considérés comme instables ou peu sûrs.Le choix des composants à isoler peut être décidé par l'équipe de développement et l'équipe opérationnelle, à partir de leur expertise, ou bien déterminé à partir d'une combinaison d'indicateurs.Ces derniers évoluent au cours du temps pour refléter la fiabilité des composants.Par exemple, des composants peuvent être considérés fiables après une période de quarantaine; une mise à jour peut entraîner la dégradation de leur stabilité, etc..Par conséquent, il est indispensable de remettre en cause les choix initiaux dans l'isolation des composants afin, dans le premier cas, de limiter le coup des communications entre composants et, dans le deuxième cas, de maintenir le niveau de fiabilité du noyau critique du produit.

Service-Oriented architectures (SOA) are considered the most advanced way to develop and integrate modular and flexible applications.There are many SOA platforms available for software developers and architects; the most evolved of them being SCA and OSGi.An application based on one of these platforms can be assembled with only the components required for the execution of its tasks, which helps decreasing its resource consumption and increasing its maintainability.Furthermore, those platforms allow adding plug-ins at runtime, even if they were not known during the early stages of the development of the application.Thus, they allow updating, extending and adapting the features of the base product or of the technical services required for its execution, continuously and without outage.Those capabilities are applied in the DevOps paradigm and, more generally, to implement the continuous deployment of artifacts.However, the extensibility provided by those platforms can decrease the overall reliability of the system: a strong tendency in software development is the assembly of third-parties components.Such components may be of unknown or even questionable quality.In case of error, deterioration of performance, ... it is difficult to identify the implicated components or combinations of components.It becomes essential for the software producer to determine the responsibility of the various components involved in a malfunction.This thesis aims to provide a platform, Cohorte, to design and implement scalable software products, resilient to malfunctions of unqualified extensions.The components of such products may be developed in various programming languages and be deployed continuously (adding, updating and withdrawal) and without interruption of service.Our proposal adopts the principle of isolating the components considered unstable or insecure.The choice of the components to be isolated may be decided by the development team and the operational team, from their expertise, or determined from a combination of indicators.The latters evolve over time to reflect the reliability of components.For example, components can be considered reliable after a quarantine period; an update may result in deterioration of stability, ...Therefore, it is essential to question the initial choices in isolating components to limit, in the first case, the scope of communications between components and, in the second case, to maintain the reliability of the critical core of the product.