Parmi les raisons qui poussent à la création de microservices, on trouve souvent l'isolation comme moyen de faciliter le changement. Partager du code entre des services couple ces derniers, ce qui réduit l'efficacité de l'isolation et la capacité d'opérer le changement. Dans une série d'articles, David Dawson questionne le concept de Don’t Repeat Yourself (DRY) pour les microservices.
David, CEO de Simplicity itself, compte plusieurs raisons de créer des microservices dont :
- La scalabilité indépendante
- L'isolation des services
- La séparation des cycles de vie des services
David pense que toutes ces raisons sont liées à la facilitation du changement, que ce soit dans l'environnement ou le code. Il pense également que le changement est souvent le principal moteur de séparation des services.
Selon David, les raisons pour lesquelles les développeurs partagent du code entre les services sont peu nombreuses. Parmi elles, on trouve :
- Tirer parti de fonctionnalités techniques existantes (ex : par des bibliothèques partagées)
- Partager des schémas de données (ex : en utilisant les mêmes classes)
- Partager des sources de données (ex : utilisation du même stockage par plusieurs services)
David met l'accent sur le fait que partager du code va lier les services entre eux. Créer une seule source de vérité, en respectant le principe de DRY au sein d'un même service va créer du couplage mais ne posera pas de problème si ce service a une seule responsabilité. A contrario, lorsque l'on dépasse ces frontières, quand bien même des similitudes existent, les contextes sont différents et les problématiques doivent être implémentées avec des codes différents et des sources de données différentes. David insiste sur le fait que, bien que les choses se ressemblent, il faut résister à la tentation de lier des services parce que cela signifie que l'on couple des contextes différents à travers les frontières, ce qui est le chemin direct vers une grande boule de boue.
David pense que le principe de DRY est devenu l'un des fondamentaux du développement logiciel, à l'instar des design patterns, mais qu'il a également été transformé en principe de Don’t Repeat Anything (ne rien répéter) et Copy and Paste is bad (copier-coller c'est mal). À l'origine, dans le livre "The Pragmatic Programmer", DRY était décrit comme ceci :
Tout morceau de connaissance doit avoir une seule représentation non-ambiguë au sein du système.
David note que le mot-clé est le concept de connaissance, et non la recopie. Bien que le principe soit utile dans certains cas, il pense que le terme a été pris hors de son contexte et appliqué trop largement. Appliqué à un plus haut niveau sur une architecture en microservices, en partageant un schéma par exemple, cela implique un coût de maintenance sans pour autant apporter les bénéfices liés à DRY.