Ayant lu « Les microservices, le régime tendance », vous savez ce que sont les microservices et quels sont les avantages que vous pourriez en tirer. Vous avez peut-être envie de les mettre en place mais vous ne savez probablement pas par où commencer. Avant de se lancer, il faut savoir où vous mettez les pieds et j’espère pouvoir vous déblayer un peu le chemin en écrivant cet article. Les microservices étant une philosophie d’architecture plutôt que l’application concrète d’un pattern, je ne pourrai pas aborder de façon exhaustive tous les enjeux d’une mise en place. Cependant je vais essayer d’aborder le plus de pistes possibles et d’expliciter les « grandes lignes ».

La première des choses à souligner est que la notion de microservice est extrêmement liée à celle de découpage, il faut donc avoir une application déjà en place. Je ne suis pas convaincu qu’il faille débuter le développement d’une application par une architecture en microservices. En effet, au démarrage d’un projet, nous allons nous concentrer sur l’efficacité et la rapidité de production, il ne faut donc pas se concentrer sur l’architecture puisqu’au début, nous n’avons pas d’idées concrètes du point d’arrivée. Il existe de nombreuses entreprises qui réécrivent l’intégralité de leur base de code plusieurs fois dans les premières années. Pour bénéficier des avantages d’une architecture en microservice, il faut avoir une vision fonctionnelle globale de notre application, ce qui n’est pas le cas au commencement d’un projet. Un découpage trop anticipé sera la plupart du temps un mauvais découpage. En revanche, si vous débutez, rien ne vous empêche d’être familier des notions et des différentes technologies que nous allons expliciter plus bas pour anticiper au mieux les futures découpes.

Modélisation d’un microservice

De mon point de vue, il est indispensable de connaître certaines notions avant de se lancer dans le découpage de son application. Nous allons les aborder rapidement ici, mais je vous invite à vous documenter d’avantage pour bien comprendre les enjeux.

Couplage faible

Quand 2 services sont à « couplage faible », un changement dans l’un n’entraînera pas nécessairement de changement dans l’autre. L’essence même d’un microservice est d’être capable d’y effectuer une modification et de la déployer sans avoir à modifier le reste de l’application, cette notion est donc fondamentale. Un service faiblement couplé ne connaît que le strict minimum des services avec lesquels il interagit. Il faut aussi faire attention à la fréquence d’échanges entre 2 services, parce qu’en plus des potentiels problèmes de performance, les communications récurrentes peuvent amener à un couplage fort.

Cohésion forte

Nous voulons regrouper toutes les fonctionnalités liées entre elles au même endroit car si nous voulons changer un comportement, nous devons être capable de ne le changer qu’à un seul endroit. Ceci dans le but de déployer de façon indépendante tous nos services.

Je voudrais attirer votre attention sur ces 2 concepts fondamentaux à respecter pour faire des microservices. Ces notions sont très présentes dans le monde de la programmation objet mais il est indispensable de les redéfinir et de les garder en tête lors d’un découpage en microservices.  Du coup nous voulons trouver des « limites » ou des « frontières » dans notre domaine métier qui vont nous assurer que les fonctionnalités liées se trouvent au même endroit et qu’elles ne sont pas couplées fortement avec d’autres.

Bounded Context

Le livre d’Eric Evans Domain-Driven Design explique comment créer des systèmes qui modélisent les différent domaines du « monde réel » d’une entreprise. Ce livre est rempli de principes fondamentaux comme l’utilisation d’un même langage par tout le monde (ubiquitous language), l’abstraction par repository, et bien d’autres. Mais le concept le plus important qu’Eric Evans explicite est celui des bounded context. L’idée est que n’importe quel domaine est la résultante de plusieurs « contextes limités » ayant leurs propres notions. Certaines données vont rester à l’intérieur du bounded context, lorsque d’autres vont être communiquées à d’autres bounded context. Tout ça est un peu théorique, mais disons que si un contexte correspond à une responsabilité spécifique, un « contexte limité » signifie que la responsabilité est renforcée de façon explicite par les limites.

Si vous voulez récupérer des informations d’un bounded context ou en utiliser une fonctionnalité, vous communiquerez avec sa « frontière » ou son « interface » (boundary). Eric Evans utilise une analogie avec les cellules dans laquelle « les cellules existent car leurs membranes définissent ce qui est dedans, ce qui est dehors et ce qui peut y pénétrer ».

Je dirais en conclusion, que si nos microservices représentent ces bounded context, nous avons de grandes chances d’assurer le couplage faible et la cohésion forte. La première étape est donc de les identifier dans votre application, et peut être de commencer par en faire des modules. Pour vous aider à les identifier, il faut penser aux fonctionnalités métier que fournit votre application et ne surtout pas découper vos contextes par rapport aux données qu’ils utilisent. Demandez vous d’abord « Que fait tel context ? » puis « Quelles sont les données dont il a besoin ».