Les Microservices sont-ils l’avenir des applications en entreprise ?

Les Microservices à l’orde du jour, avec la montée en puissance de la containerisation dans les entreprises, on recommence à entendre parler de ce terme comme le nouveau graal, la prochaine étape de l’évolution de nos applications.

Microservices ou maxiservices ?

Avant de décrire plus précisément ce que sont les microservices, commençons par tordre le cou à certaines idées reçues.

“Je déploie des applications en container donc je fais du Microservice.”

Non, il ne suffit pas de découper une application en différents “modules” et de les containeriser pour pouvoir parler de microservices. Au plus, on ne fait que reproduire une architecture “n tiers” avec des containers.

“Les Microservices sont des containers”

Non, si la containerisation est bien adaptée aux architectures microservices, il est tout à fait possible d’envisager d’autres “contenants” (ex : des machines virtuelles ou des web apps).

“Les Microservices sont de “petits services” web « 

Oui, mais il est abusif de réduire les microservices à de “petits services” s’échangeant des requêtes REST ou SOAP, c’est bien plus que cela.

Bien qu’il n’existe pas de définition normalisée des architectures microservices, Martin Fowler, auteur reconnu et pionnier dans le domaine, les décrit comme « Un style d’architecture qui partage des caractéristiques communes avec les aptitudes de l’entreprise» (Organisation, Processus, Management).

Architectures Microservices

En ce sens, les architectures microservices ne peuvent se résumer à une infrastructure technique ou une manière d’organiser l’exécution de son code applicatif. Les microservices sont une combinaison de modèles techniques et organisationnels destinés à apporter une réponse à des questions stratégiques. Comment construire des applications ultra résilientes et conserver une capacité d’innovation et d’adaptation à des échelles massives ?

Qu’est-ce qui définit une architecture microservices et qu’est-ce qui la différencie d’une architecture classique ?

La réponse à cette question s’articule en deux axes indissociables. Un axe technique (Architecture, Technologie, Patterns) et un axe organisationnel (Processus, Organisation, Management).

Une architecture spécifique héritée des SOA

Certes, les architectures microservices sont constituées de multiples “petits services”, mais elles répondent à des patterns spécifiques qui les différencient d’une architecture “n tiers” classique. Les architectures microservices partagent de nombreuses caractéristiques avec les architectures SOA (Service Oriented Architecture).

Pour Steve Jones, CTO de CapGemini, les architectures MS ne sont qu’une approche orientée “Delivery” d’une SOA bien conçue.

• Communication asynchrone et API Gateway

Les architectures microservices disposent de concepts similaires aux SOA comme un “Bus de message asynchrone” permettant de gérer la communication des différents modules. L’API Gateway est un pattern essentiel permettant de répondre à l’éclatement de l’application en de multiples “endpoints”. Cet élément permet d’exposer aux consommateurs une API uniforme de manière sécurisée.

• Scalabilité et résilience

Un autre pattern essentiel des architectures microservices est sa capacité à répondre à la charge de manière différenciée. Plutôt que de déployer de nouvelles instances d’une application, seuls les services sollicités sont déployés puis détruits dès que la charge est redescendue.

Les architectures microservices prônent un modèle basé sur la “résilience” plutôt que sur la “robustesse” Share on X. Le crash d’un processus ne peut entraîner la disparition du service, son existence étant assurée au travers de multiples réplicas, créés et détruits à la demande.

• Monolythe VS Microservices

On oppose souvent les architectures microservices (modulaires) avec le modèle classique “Monolithiques”.

Imaginez votre application monolithique comme un train composé de wagons représentant vos différents modules. Dans le cas où l’un des wagons aurait un problème, il y a de fortes chances pour que votre train déraille. De même, si vous devez effectuer une modification sur l’un des wagons, vous devrez procéder à la livraison d’un train complet.

Comme cette opération est lourde, vous allez attendre un nombre de modifications suffisant pour justifier le lancement d’un nouveau train. De même, si un seul des wagons est plein, vous allez probablement devoir déployer un ou plusieurs nouveaux trains.

Imaginez une flotte de véhicules Uber

Par opposition, une application microservices est plutôt comme une flotte de véhicules Uber. Le crash d’un véhicule n’a pas d’incidence sur le service tant qu’un nombre suffisant de véhicules identiques est disponible. Si un type de véhicule est trop demandé, il suffit d’en rajouter en circulation.  De même il existe des patterns permettant de mettre à jour les véhicules sans perturber le service (Blue Green deployment, Canary Release etc.)

Bien sûr, ce modèle nécessite une application pensée et développée dans ce sens, mais cela ne suffit pas. Pour en tirer parti il faut avoir adopté un modèle organisationnel particulier.