Je ne m'amuse généralement pas à chroniquer les ouvrages techniques que je lis. Mais je me suis décidé à le faire pourtant, sur la deuxième édition de cet ouvrage de Sam Newman paru chez O'Reilly, pour une mise à niveau professionnelle. Il y a je crois, derrière cet exercice, la volonté de mieux assimiler des concepts (qu'ils soient techniques ou plus littéraires d'ailleurs). Il s'agit donc plutôt de synthétiser cet ouvrage, de manière différente que je le fais habituellement, en reprenant les citations retenues.
L'ouvrage est incrémental: il pose d'abord les bases de l'architecture en microservices. De l'extérieur, un simple microservice doit être traité comme une boite noire. Ce qui implique notamment qu'une telle architecture doit éviter au maximum l'usage de base de données partagées. Et par conséquent, que chaque microservice embarque sa propre base de données quand cela est possible. Et un tel compartimentage passe par cacher l'information, en n'exposant que le minimum sur des interfaces externes.
L'indépendance concerne aussi le déploiement des microservices. Cette notion implique le fait de pouvoir monter en version une partie du système, sans avoir à tout redéployer. Idéalement, chaque instance de microservice devrait pouvoir s'exécuter en isolation. Mais la question qui se pose alors concerne les moyens de faire transiter de la donnée entre microservices, afin d'assurer une communication entre eux. Et la rémanence des communications requiert une attention particulière à l'agrégation des logs, qui est un pré-requis essentiel à de telles architectures. Pour l'auteur, les logs sont d'importance capitale pour la compréhension du système, notamment en production. Il est donc indispensable d'y penser dès la phase de conception (et une attention particulière doit être consacrée aux identifiants de corrélation entre les logs de différents microservices, pour une requête donnée). Cela s'avère pertinent lors d'une phase de test, notamment de bout en bout.
La réflexion initiale de l'architecte d'un tel système doit, pour Newman, se concentrer sur les domaines d'activité. Malgré le fait qu'il puisse y avoir des alternatives au "Domain-Driven Design" (qui semble être la recommandation). L'auteur énonce par exemple les alternatives d'architectures basées sur les contraintes suivantes:
D'ailleurs, Newman met immédiatement en garde le lecteur quant à la difficulté de migrer d'une architecture monolithique à une architecture en microservices. Pour lui, une telle migration doit se concrétiser uniquement si les moyens d'arriver aux objectifs finaux ne sont pas possible en monolithe. Car les transactions distribuées sont complexes à implémenter, et que ce but ne peut s'atteindre que de manière incrémentale.
L'auteur rédige un chapitre entier sur les différents types de communication possibles entre microservices. Selon lui, les mécanismes les plus pertinents sont la communication bloquante synchrone et la communication non-bloquante asynchrone. Il détaille aussi les modes de collaboration par requête-réponse et par événement. Ce qui peut parfois passer par la sérialisation et dé-sérialisation des données pour une transmission réseau (en prenant en compte la charge utile des messages). Pour résumer, Newman définit ces quatre principes de la manière suivante:
Le mode non-bloquant asynchrone permet davantage de parallélisation et peut drastiquement améliorer la latence des opérations du système.
For smaller teams, either approach is fine, but as you scale, I feel that the one repository per microservice (multirepos) approach is more straightforward.
Parmi les aspects fondamentaux à avoir en tête dès la phase de conception, la cybersécurité apparaît aussi primordiale. Paradoxalement, malgré l'isolation, les attaques peuvent couvrir une plus grande zone dans une architecture en microservices. Il y a en effet davantage de modules à couvrir pour se défendre. Le NIST définit les cinq préceptes suivants à considérer dès la conception: identification, protection, détection, réponse et récupération. Les accès aux données sont notamment à sécuriser, en déployant par exemple:
Mais il est aussi suggéré de concevoir l'architecture en la découpant par zones, selon la sensibilité des données qu'elles couvrent. Ce modèle peut être aussi bénéfique afin d'améliorer la résilience du système en cas de panne, pour sa robustesse, son rebond, son extensibilité et adaptabilité.
Un chapitre est consacré à la mise a l'échelle. Je l'ai parcouru rapidement. Il y a dans cet ouvrage conséquent beaucoup d'information à assimiler (un répertoire de version par microservice, par exemple). Je n'ai pas achevé la lecture, car j'ai surtout réalisé que ce genre d'ouvrage technique ne se lit pas de manière linéaire: ce sont des lectures sur lesquelles on revient, pour se rafraîchir la mémoire ou consolider une notion. Je sais du coup que je serai amené à y revenir, tant l'ouvrage est instructif.