Dans une architecture basée sur les microservices, il est important de séparer les différents services. Les services d'entité sont un pattern commun maintenant appliqué aux microservices, mais [Michael Nygard] (https://twitter.com/mtnygard) prétend qu'ils sont un anti-pattern qui vont à l'encontre de la séparation dans une courte série de billets de blog sur la manière de travailler avec les microservices.
Nygard, auteur entre autres de Release It!, note que les services d'entité sont une solution à un problème qui est régulièrement redécouvert, et fait à la fois référence à un livre électronique d'architecture sur les microservices de Microsoft et un tutoriel de Spring pour deux des nombreux exemples d'utilisation de ce pattern.
Pour Nygard, un anti-pattern est un modèle qui aggrave les choses. En argumentant que les services d'entité sont en réalité un anti-pattern, il utilise une grande application monolithique traditionnelle en tant qu'exemple. Dans cette application, il existe plusieurs instances du processus avec toutes les fonctionnalités locales et en cours de traitement :
En déplaçant cette application vers une architecture microservice, en utilisant un exemple du tutoriel Spring, certaines fonctionnalités seront toujours contenues dans l'un des services, mais Nygard prétend que la plupart des fonctionnalités nécessiteront des agrégats composés de plusieurs entités, créant ainsi des dépendances entre deux ou plusieurs services d'entité. Un exemple est de fixer le prix dans un panier qui impliquera tous les services représentés :
Pour Nygard, ces dépendances conduisent à un couplage opérationnel qui affectera la disponibilité, la performance et la capacité. Il remarque également qu'ils créent un couplage sémantique où un changement dans un service peut se répercuter sur d'autres services. Dans le pire des cas, cela peut même aboutir à un service ayant besoin de traiter différentes versions de services.
Pour Nygard, le contexte résultant du passage à une architecture de microservices avec des services d'entité inclut :
- Les équipes peuvent toujours déployer selon leur propre cadence.
- Le couplage sémantique nécessite une négociation entre équipes.
- Les services d'entité sont invoqués dans la plupart des demandes, ce qui augmente la charge.
- La disponibilité globale est couplée à de nombreux services.
Par cela, Nygard croit que les critères sont remplis pour prétendre que les services d'entité sont un anti-pattern.
Dans un autre billet, Ben Morris, architecte principal chez Fourth.com, affirme que les services d'entité utilisés dans une architecture de microservices sont plus mauvais qu'un monolithe et fait référence à la publication de Nygard. Morris fait valoir qu'un aspect important des microservices est l'autonomie, mais que plus les services sont fins, plus ils sont couplés à d'autres services, ce qui nuit à cette importante autonomie. Il note que les changements d'un processus peuvent se révéler difficiles car ils ont tendance à toucher de nombreux services, et encore plus s'ils sont gérés par différentes équipes de développement. Un risque lié aux petits services couplés est également que l'échec d'un seul service peut avoir un effet en cascade, entraînant l'échec de plusieurs processus.
Le poste de Nygard a engendré une longue discussion. L'un des auteurs du livre électronique de Microsoft note que dans l'ouvrage, ils mettent en garde contre le couplage de microservices avec des appels HTTP. Il note également l'importance d'avoir les bons modèles de domaine pour pouvoir rendre les microservices autonomes.
Dans un article de blog à venir, Nygard se penchera sur les alternatives aux services d'entité.