Microservices Time TO Market
Data driven

Hacker son Time To Market : les applications monolithes

28 septembre 2017

Vos problèmes ont un nom : les applications Monolithes

Les applications monolithes sont des applications avec un périmètre fonctionnel trop large, c’est à dire des applications qui implémentent des fonctionnalités nombreuses et qui répondent à des cas d’usages trop variés et hétérogènes. Une application monolithe est une application qui pouvait avoir un périmètre réduit et clairement défini initialement mais qui avec le temps, a hébergé beaucoup trop de fonctionnalités diverses. C’est ainsi que l’on peut se retrouver avec une application qui s’adresse à la fois aux clients finaux (B2C), aux partenaires (B2B) et qui intègre aussi les fonctionnalités de paramétrage et de configuration aux mains des experts métiers.

Sur un site de e-commerce, cela pourrait se traduire par l’intégration des fonctionnalités d’achats en ligne par les clients finaux, de consultation des commandes à livrer par les partenaires en charges de livraisons et par la gestion des stocks et du pricing des articles par les administrateurs au sein d’une même application web. On le voit rien qu’avec cet exemple simple, une telle application devra être complexe ne serait que dans sa gestion de la sécurité et des contrôles d’accès qui devront prendre en compte beaucoup de cas d’usages incompatibles entre eux.

De par son périmètre fonctionnel flou, une application monolithe est une application avec une cohérence fonctionnelle faible. Effectivement, dans notre exemple, il n’y a pas de cohérence entre la gestion du pricing des produits et la gestion des livraisons.

Une application monolithe est une application dont les fonctionnalités ont un couplage fort entre elles. C’est ce que l’on appelle une application avec du code spaghetti : on ne sait plus déterminer quel code est utilisé pour quelle fonctionnalité, tout dépend potentiellement de tout. Ce genre d’application est alors très compliqué à faire évoluer sans risque car les études d’impacts sont souvent complexes : faire évoluer uniquement un périmètre donné de l’application n’est souvent pas possible.

code spaghetti applications monolithes

Le couplage fort et la cohérence fonctionnelle faible d’une application Monolithe se traduisent rapidement en de sérieux problèmes d’évolutivité. Une application monolithe est très complexe et donc très coûteuse à faire évoluer pour les raisons suivantes :

  • Base de code importante (application trop grosse) qui ne peut pas être maintenue par une seule équipe agile (10 pers max). Les applications monolithes sont peu compatibles avec un mode d’organisation Agile.
  • Complexité pour les analyses d’impacts (code spaghetti).
  • Complexité du code et complexité pour effectuer des refactorings : la base de code contient des portions de code vieillissantes que plus personne ne maitrise et que l’équipe évite autant que possible de toucher.
  • Cycle de vie complexe à gérer : son périmètre fonctionnel trop large impacte des équipes métiers distinctes qui ont potentiellement des besoins et des objectifs parfois incompatibles (planning des évolutions différentes ce qui conduit à des exigences de dates de livraisons également différentes, capacité et disponibilité de équipes métiers pour effectuer les tests et la recette, etc.).

Cette faible évolutivité a un impact très négatif sur la capacité des équipes à livrer rapidement des évolutions et donc, sur le Time To Market.

A ces problèmes s’ajoute également un coût résiduel de fonctionnement trop élevé ou que l’on pourrait diminuer. Une application Monolithe est une application qui n’est pas prévue pour la mise à l’échelle (scalabilité). Sa taille importante ne lui permet pas de se passer de la notion de scalabilité verticale : cela signifie que les applications monolithes nécessitent une infrastructure, c’est-à-dire des machines, avec des capacités importantes pour fonctionner (CPUs multi-cœurs performants, allocation de RAM importante, espace disque important).

Scalabilité verticale applications monolithes

Les exigences d’une application Monolithe (qualité de service : durée maximale d’indisponibilité maximale, charge max à supporter, plage horaire de disponibilité de service, etc.) doivent prendre en compte les besoins de fonctionnalités complètement différentes. On doit alors s’adapter aux besoins des fonctionnalités les plus exigeantes, ce qui conduit à une application souvent surdimensionnée pour certains usages. Ce sur-dimensionnement peut se convertir en surcoût de fonctionnement. Ce surcoût de fonctionnement a un impact négatif sur le Time To Market car il mobilise des ressources qui auraient pu être investies dans de la production de valeur à travers l’ajout de nouvelles fonctionnalités à l’application ou au produit.

Les applications monolithes sont donc un anti-pattern pour les équipes qui souhaitent réduire leur Time To Market : ce sont des applications complexes, coûteuses à maintenir et lentes à faire évoluer. La refonte d’une application monolithe est un projet ambitieux, long, complexe et qui nécessite de mobiliser de nombreuses ressources.

Prenons l’exemple simplifié d’une application monolithe :

  • Une application simplifiée avec 3 fonctionnalités qui sont liées entre elles (code spaghetti) :
    • Gestion des commandes
    • Gestion des factures
    • Gestion des livraisons
  • C’est une application monolithe qui favorise la scalabilité verticale : elle est donc déployée sur deux « gros » serveurs.
  • Cette application utilise une seule base de données qui héberge les référentiels suivants liés entre eux :
    • Référentiel des clients
    • Référentiel pour la gestion des commandes
    • Référentiel pour la gestion des livraisons
    • Référentiel pour la gestion des factures

Applications monolithes simplifiées

Nous détaillerons dans le prochain article, un pattern d’architecture qui vise à transformer les applications monolithes en applications évolutives et agiles.


Editor – c’est la 2ème partie d’une suite d’articles décrivant comment l’architecture logicielle est un levier d’optimisation du Time To Market :

  1. Le Time To Market : un enjeu stratégique
  2. Le Time To Market : les applications monolithes
  3. Le Time To Market : Microservices vs Applications Monolithes
  4. Le Time To Market : caractéristiques des Microservices
  5. Le Time To Market : Microservices et agilité
  6. Le Time To Market : les difficultés posées par les Microservices (1/2)
  7. Le Time To Market : les difficultés posées par les Microservices (2/2)
  8. Le Time To Market : une trajectoire pour la mise en œuvre de Microservices

 

Newsletter

Inscrivez-vous à notre newsletter pour recevoir nos dernières actualités*

Les informations recueillies sur ce formulaire sont enregistrées dans un fichier informatisé de gestion des Clients et Prospects (CRM).

Le Responsable de traitement est la société weave, 37 rue du rocher 75008 Paris RCS Paris 802 396 085.

Elles sont destinées à l’activité marketing du groupe weave ainsi quà celle de ses filiales, à l’exclusion de tout transfert hors de l’UE. Elles sont conservées pour une durée conforme aux dispositions légales (par exemple 3 ans pour les données prospects).

Ce traitement nécessite votre consentement que vous pourrez retirer à tout moment sans que cela ne remette en cause sa licéité.

Conformément à la loi « Informatique et Libertés » et au règlement européen n°2016/679, vous bénéficiez d’un droit d’accès, de rectification ou d’effacement, ainsi que d’un droit à la portabilité de vos données ou de limitation du traitement. Vous pouvez également pour des raisons tenant à votre situation particulière, vous opposer au traitement de vos données et donner des directives relatives à la conservation, à l’effacement et à la communication de vos données après votre décès. Vous disposez également du droit d’introduire une réclamation auprès de la Commission Nationale de l’Informatique et des Libertés (www.cnil.fr).

Vous pouvez exercer vos droits en nous contactant à l’adresse vosdonnees@weave.eu.

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour mesurer notre audience, vous proposer des contenus et des offres personnalisées, ainsi que des fonctionnalités de partage sur les réseaux sociaux. En savoir plus sur notre politique de cookies et notre charte des données personnelles