Microservices : 5 prérequis indispensables à leur développement

Les investissements nécessaires à la migration de services existants et les risques potentiels font hésiter les acteurs plus modestes, qui n'ont pas forcément l'expertise et les connaissances à disposition.

Pourtant, les avantages des applications développées en microservices sont nombreux, notamment en termes de stabilité, de flexibilité et de maintenance.
Décomposer des applications monolithiques lourdes en différents services métier, répondant chacun à des tâches bien distinctes, garantit un haut niveau de disponibilité des services aux utilisateurs et apparaît beaucoup plus simple à gérer pour les équipes de développement.

Pour réussir ce type de projet, avant de se lancer, il est important d'avoir en tête 5 prérequis :  

1-  Privilégier le développement des microservices sur les systèmes existants

Les microservices ne sont pas adaptés à tous les projets. Pour développer une architecture microservices, il est recommandé de se concentrer sur des systèmes existants monolithes, et d'en extraire les services les uns après les autres. En effet, pour être efficace, il faut savoir quel service répond à quel besoin : en partant d'un système existant, on connaît déjà les liens de communication entre les différents services, les règles métier auxquelles ils répondent et les besoins en maintenance. Il est juste nécessaire de bien préparer le terrain en réalisant une cartographie des microservices et la documentation associée.

A contrario, si l'on démarre un nouveau projet, il est difficile de savoir comment les microservices vont communiquer entre eux, et les règles métier pas encore bien définies peuvent engendrer une complexité plus importante.
De plus, le coût de mise en place d'une architecture microservices n'est pas adapté pour des nouveaux projets, et l'intérêt est très amoindri par l'absence de complexité initiale.

2-   Plus on attend, plus le changement prendra du temps

Il est possible de développer des microservices à partir du moment où les développements paraissent trop lents et que la maintenance devient trop coûteuse.. Dans ce cas, inutile d'attendre trop longtemps, car les monolithes auront malheureusement toujours tendance à se complexifier.

En revanche, il n'est pas envisageable de migrer toute l'application d'un coup. Extraire petit à petit des microservices de son monolithe peut s'avérer très bénéfique pour les développeurs et le business. Il n'est jamais trop tard pour commencer les travaux, le principal est de comprendre les bénéfices d'une architecture en microservices et les conséquences qui en découle.

3-  S'entourer d'experts techniques qui comprennent les métiers

Il est essentiel de choisir un expert qui connaît et comprend les enjeux des différents métiers, leurs limites ainsi que les liens entre eux. Il lui sera ainsi plus facile d'extraire le code lié aux fonctionnalités à développer. Techniquement, il devra bien connaître les API et leur architecture, et être soucieux de bien tester son code. En termes de technologies, il devra maîtriser Kubernetes et surtout Docker, AWS et Google Cloud, ainsi que les technologies de monitoring, de log et de tracing.

Il est également important de connaître les bonnes pratiques liées au microservices, entre autres : un (ou plusieurs) « datastore » spécifique par microservice, le concept de « stateless », les principes de déploiement continu et l'importance d'avoir un build dédié par microservice, les notions de communications et de sécurité, etc.

4-  Être conscient que le passage aux microservices demande un investissement conséquent

En effet, les investissements sont lourds d'un point de vue humain comme financier. Découper une application monolitique en différents microservices services peut se mesurer en mois, à raison d'une ou plusieurs équipes de devops et de développeurs. Il faut pouvoir assumer cet investissement. Mais les bénéfices peuvent être nombreux sur le long terme : les temps de développement s'en trouvent réduits, il est plus simple de corriger les bugs et surtout, en cas de problèmes sur un service, il est possible de programmer à l'avance le basculement sur une version alternative afin que cela n'impacte pas le parcours client.

5-  Miser sur la conception de microservices orientés DDD

Au préalable, il est nécessaire de se renseigner sur les approches de la conception pilotée par domaine, ou DDD pour Domain-Driven-Design, afin que chaque microservice soit relié à un métier bien défini. Un exemple que j'aime citer est un système de notifications. Certains pourraient avoir en tête d'avoir un microservice pour envoyer les notifications, un autre pour gérer la notion de « vu/non vu »,.. En vérité, ce ne sont pas des microservices à proprement parler, mais dans la plupart des cas des fonctionnalités propres au microservices notifications. Il faut faire attention à ne pas basculer dans des « nanoservices » et garder en tête ces notions d'unité métier.

Pour résumer, si développer des microservices n'est pas adapté à tous les projets IT, ils peuvent en sauver un grand nombre, à condition de bien anticiper leurs mises en oeuvre. Les deux clés de réussite pour ces projets sont la phase préalable de cartographie des microservices afin de définir les règles métier qu'ils régissent ainsi que les liens de communication entre les différents services, et l'accompagnement par des experts capables de conjuguer besoins techniques et fonctionnels.

_{Crédit photo : Macrovector-Shutterstock}

Thomas Ruiz, Lead Developer & Architect - Neoxia.