Qu’est-ce qu’une architecture microservices ?

Une architecture microservices a pour objet de diviser une application en fonctionnalités encapsulées au sein de services autonomes. Chacun de ces services est géré et évolue indépendamment des autres services.

Concrètement, avec cette architecture, il est possible pour les développeurs de faire évoluer les microservices dont ils ont la charge selon des cycles de vie différents. Un service peut évoluer rapidement d’une version 1 à une version 10 tandis qu’un autre service, plus stable, resterait dans une version 1.

L’architecture orientée services (SOA Service-Oriented Architecture) et l’architecture microservices sont apparentées. Cependant, l’indépendance de services et l’importance donnée aux APIs dans la seconde sont deux points essentiels qui les différencient.

Cette architecture logicielle permet de répondre aux différentes problématiques soulevées par les applications monolithiques.

D’une application monolithique à une architecture microservices

Pourquoi aller vers une application microservices ?

Passer à une architecture microservices permet de moderniser son application notamment s’il s’agit d’une architecture avec de fortes capacités d’évolution, d’adaptation et de maintenabilité.

Avec ce type d’architecture, on s’affranchit de problèmes que l’on peut connaitre sur les applications dites ‘legacy’ (héritées du passé) :

  • Des évolutions parfois longues et difficiles à mettre en œuvre : soit parce que l’application elle-même est assez opaque et les changements risqués ; soit parce que l’architecture a évolué au fil des modifications et est devenue trop complexe ; etc.
  • Une maintenance désormais trop chère suite à de nombreux changements

Les évolutions successives et parfois mal contrôlées des applications Legacy sont autant de points qui viennent complexifier le travail des développeurs. Surtout lorsque l’équipe technique s’agrandit et que tous ses membres sont amenés à travailler en parallèle sur un même projet.

Les demandes et points d’entrées se multiplient créant des problèmes de responsabilités, difficiles à déterminer voire inexistantes, et de cohérence, souvent non respectée. L’architecture microservices tente de résoudre ce problème en instaurant un seul point d’entrée : l’API.

Dans le cadre d’applications monolithiques, nous sommes parfois face à des bases de données tellement importantes que personne ne sait réellement ce qui s’y passe. Avec une base de données par microservices, nous sommes dans un environnement beaucoup plus contrôlé

commente Sébastien Gissinger, Consultant chez SoftFluent.

Personne ne doit attaquer la base de données directement, tout se fait par l’intermédiaire de l’API du microservice

Un microservice peut-il lui aussi devenir trop lourd ?

On peut avoir un microservice qui sert à la communication afin de gérer, par exemple, les envois de mails, de sms. Si demain ce service gère beaucoup plus de paramètres, plus de volume ou présente des écarts de charges trop importants par fonctionnalité (ex : 500 000 mails/jour vs 10 sms/jour), il est préférable de diviser le microservice en plusieurs microservices. Cela permettra de les faire évoluer de manière indépendante tout en évitant qu’une dépendance ne vienne en impacter une autre et, ainsi, de gérer chaque dépendance en fonction de ses besoins spécifiques, notamment en infrastructure

selon Wesley Van den Eede, Consultant en transformation.

Comment passer d’une application Legacy à une architecture microservices ?

Passer d’une application Legacy à une application microservices est un processus long. C’est pourquoi on recommande une approche incrémentale. Au fur et à mesure, l’application est décomposée en fonctionnalités qui sont isolées au sein de microservices. Lorsque l’application est assez bien découpée, elle peut cohabiter avec une architecture microservices, le temps de moderniser le reste de l’application. Ce genre de situation est plus gérable surtout s’il n’y a pas d’interaction entre les deux.

L’arrivée d’un “petit projet” est également une bonne occasion de se lancer. Cela permet non seulement de commencer dans un contexte moins complexe mais aussi de prouver que la modernisation est possible, fonctionne et est bénéfique.

L’équipe de développeurs doit également apprendre à penser différemment. La démarche change, le développeur n’appelle plus une fonction, mais un microservice avec plus de paramètres à prendre en compte. D’ailleurs, les équipes de développeurs peuvent être gérées différemment. Il n’est pas rare de trouver des équipes dédiées à un ou plusieurs microservices.

L’avantage de ce type d’organisation est de disposer d’équipes performantes contrôlant parfaitement le microservice. Cela évite notamment d’avoir trop de développeurs enchainant les requêtes sur une même base de données.

Étape importante lors de cette modernisation : il faut analyser l’application Legacy et comprendre comment la diviser et la restructurer en microservices pertinents. Cette réflexion, qui doit se faire en amont, est directement corrélée à l’application, son organisation, ses fonctionnalités et leur importance pour le métier.

Mise en place

La mise en place d’une architecture microservices peut être envisagée de deux manières :

  1. En utilisant les services REST. C’est la manière la plus usitée et simple et à mettre en place dans un premier temps. Cependant, cette approche présente des inconvénients. Les services REST sont majoritairement des appels synchrones et, pour certains, ne sont pas rejouables simplement en cas d’erreur (principalement les opérations PUT/POST). La scalabilité, dans ce cas, est fortement conditionnée à la mise en place d’un système de balancing permettant d’équilibrer la charge entre les différents services répliqués. On ajoute donc des points de contention au système avec pour conséquences, des pertes de performances.
  2. En utilisant un bus de messages. Son rôle étant de transmettre les messages, il doit être le plus simple possible aucune logique ne doit y être intégrée. Le système devient totalement asynchrone et les microservices n’ont aucun lien entre eux. Le système devient plus tolérant aux pannes, si un service tombe le bus conservera le message qui sera alors consommé à la remise en place du service. Dans le cas d’un bus, un système de monitoring doit être mis en place pour observer la consommation des messages et l’état des services en général, le système ne générant pas d’erreur en cas de service indisponible.

Faire cohabiter ces deux approches le temps de migrer d’une solution en services REST vers une solution de bus peut être un bon compromis

déclare Ange Guyader, Team Leader chez SoftFluent.

Microservices et DevOps

Le chemin vers une architecture microservices reste long et plus ou moins complexe. Il nécessite un changement de culture, de fonctionnement et des compétences particulières de l’équipe technique. Un élément à bien prendre en compte avant d’entreprendre cette modernisation.

La culture et les outils DevOps permettent de mettre en œuvre des processus qui ne pourront être qu’avantageux pour cette modernisation et la bonne maîtrise de l’architecture.

De fait, les capacités d’adaptation et d’évolutivité appellent des méthodes de développement plus agiles et plus automatisées. On note aussi une plus forte autonomie des équipes dans les processus DevOps qui conviendra à cette notion d’équipes plus petites et plus performantes, mais dédiées à un ou plusieurs microservices.

Lorsque l’on a une architecture microservices, la démarche DevOps est indispensable. Avec une application monolithique, le travail est traditionnellement effectué en silo. Avec des microservices versionnés, on livre de manière beaucoup agile. L’architecture microservice facilite également la collaboration entre les équipes de développeurs

précise Sébastien Gissinger

SoftFluent est une société de développement informatique créée en 2005 par d’anciens consultants Microsoft et certifiée Microsoft Gold Partner. Nous vous accompagnons tout le long de votre projet afin de répondre au mieux aux besoins de votre entreprise et d’en garantir le succès.

Forte de son expérience terrain , nous pouvons répondre à vos besoins en développement d’une solution logicielle sur mesure sur la base d’une architecture microservices, d’évolution d’une application déjà existante ou tout autre projet IT.

Pour en savoir plus, contactez-nous.