Architecture monolithique : une unité déployable, une base de données
Architecture monolithique sur un canevas interactif : une application déployable avec des modules d'interface utilisateur, de logique métier et d'accès aux données, une base de données partagée et le plafond d'évolutivité qui en résulte.
Un monolithe est une application construite et déployée comme une seule unité : l'interface utilisateur, la logique métier et l'accès aux données s'exécutent tous dans un seul processus sur une base de données partagée, et la mise à l'échelle signifie la réplication de l'ensemble.
Architecture monolithique : une unité déployable, une base de données
Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.
Comment lire ce visuel
- Suivez la demande du client, à travers les trois modules, dans la base de données partagée, et revenez en arrière : un aller-retour à travers un processus.
- Les modules sont à l'intérieur de la bande « Application monolithique » car ils partagent un processus et un déploiement ; ce confinement est la définition d’un monolithe.
- La dernière case est la punchline : le chemin de mise à l'échelle est sur le côté, dupliquant l'ensemble de l'application.
Le chemin de la demande à travers un seul processus
"Le client envoie une demande" entre "La demande entre dans l'application déployable unique", puis "Le module d'interface utilisateur achemine et restitue", "Le module de logique métier la traite" et "Le module d'accès aux données interroge la base de données": le tout dans la seule voie "Application monolithique". Les trois modules sont dessinés empilés pour montrer qu'ils partagent de la mémoire, un processus et un déploiement : rien chez eux n'est déployable séparément.
La base de données partagée
"Une base de données partagée stocke tout" est la deuxième caractéristique déterminante du monolithe. Tous les modules lisent et écrivent le même schéma, ce qui rend les jointures et les transactions simples : c'est la raison pour laquelle un monolithe est si productif au début. Le cluster « Base de données » se situe en dehors de la bande d'application car il s'agit d'un processus distinct, mais il est partagé : le couplage réside dans le schéma dont dépend chaque module.
Le plafond évolutif
"La réponse revient via les mêmes modules" complète l'aller-retour, et "La mise à l'échelle signifie la réplication de l'ensemble de l'application" est le verdict. Une fonctionnalité occupée force l'intégralité de la base de code et son pool de connexions sur un autre serveur, gaspillant ainsi de la capacité sur les parties qui ne sont pas occupées. C’est cette inefficacité, et non une quelconque défaillance technique, qui finit par motiver la scission en microservices.
Relations et enseignements clés
- Tous les modules partagent un processus, une base de code et un déploiement : ce confinement est la définition.
- La base de données partagée couple chaque module à un seul schéma.
- Les demandes transitent par chaque module en un seul aller-retour : il n'y a pas d'appel de service distinct.
- La mise à l'échelle est grossière : l'ensemble de l'application est dupliqué, fonctionnalité occupée ou non.
- La vitesse de développement du monolithe est réelle ; le plafond d'échelle est ce qu'il échange.
Quand utiliser ce visuel
- Expliquer pourquoi l'application d'une équipe est difficile à faire évoluer même si elle est facile à développer.
- Enseigner le contraste qui rend les microservices compréhensibles : la scission n'a de sens que face au plafond du monolithe.
- Documenter la structure d'un système existant avant de planifier comment le décomposer.
Comment cela fonctionne
Renommez les modules dans votre base de code
Remplacez l'interface utilisateur, la logique métier et l'accès aux données par vos couches et modules réels, et ajoutez ceux qui manquent aux trois génériques.
Marquez les véritables goulots d’étranglement en matière de mise à l’échelle
Annotez la dernière case avec la fonctionnalité ou la requête réelle qui force votre mise à l'échelle et la capacité gaspillée en répliquant l'ensemble de l'application.
Dessiner les candidats à l'extraction
Ajoutez une limite en pointillés autour du module qui est le meilleur candidat pour devenir un service, avec une note sur le couplage qui devrait être supprimé.
Lien vers l'alternative aux microservices
Une fois les candidats à l'extraction marqués, créez un lien vers le visuel des microservices pour comparer l'architecture cible côte à côte.
Questions fréquentes
Qu'est-ce qu'une architecture monolithique ?
Un monolithe est une application dont l'interface utilisateur, la logique métier et l'accès aux données sont construits, déployés et mis à l'échelle comme une seule unité : une base de code unique produisant un seul artefact déployable, exécuté sur une base de données partagée. Le visuel montre la requête traversant les trois modules dans un seul couloir d'application, car ce confinement est la définition.
Pourquoi les équipes commencent-elles avec un monolithe ?
Parce que pour la plupart des équipes et pendant la majeure partie de la durée de vie d'une application, un monolithe constitue le moyen de livraison le plus rapide. Il n'y a pas de réseau entre les modules, le schéma partagé simplifie les jointures et les transactions, et le déploiement n'est qu'un artefact. L'encadré de base de données partagée du visuel le souligne clairement : l'échange ne devient négatif que lorsque la mise à l'échelle indépendante ou l'autonomie de l'équipe devient la contrainte contraignante.
Quel est le principal problème d’un monolithe ?
Le plafond évolutif et le couplage. La mise à l'échelle signifie la réplication de l'ensemble de l'application, de sorte qu'une fonctionnalité occupée gaspille de la capacité dans tout le reste, et chaque modification touche une base de code et un schéma dont tout le monde dépend. À mesure que l’équipe et la base de code se développent, ces deux effets ralentissent le déploiement et forcent la coordination : les conditions dans lesquelles les équipes commencent à extraire les services.
Comment un monolithe devient-il des microservices ?
Progressivement, en extrayant une capacité à la fois. La première étape consiste à identifier un module qui peut être autonome (ses propres données limitées), puis à lui donner sa propre base de données, une API et éventuellement un déploiement indépendant. L'étape candidate à l'extraction du visuel modélise exactement ceci : marquer le module, couper le couplage et diviser. L’erreur est de réécrire tout le monolithe d’un coup, ce qui explique l’échec des migrations.
Modifier ce visuel dans QueryChart (FlowJam)
Ouvrez ce canevas monolithique exact en tant que votre propre graphique, renommez les modules dans votre base de code et cartographiez votre goulot d'étranglement de mise à l'échelle.