Microservices : un état des lieux

En 2005, Alistair Cockburn présentait l’architecture hexagonale (ou modèle “Ports and Adapters”) afin de permettre la conception d’applications pouvant être testées en isolation de leurs runtimes et bases de données.

Cela a été l’inspiration pour l’architecture microservices, dont Alistair donna ensuite la définition suivante : “An architectural style or an approach for building IT systems as a set of business capabilities that are autonomous, self contained, and loosely coupled”

Le but principal de cette architecture ne date pas d’hier, il est question de séparer clairement le métier de l’implémentation technique (notion d'isolation).

Comme nous le verrons plus en détail par la suite, la notion d'isolation est capitale pour les microservices, or l’isolation amène la redondance, et cette dernière, on nous a appris à la "combattre" depuis des dizaines d’années.
Rappelez-vous le principe introduit dans The Pragmatic Programmer : Don’t Repeat Yourself (DRY).

Prenons le cas de 2 classes partageant un même comportement.
Comme on nous l’a appris en programmation OO, on aura généralement tendance à sortir ce comportement commun dans une classe de plus haut niveau, qui sera ensuite héritée.
Si on change le comportement de la classe mère, on impacte donc les 2 classes filles.
Cet héritage a donc augmenté le couplage entre nos classes.

Dans le cas des microservices, nous voulons éviter au maximum tout couplage, afin que ces derniers soient le plus indépendants possible. Donc, entre DRY et couplage, et isolation et redondance, la 2nd approche est privilégiée.

Du fait du développement d’Internet, tout le monde communique avec tout le monde, et est en concurrence avec tout le monde.
L’émergence des microservices est la conséquence de l’évolution de nos applications pour faire face à ces nouveaux besoins :

Pour adresser ces problématiques, des sociétés comme Netflix, Amazon, eBay commencèrent à casser leurs monolithes en services :

Ces services distribués, petits, simples et découplés permirent aux applications de devenir scalables, résilientes et flexibles.
→ Ils prirent progressivement le nom de microservices.

Les microservices sont maintenant l’architecture "par défaut" pour bâtir des applications Cloud-native.

L’approche Cloud-native a les grandes caractéristiques suivantes :

Voici une définition de l’approche Cloud-native que j’aime particulièrement :

On y parle d’exploiter les avantages qu’offre la conception dans le Cloud, afin de répondre aux nombreuses contraintes inhérentes au développement de microservices.
En effet, le développement de ces derniers est complexe, principalement car ils sont nombreux.
On ne développe jamais un mais DES microservices, dont il faut assurer la communication, le cycle de vie, le monitoring, etc etc. Tout cela nécessite la mise en place d’un environnement complexe, on parlera de capability model.

Rappelons les caractéristiques des microservices :

Ce dernier va très rapidement devoir communiquer avec d’autres microservices, ce qui se fera au travers d'API.

Afin que nos microservices puissent se trouver les uns les autres, ils s’enregistrent auprès d’un Service Discovery.

Dès lor que vous avez plusieurs instances d’un même microservice, vous avez besoin d’un Load Balancer pour distribuer le trafic et la charge.

Il faut proposer un point d’entrée unique pour tous vos services.
C’est le rôle L'API gateway, qui, de ce fait, est également le lieu idéal pour implémenter certains aspects transverses comme le routage statique et le routage dynamique.
Par exemple, en fonction de certaines données de la requête arrivante, on dirige une population de beta-testeurs sur une version spécifique de certains services.

Les microservices communiquent entre eux avec un protocole léger et indépendant de leur technologie.

la communication peut être synchrone ou asynchrone.

Vos microservices étant nombreux, vous n’allez pas gérer la configuration de chacun d’eux séparemment, il va donc falloir centraliser leur configuration.

Les microservices sont des systèmes distribués, pour éviter tout problème de réseau, ou que la défaillance d’un service (ou instance de service) n’impacte les autres, vous devez penser à la résilience de l’application dès sa conception, ce qu’on appelle le Design for failure.

Voici les principaux patterns à mettre en place :

Notre bon vieux monolithe a cédé la place à plusieurs dizaines ou centaines de microservices, en conséquence, la gestion des logs et du tracing est devenue bien plus compliquée.

Chaque microservice a ses propres logs, et une transaction utilisateur peut impliquer plusieurs de ces derniers.
Les patterns suivants permettent de ne pas se noyer dans cette masse de données :

Nos microservices sont nombreux, on ne va pas pouvoir chacun les déployer, ou les redémarrer (gestion de panne), "à la main", d’où la mise en place des patterns suivants :

Au sein de l’écosystème Spring, les projets Boot et Cloud sont ceux permettant d’implémenter des microservices.

Reprenons la conclusion précédente : "nous avons déplacé toutes les préoccupations de communication des applications en dehors du domaine métier"

Nous avons donc séparé "le métier" de tout le côté "plomberie".
Plomberie facilitée par le couple Kubernetes / Istio qui décharge grandement le développeur de sa gestion.

→ Nous avons permis au développeur de se concentrer quasi uniquement sur le métier.

Mais, ceci n’était-il pas déjà la promesse avancée par…​ JEE (Java Enterprise Edition) ?
Le développeur s’occupe du code métier, et le serveur d’application s’occupe de toute la plomberie.

Ce serveur d’application "honni", synonyme de "vieilles" applications monolithiques, avec toutes ses JSRs embarquées…​ Ne sommes-nous pas en train de le remplacer par une version plus flexible et distribuée (Kubernetes / Istio), mais, finalement, dans les services rendus, pas si éloignée ?
Au final, on pourrait voir Kubernetes / Istio comme une simple "mise au goût du jour" d’un concept vieux de 20 ans 😉