Qu’est-ce qu’une architecture microservices ?

Le terme d’architecture dite « microservices », est un terme assez récent puisqu’apparu en 2011. C’est une approche logicielle où une application est décomposée en petits services qui sont spécialisés dans une seule tâche. Ce sont des services métiers au sens où ces services fournissent une fonctionnalité avec un sens métier (panier e-commerce, gestion du paiement…).

Chaque microservice possède son environnement propre (conteneur, hébergement de code, BDD) avec sa propre technologie et communique avec les autres microservices via des API agnostiques du langage de programmation.

Ces systèmes de communication, qui doivent être simples, rapidement compréhensibles et faciles à consommer permettent aux microservices de rester indépendants et donc facilement scalables et évolutifs.

On observe différents types de communications entre microservices :

  • Appels synchrones point à point,
  • Diffusion de messages asynchrones point à point,
  • Diffusion d’événements via des bus de messages auxquels s’abonnent les consommateurs.

Pour résumé, un microservice :

  • Représente une fonctionnalité métier,
  • Est déployable individuellement,
  • A son propre environnement,
  • Sa propre technologie,
  • Est indépendant et peut tomber sans (trop) impacter les autres.
…et concrètement ?

Prenons l’exemple d’un site de vente en ligne : si je suis une logique d’architecture microservices, chaque fonctionnalité de mon site aura son propre service avec sa propre équipe de développement. Il va donc sans dire que ce type d’architecture est particulièrement adapté aux gros projets générant une forte valeur ajoutée (nous y reviendrons).

De fait, chaque fonctionnalité (page d’accueil, authentification, chat, gestion panier, paiement, gestion des stocks, suivi logistique, facturation, gestion fournisseurs, transporteurs etc…) sera en mesure de communiquer avec mon interface utilisateur mais également avec n’importe lequel des autres services représentant une fonctionnalité (ex. mon tunnel de commande devra être en mesure de communiquer avec mon front, mais aussi avec le compte client, le paiement, la simulation logistique, la gestion des stocks etc…)

Un dessin valant mieux qu’un long discours, je vous invite à consulter le schéma ci-dessous. On observe clairement la multitude de microservices possédant chacun son environnement propre et capable de discuter avec l’interface utilisateur mais aussi avec ses autres « collègues » microservices de façon indépendante.

Attendez, ne partez pas sans avoir lu nos articles sur les différentes architectures et les raisons d'utiliser les microservices !