Architecture distribuée - Les enjeux d'un système décentralisé

04/01/2021 - Blog

Notre société évolue dans un monde toujours plus interconnecté. Il en va de même pour les applications et leur déploiement. Les systèmes monolithiques (un projet, un livrable, une instance d’exécution) ne permettent plus de répondre efficacement aux différentes problématiques qu’impose la réalisation d’un système complexe. L’architecture distribuée ou l'informatique distribuée désigne un système d'information ou un réseau pour lequel l'ensemble des ressources disponibles ne se trouvent pas au même endroit ou sur une même machine. En cela elle s'oppose à l'informatique centralisée .

Temps de lecture 10 mn    

Niveau Expert | 


Internet est un exemple de réseau distribué puisqu'il ne possède aucun nœud central. Les architectures distribuées reposent sur la possibilité d'utiliser des objets qui s'exécutent sur des machines réparties sur le réseau et communiquent par messages au travers du réseau.

Les problématiques auxquelles tout éditeur de logiciel est confronté aujourd’hui sont celles de l’autonomie des équipes, potentiellement géographiquement éloignées, des systèmes dit « à la carte », de l’isolation des responsabilités fonctionnelles/techniques, de la gestion des versions « dynamiques », de la flexibilité de déploiement, de l’hétérogénéité potentielle des clients finaux (consommateurs et usagers) sans oublier l’interopérabilité dans un système d’information hétérogène. L’objectif global reste lui toujours le même, à savoir garantir la maintenabilité du système.

Les aspects de maintenance sont essentiels dans le cadre de la réalisation de systèmes avec une durée de vie accrue. Une mauvaise maintenabilité au niveau architectural peut générer des conséquences à fort impact, notamment sur les coûts, les fonctionnalités et bien sûr la technique. Des ajouts de « blocs » de construction non maitrisés (syndrome spaghetti) et des risques de dérives exponentielles sont alors à craindre. L’architecture perdrait de ce fait sa faculté documentaire et cadrante.

L’interface, point convergeant de toute l’architecture

Dès le début des années 80, les enjeux croissants de compatibilité entre les différents systèmes ont donné naissance au domaine de recherche de l’interopérabilité. Les principes SOA (Service Oriented Architecture, architecture orientée services), constituent la première forme de standardisation de systèmes distribués.  L’architecture orientée services représente un moyen technique d’intégration des divers systèmes d’information de l’entreprise considérant chaque ressource informatique comme un service. Elle permet de construire les « buildings blocks » qui composeront l'urbanisme du système d'information.

Tout système distribué repose sur 1) un faible couplage entre services (autonomie de déploiement, d’exécution, couplage entre composants), 2) un contrat de services (partage du format de communication), 3) une composition de services (un ensemble de services peut composer un service de haut-niveau) et 4) la découverte de services (annuaire centralisé, interrogeable, permettant d’orchestrer les différents services d’un système).

La notion d’interface est importante dans l’approche orientée services. Elle représente le point d’entrée unique vers les fonctionnalités de la solution logicielle et assure la communication grâce à l’échange de messages. Chaque message est porteur de la sémantique particulière à la solution logicielle. De plus, ce message est rédigé dans un langage compréhensible aux composants intéressés.

Le découplage fonctionnel et technique permet quant à lui d’améliorer le « time-to-market » dans la maintenance, puisqu’il permet de cibler des fonctionnalités.

Chaque service étant autonome, il est possible de le faire évoluer indépendamment des autres. Alors qu’une application monolithique doit être entièrement redéployée, pour toute évolution, seul le service à modifier sera concerné dans une application à base de services.

Aligner métiers et technique, la seule méthode

En matière de méthodes de travail, on dénombre trois approches quand on parle d’architecture distribuée. Le Domain Driven Development permet dans le cas d’une distribution fonctionnelle, l’alignement du métier et de la technique sur les concepts de contexte borné, entre autres. Celles des équipes autonomes à responsabilité identifiée se concentre sur un seul domaine (service, dans notre cas). Une des dérives constatées est d’avoir des équipes s’occupant du système dans son ensemble. Des risques de factorisation prématurée et de perte d’autonomie des services sont alors réels. Finalement, le système de l’architecture émergente nécessite une distribution à priori volumineuse. De ce fait, les grandes décisions de conception et d’architecture doivent se faire le plus tard possible. Il est important de suivre les incréments architecturaux comme n’importe quel autre incrément de valeur. On constate alors que peu importe la problématique de l’entreprise, l’une de ces trois approches peut être activée pour accompagner le porteur de projet vers une organisation en architecture distribuée.

Réduire la complexité pour assurer l’évolution du système

Plusieurs éléments techniques sont à prendre en considération afin de garantir le succès d’un projet basé sur un système distribué. La mise en place d’un identifiant de corrélation permet de tracer toutes les interactions entre services, de l’appel initial à la réponse finale. Ensuite, le fait d’agréger les logs permet, à l’aide d’un identifiant de corrélation, d’obtenir une vue complète et simple afin de répondre à la question : que s’est-il passé sur mon système ? Le monitoring du système dans son ensemble constitue également un critère essentiel. Bien que composé de services, à priori autonomes, le monitoring peut se faire à titre individuel (service) et sur l’ensemble du système. Finalement, le système doit être déployé dans son environnement à l’aide d’outils permettant d’orchestrer par exemple la scalabilité, la disponibilité, ceci afin de simplifier au maximum l’exploitation de ces types d’architecture.

Retours d’expérience : assurer une vision globale

La transition d’architectures classiques (type monolithe) vers des architectures distribuées comporte une montée en compétences qui n’est de loin pas que technique (hardskills). Les éléments suivants doivent impérativement être maitrisés. Si la responsabilité globale d’un service n’est pas clairement comprise en termes de responsabilité et d’isolation fonctionnelle, des biais cognitifs (surtout culturels) apparaissent. Une tendance à la factorisation intra-service et la création de couplage en découle. De plus, si les engagements d’une équipe sont dispersés entre plusieurs services (et donc plusieurs responsabilités) l’architecture résultante sera couplée (p.ex. réalisation à la fois de contrat et de consommateurs du contrat). Trouver la bonne façon de découper l’application est importante et n’est pas aisé. Si la granularité est trop petite, la complexité globale peut devenir plus grande que celle d’une application monolithique.

La loi de Conway, qui stipule que les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation, s’applique particulièrement bien aux systèmes distribués. On constate ensuite que les mêmes problématiques se rencontrent au niveau de l’industrialisation du système. La construction du produit est souvent vue de manière globale, ce qui aboutit à des systèmes de construction complexe.

La perte de vision globale du système est certainement le problème le plus critique que l’on a pu constater. Portée par le code et sa structure, la documentation se doit être la plus vivante possible et l’état du système doit être prédictif. Tout cela ne sera rendu possible que par les points cités plus haut (logging, monitoring centralisé, identifiant de corrélation). La responsabilité du système dans son ensemble (la solution) doit également être découplée de la responsabilité de l’architecture logicielle. Pour se faire, nous recommandons une démarche, nécessaire même si elle n’est pas toujours aisée, de testabilité. Il y a lieu de clairement définir les stratégies et niveaux de tests en amont. On ne testera pas un service comme on testera le système dans son ensemble. Le risque ici est que l’infrastructure de test aboutisse à « une usine à gaz », impactant le travail de développement et d’industrialisation du produit. L’expérience montre que la stratégie de tests devrait intervenir très tôt dans la conception, et potentiellement raffinée au fur et à mesure de l’évolution du système et de ses composants.

Pour conclure, l’expérience a démontré que dès la conception d’un système distribué, deux principes guident tout le processus : la simplicité et le pragmatisme. La complexité inhérente des systèmes distribués impose des réponses simples et adaptées au besoin et au contexte du système.

L’importance de soutenir le besoin est la nature même du choix d’un système distribué.

Par Thierry Bouvet, Solution Architect