Comment choisir l’architecture logicielle idéale grâce aux Architectural Drivers ?

Le Craftsmanship, dans le développement logiciel, est l’art de créer des solutions de haute qualité, fiables et maintenables. Un aspect essentiel de ce processus est le choix d’une architecture adaptée à votre projet.

Le choix de la bonne architecture logicielle est un élément crucial pour le succès de votre développement. Cependant, avec la multitude de choix disponibles, il peut être difficile de savoir par où commencer. C’est là que les “Architectural Drivers” entrent en jeu pour nous offrir une méthodologie pour guider cette décision.

Dans cet article, nous allons explorer comment choisir entre deux des architectures populaires qui ont suscité beaucoup d’intérêt et de débats dans la communauté des développeurs :  les microservices et les modèles monolithes modulaires, en utilisant les Architectural Drivers.

Nous allons examiner les facteurs clés tels que la performance, la scalabilité, la sécurité et la maintenabilité, et expliquer comment ils peuvent aider à prendre des décisions éclairées.

Comprendre les Architectural Drivers

Les Architectural Drivers sont des éléments clés qui aident à façonner l’architecture d’un système. Ils représentent les exigences et les contraintes du projet qui ont un impact significatif sur la structure globale du système.

Les “Architectural Drivers” peuvent être regroupés en quatre catégories :

• Les besoins fonctionnels : ce sont les fonctionnalités et les capacités attendues du système. Ils décrivent ce que le logiciel doit faire pour répondre aux exigences métier. Par exemple, les besoins fonctionnels incluent les processus métier, les interfaces utilisateur et les interactions avec d’autres systèmes.
• Les contraintes et les préférences : il s’agit des limitations dans lesquelles le système doit fonctionner, telles que le budget, le temps, les ressources ou les exigences réglementaires.
• Les contraintes et préoccupations techniques : ce sont les contraintes liées à l’environnement technique dans lequel le système sera déployé et maintenu. Les exigences techniques peuvent inclure des aspects tels que les plateformes matérielles et logicielles, les normes de codage, les protocoles de communication, et les modalités d’intégrations avec d’autres systèmes tiers.
• Attributs de qualité : les attributs de qualité sont les exigences non fonctionnelles qui décrivent la manière dont le système exécute ses fonctions. Cela peut inclure des facteurs tels que la fiabilité, l’évolutivité, la maintenabilité, la sécurité, l’accessibilité et les performances. Identifier et hiérarchiser les attributs de qualité souhaités aide à garantir que l’architecture du système est capable de répondre à ces exigences.

Les “Architectural Drivers” jouent un rôle essentiel dans la sélection de l’architecture logicielle la plus adaptée à vos besoins, car ils permettent de dresser un cadre pour soutenir la prise de décisions lors des phases de conception et de mise en œuvre d’un système. Ils permettent d’assurer que l’architecture du système reste alignée sur son objectif prévu :

• Alignement avec les objectifs de l’entreprise : une architecture doit répondre aux besoins fonctionnels et non fonctionnels du projet. Elle permet d’assurer que le système développé répondra aux attentes des parties prenantes et contribuera aux objectifs de l’entreprise.
• Adaptabilité face aux changements futurs : une architecture conforme aux “Architectural Drivers” facilite la prévision des évolutions potentielles du système, et permet de sélectionner une architecture capable de s’adapter aux modifications des exigences fonctionnelles et techniques.
• Cohérence et maintenabilité du code : considérer les “Architectural Drivers” lors du choix de l’architecture garantit une structuration cohérente et une maintenance aisée du code, simplifiant ainsi les mises à jour et les adaptations futures.

Il est donc important de réfléchir soigneusement aux choix que l’on fait en matière d’architecture logicielle, en pesant les avantages et les inconvénients de chaque option, en conciliant les besoins fonctionnels et non fonctionnels avec les contraintes et les préférences du projet et des parties prenantes. Des compromis sont nécessaires, et il est vital d’identifier la ou les solution(s) la/les plus appropriée(s) pour chaque situation.

Comprendre l’architecture microservices : définition, avantages et défis

Qu’est-ce que l’architecture microservices ?

L’architecture microservices est un modèle d’architecture logicielle qui organise une application en un ensemble de services indépendants. Chaque service est responsable d’une fonctionnalité spécifique et communique avec les autres services via des interfaces bien définies dites API (Application Programming Interface).

Elle repose sur quelques principes fondateurs qui permettent de construire des systèmes évolutifs, flexibles et résilients :

• Le découplage des services : les microservices peuvent être développés et déployés indépendamment les uns les autres, ce qui permet de travailler sur une partie du système sans perturber les autres services.
• Une meilleure granularité : les microservices sont des unités indépendantes pouvant être développées, déployées et mises à l’échelle individuellement.
• Une responsabilité unique : chaque microservice est responsable d’une seule mission : il s’agit du « S » de la méthode SOLID. Il doit ainsi fournir un ensemble cohérent de fonctionnalités, dans le but d’accomplir cette mission.
• L’interopérabilité : les microservices communiquent entre eux via des protocoles standardisés et indépendants de la technologie utilisée, facilitant ainsi l’intégration et la communication entre les services.

Cette architecture a émergé pour répondre aux besoins croissants des entreprises en matière de systèmes logiciels de plus en plus complexes, évolutifs, résilients et flexibles :

• Scalabilité et évolutivité : les microservices peuvent être redimensionnés indépendamment les uns les autres. Cela implique l’ajustement de la capacité de chaque service en fonction de l’évolution de la charge de travail ainsi que les ressources allouées au développement et à la maintenance qui peuvent être ajustées de manière indépendante en fonction de l’évolution des besoins métiers.
• Flexibilité technologique : chaque microservice peut être développé, testé et déployé en utilisant des langages de programmation et des technologies différentes, ce qui permet de choisir les outils et les processus les mieux adaptés pour chaque service (langage de programmation et framework, modèle de base de données, techniques et approches DevOps, CI/CD, etc.).
• Résilience : les microservices doivent être conçus de manière à ce que les erreurs ou les problèmes de performance affectant l’un d’entre eux ne se propagent pas aux autres services, garantissant ainsi une meilleure résilience globale du système.

“Microservices are not a silver bullet to solve all your problems. They solve certain problems while introducing others.”

Martin Fowler

Les inconvénients de l’architecture microservices

En effet, bien que l’architecture microservices offre de nombreux avantages, elle peut également présenter des défis (une manière plus juste pour décrire les inconvénients d’une architecture logicielle) en termes de conception, notamment pour la coordination et la gestion des différents services :

• Un potentiel re-passage par la case « Complexité » : la gestion d’un grand nombre de microservices peut entraîner une complexité accrue, tant au niveau du développement que de la gestion de l’infrastructure.
• Latence : les communications entre les microservices peuvent introduire une latence supplémentaire, notamment en raison de la sérialisation et de la désérialisation des données.

“Networks are not reliable. Packets get lost. Connections are severed. Yet they work.” – Dave Piscitello, expert en sécurité informatique.

• Déploiement et gestion : le déploiement et la gestion des microservices nécessitent des outils et des compétences spécifiques, tels que les conteneurs, les orchestrateurs et les API Gateways.
• Sécurité : la sécurisation des communications entre les microservices, et la gestion des accès peuvent être plus complexes et nécessitent une attention particulière.

Dans la partie suivante, nous aborderons l’architecture des monolithes modulaires et en discuterons les avantages et les inconvénients en comparaison avec l’architecture microservices.

Comprendre l’architecture monolithe modulaire : définition, avantages et défis

Définition de l’architecture monolithique modulaire

L’architecture monolithique modulaire est une approche architecturale qui organise une application en un système unique divisé en plusieurs modules. Chaque module est responsable d’une fonctionnalité spécifique et communique avec les autres modules au sein d’un monolithe.

“The modular monolith offers the advantages of modularity without the distributed-systems complexities.”

Martin Fowler

Les principes clés d’une architecture monolithe modulaire sont :

• La modularité, la voie de l’encapsulation : les monolithes modulaires sont conçus pour être composés de modules indépendants qui encapsulent une fonctionnalité spécifique et interagissent les uns avec les autres via des interfaces claires.
• La cohésion : les modules d’un monolithe modulaire doivent être fortement cohésifs, c’est-à-dire qu’ils doivent contenir des éléments liés à un seul domaine fonctionnel ou à une seule responsabilité.
• Un couplage faible, mais pas inexistant : les modules d’un monolithe modulaire doivent être faiblement couplés, c’est-à-dire qu’ils doivent minimiser les dépendances entre eux et favoriser l’indépendance.
• Intégration : les modules d’un monolithe modulaire sont intégrés au sein d’une seule base de code, et partagent le même cycle de développement, de déploiement et d’exécution.

Avantages d’un monolithe modulaire

Les avantages que peut nous apporter un monolithe modulaire  sont les suivants :

• Simplicité : les monolithes modulaires sont généralement plus simples à développer et à déployer que les microservices, car ils nécessitent moins d’outils et d’infrastructure.
• Performance : les communications entre les modules au sein d’un monolithe sont généralement plus rapides que celles entre les microservices, car elles ne nécessitent pas de communication réseau.
• Gestion : les monolithes modulaires peuvent être plus faciles à gérer, car ils ne nécessitent pas de gérer de multiples instances de services et d’orchestrer leur interaction.
• Testabilité : les tests unitaires et d’intégration peuvent être plus simples dans un monolithe modulaire, car ils n’impliquent pas de communications interservices.

Inconvénients du monolithe modulaire

Cependant, et comme toute architecture, un monolithe modulaire ne fournit pas de réponse fiable à certains problèmes, notamment :

• Scalabilité : la mise à l’échelle des monolithes modulaires est moins flexible que celle des microservices, car elle concerne le système dans son ensemble plutôt que sur un service ou un module particulier.
• Flexibilité technologique : étant intégrés dans un seul codebase, les monolithes modulaires peuvent limiter la diversité des technologies utilisées pour chaque module.
• Résilience : du fait que les modules d’un monolithe modulaire sont intégrés dans un seul codebase et partagent le même cycle de déploiement et d’exécution, les erreurs ou les problèmes de performance dans un module peuvent avoir un impact sur l’ensemble du système, ce qui réduit la résilience globale.

Dans les sections suivantes de cet article, nous comparerons les deux styles d’architectures en fonction des « Architectural Drivers » et expliquerons comment choisir l’architecture la plus adaptée à votre projet.

Architecture microservices et monolithique modulaire : comparaison en fonction des “Architectural Drivers”

Après avoir étudié les architectures microservices et monolithique modulaire, nous allons nous pencher sur les « Architectural Drivers » dans l’optique de faire un choix.

Pour ce faire, commençons par identifier les facteurs clés qui peuvent influencer notre décision de la conception du nouveau système et peuvent avoir un impact significatif sur ses qualités et ses performances.

Le tableau ci-dessous résume les principales distinctions entre les architectures microservices et monolithiques modulaires en tenant compte des divers critères issus des Architectural Drivers, tels que la scalabilité, les compétences techniques requises, ainsi que les coûts financiers potentiels associés à l’infrastructure, et met également en évidence un certain nombre d’inconvénients pour ces architectures, tels que la complexité des tests d’intégration, la gestion des dépendances, la gestion des infrastructures, le déploiement et l’adaptabilité à la croissance.

Remarque : Ce tableau peut être utilisé comme un outil de comparaison rapide pour identifier les forces et les faiblesses de chaque architecture en fonction des différents facteurs.

Le second tableau ci-dessous offre une comparaison détaillée entre les architectures microservices et les architectures monolithiques modulaires en termes de réponse à certains critères de sélection tels que la scalabilité, la complexité, la fiabilité, la résilience, la flexibilité et l’évolutivité :

Remarque : Veuillez noter que certains éléments liés aux architectures microservices et monolithiques modulaires n’ont pas été détaillés dans cette explication, car l’objectif est de présenter la démarche générale plutôt qu’une liste exhaustive de facteurs. Vous pouvez également prendre en compte d’autres éléments tels que le temps de développement et de déploiement, ainsi que la communication et l’intégration interfonctionnelle (module vs service) dans votre analyse.

Comment choisir une architecture : méthode de prise de décision

Pour choisir une architecture adaptée à un projet donné, il est possible de suivre une approche générale afin de faciliter la prise de décision. Cette approche peut être affinée par la suite en fonction de l’évolution des besoins et du niveau d’analyse souhaité.

Voici une proposition d’approche en six étapes :

1. Identifier les Architectural Drivers du projet, qui en définissent les besoins et les exigences fonctionnelles et non fonctionnelles.
2. Identifier et évaluer différents types d’architectures en examinant les avantages et les inconvénients de chacun d’entre eux.
3. Identifier et hiérarchiser les facteurs de sélection en fonction des Architectural Drivers du projet, en fonction de leur impact sur le projet.
4. Évaluer les ressources disponibles, telles que la taille de l’équipe de développement, les compétences et l’expertise des membres de l’équipe, ainsi que les outils et les technologies disponibles.
5. Identifier et évaluer les risques associés à chaque architecture pour déterminer leur impact potentiel sur le projet.
6. Utiliser toutes les informations collectées pour prendre une décision éclairée sur l’architecture la plus adaptée au projet.

Compléments essentiels à une bonne architecture logicielle

Adopter les bons réflexes et la bonne approche pour le choix d’une architecture logicielle adaptée à votre projet est essentiel, mais cela ne garantit pas à lui seul la réussite de votre projet. Il est recommandé d’accompagner cette approche par quelques considérations pour maximiser les chances de réussite de votre projet et garantir la qualité et la pérennité de votre architecture logicielle :

1. Revues et évaluations régulières de l’architecture : il est essentiel de réaliser des revues et des évaluations régulières de l’architecture pour s’assurer qu’elle répond toujours aux exigences actuelles et futures. Ces revues permettent d’identifier les axes d’amélioration, les problèmes potentiels et les opportunités d’optimisation.
2. Utilisation de métriques et d’outils de surveillance : adopter ces pratiques peut aider à comprendre les performances de l’architecture, à identifier les goulots d’étranglement et à apporter les modifications nécessaires pour l’améliorer. Des outils tels qu’Azure Monitor, Application Insights et Azure Log Analytics peuvent fournir des informations précieuses sur l’état et les performances du système.
3. Documentation des décisions et justifications architecturales : cette documentation consiste à consigner les choix et les raisons qui ont conduit à la conception et à l’évolution d’une architecture logicielle. Cette documentation est cruciale pour garantir la compréhension et le suivi des choix effectués, ainsi que pour assurer la qualité et la pérennité de l’architecture. Elle doit être maintenue à jour et accessible à tous les membres de l’équipe pour réduire les risques d’incompréhension et d’erreurs lors de la maintenance ou de l’évolution du système.
4. Adopter les bonnes pratiques de développement : il est important d’adopter des bonnes pratiques de développement, telles que le “Clean Code” et les principes SOLID, pour garantir un code de qualité, facile à maintenir et évolutif. Les modèles de conception (ou patrons de conception) peuvent être utilisés pour accompagner la mise en œuvre de l’architecture logicielle et en faciliter l’implémentation.
5. Testing : la mise en place d’une politique de tests rigoureuse est essentielle pour garantir la qualité et la pérennité de votre architecture logicielle et la fiabilité de votre application. Les tests unitaires, les tests d’intégration et les tests de charge permettent de s’assurer que chaque composant logiciel fonctionne correctement, et que l’ensemble du système est cohérent et performant. Des tests de sécurité peuvent être réalisés pour identifier et corriger les vulnérabilités de sécurité de l’application, ce qui contribue à la protection de votre application contre les attaques malveillantes.
6. Automatisation CI/CD : l’automatisation de ces processus permet de détecter rapidement les problèmes de code et de les corriger avant qu’ils ne deviennent des problèmes majeurs. L’automatisation permet également de réduire les risques de déploiement et d’optimiser les délais de mise à jour en permettant des déploiements plus rapides et plus réguliers.

En tenant compte de ces éléments clés, vous maximisez les chances de réussite de votre projet et garantissez la qualité et la pérennité de votre architecture logicielle.

Architecture logicielle : l’essentiel à retenir

L’architecture logicielle est un élément fondamental pour le développement de logiciels de qualité, performants, évolutifs et maintenables. Les décisions prises lors de la phase de conception ont un impact significatif sur le succès du projet, et certaines d’entre elles peuvent être irréversibles ou entraîner de lourdes conséquences.

Il est donc crucial de prendre le temps nécessaire pour analyser les besoins et les contraintes du projet, évaluer les différentes options architecturales disponibles et sélectionner celle qui convient le mieux au contexte spécifique. L’utilisation d’une approche basée sur les Architectural Drivers favorise une prise de décision plus éclairée et structurée, en mettant l’accent sur les aspects essentiels du projet.

Il est également important de noter que l’architecture logicielle ne peut pas garantir à elle seule la qualité du logiciel. D’autres facteurs, tels que la qualité du code, la qualité des tests et la qualité de la documentation, sont également importants pour garantir la qualité du logiciel.

Le mot de la fin : il n’y a pas de solution unique pour tous les projets, et chaque projet aura des exigences et des défis uniques. Une évaluation continue de l’architecture est donc nécessaire pour garantir qu’elle reste adaptée aux besoins changeants du projet.

Vous souhaitez en savoir plus sur le Craftsmanship ? Retrouvez notre série d’articles du Mois du Craft :

• Le Craft est-il toujours d’actualité ?
• Comment crafter une infrastructure avec Terraform ?
• Craft et PowerShell : de la nécessité d’appliquer les pratiques de Software Engineering à l’architecture
• Les bonnes pratiques de tests unitaires PySpark
• Télémétrie : la garantie d’un code qui fonctionne
• Boostez la performance de vos applications avec Asyncio : un guide pratique pour les développeurs Python