L’architecture monolithique ? Toujours d'actualité

L’architecture monolithique ou monolithe est le modèle par défaut de création d’une application logicielle. Cette approche monolithique permet de construire chaque projet informatique comme un programme unique et indivisible. Généralement, la solution comprend une interface utilisateur, une application côté serveur et une base de données. Toutes les fonctions sont gérées et définies en un seul endroit. Ces applications monolithiques mainframe reposent sur un socle complexe et toute modification dans le code source impacte l’ensemble du programme. Elles sont donc considérées par les développeurs IT comme difficiles à maintenir, à corriger, à faire évoluer et à réutiliser dans d’autres projets. L’architecture monolithe est souvent délaissée au profit de nouveaux types d’approches notamment le modulaire avec les microservices, beaucoup plus adaptés aux processus itératifs. Alors faut-il complètement abandonner l’architecture monolithique ?

L’architecture monolithique : avantages et inconvénients

Le mot « Monolithique » signifie littéralement composé d’une seule pièce. Pour les applications logicielles, cela veut dire que les différents composants sont au même niveau. La logique métier, la couche d’accès aux données, les diverses intégrations de services ou API forment un seul bloc.

C’est l’approche traditionnelle et historique pour la conception des programmes informatiques. Encore aujourd’hui, malgré une évolution des modes de développement vers les cycles itératifs et le DevOps voire le DevSecOps, l’architecture monolithique reste très utilisée.

Elle comporte en effet plusieurs avantages dont :

une grande simplicité de mise en œuvre. Basiquement si aucune architecture n’est appliquée, le résultat sera probablement proche du monolithique ;
des tests rapides : il est facile de déployer ce type d’application en local par exemple pour la débugger ;
une simplicité de déploiement : il suffit de copier-coller l’application packagée sur un serveur ;
moins de latence : dans la structure monolithique, tous les appels sont locaux, les temps de traitement et de réponse sont ainsi réduits ;
des intégrations simplifiées : des éléments comme les frameworks, les bibliothèques ou les scripts peuvent être ajoutés rapidement.

Cependant, l’approche monolithique comporte aussi plusieurs inconvénients :

une maintenance compliquée : les applications deviennent souvent volumineuses et complexes. Bien comprendre et tester l’ensemble des dépendances avant d’apporter des modifications est donc indispensable ;
des lenteurs de chargement : toujours à cause de la taille du code source, l’environnement de développement peut être surchargé et les applications longues à lancer ;
un potentiel manque de fiabilité : un bug au niveau de n’importe quel composant peut interrompre tout le processus et donc le fonctionnement de l’application ;
des redéploiements intégraux : à chaque fois qu’un correctif ou une évolution est apporté, il faut redéployer l’ensemble du programme ;
des difficultés pour travailler simultanément : à cause des forts liens et dépendances entre les différents composants, les développeurs peuvent créer de nombreux conflits lorsqu’ils modifient en même temps le code source ;

Ces derniers points sont particulièrement incompatibles avec les modes de développement modernes. La méthode agile et ses cycles itératifs impliquent des déploiements très fréquents. La philosophie DevOps offre, quant à elle, une approche plus interactive et collaborative.

C’est pourquoi de nouvelles pratiques plus modulaires avec en particulier l’architecture microservices sont de plus en plus employées à la place du monolithique.

Architecture monolithe VS microservices

L’architecture microservices consiste, comme son nom l’indique, à diviser une solution en plusieurs services plus petits, individuels et indépendants les uns des autres. Chacun de ces conteneurs est complet et peut fonctionner de manière autonome. Ils communiquent entre eux grâce à des API.

Les avantages de cette approche sont donc nombreux :

chaque micro service peut être implémenté dans des langages de programmation ou des plateformes diverses tout en étant interopérable avec les autres ;
les architectures microservices offrent, en général, des temps de développement plus rapides que les monolithiques car, travailler en simultané sur les multiples composants est plus simple ;
les conteneurs gèrent leurs propres modèles et données, ils sont donc exploitables de manière indépendante. L’application est plus facile à maintenir et à faire évoluer ;
une fois développés, les microservices peuvent être réutilisés dans différents logiciels et programmes ;
le socle de code source est beaucoup plus petit que pour le monolithe. Cela permet de bien comprendre le projet et simplifie sa reprise par d’autres équipes de développement.

Néanmoins, les approches microservices ne sont pas exemptes de défauts. Ils ont basiquement tous les inconvénients d’un système distribué. Les applications peuvent devenir rapidement complexes notamment au niveau de la gestion de la communication entre les différents modules, du débogage et des tests d’intégrations.

Les architectures microservices sont aussi réputées moins stables et sécurisées que les monolithes.

En effet, un environnement de microservices regorge d’API pour que les composants puissent dialoguer entre eux. Cependant, cette quantité élevée d’interfaces offre également aux pirates informatiques davantage de « possibilités » pour s’introduire dans le programme.

En partie à cause de ces inconvénients, un troisième type d’approche, qui fait le consensus entre les deux précédentes, s’est développé : le monolithe modulaire.

Monolithe modulaire, le bon compromis ?

Le monolithique modulaire et une architecture de conception logicielle basée sur un monolithe, mais avec des composants interchangeables (et idéalement réutilisables).

C’est une solution pour bénéficier de certains avantages des microservices tout en en évitant la complexité. Le code produit possède des dépendances mieux organisées qu’avec le monolithe standard. Chaque module expose une définition d’interface de programmation à d’autres éléments. De plus, le monolithique modulaire permet de limiter les dépendances en séparant les stockages de données.

Néanmoins, cette architecture modulaire du monolithique ne reprend pas tous les atouts des microservices notamment en ce qui concerne le mélange de choix technologiques et de langages de programmation.

Cette structure est davantage conseillée pour les applications et logiciels d'ampleur et de complexité moyenne ou pour simplifier une architecture monolithe classique sans se lancer dans une refonte longue et coûteuse avec les microservices.

L’approche monolithique n’est cependant pas à abandonner. Les approches microservices et monolithe modulaire comportent aussi leurs inconvénients. Le choix d’un type d’application est lié aux besoins exprimés, à sa complexité, mais également aux compétences et préférences des équipes sur le projet.

[content-cta overline="Le Forum" 
subtitle="Monolithe, le bon compromis ?"*
content="Rejoignez la communauté pour échanger avec vos pairs"*
primary-button="J'y vais" 
primary-button-url="https://www.free-work.com/fr/tech-it/forum/" 
image="https://statics.free-work.com/blog/posts/more_images/image-5xgFMN5C2eulUaQf.png" /]