« Le Monolithe d'abord » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 27 : | Ligne 27 : | ||
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/> | 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/> | <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 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/> | 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/> | <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/> | 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/> | <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 "monolithe d'bord". 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. | |||
