+ 33 6 68 40 27 75 contact@odeven.fr
Sélectionner une page

Préambule

Cet article est le premier d’une liste de 5 chapitres, concernant l’architecture logicielle, afin de vous aider à analyser vos besoins, et à choisir l’architecture la plus adaptée pour réaliser votre projet.

  1. L’architecture Monolithique
  2. L’Architecture Orientée Service ou « Service Oriented Architecture (SOA) »
  3. L’Architecture Orientée Événement ou « Event Oriented Architecture (EOA) »
  4. Architecture Moderne : Les concepts essentiels
  5. Architecture Moderne : Exemple de création d’un nouveau projet

Introduction

L’Architecture Monolithique est l’architecture la plus “classique”. C’est la plus simple, et probablement la plus utilisée dans le monde. Néanmoins, ça ne fait pas d’elle la meilleure pour autant.

Cette architecture consiste à réunir la totalité du code dans un seul et même programme (projet, application, module, à vous de choisir le mot qui vous convient le mieux). C’est-à-dire que les éléments qui composent cette solution ne peuvent être séparés sur des serveurs différents par exemple.

Tous les développeurs apprennent leur métier avec cette architecture, pour la simple raison qu’elle ne nécessite aucune notion d’architecture pour pouvoir être utilisée.

Avantages

Cette architecture présente tout de même des avantages :

  • Simple à développer
  • Simple à déployer
  • Peu coûteuse sur le (très) court terme
  • Ne nécessite pas de connaissance spécifique pour être utilisée

Inconvénients

Cette architecture reflète certes la simplicité, mais elle se révèle très souvent être un mauvais choix sur le long termes. En effet, elle présente les inconvénients suivants :

  • Maintenance du code de plus en plus compliquée/contraignante
  • Nouvelles fonctionnalités de plus en plus longues à développer
  • Application difficile à optimiser
  • Application lourde et longue à compiler/démarrer
  • Très dépendante des technologies employées initialement
  • Difficulté à intégrer de nouvelles ressources humaines
  • Difficulté à faire collaborer plusieurs équipes

Comme vous pouvez le constater, les inconvénients sont nombreux, et touchent des domaines différents.

Quelle rentabilité pour l’entreprise ?

Cette question est la plus importante. Elle englobe en réalité 4 questions :

  • Combien de temps pour développer l’application ?
  • Quels bénéfices l’application apportera-t-elle ?
  • Coût de la maintenance (ressources humaines, coût du matériel) ?
  • Évolutivité ?

Une entreprise se fiche la plupart du temps de faire une application propre et robuste. Tout ce qui l’intéresse, c’est de faire un maximum de bénéfices. Cette stratégie peut être basée sur le court, moyen, ou long terme. Tout dépend de la mentalité de l’entreprise, et du contexte.

Une application monolithique peut être développée par n’importe quel développeur justifiant d’un minimum de formation. Cela présente l’avantage de ne pas avoir à embaucher de spécialistes.

Le temps nécessaire pour développer l’application sera presque toujours plus court avec une architecture monolithique.

Concernant les bénéfices engendrés par l’application, cela est bien sûr impossible à dire en se basant uniquement sur l’architecture. Tout ce qu’on peut dire, c’est qu’une architecture monolithique possède des limites. Et lorsqu’on rencontre ces limites, la qualité de l’application est détériorée (temps d’exécution par exemple).

De même, plus l’application grossit, plus elle entraîne de bug. La correction des bugs finit éventuellement par entraîner de nouveaux bugs, dû à la quantité massives de règles de gestions à intégrer dans un seul et même programme. Ceci a donc forcément un impact sur la qualité de l’application. Une application monolithique, même très grosse, peut fonctionner, mais rarement correctement. A ce stade, la maintenance devient très compliquée, et la correction d’un bug peut devenir de plus en plus longue (temps pour trouver la provenance du bug, temps pour assimiler l’impact potentiel d’un correctif, etc…).

Concernant l’évolutivité, rien n’est impossible avec une architecture monolithique. Mais chaque évolution est généralement de plus en plus coûteuse. En effet, l’impact sur les autres fonctionnalités est rarement négligeable, et entraîne fréquemment des bugs, des conflits, ou bien impact la performance. L’application ne tend que vers une seule chose : devenir ingérable.

Ainsi, pour répondre à la question, on peut dissocier deux situations :

  • L’application est simple, et n’évoluera jamais : il faut alors privilégier l’architecture monolithique.
  • L’application est plus complexe, ou tend à évoluer : Il faut choisir une véritable architecture.

Attention : il est rare qu’une application n’évolue jamais. Ne serait-ce qu’en termes de technologies, une application Web par exemple est dépendante des navigateurs. Si on développe une application basique pour Internet Explorer 6, viendra un moment où l’on devra faire évoluer l’application.

Analogie

Une analogie intéressante pour assimiler le concept d’architecture logicielle est de comparer la création d’une application à la création d’un immeuble.

Un immeuble doit reposer sur des fondations solides. Celles-ci doivent prévoir de supporter la charge de l’immeuble afin qu’il ne s’écroule pas. En architecture logicielle, c’est pareil. Il faut analyser ce que l’application devra supporter afin d’établir une base saine et solide.

Mais cela va encore plus loin. Dans le bâtiment, on voit parfois des annexes s’ajouter. Dans une application, les nouvelles fonctionnalités sont très fréquentes, voir inévitables. Il faut donc s’interroger sur le futur de l’application afin de mettre en place des fondations capables de supporter l’ajout de nouvelles fonctionnalités.

On pourrait se dire “je fabrique des fondations basiques, et je les améliorerait au fur-et-à-mesure !”. Mais vous vous voyez faire ça pour un immeuble ? C’est théoriquement possible, mais à quel coût ? Très souvent, dans le bâtiment, l’issue est la même : on détruit, et on recommence.

En logiciel, c’est pareil. Mais on a la chance de pouvoir mettre en place des fondations solides et flexibles. Et ça, c’est ce qu’on appelle “Architecture Logicielle”.

Aller au Chapitre 2 – L’Architecture Orientée Service ou « Service Oriented Architecture (SOA) »