Le Monolithe d'abord - Historique des versions

Fabrice Aimetti le 16 avril 2020 à 06:30

2020-04-16T06:30:02Z

← Version précédente		Version du 16 avril 2020 à 06:30
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/>

Fabrice Aimetti le 4 avril 2019 à 15:16

2019-04-04T15:16:09Z

← Version précédente		Version du 4 avril 2019 à 15:16
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 ~~"monolithique~~ 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/>		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 "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/>		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/>

Fabrice Aimetti le 4 avril 2019 à 15:14

2019-04-04T15:14:55Z

@@ 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/>
 <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/>
 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/>

Fabrice Aimetti le 4 avril 2019 à 15:04

2019-04-04T15:04:14Z

@@ Ligne 18 : / Ligne 18 : @@
 <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/>

Fabrice Aimetti le 4 avril 2019 à 13:55

2019-04-04T13:55:10Z

← Version précédente		Version du 4 avril 2019 à 13:55
Ligne 16 :		Ligne 16 :
	<br/>		<br/>
	[[Fichier:MonolithPath.png\|border\|800px]]<br/>		[[Fichier:MonolithPath.png\|border\|800px]]<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/>		<br/>

Fabrice Aimetti le 4 avril 2019 à 13:46

2019-04-04T13:46:13Z

← Version précédente		Version du 4 avril 2019 à 13:46
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]]<br/>		[[Fichier:MonolithPath.png\|border\|800px]]<br/>
	<br/>		<br/>

Fabrice Aimetti : Page créée avec « Category: Portail Equipe de développement Catégorie:Martin Fowler Auteur : Martin Fowler
Source : [https://martinfowler.com/bliki/MonolithFirst.html Monolit... »

2019-04-04T13:45:48Z

Page créée avec « Category: Portail Equipe de développement Catégorie:Martin Fowler Auteur : Martin Fowler Source : [https://martinfowler.com/bliki/MonolithFirst.html Monolit... »

Nouvelle page

[[Category: Portail Equipe de développement]]
[[Catégorie:Martin Fowler]]
Auteur : Martin Fowler 
Source : [https://martinfowler.com/bliki/MonolithFirst.html MonolithFirst] 
Date : 03/06/2015 
----
Traducteur : Fabrice Aimetti 
Date : 04/04/2019 
----
Traduction : 
 
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.''' 
 
[[Fichier:MonolithPath.png|border]]