Architecture monolithique guide #1

Une architecture monolithique est le modèle unifié traditionnel pour la conception d’un logiciel d’entreprise. Monolithique, dans ce contexte, signifie composé d’un seul tenant. Selon le dictionnaire, l’ adjectif monolithique signifie « Qui forme un ensemble rigide, homogène. »

Le logiciel monolithique est conçu pour être autonome ; les composants du programme sont interconnectés et interdépendants plutôt que faiblement couplés comme c’est le cas avec les programmes logiciels modulaires. Dans une architecture étroitement couplée, chaque composant et ses composants associés doivent être présents pour que le code soit exécuté ou compilé.

De plus, si un composant du programme doit être mis à jour, l’ensemble de l’application doit être réécrit, alors que dans une application modulaire, tout module séparé (comme un microservice ) peut être modifié sans affecter les autres parties du programme. Les architectures modulaires réduisent le risque qu’un changement effectué dans un élément crée des changements imprévus dans d’autres éléments, car les modules sont relativement indépendants. Les programmes modulaires se prêtent également plus facilement aux processus itératifs que les programmes monolithiques.

Cependant, les architectures monolithiques présentent également des avantages . Les applications monolithiques ont généralement un meilleur débit que les approches modulaires, telles que l’architecture de microservices (MSA) et ils peuvent être plus faciles à tester et à déboguer car, avec moins d’éléments, il y a moins de variables qui entrent en jeu.

Le contexte

Vous développez une application d’entreprise côté serveur. Il doit prendre en charge une variété de clients différents, notamment les navigateurs de bureau, les navigateurs mobiles et les applications mobiles natives. L’application peut également exposer une API à consommer par des tiers. Il peut également s’intégrer à d’autres applications via des services Web ou un courtier de messages. L’application gère les requêtes (requêtes et messages HTTP) en exécutant la logique métier ; accéder à une base de données ; échanger des messages avec d’autres systèmes ; et renvoyer une réponse HTML/JSON/XML. Il existe des composants logiques correspondant à différents domaines fonctionnels de l’application.

Problème

Quelle est l’architecture de déploiement de l’application ?

Les forces

• Une équipe de développeurs travaille sur l’application
• Les nouveaux membres de l’équipe doivent rapidement devenir productifs
• L’application doit être facile à comprendre et à modifier
• Vous souhaitez pratiquer le déploiement continu de l’application
• Vous devez exécuter plusieurs instances de l’application sur plusieurs machines afin de répondre aux exigences d’évolutivité et de disponibilité
• Vous souhaitez profiter des technologies émergentes (frameworks, langages de programmation, etc.)

Solution

Construisez une application avec une architecture monolithique. Par exemple:

• un seul fichier Java WAR.
• une seule hiérarchie de répertoires de code Rails ou NodeJS

Exemple d’architecture monolithique

Imaginons que vous construisiez une application de commerce électronique qui prend les commandes des clients, vérifie l’inventaire et le crédit disponible, et les expédie. L’application se compose de plusieurs composants, dont StoreFrontUI, qui implémente l’interface utilisateur, ainsi que de certains services backend pour vérifier le crédit, maintenir l’inventaire et expédier les commandes.

L’application est déployée comme une seule application monolithique. Par exemple, une application Web Java se compose d’un seul fichier WAR qui s’exécute sur un conteneur Web tel que Tomcat. Une application Rails consiste en une seule hiérarchie de répertoires déployée en utilisant, par exemple, Phusion Passenger sur Apache/Nginx ou JRuby sur Tomcat. Vous pouvez exécuter plusieurs instances de l’application derrière un équilibreur de charge afin de faire évoluer et d’améliorer la disponibilité.

Contexte résultant

Cette solution présente de nombreux avantages :

• Simple à développer – l’objectif des outils de développement et des IDE actuels est de prendre en charge le développement d’applications monolithiques
• Simple à déployer – il vous suffit de déployer le fichier WAR (ou la hiérarchie de répertoires) sur le runtime approprié
• Simple à mettre à l’échelle – vous pouvez faire évoluer l’application en exécutant plusieurs copies de l’application derrière un équilibreur de charge

Cependant, une fois que l’application devient volumineuse et que l’équipe s’agrandit, cette approche présente un certain nombre d’inconvénients qui deviennent de plus en plus importants :

• La grande base de code monolithique intimide les développeurs, en particulier ceux qui sont nouveaux dans l’équipe. L’application peut être difficile à comprendre et à modifier. En conséquence, le développement ralentit généralement. De plus, étant donné qu’il n’y a pas de limites strictes entre les modules, la modularité s’effondre avec le temps. De plus, comme il peut être difficile de comprendre comment implémenter correctement un changement, la qualité du code diminue avec le temps. C’est une spirale descendante.
• IDE surchargé – plus la base de code est grande, plus l’IDE est lent et moins les développeurs sont productifs.
• Conteneur Web surchargé – plus l’application est volumineuse, plus le démarrage est long. Cela a eu un impact énorme sur la productivité des développeurs en raison du temps perdu à attendre le démarrage du conteneur. Cela a également un impact sur le déploiement.
• Le déploiement continu est difficile – une grande application monolithique est également un obstacle aux déploiements fréquents. Pour mettre à jour un composant, vous devez redéployer l’intégralité de l’application. Cela interrompra les tâches en arrière-plan (par exemple, les tâches Quartz dans une application Java), qu’elles soient ou non affectées par le changement, et causera éventuellement des problèmes. Il est également possible que les composants qui n’ont pas été mis à jour ne démarrent pas correctement. En conséquence, le risque associé au redéploiement augmente, ce qui décourage les mises à jour fréquentes. C’est particulièrement un problème pour les développeurs d’interfaces utilisateur, car ils doivent généralement itérer rapidement et se redéployer fréquemment.
• La mise à l’échelle de l’application peut être difficile – une architecture monolithique est qu’elle ne peut évoluer que dans une dimension. D’une part, il peut évoluer avec un volume de transactions croissant en exécutant plus de copies de l’application. Certains clouds peuvent même ajuster le nombre d’instances de manière dynamique en fonction de la charge. Mais d’un autre côté, cette architecture ne peut pas évoluer avec un volume de données croissant. Chaque copie d’instance d’application accédera à toutes les données, ce qui rend la mise en cache moins efficace et augmente la consommation de mémoire et le trafic d’E/S. En outre, différents composants d’application ont des besoins en ressources différents – l’un peut être gourmand en CPU tandis qu’un autre peut être gourmand en mémoire. Avec une architecture monolithique, nous ne pouvons pas dimensionner chaque composant indépendamment
• Obstacle au développement à grande échelle – Une application monolithique est également un obstacle au développement à grande échelle. Une fois que l’application atteint une certaine taille, il est utile de diviser l’organisation d’ingénierie en équipes qui se concentrent sur des domaines fonctionnels spécifiques. Par exemple, nous pourrions vouloir avoir l’équipe d’interface utilisateur, l’équipe de comptabilité, l’équipe d’inventaire, etc. Le problème avec une application monolithique est qu’elle empêche les équipes de travailler de manière indépendante. Les équipes doivent coordonner leurs efforts de développement et de redéploiement. Il est beaucoup plus difficile pour une équipe de faire un changement et de mettre à jour la production.
• Nécessite un engagement à long terme envers une pile technologique – une architecture monolithique vous oblige à être marié à la pile technologique (et dans certains cas, à une version particulière de cette technologie) que vous avez choisie au début du développement. Avec une application monolithique, il peut être difficile d’adopter progressivement une nouvelle technologie. Par exemple, imaginons que vous choisissiez la JVM. Vous avez le choix entre plusieurs langages, car en plus de Java, vous pouvez utiliser d’autres langages JVM qui interagissent bien avec Java, tels que Groovy et Scala. Mais les composants écrits dans des langages non JVM n’ont pas leur place dans votre architecture monolithique. De plus, si votre application utilise un framework de plate-forme qui devient par la suite obsolète, il peut être difficile de migrer progressivement l’application vers un framework plus récent et meilleur.

Motifs associés

L’ architecture de microservices est un modèle alternatif qui répond aux limitations de l’architecture monolithique.

Utilisations connues

Services Internet bien connus tels que Netflix, Amazon.com et eBay avaient initialement une architecture monolithique. La plupart des applications Web développées par l’auteur avaient une architecture monolithique.