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” Cliquez pour tweeter. 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.

Un modèle organisationnel, une gouvernance et des outils spécifiques à mettre en place

C’est l’aspect le plus difficile pour les organisations qui souhaitent évoluer vers des modèles applicatifs “cloud natives”. Pour les entreprises qui appliquent un modèle ITIL “serveur centrique” depuis de nombreuses années, cela peut représenter un cap difficile à franchir. Les architectures Cloud natives sont “Service Centrique”. Ce seul aspect induit une véritable évolution de la gouvernance d’un SI.

Les architectures microservices nécessitent une grande maturité technique. Il ne s’agit pas seulement d’être doté des bons outils (CI/CD), encore faut-il disposer de la culture (DevOps) permettant de les mettre en œuvre de la bonne manière.

• Live and let die

La création et la destruction d’instances, parfois en quelques minutes d’intervalle sont incompatibles avec une vision “analytique” visant à stocker l’ensemble de ces informations dans une CMDB. Si cette notion garde son sens, il faut revoir le niveau de détail et la définition des “Configuration Item” à un niveau “service”.

• La vélocité de livraison, l’aspect clef des architectures microservices

L’un des principaux atouts des architectures microservices est leur capacité intrinsèque à maintenir un flot continu de livraisons.

A fur et à mesure qu’une application classique grossit, sa base de code devient de plus en plus importante. Les modifications deviennent de plus en plus complexes et coûteuses à implémenter. La fréquence des livraisons ralentit, et ce, d’autant plus vite que les demandes de changements s’accumulent.

Les architectures microservices sont une manière de segmenter une application en différents modules indépendants disposant de leur propre base de code Cliquez pour tweeter.

• Pizza & Product team

Un microservice ne peut être géré que par une seule équipe clairement identifiée et disposant d’une autonomie étendue. Contrairement à une équipe projet qui a un début et une fin, cette équipe existe aussi longtemps que le service existe. Elle est responsable des évolutions, du déploiement et du support.

Parce qu’elle est autonome dans le déploiement, elle n’a pas à attendre le passage d’un “batch” pour voir ses modifications apportées en production.

Le terme « Pizza Team » nous vient de Jeff Bezos (PDG Amazon) et signifie que l’équipe doit pouvoir être nourrie par une ou deux pizzas. Cette taille réduite est le garant d’une productivité maximale (partant du principe de nombreuses fois éprouvé que la productivité d’une équipe chute de manière importante au-delà de 9 personnes).

Quelques conclusions et vérités …

Il n’est pas possible de traiter ce sujet de manière exhaustive dans un seul article tant il est vaste et complexe. Nous pouvons cependant tirer quelques conclusions et rétablir quelques vérités permettant d’y voir un peu plus clair.

• Culture DevOps et outils adaptés

La mise en œuvre d’une architecture microservices requiert de hautes compétences techniques et une grande maturité de la culture DevOps. L’infrastructure sous-jacente doit être entièrement automatisée (raison pour laquelle la plupart des applications microservices sont créées dans le Cloud Public) et dotée des outils permettant la mise en œuvre des concepts de Continuous Integration / Continuous Deployment (CI/CD) et d’Infrastructure as Code (IaC)

• Gérer la complexité d’un système distribué

L’ADN d’une application microservices réside dans le couplage faible des différents modules. Cette caractéristique implique une distribution de l’information et un mode de communication asynchrone. La gestion et l’évolution d’un tel système est extrêmement complexe et nécessite de fortes compétences.

• GreenField ou BrownField ?

Le découpage en microservices est un exercice périlleux très structurant pour le futur de l’application. Les choix effectués lors de la création d’une application devront être assumés dans le temps alors que de nombreuses hypothèses n’ont pas encore été éprouvées par la réalité du terrain.

Pour ces raisons, de nombreuses voix s’élèvent pour disqualifier les architectures microservices dans le cadre d’une création. Une application “microservices” étant infiniment plus complexe à maintenir (il faut parfois créer ses propres outils pour assurer le MCO).

Une architecture ne devient pertinente qu’à partir du moment où votre application est devenue trop lourde et trop complexe à maintenir d’un seul bloc et que cela devient un problème stratégique pour l’entreprise.

Quand on entame la migration d’une application vers une architecture microservices on parle parfois de “peler l’oignon”. On va enlever une à une les couches de l’application en identifiant les services à sortir jusqu’à ce que le code d’origine ait totalement été remplacé.

Microservices : Un choix stratégique

Dans un monde où toute entreprise est destinée à devenir une “software company” (dixit Satya Nadella, CEO Microsoft). L’utilisation des architectures microservices doit être évaluée au regard d’impératifs stratégiques.

• La nécessité d’innover ou de pénétrer de nouveaux marchés
• La nécessité d’aligner les objectifs métiers et l’outil informatique
• La nécessité de changer les structures de gouvernance de l’IT pour permettre des prises de décisions rapides
• La nécessité de s’adapter plus rapidement aux conditions du marché
• La nécessité de défendre son marché contre des concurrents disruptifs

Ces choix sont souvent une question de survie pour les entreprises concernées. En conséquence, si vous n’avez pas encore commencé à mettre en œuvre ce type d’architecture, il y a peu de chance que vous en ayez réellement besoin.

Cependant, si les concepts DevOps, CI/CD et les pizza team sont des composantes récurrentes des architectures microservices, ces pratiques conservent toute leur valeur dans un modèle plus classique.

Rien que dans ce domaine, il y a déjà fort à faire pour gagner en agilité et en productivité !

Pour aller plus loin sur thème  sur le site iTPro.fr : 

1. Vidéo : A la découverte d’Azure Container Apps ! · iTPro.fr
2. Les Microservices sont-ils l’avenir des applications en entreprise ? · iTPro.fr