> ## Documentation Index > Fetch the complete documentation index at: https://docs.arkatech.fr/llms.txt > Use this file to discover all available pages before exploring further. # Concepts d'architecture > Ce document décrit les architectures logicielles majeures, de la plus traditionnelle aux approches les plus modernes, en détaillant leurs principes, avantages, inconvénients et cas d'usage typiques. # Monolithe Le Monolithe représente une architecture où **toutes les fonctionnalités logicielles sont regroupées dans une seule base de code et un seul exécutable/déploiable**. Il s'agit d'une application unique, souvent couplée à une unique base de données. Monolithe **Caractéristiques Clés** * **Couplage Élevé :** Les composants sont fortement interdépendants ; une modification dans un module peut potentiellement affecter l'ensemble de l'application. * **Technologie Uniforme :** L'ensemble de l'application est généralement construit avec un seul langage de programmation, un seul framework, et un seul type de base de données. * **Processus Unique :** Un seul processus s'exécute pour l'ensemble du système. **Avantages** * **Simplicité Initiale :** Développement, test, et déploiement **initiaux** plus simples pour les petites applications ou les équipes peu nombreuses. * **Débogage Facile :** Le traçage des requêtes (stack trace) est aisé au sein d'un seul processus. * **Gestion Centralisée :** Une seule codebase à gérer. **Inconvénients** * **Difficulté de Mise à l'Échelle (Scaling) :** On ne peut mettre à l'échelle que l'intégralité de l'application, même si un seul composant (ex. : module de facturation) est sollicité. Cela gaspille des ressources. * **Lenteur des Déploiements :** Le moindre changement nécessite de re-déployer et redémarrer l'intégralité de l'application, ce qui entraîne un temps d'arrêt (downtime) plus long. * **Barrière Technologique :** Il est difficile d'adopter de nouvelles technologies pour une seule partie de l'application sans réécrire l'ensemble. * **Complexité à Long Terme (Big Ball of Mud) :** Avec la croissance, la base de code devient souvent trop grande et complexe à maintenir pour une grande équipe. **Cas d'Usage** * Applications très petites ou prototypes. * Projets avec des équipes de développement très réduites. # **Architecture Orientée Services (SOA)** La SOA est une approche où l'application est **décomposée en services plus grands, autonomes et réutilisables**. Ces services communiquent généralement via un **Enterprise Service Bus (ESB)**, un point de médiation centralisé. Download **Caractéristiques Clés** * **Services Granulaires (Moyens) :** Les services sont généralement plus grands que les microservices (par exemple, un service de "Gestion des Commandes" complet). * **ESB (Enterprise Service Bus) :** Un composant central pour la communication, la transformation de messages, le routage et l'orchestration des services. * **Réutilisation et Interopérabilité :** L'accent est mis sur l'interopérabilité entre applications d'entreprise hétérogènes. **Avantages** * **Réutilisation Améliorée :** Les services peuvent être consommés par plusieurs applications au sein de l'entreprise. * **Interoperabilité :** L'ESB gère la complexité de communication entre différents protocoles et formats de données. * **Indépendance Technologique :** Les services peuvent être construits avec différentes technologies, tant qu'ils respectent le contrat d'interface (souvent SOAP ou REST). **Inconvénients** * **Complexité de l'ESB :** L'ESB devient un point de défaillance unique (**Single Point of Failure**) et un goulot d'étranglement de performance s'il est mal géré. * **Coûts Élevés :** L'implémentation et la maintenance d'un ESB sont souvent coûteuses. * **Déploiement Centralisé :** Bien que les services soient séparés, l'architecture reste souvent centralisée autour de l'ESB. **Cas d'Usage** * Grandes organisations cherchant à intégrer des systèmes existants (Legacy) et de nouvelles applications. * Environnements nécessitant une médiation et une transformation de données complexes (finance, assurances). # Microservices Le modèle Microservices décompose une application en un ensemble de **services très petits, indépendants, chacun ayant sa propre base de données et géré par une petite équipe dédiée**. La communication se fait généralement via des APIs légères (REST, gRPC, ou Asynchrone via des files d'attente). Microservices **Caractéristiques Clés** * **Services Très Granulaires (Petits) :** Chaque service se concentre sur une seule capacité métier (le principe de responsabilité unique - *Single Responsibility Principle*). * **Déploiement Indépendant :** Chaque service peut être développé, testé, et déployé indépendamment des autres. * **Base de Données Par Service (Polyglot Persistence) :** Chaque service gère ses propres données, garantissant un couplage très faible. Cela permet d'utiliser la meilleure technologie de base de données pour chaque besoin (ex: MongoDB pour les profils, PostgreSQL pour les transactions). * **Équipes Autonomes (Two Pizza Team) :** Chaque service peut être maintenu par une petite équipe (idéalement, une équipe qui peut être nourrie par deux pizzas). **Avantages** * **Scalabilité Élevée :** Possibilité de mettre à l'échelle uniquement les services qui en ont besoin. * **Résilience/Tolérance aux Pannes :** La panne d'un service n'entraîne pas la panne de tout le système. * **Adoption Technologique (Polyglot Technology) :** Liberté d'utiliser la meilleure technologie (langage, framework) pour chaque service. * **Déploiement Rapide/Continu (CI/CD) :** Les mises à jour ne concernent qu'un petit service, ce qui permet un rythme de livraison très rapide et une réduction des risques. **Inconvénients** * **Complexité Opérationnelle :** Nécessite des outils sophistiqués pour le monitoring, le *logging*, le traçage distribué et la gestion d'un grand nombre de services (DevOps, Kubernetes). * **Gestion des Transactions Distribuées :** Les transactions qui couvrent plusieurs services (Saga Pattern) sont complexes à implémenter et à maintenir. * **Latence Réseau :** Communication entre services via le réseau, ce qui introduit une latence et des points de défaillance potentiels. **Cas d'Usage** * Applications très grandes nécessitant une mise à l'échelle massive (e-commerce, streaming). * Organisations avec plusieurs équipes autonomes travaillant sur des domaines métier différents. # **Serverless/FaaS (Function as a Service)** Le modèle Serverless, dont FaaS est la principale implémentation, permet aux développeurs de **déployer uniquement des fonctions de code courtes et sans état (stateless)**. L'intégralité de l'infrastructure d'exécution (gestion du serveur, mise à l'échelle, *patching*) est gérée automatiquement par le fournisseur Cloud (AWS Lambda, Azure Functions, Google Cloud Functions). Serverless **Caractéristiques Clés** * **Fonctions Éphémères :** Le code ne s'exécute que lorsque qu'il est déclenché par un événement (requête HTTP, nouveau fichier dans un *bucket* S3, message dans une file d'attente). * **Mise à l'Échelle Automatique et Instantanée :** La plateforme Cloud gère la mise à l'échelle de zéro à un grand nombre d'instances en fonction du trafic. * **Pas de Gestion de Serveur (Zero Server Management) :** Le développeur ne se soucie pas des machines virtuelles, des conteneurs ou des systèmes d'exploitation. * **Paiement à l'Usage :** Facturation uniquement pour le temps de calcul réel des fonctions (temps d'exécution et mémoire utilisée). **Avantages** * **Réduction des Coûts d'Opération :** Élimination des coûts d'infrastructure au repos (vous payez ce que vous utilisez, pas un serveur qui tourne 24/7). * **Délai de Mise sur le Marché (Time-to-Market) Accéléré :** Concentration exclusive sur la logique métier du code. * **Scalabilité par Défaut :** La mise à l'échelle est illimitée et gérée par le fournisseur Cloud. **Inconvénients** * **Vendor Lock-in (Dépendance au Fournisseur) :** Le code est étroitement lié aux API et services spécifiques du fournisseur Cloud (AWS, Azure, GCP). * **Cold Start :** La première requête à une fonction qui n'a pas été exécutée récemment (non "chaude") peut subir un délai de latence plus long le temps que l'environnement s'initialise. * **Complexité du Débogage Distribué :** Le débogage et le monitoring sont plus difficiles, car l'infrastructure est abstraite et gérée par le fournisseur. * **Limites d'Exécution :** Les fournisseurs imposent souvent des limites sur la durée d'exécution et la quantité de mémoire pour chaque fonction. **Cas d'Usage** * Traitement de données déclenché par des événements (redimensionnement d'images après un *upload*). * APIs et *backends* légers à trafic variable et imprévisible. * Automatisation de tâches planifiées (Cron jobs).