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.
- 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.
- 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.
- 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.
- 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é.
- 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.
- 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).
- 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.
- 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).
- 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).
- 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.
- 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.
- 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).
- 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).
- 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.
- 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.
- 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).