Les différentes architectures applicatives

Quelles sont les différences entre les architectures ?

Passons en revue, si vous le voulez bien, les différentes architectures applicatives les plus répandues lors de projets informatiques.

On retrouve premièrement, l’architecture dite monolithique : tous les composants sont interconnectés et dépendants. En gros c’est une application pour laquelle l’ensemble du code et des fonctionnalités sont implémentés dans un même programme. Elle n’en reste pas moins très répandue puisqu’elle représente à l’heure actuelle une large majorité des applications existantes.

Les avantages du monolithe :

• Mise en place simple,
• Une seule base de code,
• Pas de latence réseau,
• Gestion d’une seule BDD simplifiée,
• Très rapide à mettre en œuvre : à petite échelle, c’est ce qu’il faut !

Ses inconvénients (surtout quand on commence à grossir) :

• Pas de modularité,
• Temps de build élevé,
• Temps de déploiement,
• Complexe à maintenir,
• Pas de scalabilité.

On remarque en plus qu’avec le temps les applications monolithiques ont tendances à grossir car elles intègrent toujours plus de fonctionnalités. Elles développent des interdépendances entre elles et les fonctionnalités obsolètes ne sont pas toujours supprimées faute de temps. Le code a donc tendance s’étoffer et devenir inmaintenable.

D’un point de vue technologique, on reste sur des systèmes qui se déprécient avec le temps et peuvent créer des problématiques en termes de performances et de sécurité.

Enfin et c’est cela son principal inconvénient : plus un projet devient gros, plus il devient critique pour l’entreprise et moins on souhaitera y toucher en implémentant de nouvelles fonctionnalités par peur de le rendre instable. On préfère la stabilité à l’innovation. Alors qu’on ne devrait pas !

C’est dans ce contexte et fort de l’adage « ne pas mettre tous ses œufs dans le même panier » qu’est arrivée l’architecture orientée service (SOA) dans les années 2000. Ayant ouvert la voie aux microservices, elle se caractérise par l’introduction de systèmes de services autonomes où les échanges se font via un ESB qui est un middleware permettant la communication des applications qui n'ont pas été conçues pour fonctionner ensemble.

De manière générale, on observe que la taille des services est donc plus importante en SOA qu’en microservices (…d’où le micro)

Retenons qu’un monolithe adaptera son organisation au niveau technique, l’architecture orientée services d’un point de vue domaine, les microservices au niveau métier !

En fait, si l’on caricature un peu, ce qui passe pour une vilaine manie, on peut dégager comme tendance que les projets entrepris avant les années 2000 s’effectuaient systématiquement en architecture monolithique quand ceux plus ambitieux des années 2000 s’organisaient en SOA puis en microservices à partir de 2010

Attendez, ne partez pas sans avoir lu nos articles sur la définition d'une architecture microservices et les raisons des les utiliser !