Architecture des Systèmes d'Information - Cours 2 PDF

**Architecture des systèmes d\'information** **Cours 2** **Applications Monolithiques et Microservices** Introduction Le développement logiciel a évolué au fil des années, et avec lui les architectures utilisées pour construire des applications. Dans ce contexte, nous abordons deux approches pri...

**Architecture des systèmes d\'information** **Cours 2** **Applications Monolithiques et Microservices** Introduction Le développement logiciel a évolué au fil des années, et avec lui les architectures utilisées pour construire des applications. Dans ce contexte, nous abordons deux approches principales : les applications monolithiques et les microservices. Chacune de ces architectures présente des avantages et des limitations qui influencent leur choix en fonction des besoins d\'une organisation. Dans cette leçon, nous analyserons les caractéristiques de ces deux architectures, leurs avantages et inconvénients, ainsi que les défis liés à la gestion d'une architecture de microservices. 1\. Les applications monolithiques et leurs limitations Une application monolithique est une application logicielle à architecture monolithique, où différents modules ou composants sont combinés dans un seul programme, formant une application unique et centralisée. Cette approche a été largement utilisée par le passé avant l\'émergence des microservices. Avantages des applications monolithiques - Simplicité de déploiement : Une application monolithique est constituée d\'un seul bloc de code, ce qui rend son déploiement relativement simple. Il suffit de fusionner l\'ensemble du code et de le déployer comme une seule entité. - Complexité gérée : Dans une architecture monolithique, les services sont centralisés, ce qui facilite la gestion de la complexité. Les tests peuvent être effectués de bout en bout, ce qui permet une vérification cohérente de l\'application dans son ensemble. - Faible dépendance : Les monolithes ne partagent généralement pas d\'infrastructure complexe. Cela signifie qu\'il y a moins de dépendances externes, ce qui simplifie certaines opérations. Limitations des applications monolithiques - Scalabilité coûteuse : Bien qu\'il soit possible de mettre à l\'échelle une application monolithique, cette opération est souvent coûteuse en termes de délais et d\'infrastructure. Si le code de l'application est trop volumineux ou mal conçu, la mise à l'échelle devient un véritable défi. - Fréquence des mises à jour : Dans un monolithe, toute mise à jour nécessite de redéployer l'application entière, même si seul un composant a été modifié. Cela empêche les déploiements continus et réduit la flexibilité. - Difficulté de retour arrière (rollback) : Si un composant de l\'application échoue après une mise à jour, il peut être difficile de revenir en arrière rapidement et en toute sécurité. Un rollback est souvent nécessaire, mais cela peut exposer l\'application à de nouveaux risques. - Taille et complexité : Au fur et à mesure que de nouvelles fonctionnalités sont ajoutées à une application monolithique, celle-ci tend à devenir de plus en plus grande et complexe. Cela peut aggraver les limitations de scalabilité et rendre l'application plus difficile à maintenir. 2\. Définition et propriétés des microservices Les microservices représentent une architecture où chaque service est une application indépendante, spécialisée dans une fonctionnalité ou un domaine spécifique. Contrairement à un monolithe, chaque microservice possède sa propre logique métier et son propre modèle de données. Caractéristiques clés des microservices - Modularité : Chaque microservice est conçu pour accomplir une fonction métier spécifique. Cela permet une approche modulaire de l\'application, où chaque module peut être développé, testé et déployé indépendamment. - Autonomie : Chaque microservice est autonome, ce qui signifie qu\'il peut être développé, déployé et mis à jour indépendamment des autres. Cette indépendance favorise la flexibilité et réduit les risques liés aux dépendances. - Décentralisation des données : Chaque microservice possède généralement sa propre base de données, garantissant ainsi une isolation des données et permettant une gestion plus fine des informations. Avantages des microservices - Scalabilité : Un des principaux avantages des microservices est la possibilité de scaler indépendamment les services en fonction des besoins. Plutôt que de faire évoluer l'ensemble de l'application monolithique, on peut scaler uniquement les services critiques, ce qui optimise l'utilisation des ressources. - Vitesse de développement : Avec des services plus petits et indépendants, les équipes peuvent travailler plus rapidement et déployer des fonctionnalités plus fréquemment. Chaque équipe peut se concentrer sur un microservice sans interférer avec les autres équipes. - Optimisation et compatibilité : Les microservices permettent d\'utiliser plusieurs technologies et langages de programmation différents pour chaque service. Cela permet d'optimiser chaque service en fonction de la technologie qui offre les meilleures performances ou la meilleure fiabilité pour une tâche donnée. - Isolation des pannes : Un échec dans un microservice n'entraîne pas la défaillance de l\'ensemble de l'application. Chaque service étant indépendant, les pannes peuvent être isolées et gérées sans perturber les autres services. 3\. Architecture décentralisée : Gouvernance et Catalogue de services Une des caractéristiques majeures de l\'architecture des microservices est la gouvernance décentralisée. Gouvernance décentralisée vs centralisée - Monolithes : La gouvernance est centralisée, ce qui signifie qu\'un seul processus contrôle le déploiement et la mise à jour de l'application dans son ensemble. - Microservices : Dans une architecture de microservices, chaque service a sa propre gouvernance. Chaque équipe de développement suit son propre calendrier de déploiement et ses propres priorités. Cela permet une plus grande souplesse et une gestion plus fine des mises à jour. Catalogue de services Le catalogue de services est un référentiel centralisé qui répertorie tous les microservices disponibles dans une organisation. Ce catalogue facilite la découverte, la réutilisation et la surveillance des services. C'est un outil essentiel pour gérer efficacement les microservices dans une organisation. 4\. Défis et pièges des microservices Bien que les microservices offrent de nombreux avantages, leur mise en œuvre n\'est pas sans défis : - Complexité accrue : La gestion des microservices est plus complexe que celle des applications monolithiques. Un catalogue de services bien structuré et une bonne gestion des services sont essentiels pour éviter que l'architecture ne devienne ingérable. - Transactions distribuées : Les transactions métier qui traversent plusieurs services nécessitent une synchronisation et une séquence précises. La gestion des rollbacks dans ce contexte peut être complexe et risquée. - Gestion de bout en bout, tests et surveillance : Les microservices nécessitent une gestion et une surveillance complexes. Les tests de bout en bout et la gestion des logs deviennent plus difficiles, car chaque service doit être testé indépendamment, tout en s'assurant que l'ensemble fonctionne correctement. Exemple notable : Netflix avec AWS Un exemple notable d'architecture de microservices à grande échelle est Netflix, qui utilise Amazon Web Services (AWS) pour gérer son infrastructure de microservices. Netflix a déployé des milliers de microservices pour gérer des aspects aussi variés que la gestion des utilisateurs, la recommandation de contenu et la gestion des paiements. **L\'Orientation Axée sur les Affaires et les Concepts Architecturaux Avancés** **Introduction** Dans le développement logiciel moderne, il existe diverses approches et modèles qui visent à améliorer la flexibilité, l\'évolutivité et la résilience des systèmes. Parmi ces approches, **le développement piloté par le domaine** (Domain-Driven Design, ou DDD) et certains **modèles architecturaux** tels que le **circuit breaker**, le **retry pattern** et le **event broker pattern** sont essentiels. Cette leçon se concentre sur l\'importance d\'aligner la conception logicielle avec les besoins métiers, ainsi que sur l\'application de certains modèles pour améliorer la gestion des erreurs et la communication entre composants. **1. Le Développement Piloté par le Domaine (DDD)** Le **Domain-Driven Design (DDD)** est une approche de développement logiciel qui vise à aligner la conception du logiciel avec le domaine métier. DDD repose sur une collaboration étroite avec les experts du domaine afin de créer un **modèle commun** qui représente les concepts et les règles métiers. **Principes clés de DDD** - **Langage commun** : DDD insiste sur l\'importance de créer un langage partagé entre les développeurs et les experts métiers. Ce langage est utilisé pour décrire les fonctionnalités, les concepts et les règles du domaine d'activité. - **Sous-domaines et Contextes Délimités** : DDD propose de diviser des systèmes complexes en **sous-domaines** et en **contextes délimités**. Un sous-domaine est une partie du domaine métier, tandis qu'un contexte délimité est une zone dans laquelle un modèle spécifique est appliqué. Cela permet de maintenir des systèmes flexibles et évolutifs tout en restant étroitement liés aux besoins métiers. - **Modèles métier** : L\'idée principale de DDD est de construire des modèles qui sont le reflet du **domaine métier**. Cela permet d\'avoir une application qui reste cohérente avec les règles et objectifs d'affaires tout au long de son développement. **Bénéfices de DDD** - Alignement direct entre les **besoins métiers** et la conception logicielle. - **Flexibilité et évolutivité** des systèmes complexes grâce à la délimitation des sous-domaines et des contextes. - Réduction de l'écart entre les équipes techniques et les experts métier grâce à un **langage partagé**. **2. Modèle Circuit Breaker** Le **Circuit Breaker** est un modèle de conception utilisé pour empêcher les échecs en chaîne dans un système distribué. Lorsque l\'un des services subit des échecs répétés, le **circuit** s\'ouvre, empêchant de nouvelles demandes vers ce service défaillant et laissant ainsi un temps pour la récupération du service. **Fonctionnement du Circuit Breaker** - **Ouverture du circuit** : Lorsqu\'un service échoue de manière répétée, le circuit s\'ouvre, ce qui bloque les requêtes et évite de surcharger un service en panne. - **Fermeture du circuit** : Une fois que le service a récupéré sa stabilité, le circuit se ferme et les requêtes normales peuvent être envoyées à nouveau. **Avantages du Circuit Breaker** - **Résilience** : Il améliore la résilience du système en évitant la propagation des erreurs à travers toute l\'application. - **Prévention de la surcharge** : Il évite de soumettre un service défaillant à des requêtes répétées, ce qui pourrait aggraver la panne. **3. Modèle Retry Pattern** Le **Retry Pattern** (modèle de nouvelle tentative) est une stratégie pour gérer les erreurs temporaires en réessayant une opération après un échec. Cette technique est couramment utilisée dans les systèmes distribués où des erreurs peuvent être intermittentes, comme les échecs de réseau. **Stratégies de Retry** - **Délai fixe** : Après chaque échec, une nouvelle tentative est envoyée après un délai fixe. Par exemple, une tentative de réessai pourrait être effectuée toutes les 100 millisecondes. - **Délai incrémental** : Le délai entre chaque tentative augmente progressivement à chaque échec. Par exemple, pour chaque nouvelle tentative, le délai pourrait être de 100 ms, 200 ms, etc. - **BackOff Exponentiel** : Le délai entre chaque tentative augmente de manière exponentielle. Par exemple, le délai pourrait être défini comme 100 \* 2\^(i-1) ms, où i représente le nombre de tentatives. **Avantages du Retry Pattern** - **Gestion des erreurs temporaires** : Permet de gérer les erreurs temporaires en réessayant une opération au lieu d'abandonner immédiatement. - **Flexibilité** : Différentes stratégies de délai peuvent être utilisées en fonction des besoins du système (délai fixe, incrémental ou exponentiel). **4. Modèle Event Broker** Le **Event Broker Pattern** est un modèle de conception dans lequel un intermédiaire, appelé **Event Broker**, gère et distribue les événements entre les producteurs (éditeurs d\'événements) et les consommateurs (abonnés à l\'événement). **Fonctionnement de l\'Event Broker** - **Routage des événements** : L\'Event Broker reçoit les événements des producteurs et les distribue aux consommateurs appropriés en fonction de règles comme les abonnements ou les sujets. - **Découplage** : Les producteurs et les consommateurs sont découplés, ce qui signifie qu\'ils n\'ont pas besoin de se connaître directement pour communiquer. - **Scalabilité** : Ce modèle permet d\'ajouter de nouveaux consommateurs sans affecter les producteurs ou le reste du système. **Avantages de l\'Event Broker** - **Découplage** : Les producteurs et les consommateurs sont indépendants, ce qui facilite l\'ajout ou la suppression de composants sans perturber l'ensemble du système. - **Scalabilité** : Le système peut facilement évoluer en ajoutant de nouveaux consommateurs qui recevront les événements sans interférer avec les autres parties du système. **Exemple d\'implémentation** Les systèmes de messagerie, comme **Kafka** ou **RabbitMQ**, utilisent souvent le modèle de l\'Event Broker pour distribuer des messages entre différents composants d\'une architecture distribuée. **Authentification, Autorisation et Modèles de Sécurisation Avancés** **1. Authentification vs. Autorisation** Dans le cadre de la sécurité des systèmes, **l\'authentification** et **l\'autorisation** sont deux processus distincts mais complémentaires, chacun ayant un rôle spécifique dans la gestion de l\'accès aux ressources d\'un système. **Authentification** L\'**authentification** est le processus par lequel un utilisateur prouve son identité, généralement en fournissant des informations d\'identification telles que des mots de passe, des tokens ou des informations biométriques (empreintes digitales, reconnaissance faciale, etc.). Elle permet de répondre à la question : **\"Qui êtes-vous ?\"** L\'authentification est cruciale pour garantir que seules les personnes autorisées peuvent accéder à un système donné. Sans ce processus, il serait impossible de savoir qui accède à quoi, rendant le système vulnérable. **Exemples de méthodes d\'authentification :** - **Mot de passe** : La méthode la plus courante et la plus simple, mais aussi la plus vulnérable si elle est mal gérée. - **Tokens** : Utilisation de clés ou de jetons d\'authentification temporaires pour valider l\'utilisateur, souvent utilisés dans des systèmes plus complexes comme les API. - **Biométrie** : Utilisation de caractéristiques physiques uniques de l\'utilisateur, telles que les empreintes digitales ou la reconnaissance faciale. **Autorisation** L\'**autorisation** intervient après l\'authentification et détermine **les droits d\'accès** d\'un utilisateur authentifié. Elle définit ce que l\'utilisateur peut faire dans le système ou quelles ressources il peut accéder. Elle répond à la question : **\"Que pouvez-vous faire ?\"** Par exemple, un utilisateur authentifié peut être autorisé à consulter des données sensibles, mais pas à les modifier, selon les rôles et permissions qui lui sont attribués. L\'autorisation peut être gérée par des mécanismes comme les **rôles** (utilisateur, administrateur, etc.) ou des **permissions spécifiques** (lecture, écriture, suppression, etc.). **Exemples de gestion de l\'autorisation :** - **Rôles d\'utilisateur** : Un système peut attribuer des rôles spécifiques à chaque utilisateur, par exemple \"Admin\" ou \"Utilisateurs standard\", avec des permissions différentes selon le rôle. - **Contrôles d\'accès basés sur les attributs (ABAC)** : Les permissions sont définies en fonction des attributs des utilisateurs, comme leur département ou leur niveau hiérarchique. **2. Les Modèles SSO, OAuth, et OIDC** Pour améliorer l\'expérience utilisateur et la gestion de la sécurité, plusieurs modèles sont utilisés, comme le **Single Sign-On (SSO)**, **OAuth 2.0** et **OIDC (OpenID Connect)**. Ces modèles facilitent l\'authentification et l\'autorisation à travers différentes applications et services tout en garantissant une sécurité renforcée. **SSO (Single Sign-On)** Le **Single Sign-On (SSO)** est un mécanisme qui permet à un utilisateur de s\'authentifier une seule fois pour accéder à plusieurs applications ou services. Cela évite à l\'utilisateur de devoir saisir à nouveau ses identifiants chaque fois qu\'il souhaite accéder à un service différent. Une fois connecté, l\'utilisateur bénéficie d\'une session unique qui lui permet d\'utiliser différentes applications sans se réauthentifier. **Avantages du SSO :** - **Simplicité d\'utilisation** : Un seul login pour plusieurs applications. - **Amélioration de la sécurité** : Moins de risques liés à la gestion de plusieurs mots de passe. **OAuth 2.0** Le protocole **OAuth 2.0** est un mécanisme d\'autorisation qui permet à des applications tierces d\'accéder à des ressources utilisateur sans exposer les informations d\'identification de l\'utilisateur. OAuth permet de déléguer l\'accès à certaines ressources tout en gardant le contrôle sur les informations sensibles. **Exemple de scénario avec OAuth 2.0 :** - Un utilisateur peut autoriser une application tierce (par exemple, une application de gestion de fichiers) à accéder à son compte Google Drive sans que l\'application n\'ait besoin de connaître son mot de passe. **Avantages d\'OAuth 2.0 :** - Permet d\'octroyer des **accès limités** aux données d\'un utilisateur. - Protège les **informations sensibles** des utilisateurs en évitant de partager leurs identifiants. **OIDC (OpenID Connect)** **OpenID Connect (OIDC)** est une couche d\'identité construite sur OAuth 2.0. Tandis qu\'OAuth s\'occupe de l\'autorisation, OIDC ajoute un composant d\'**authentification** en permettant de vérifier l\'identité de l\'utilisateur. Cela permet de garantir que l\'utilisateur est bien celui qu\'il prétend être, tout en gérant l\'accès aux ressources de manière sécurisée. **Exemple d\'utilisation d\'OIDC :** - Lorsqu\'un utilisateur se connecte à une application, l\'application peut utiliser OIDC pour obtenir des informations supplémentaires sur l\'utilisateur (par exemple, son nom, son adresse email) en plus de l\'authentification elle-même. **Résumé des différences :** - **SSO** = Un seul login pour accéder à plusieurs services. - **OAuth** = Autorisation d\'accès à des ressources sans exposer les identifiants de l\'utilisateur. - **OIDC** = Authentification (vérification de l\'identité de l\'utilisateur) + Autorisation (accès aux ressources). Une image contenant texte, diagramme, capture d'écran, conception Description générée automatiquement  **L\'importance du CI/CD et du DevOps** Le **CI/CD (Continuous Integration/Continuous Deployment)** et **DevOps** sont des pratiques essentielles pour automatiser le développement, les tests et le déploiement des logiciels. Elles permettent de livrer des applications plus rapidement, avec une meilleure qualité et une plus grande sécurité en favorisant la collaboration entre les équipes de développement et d\'exploitation. **1. CI/CD : Qu\'est-ce que c\'est ?** - **CI (Continuous Integration)** : Intégration continue où chaque modification de code est automatiquement testée. - **CD (Continuous Deployment/Delivery)** : Livraison continue où le code validé est déployé automatiquement en production, ou dans un environnement de pré-production. **2. Les avantages** - **Automatisation** des tests et du déploiement, réduisant les erreurs humaines. - **Amélioration de la qualité** grâce à des tests continus. - **Réduction du délai de mise sur le marché**. - **Meilleure collaboration** entre les équipes. **Exemple de CI/CD pour un Projet Java** Pour un projet Java : 1. **CI avec Jenkins** : Le code est intégré et testé automatiquement avec Jenkins dès qu\'un commit est effectué. 2. **Docker et Kubernetes** : Le code est empaqueté en Docker et déployé dans Kubernetes pour assurer une mise à l\'échelle et un test sur l\'environnement de pré-production. **CI/CD Complexe pour une Banque** Dans le contexte bancaire, le CI/CD devient plus complexe à cause des exigences de **sécurité** et de **conformité** : - **Sécurisation du pipeline** avec des méthodes d\'authentification renforcées et des tests de sécurité. - **Audit et traçabilité** pour garantir la conformité réglementaire. - **Haute disponibilité** avec des mécanismes de **rollback** et de **monitoring** en production pour assurer une continuité des services. **Outils de Journalisation Centralisée : ELK Stack et Fluentd** Les outils de journalisation centralisée, comme **ELK Stack** (Elasticsearch, Logstash, Kibana) et **Fluentd**, permettent de collecter, agréger, analyser et visualiser les logs des services d'une application. Ces outils sont essentiels pour la gestion des erreurs, la surveillance de la performance et la résolution des problèmes dans des environnements de production complexes. - **ELK Stack** : - **Elasticsearch** : Stocke et indexe les logs pour une recherche rapide. - **Logstash** : Collecte, filtre et transforme les logs avant de les envoyer à Elasticsearch. - **Kibana** : Permet la visualisation et l\'analyse des logs à travers des tableaux de bord interactifs. - **Fluentd** : Outil léger et flexible qui collecte et envoie les logs vers des systèmes variés, y compris Elasticsearch. **Importance des Logs pour le Diagnostic et la Résolution des Problèmes** Les logs sont essentiels pour : - **Diagnostiquer les problèmes** : Ils fournissent des détails sur les erreurs, exceptions et comportements anormaux. - **Résoudre les problèmes** : Ils aident à localiser et comprendre les pannes dans les systèmes distribués. - **Surveillance continue** : Les alertes et l'analyse en temps réel permettent d'identifier et résoudre rapidement les problèmes avant qu\'ils ne deviennent critiques. En résumé, ces outils facilitent la gestion des logs, permettant une résolution rapide des incidents et une surveillance proactive des systèmes. **Outils de Surveillance : Grafana et Splunk** **Grafana** est un outil open-source permettant de créer des tableaux de bord interactifs pour visualiser les données provenant de différentes sources (Prometheus, InfluxDB, etc.), offrant ainsi une observabilité en temps réel des performances et des événements systèmes. **Splunk** est une plateforme d'analyse de données qui collecte, indexe et visualise les logs et événements générés par les applications et systèmes IT, facilitant l'analyse pour la sécurité et les opérations IT. **Importance de l\'Observabilité** Ces outils permettent de collecter des **métriques**, d'envoyer des **alertes** en cas d'anomalies, et de suivre en temps réel les **performances** des systèmes pour garantir leur bon fonctionnement.