Microservices vs Monolith : prendre la bonne décision en matière d'architecture

72 % des entreprises qui ont adopté les microservices prématurément signalent une complexité accrue sans avantages proportionnels. Le battage médiatique des microservices a conduit de nombreuses équipes à distribuer leur application sur des dizaines de services alors qu'un monolithe bien structuré les aurait servi mieux, plus rapidement et à moindre coût.

Ce guide fournit un cadre honnête pour choisir entre les architectures monolithiques et de microservices, y compris les approches hybrides qui sont souvent les plus pertinentes pour les entreprises en croissance.

Points clés à retenir

 - Commencez avec un monolithe, sauf si vous avez un besoin spécifique et avéré de mise à l'échelle ou de déploiement indépendant.

• La taille de l'équipe est le meilleur indicateur du succès des microservices : minimum 3 ingénieurs par service
• Le modèle « monolithe modulaire » offre la plupart des avantages des microservices sans les frais opérationnels
• La migration du monolithe vers les microservices doit être incrémentielle, en extrayant un service à la fois

---

La comparaison honnête

Avantages du monolithe

Avantages des microservices

Coûts des microservices (souvent sous-estimés)

---

Le cadre décisionnel

Décision selon la taille de l'équipe

Décision en fonction des besoins

Décision en fonction des besoins de déploiement

---

Le monolithe modulaire : le meilleur des deux mondes

Un monolithe modulaire organise le code en modules bien délimités au sein d'une seule unité déployable. Les modules communiquent via des interfaces définies, et non via un accès direct à la base de données.

Architecture

Single Deployment Unit
+---------------------------------------------------+
|  [Orders Module]  [Inventory Module]  [Users Module] |
|       |                  |                 |        |
|       +------ Internal API Layer ----------+        |
|       |                  |                 |        |
|  [Orders DB]   [Inventory DB]    [Users DB]          |
|       |                  |                 |        |
|       +------ Shared Database Server ------+        |
+---------------------------------------------------+

Modèle de monolithe modulaire NestJS

// orders/orders.module.ts
@Module({
  imports: [
    InventoryModule, // Explicit dependency declaration
    UsersModule,
  ],
  controllers: [OrdersController],
  providers: [OrdersService],
  exports: [OrdersService], // Controlled public interface
})
export class OrdersModule {}

// inventory/inventory.module.ts
@Module({
  controllers: [InventoryController],
  providers: [InventoryService],
  exports: [InventoryService], // Only expose what others need
})
export class InventoryModule {}

Règles du module :

1. Les modules communiquent via des services exportés, jamais via un accès direct à la base de données
2. Chaque module possède exclusivement ses tables de base de données
3. Les données partagées sont accessibles via des méthodes de service, et non via des JOINs au-delà des limites du module.
4. Les dépendances du module sont explicites dans le tableau imports

Quand extraire un module dans un service

Extraire quand :

• Le module doit évoluer indépendamment (par exemple, traitement d'image, recherche)
• La fréquence de déploiement du module diffère considérablement du reste
• Le module est maintenu par une équipe distincte
• Le module a des exigences technologiques différentes (par exemple, modèle ML en Python)

Ne PAS extraire lorsque :

• "On dirait que ça devrait être un service"
• Vous souhaitez une architecture plus propre (refactorisez plutôt le monolithe)
• Vous n'avez pas identifié de besoin spécifique de mise à l'échelle ou de déploiement

---

Stratégie de migration : du monolithe vers les microservices

Le motif de la figue étrangleur

Remplacez progressivement les fonctionnalités monolithiques par des microservices, en acheminant le trafic vers le nouveau service tandis que l'ancien code reste comme solution de secours.

Étape 1 : Identifiez le candidat à l'extraction (besoin de mise à l'échelle ou friction de déploiement le plus élevé)

Étape 2 : Créez le nouveau service aux côtés du monolithe

Étape 3 : Acheminer le trafic vers le nouveau service via la passerelle API

Étape 4 : Vérifiez l'exactitude en exécutant les deux en parallèle

Étape 5 : Supprimez l'ancien code du monolithe

Considérations sur la migration des données

Recommandation : Commencez par une base de données partagée lors de la migration, puis passez à une base de données par service une fois les limites du service prouvées.

---

Exemples d'architecture du monde réel

Plateforme de commerce électronique

Modular Monolith (recommended for most):
- Product catalog module
- Cart and checkout module
- Order management module
- User accounts module
- Inventory module
All in one deployable unit, backed by one PostgreSQL instance.

Selective Microservices (for high-traffic stores):
- Search service (Elasticsearch, scales independently)
- Image processing service (CPU-intensive, different scaling)
- Payment service (PCI compliance boundary)
Everything else stays in the monolith.

Système ERP (style Odoo)

Monolith is the correct choice for ERP:
- Deep cross-module data relationships
- Complex business rules spanning modules
- Consistent reporting across all data
- Smaller concurrent user counts
- Transactional consistency critical

Odoo itself is a modular monolith: modules are installed/uninstalled,
but everything runs in one process with one database.

---

Questions fréquemment posées

Notre monolithe nous retient-il ?

Probablement pas, à moins que vous ayez des preuves de goulots d'étranglement spécifiques. Si les déploiements sont lents, investissez dans CI/CD. Si un composant doit évoluer, extrayez-le. Si les équipes se marchent les unes sur les autres, imposez les limites des modules. La plupart des « problèmes monolithiques » sont en réalité des problèmes d'organisation du code que les microservices ne résoudraient pas : ils se contenteraient de les distribuer.

Combien de microservices est-ce trop ?

Une limite pratique : pas plus de 3 à 5 prestations par ingénieur chargé des opérations. Une équipe de 5 ingénieurs ne doit pas posséder plus de 15 à 25 services. Au-delà de cela, les frais opérationnels dominent et la vitesse d’ingénierie diminue. De nombreuses entreprises prospères gèrent 5 à 10 services bien définis plutôt que des centaines de nanoservices.

Pouvons-nous utiliser différentes bases de données pour différents modules dans un monolithe ?

Oui, c'est l'approche monolithique modulaire. Chaque module peut utiliser un schéma distinct ou même une instance de base de données distincte au sein de la même unité déployable. Cela préserve les limites de propriété des données sans le coût opérationnel de services distincts. Cela facilite également les extractions futures.

Comment ECOSIRE aborde-t-il cela pour les clients ?

Nous recommandons de commencer par un monolithe modulaire pour la plupart des clients. Nos services de mise en œuvre Odoo utilisent l'architecture modulaire d'Odoo et nos projets de développement personnalisés suivent le modèle monolithique modulaire NestJS. Nous extrayons les services uniquement lorsqu'il est avéré qu'une mise à l'échelle indépendante est nécessaire – généralement une recherche, un traitement de fichiers ou des intégrations externes. Consultez notre guide DevOps pour connaître la philosophie architecturale complète.

---

Ce qui vient ensuite

Les décisions architecturales sont fondamentales. Une fois que vous avez choisi votre approche, investissez dans l'automatisation CI/CD pour un déploiement fiable, la surveillance pour une visibilité opérationnelle et dans les modèles de passerelle API pour gérer la communication de service à service.

Contactez ECOSIRE pour des conseils en architecture, ou explorez nos services de mise en œuvre Odoo pour une architecture ERP qui évolue avec votre entreprise.

---

Publié par ECOSIRE – aide les entreprises à choisir la bonne architecture pour leur stade de croissance.