Le DSI ayant choisi,
Un système monolithe.

Se trouva fort dépourvu,
Quand la team business fut venue.

Car leur volonté,
Était de remplacer.

Son beau monolithe,
Par de nouveaux outils, plus ergonomiques.

Pas assez de ressource,
Pour connecter toutes ces nouvelles sources.

Par un seul cahier des charges,
Pour l’aider à dépasser cette surcharge.

Il alla demander de l’aide,
A ses freelances, son ESN et même ses collègues.

Mais ceux-ci sont débordés,
Et n’ont pas envie de travailler,

Sur ce monolithe,
Beaucoup trop spécifique.

Que faisiez vous du temps des microservices ?
Je m’épuisait à complexifier mon système pour offrir plus de services.

Vous vous épuisiez à complexifiez votre système !
Et bien continuez à transpirer maintenant.

Cette introduction, un brin provocatrice, 😉 est tirée d’une expérience personnelle.

J’ai passé BEAUCOUP de temps, en tant que DSI, à enrichir des monolithes et me faire « enguirlander » par les équipes métiers qui trouvaient les outils spécifiques du marché (plus récent, plus novateur, plus puissants…).
Après cette expérience j’ai passé beaucoup de temps à étudier les systèmes moins monolithiques.

L’objectif de cet article est de vous présenter mon constat concernant les approches d’architectures monolithiques et microservices.

Donc que vous fassiez partie de la team business (frustrée de vos outils) ou de la team DSI (frustrée des réflexions désobligeantes du business) la suite de cet article devrait vous plaire.

Avant toute chose, il nous faut poser, les bases.
Dans le paragraphe suivant, vous comprendrez mieux ce qu’est une architecture monolithique.

Monolithe ou microservices on pose les bases.

C’est quoi un système monolithique?

A la base il y avait le monolithe !

Pour faire simple, un monolithe est un système qui « embarque » tout ce dont vous avez besoin pour votre activité.
Ces applications sont donc conçues pour englober toutes les fonctions de l’entreprise et elles sont très étroitement couplées.

Et ceci va souvent très loin !

Imaginez, par exemple, tout ce qu’un tel système doit embarquer comme fonctionnalités pour faire tourner un site ecommerce :

Gestion de catalogue
Gestion de contenu
Gestion des commandes
Gestion des factures
Gestion des stocks
Gestion des prix
Gestion des paiements
….

Une seule application pour gérer l’ensemble de votre entreprise, sympa comme promesse !

Nous le verrons, plus en détail plus tard dans cet article, mais la contrepartie de ca est que ces applications sont souvent complexes.

Restez attentif, car dans le prochain paragraphe, nous allons aborder quelque chose de fondamentale !
Nous allons voir ce qui a fait basculer nos bons gros monolithes.

Qu’est ce qui a fait basculer nos beaux monolithes ?

Ce qui a fait basculer nos monolithes, est quelque chose de beaucoup plus petit que lui, beaucoup plus agile, plus indépendant…

Ce « casseur de monolithe » se nomme, « les microservices » !

L’architecture en microservices est une technique de développement logiciel, dont l’objectif est de structurer une application grâce à un ensemble de services qui communiquent ensemble.

Contrairement à l’approche monolithique, l’architecture microservices permet de déployer de petites applications indépendantes sous forme de services, reliées entre elles via l’intégration des applications.

Alors imaginez maintenant un système ecommerce avec une approche en microservices.

Un service de gestion de catalogue
Un service de gestion de contenu
Un service de Gestion des commandes
Un service de Gestion des factures
Un service de Gestion des stocks
Un service de Gestion des prix
Un service de Gestion des paiements
….

Ca y est le décor est planté !
Voyions maintenant les avantages et inconvénients de chacune de ces solutions.

Les avantage et inconvénients des architectures monolithiques et microservices ?

Les avantages d’un système monolithique.

Commençons par ce qui est (de mon point de vue) du positif dans les architectures monolithiques.

1, La simplicité de mise en place et son aspect « malléable ».

C’est surement pour cela d’ailleurs que beaucoup de start up on encore des structures comme celle-ci.
Avec une base de code unique il est plus facile de corriger les problèmes transversaux, de faire évoluer l’ensemble rapidement…

2, La performance.

Ca va peut être vous étonner !
Mais une architecture monolithique est performante car les fonctionnalités se partagent la mémoire vive. Pas besoin donc, d’attendre qu’un service nous réponde…

3, Le prix.
Au moins au début (ca on le verra un peu plus loin en détail) une architecture monolithique est rapidement mise en place et ne nécessite que peu d’investissements (un serveur et c’est parti 😅).

Passons maintenant à l’envers du décor 😈.

Les inconvénients du système monolithique.

Et oui (en informatique) tout ce qui a marché un jour n’est pas forcément vrai le lendemain.

De mon point de vue, les principaux inconvénients de ce système sont les suivants :

1, La complexité.
Là tous les développeurs qui ont eu l’honneur de travailler dans un environnement spécifique vont me comprendre.
Nous avons tous perdu nos cheveux à essayer de comprendre les règles fonctionnelles 🤯.

Avec le temps il y a un fort risque d’enchevêtrement du code et ca devient franchement difficile à comprendre donc difficile à maintenir….

Ceci entraine :

Des problèmes de fiabilité (« je ne comprends pas ! J’ai modifié le tunnel du front ca a fait péter le système de gestion des commandes du back » 🤯),
Des surcouts de support,
Des difficultés à former les développeurs (et les retenir car ils n’ont plus envie d’une telle complexité)….

2, La dette technique.
Et bim ! Seconde prise de tête pour tous les DSI et développeurs cette horrible dette technologique.
Etant donné que tout est enchevêtré il est complexe de faire évoluer la technologie. Beaucoup de systèmes monolithes fissent donc avec un important retard technologique
« Quoi votre back office est sous du symfony 1.4, mais vous êtes fou il faut le faire évoluer… »😭.

3, La scalabilité. Souvent, la seule solution pour faire « scaler » un système monolithique consiste à créer plusieurs copies du monolithe (pas très efficace et gourmant en ressources).

Voyons maintenant si notre architecture en microservices peut mieux faire.

Les avantages d’une architecture en microservices.

1, L’agilité, l’énorme avantage d’une architecture en microservices c’est l’agilité.
Chaque système étant indépendant il devient beaucoup plus facile de les échanger, les faire évoluer, ajouter des fonctionnalités sans impacter les autres….

2, La scalabilité, ce point est évident, c’est juste l’inverse du système monolithique.
Les systèmes (ou composants) étant indépendants il est beaucoup plus facile de faire «scaler » un élément plutôt que les autres…

3, L’évolutivité et le choix technologique, un système en microservices étant plus simple à maintenir (car il est limité à certaines fonctionnalités). Il devient beaucoup plus simple de faire évoluer les choix technologiques et de les adapter au contexte de l’application.

Fini donc le bon gros Legacy qui colle aux baskets 😇

Mais malheureusement il n’y a pas que des avantages, passons maintenant aux inconvénients 😈.

Les inconvénients d’une architecture en microservices.

1, La complexité « tentaculaire » 🦑, le réel défi pour une architecture en microservices est d’arriver à maîtriser la complexité.

Beaucoup d’environnements techniques différents, peu de standardisation peuvent amener (si ceci est mal géré) à des difficultés à débeuguer, des complexités à délimiter les périmètres de responsabilités…

2, Le coût, une architecture en microservices implique plus de personnes, plus d’applications hébergés, plus d’outils de surveillance, plus de lot à analyser…
Donc à l’arrivé c’est plus cher.

3, La dépendance avec le réseau, voici un autre défi de ce genre d’architecture.
Les applications étant indépendantes l’unique chose que les rassemble c’est LE RÉSEAU.
Cette dépendance pourra amener de gros déboires si elle est mal gérée (j’ai surtout en tête d’éventuels latences entre les applications….).

En conclusion, quelle est la meilleure solution monolithe ou microservices ?

Contenter la team business dépendra de votre contexte.

Si l’application que vous devez développer, gérer… est petite et/ou simple et que vous avez une équipe informatique réduite.
Le monolithe sera probablement un bon choix.

Cependant, si votre application est complexe, implique plusieurs métiers différents et surtout que vous avez les moyens d’animer une équipe informatique significative (que ce soit interne ou externe).
La il y aura un réel intérêt à considérer une architecture en microservices.

Enfin, si (comme moi) vous voulez faire évoluer votre gros monolithe vers une architecture en microservices (car votre entreprise a beaucoup évoluée, vous avez plus de moyens…) je vous conseille d’y aller très progressivement (service par service) et, avant de vous lancer, dans l’aventure, je vous conseille de vous poser les questions suivantes :

– Quels sont les compétences techniques dont nous avons besoin (autant en termes de développement, que de réseau, devops…) ?

– Est ce que TOUTES les équipes opérationnelles auront également la capacité de participer activement à l’évolution des systèmes qui leurs seront dédiés ?

Et finissez pas faire un TCO du projet 😉