Voir la source de Le Monolithe d'abord

[[Category: Portail Equipe de développement]]
[[Catégorie:Martin Fowler]]
Auteur : Martin Fowler<br/>
Source : [https://martinfowler.com/bliki/MonolithFirst.html MonolithFirst]<br/>
Date : 03/06/2015<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 04/04/2019<br/>
----
Traduction :<br/>
<br/>
Lorsque j'entends parler d'équipes utilisant une [https://martinfowler.com/articles/microservices.html architecture de microservices], j'ai remarqué une tendance commune :
# Presque toutes les histoires réussies de microservices ont commencé avec un monolithe qui est devenu trop gros et qui a été brisé.
# Dans presque tous les cas où j'ai entendu parler d'un système qui a été conçu comme un système de microservices dès le début, il a fini par avoir de graves problèmes.
Cette tendance a conduit beaucoup de mes collègues à dire qu''''il ne faut pas commencer un nouveau projet avec des microservices, même si l'on est sûr que l'application sera suffisamment grosse pour en valoir la peine.'''<br/>
<br/>
[[Fichier:MonolithPath.png|border|800px|link=]]<br/>
<br/>
Les Microservices sont une architecture utile, mais même leurs défenseurs disent que les utiliser engendre un ticket d'entrée ([https://martinfowler.com/bliki/MicroservicePremium.html MicroservicePremium]) significatif, ce qui veut dire qu'ils sont seulement utiles avec des systèmes plus complexes. Ce ticket d'entrée, essentiellement le coût de gestion d'un ensemble de services, ralentira une équipe, favorisant un monolithe pour des applications plus simples. Ceci donne un argument puissant en faveur d'une stratégie du monolithe d'abord, dans laquelle vous devrez initialement construire une nouvelle application sous forme d'un monolithe, même si vous pensez qu'il est probable qu'elle bénéficiera plus tard d'une architecture de microservices.<br/>
<br/>
La première raison est le classique Yagni ("you ain't gonna need it", "vous n'en aurez pas besoin"). Lorsque vous démarrez une nouvelle application, à quel point êtes-vous sûr qu'elle sera utile à vos utilisateurs ? Il peut être difficile de mettre à l'échelle un système logiciel mal conçu mais réussi, mais c'est quand même mieux d'être dans cette situation plutôt que l'inverse. Comme nous l'entendons aujourd'hui, la meilleure façon de savoir si une idée de logiciel est utile est souvent de construire une version simpliste de celui-ci et de voir si elle fonctionne bien. Au cours de cette première phase, vous devez donner la priorité à la vitesse (et donc au temps de cycle pour récupérer des feedbacks), de sorte que le ticket d'entrée des microservices est un frein et vous devriez vous passer.<br/>
<br/>
Le deuxième problème lorsqu'on commence avec des microservices, c'est qu'ils ne fonctionnent bien que si vous établissez de bonnes frontières stables entre les services, ce qui consiste essentiellement à tracer le bon ensemble de BoundedContexts. Tout refactoring de la fonctionnalité entre les services est beaucoup plus difficile que ça n'est pour le monolithe. Mais même les architectes expérimentés travaillant dans des domaines familiers ont beaucoup de mal à fixer les frontières des domaines dès le début. En construisant d'abord un monolithe, vous pouvez déterminer quelles sont les bonnes frontières, avant que la conception en microservices ne les recouvre d'une couche de mélasse. Cela vous donne également le temps de développer les MicroservicePrerequisites dont vous avez besoin pour des services de la bonne granularité.<br/>
<br/>
J'ai entendu parler de différentes façons d'exécuter une stratégie du monolithe d'abord. La manière logique est de concevoir un monolithe avec soin, en prêtant attention à la modularité du logiciel, tant au niveau des frontières de l'API que de la façon dont les données sont stockées. Faites-le bien, et c'est ensuite relativement simple de passer aux microservices. Cependant, je me sentirais beaucoup plus à l'aise avec cette approche si j'avais entendu un nombre suffisant d'histoires où cela s'est passé ainsi.(1)<br/>
<br/>
Une approche plus courante consiste à commencer par un monolithe et à progressivement éplucher les bords avec des micro-services. Une telle approche peut laisser un important monolithe au coeur de l'architecture des microservices, mais la plupart des nouveaux développements se produisent dans les microservices alors que le monolithe est relativement stable.<br/>
<br/>
Une autre approche courante consiste à remplacer complètement le monolithe. Peu de gens considèrent cela comme une approche dont ils peuvent être fiers, mais il y a des avantages à construire un monolithe comme une [https://martinfowler.com/bliki/SacrificialArchitecture.html Architecture que l'on va sacrifier]. N'ayez pas peur de construire un monolithe que vous allez jeter, surtout si un monolithe peut vous amener rapidement sur le marché.<br/>
<br/>
Une autre voie que j'ai empruntée consiste à commencer par quelques services de grosse granularité, plus gros que ceux que l'on s'attend à trouver. Utilisez ces services à grosse granularité  pour vous habituer à travailler avec plusieurs services, tout en profitant du fait qu'une telle granularité réduit la quantité de refactoring interservices à mener. Puis, à mesure que les frontières se stabilisent, les services se décomposent en services de granularité plus fine.(2)<br/>
<br/>
Bien que la majorité de mes contacts penchent en faveur de l'approche "monolithe d'abord", elle ne rencontre pas l'unanimité, loin s'en faut. Un contre-argument serait qu'en commençant par les microservices, on s'habitue au rythme de développement dans un environnement de microservices. Il faut beaucoup, peut-être trop, de discipline pour construire un monolithe de manière suffisamment modulaire pour pouvoir le décomposer facilement en microservices. En commençant par les microservices, vous habituez tout le monde à développer en petites équipes séparées dès le début, et le fait d'avoir des équipes séparées par les frontières des services facilitera grandement la mise à l'échelle de l'effort de développement lorsque vous en aurez besoin. C'est particulièrement pertinent pour les remplacements de systèmes où vous avez plus de chance de trouver des frontières suffisamment stables, suffisamment tôt. Bien que les preuves soient rares, je pense que vous ne devriez pas commencer par les microservices à moins d'avoir une expérience raisonnable de la construction d'un système de microservices dans l'équipe.<br/>
<br/>
Je ne pense pas avoir encore assez d'anecdotes pour bien comprendre comment décider d'utiliser une stratégie du monolithe d'abord. Les microservices n'en sont qu'à leurs débuts et il y a relativement peu d'anecdotes dont on peut tirer des leçons. Par conséquent, les conseils de quiconque sur ces sujets doivent être considérés comme provisoires, quelle que soit la confiance qu'ils suscitent.<br/>
<br/>
'''Lectures complémentaires'''<br/>
<br/>
Sam Newman [https://samnewman.io/blog/2015/04/07/microservices-for-greenfield/ décrit une étude de cas] d'une équipe qui envisage d'utiliser les microservices dans le cadre d'un nouveau projet.<br/>
<br/>
'''Notes'''<br/>
<br/>
'''(1)''' Vous ne pouvez pas supposer que vous pouvez prendre un système arbitraire et le décomposer en microservices. La plupart des systèmes acquièrent trop de dépendances entre leurs modules, et ne peuvent donc pas être simplement séparés. J'ai entendu parler de nombreuses situations où une tentative de décomposition d'un monolithe s'est rapidement retrouvée dans le pétrin. J'ai également entendu parler de quelques situations où l'accès graduel aux microservices a été couronné de succès - mais ces situations nécessitaient au départ une conception modulaire relativement bonne.<br/>
<br/>
'''(2)''' Je suppose qu'il faut strictement appeler cela un "duolithe", mais je pense que l'approche suit l'essence de la stratégie du monolithe d'abord : commencer par une grosse granularité pour acquérir de la connaissance et découper ensuite.<br/>
<br/>
'''Remerciements'''<br/>
<br/>
J'ai volé une grande partie de cette réflexion à mes collègues : James Lewis, Sam Newman, Thiyagu Palanisamy et Evan Bottcher. Les commentaires de Stefan Tilkov sur une version antérieure ont joué un rôle central dans la clarification de ma pensée. Chad Currie a créé les adorables dragons glyphes. Steven Lowe, Patrick Kua, Jean Robert D'amore, Chelsea Komlo, Ashok Subramanian, Dan Siwiec, Prasanna Pendse, Kief Morris, Chris Ford et Florian Sellmayr ont discuté des différentes versions de cet article sur notre liste de diffusion interne.