« Le Monolithe d'abord » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (Une version intermédiaire par le même utilisateur non affichée) | |||
| Ligne 15 : | Ligne 15 : | ||
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/> | 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/> | <br/> | ||
[[Fichier:MonolithPath.png|border|800px]]<br/> | [[Fichier:MonolithPath.png|border|800px|link=]]<br/> | ||
<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/> | 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/> | ||
| Ligne 23 : | Ligne 23 : | ||
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/> | 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/> | <br/> | ||
J'ai entendu parler de différentes façons d'exécuter une stratégie | 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/> | <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/> | 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/> | ||
| Ligne 33 : | Ligne 33 : | ||
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/> | 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/> | <br/> | ||
Je ne pense pas avoir encore assez d'anecdotes pour bien comprendre comment décider d'utiliser une stratégie | 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/> | <br/> | ||
'''Lectures complémentaires'''<br/> | '''Lectures complémentaires'''<br/> | ||
