Microservices, concept

 

Pour mémoire lors d’un précédent article, nous avons présenté le cas d’une fusion de deux entreprises ClouDigit et Clou.net. Voici le lien pour ce Use Case : Article Précédent.

Dans le cadre de cette fusion, un des enjeux à court terme, est d’utiliser le site web de Clou.net afin de proposer une nouvelle fonctionnalité, qui permettra de tirer parti de la force du réseau des 200 magasins et de la chaîne logistique de ClouDigit : une fonction de retrait en boutique dans les 2 heures, si les stocks de la boutique la plus proche le permettent.
Ce service est inexistant dans le site Web de Clou.net, également utilisé par ClouDigit, qui quant à elle fournira le service physique/opérationnel de livraison en deux heures.
Dans ce contexte un pattern d’architecture (modèle d’architecture) permet de répondre à cet enjeu : les architectures orientées « microservices ».

Microservices : concept

L’objectif de cet article est de faire une présentation simple et compréhensible du pattern d’architecture « microservices » : ses origines, les concepts et les enjeux/problématiques couverts.

Un second article « Microservices : exemple d’implémentation », détaillera quant à lui un exemple de mise en place technique des microservices sur la base du besoin issu de notre Use Case, en l’occurrence le « retrait-boutique ».

Origine

Pour mieux comprendre les microservices, il faut en connaître ses origines.
Ce terme proviendrait d’un échange entre plusieurs architectes logiciel venant de différents horizons qui, après un échange de plusieurs jours, en sont arrivés à la conclusion suivante :

<< Les systèmes d’informations sont trop grands/gros/imbriqués et donc difficilement maintenables >>. Force est de constater qu’ils sont également difficilement adaptables et évolutifs.
Ce constat s’est transformé et est devenu « Comment construire un système d’information évolutif et maintenable ? » et ils ont nommé cette architecture idyllique les micro apps.

Bien sûr, depuis ce brainstorming au début des années 2010, ce modèle d’architecture applicative s’est transformé et affiné. Il est, depuis 2014, parfaitement opérationnel, c’est le modèle d’architecture « microservices ».
Le modèle d’architecture « microservice » est souvent opposé au modèle d’architecture monolithique.

Concept

Si l’on se base sur la définition de TOGAF®, fournie par l’Open Group, le modèle d’architecture microservices, repose sur la définition et la création de systèmes/composants indépendants, auto-porteurs et alignés avec des activités métier. Un microservice est un service qui implémente une fonction métier unique, indépendante des autres instances et des autres services.
Les caractéristiques principales d’un microservice sont d’être :

  • Minimal
  • Complet
  • Ouvert
  • Élastique
  • Tolérant
  • Déployable unitairement et avoir un cycle de construction et de déploiement automatisé (DevOps).

Détaillons un peu, les caractéristiques principales des microservices.

Minimal

Un microservice est avant tout un service qui ne s’occupe que d’une entité fonctionnelle et une seule, de bout en bout, afin de rester simple et d’être indépendant des autres.
Quand le service a besoin de faire une interaction en dehors de son domaine, il se lie par API REST ou message.

Cette approche a comme conséquence indirecte de réduire :

  • La taille d’équipe intervenant sur l’implémentation (2 pizza team) ;
  • Le temps de formation de nouveaux intervenants dans l’équipe ;
  • Le temps des tests automatiques post-livraison.

Et donc, de manière générale, il augmente la qualité du livrable.

Complet

Un microservice se doit de limiter son interaction avec le reste du SI.
Dans l’idéal, il doit héberger la totalité des informations/données utilisées lors de son exécution en interne.

Cette isolation des données a certaines incidences, en l’occurrence :

  • Le type de base de données utilisées sera celui le plus adapté au service ;
  • Les données utilisées par le microservice ne seront accessibles de l’extérieur qu’indirectement ;
  • Les phases de synchronisation de données (externe-interne) sont importantes.

Ouvert

Une architecture microservices est avant tout un système de services qui communiquent entre eux.
Il est donc nécessaire pour déclencher, réguler ou inhiber le service d’offrir un interfaçage pertinent.

Deux modes de communication sont couramment employés dans ce style d’architecture.

  • On retrouve, sans surprise, une communication de type REST qui s’appuie généralement sur le protocole HTTP et
  • Une communication de type BUS qui centralise les échanges de messages.

Une autre particularité de l’interfaçage des microservices est sa tolérance.
En effet, il doit :

  • Tolérer des messages même s’ils comportent des données dont il n’a pas besoin ;
  • Pouvoir fonctionner dès lors qu’un message comporte les données suffisantes à son fonctionnement et tolérer l’absence d’informations optionnelles.

L’intérêt de cette tolérance permet de faciliter la migration des autres microservices et/ou le rollback sur les livrables.

Elasticité

Un microservice doit pouvoir s’adapter en termes de capacité, performance et disponibilité indépendamment des autres briques applicatives.
De fait, le besoin de disponibilité, performance et capacité d’un service permettant l’inscription à une newsletter est différent de celui permettant la recherche de produit sur un site e-commerce.

Techniquement, cette scalabilité des microservices est gérée principalement par :

  • Une instanciation multiple des microservices et
  • La mise en place d’un load-balanceur permettant d’adresser les différentes instances suivant le besoin.

Pour cela les microservices pourront s’appuyer sur les technologies de virtualisation (on-premise ou dans le cloud), mais aussi sur les technologies de conteneurisation, ce qui procurera l’avantage supplémentaire d’être indépendant de l’environnement cible de déploiement. Dans ces deux cas la scalabilité sera gérée par l’orchestrateur de virtualisation ou de conteneurisation.
Cependant la scalabilité implique une contrainte d’un point de vue conception du microservice ; ce dernier doit être :

  • Statefull : c’est-à-dire qu’il doit gérer son état et la gestion de cet état lui suffit pour être autonome et indépendant
    OU
  • Stateless : le fonctionnement interne du microservice est totalement indépendant d’un quelconque état, ce qui le rend donc autonome.

Ce point est crucial !

Tolérance

Il est illusoire d’imaginer que les microservices suppriment les dysfonctionnements des applications, cependant ils réduisent leurs impacts.

En effet,

  • Si une instance de microservice « plante », le microservice est toujours fonctionnel ;
  • Si toutes les instances « plantent », seul le service en question est impacté et pas le reste de l’application.

Techniquement, cette tolérance se traduit par :

  • Surveillance nécessaire des instances des microservices ;
  • Isolation des communications inter-service si possible par message (traitement asynchrone).

Déploiement unitaire, continu et automatisé

Ainsi et comme on le voit, un microservice est une entité simple, fonctionnelle et indépendante des autres. Les caractéristiques d’un microservice permettent d’avoir un cycle entre le build et la mise en production plus rapide, incluant le développement, et les tests. En plus de permettre la mise à disposition rapide du microservice en toute maîtrise, ces caractéristiques permettent également une automatisation plus simple des opérations de gestion du cycle de vie du microservice – build, tests et déploiement.
En effet, en augmentant la qualité du livrable, en automatisant les tests et en réduisant l’impact des dysfonctionnements, on se retrouve avec une évolution qui peut être livrée en production en toute sérénité.

Le modèle d’architecture microservice est donc particulièrement adapté à la mise en place et l’adoption d’une approche DevOps.

Conclusion

Si on enlève encore le risque d’erreur humaine lié à un process de déploiement manuel, on obtient enfin ce qui fait que cette architecture est adoptée par les plus grandes structures :

  • La réactivité et l’évolutivité en toute sécurité aux demandes de changement des clients ou d’un marché ;
  • La baisse de complexité du développement, des opérations et de la gestion des micrsoervices ;
  • La réduction de la complexité fonctionnelle des composants applicatifs.

Par contre le modèle d’architecture microservice apporte également son lot de contraintes :

  • Une complexité de gestion plus importante de l’ensemble des microservices liée à l’aspect distribué des différentes fonctions métier dans les différents services :
    • Des tests d’intégration plus conséquents et complexes ;
    • La gestion de la communication inter-services plus complexe.
  • Une gestion des déploiements plus complexe ;
  • Une supervision plus complexe.

Après toute cette théorie, je vous propose de passer à la pratique dans notre prochain article.