Un monolithe qui est distribué ! Ça sonne un peu comme une contradiction. En effet, on a défini un monolithe comme un système empaqueté dans une seule unité applicative. Ainsi défini, un monolithe ne saurait être distribué. Pourtant, il existe bien des applications en apparence distribuée, mais dont le fonctionnement au quotidien s’apparente beaucoup à celui d’un monolithe. On suspecte d’ailleurs beaucoup d’organisation d’avoir ce type de monolithe plutôt particulier dans leur écosystème. En fait, plusieurs personnes qui prétendent avoir une architecture en microservices ont plutôt ce nouveau type de monolithe que Sam Newman qualifie de monolithe distribué dans son livre intitulé « Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith ».
Sans être en fait un vrai monolithe, puisqu’un monolithe est
supposé être constitué d’une seule unité de déploiement, indivisible, difficile
d’être séparé en pièce; un monolithe distribué pose à peu de chose près les
mêmes problèmes que tous les autres monolithes. S’il est vrai que les
composants du monolithe distribué s’exécutent chacun dans son processus, comme
les microservices, ces composants sont devenus avec le temps, fortement couplés
les uns aux autres, et il est presque impossible de déployer indépendamment un
ou quelques morceaux seulement. On se trouve obligé de déployer chaque fois
toutes les pièces du système distribué. Il peut y avoir de nombreuses raisons
pour lesquelles on se retrouve avec un monolithe distribué. La plupart des
raisons sont les mêmes qu’on retrouve pour les systèmes modulaires,
c’est-à-dire des mauvaises frontières entre les modules et des informations pas
suffisamment encapsulées, débouchant ultimement sur un système fortement
couplé.
Généralement, on commence à s’apercevoir qu’on s’avance vers
un cul-de-sac lorsqu’en essayant de changer une petite fonctionnalité, on se
rend compte que plusieurs modules sont impactés. Dans une architecture
microservices, on peut aussi avoir un changement
transversal. Mais lorsque l’on commence à en avoir beaucoup, la complexité des
déploiements s’accroit très rapidement, et les coûts des déploiements
augmentent de façon drastique. La situation devient critique lorsqu’on a des
difficultés à isoler les modules impactés par un changement, et qu’on décide de
déployer l’ensemble de tous les composants du système. Cette activité de
déploiement de masse est carrément un désastre. Cela aboutit à un système qui a
un coût de modification très élevé et une portée de déploiement très grande.
Plus la portée du déploiement est grande, plus les risques augmentent et plus
il y a davantage des chances qu’un problème survienne lors du déploiement.
C’est une spirale descendante.
Les architectures microservices ont pour objectif
fondamental de faciliter l’implantation des changements. À l’inverse, un
monolithe distribué rend l’implantation d’un changement très complexe et
coûteux, pire que pour un monolithe classique.
Une situation de monolithe distribué n’est pas agréable à vivre. Dans un tel contexte, on recommande de fusionner de nouveau tous les morceaux dans un seul monolithe d’abord, afin de bien redéfinir les frontières entre les différents morceaux. Au pire on se retrouvera avec un monolithe classique et modulaire.
Aucun commentaire:
Enregistrer un commentaire