Le Monolithe d'abord
Auteur : Martin Fowler
Source : MonolithFirst
Date : 03/06/2015
Traducteur : Fabrice Aimetti
Date : 04/04/2019
Traduction :
Lorsque j'entends parler d'équipes utilisant une 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.
Les Microservices sont une architecture utile, mais même leurs défenseurs disent que les utiliser engendre un ticket d'entrée (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.
