De Monolithe à Microservices : Comment c'est plus facile avec un Monolithe Modulaire?

Commencer avec un monolithe bien structuré, tel qu'un monolithe modulaire, peut grandement faciliter la transition vers des microservices. Avec le temps, à mesure que le système évolue et que les exigences changent, vous pourriez rencontrer des problèmes de mise à l'échelle ou des défis organisationnels nécessitant un passage aux microservices.

Voici un guide détaillé sur la manière d'aborder cette migration efficacement.

Découplage en Utilisant des Contextes Délimités (bounded contexts)

La première étape pour migrer d'un monolithe à des microservices consiste à identifier les contextes délimités (bounded contexts). Ces contextes représentent des parties cohérentes du domaine qui peuvent être extraites comme des services séparés.

En utilisant le Domain-Driven Design (DDD), vous pouvez identifier des contextes délimités qui définissent des limites explicites entre les modules et séparent les responsabilités. Ce processus garantit que les microservices sont concentrés sur un domaine problématique spécifique, ce qui facilite leur gestion et leur mise à l'échelle.

Avantages dans un Monolithe :

• Facilite la refactorisation et la correction des limites.
• Ajustements moins risqués sans les complexités des systèmes distribués.

Comment un Monolithe Modulaire Résout le Couplage

Un monolithe modulaire est essentiellement un système monolithique divisé en modules distincts, chacun avec son propre ensemble cohérent de fonctionnalités, entités de domaine et cas d'utilisation. Ces modules sont isolés les uns des autres, en particulier en ce qui concerne les dépendances de base de données et la communication entre les modules.

Principes Clés :

• Isolation de la Base de Données : Les modules ne peuvent pas partager de tables de base de données ni interroger directement les tables des autres modules.
• Communication par API Publique : Les modules exposent une API publique que d'autres modules peuvent appeler, garantissant un couplage faible et une indépendance.

Avantages :

• Extraction de Modules Plus Facile : Les modules étant déjà isolés, les extraire en microservices est simple.
• Réduction du Couplage : L'isolation logique ou physique de la base de données réduit les dépendances et le couplage entre les modules.

Communication Entre Modules

Communication Synchrone :

• Appels de Méthodes : Appels en mémoire simples et rapides.
• Inconvénients : Couplage fort ; si un module est indisponible, cela affecte les modules dépendants.

Communication Asynchrone :

• Messagerie : Les modules communiquent via un bus de messages, favorisant un couplage faible.
• Avantages : Haute disponibilité ; les modules n'ont pas besoin d'être disponibles simultanément.
• Complexité : Nécessite la gestion d'un courtier de messages (Message Broker).

Approche Préférée :

• Messagerie Asynchrone : Facilite la transition vers des microservices et maintient un couplage faible.

Ajout d'un Courtier de Messages

Introduire un courtier de messages permet la communication asynchrone entre les modules. Cependant, vous n'avez pas besoin de commencer avec un courtier de messages complet. Des outils comme MassTransit offrent des mécanismes de transport en mémoire qui sont rapides et adaptés à un processus unique.

Étapes :

• Commencer avec un Transport en Mémoire : Utiliser le transport en mémoire de MassTransit pour la simplicité et la rapidité.
• Évoluer vers un Courtier de Messages Réel : Configurer un mécanisme de transport différent en cas de montée en charge, sans changer votre code de messagerie.

But :

• Modules Faiblement Couplés : Facilite le fonctionnement indépendant des modules.
• Migration Simplifiée : La messagerie abstrait la communication, rendant le passage aux microservices sans couture.

Extraction de Modules vers des Microservices

Lors de la transition vers des microservices, vous pouvez extraire des modules du monolithe en services séparés. Cela implique de :

• Introduire un Proxy Inverse (reverse proxy) : Diriger le trafic entrant vers le service approprié, masquant l'architecture des microservices aux clients.
• Se Connecter au Bus de Messages : S'assurer que le nouveau microservice se connecte au bus de messages pour la communication, en utilisant le code de messagerie existant. Cela pourrait vous rappeler une architecture basée sur les événements.
• Remplacer les Appels Synchrones : Si des appels de méthode sont utilisés, les remplacer par des appels HTTP sur le réseau, en tenant compte de l'authentification et de la tolérance aux pannes.

Pattern : Suivre le modèle de Strangler Fig, en remplaçant progressivement des parties du monolithe par des microservices jusqu'à ce que l'ancien système soit complètement transformé.

Réflexions Finales

Le couplage est le principal défi lors de la transition d'un monolithe à des microservices. Aborder le couplage au niveau de la base de données et entre les composants dès le départ peut prévenir de nombreux problèmes. Un monolithe modulaire offre une approche structurée qui simplifie cette transition :

• Identifier et Définir des Contextes Délimités : Les utiliser comme limites au sein du monolithe.
• Assurer l'Isolation des Données : Utiliser des schémas ou des bases de données séparées pour les différents modules.
• Implémenter la Communication Asynchrone : Utiliser un courtier de messages pour un couplage faible.

En essence, construire un monolithe modulaire vous prépare à une migration plus facile et moins risquée vers des microservices. Cette approche aide à maintenir la vitesse de développement tout en assurant l'évolutivité et la flexibilité à mesure que le système évolue.

Restez à l'écoute pour une mise en œuvre pratique d'un monolithe modulaire dans les jours à venir. En attendant, j'espère que ce guide vous sera utile.

À demain !