Note de lecture : Spring Microservices in Action, par John Carnell

Note : 7 ; Il reprend là où « Spring Boot in Action » s’arrête…

Effectivement, « Spring Boot in Action » m’avait laissé sur ma faim. C’est essentiellement parce qu’il se focalisait sur la construction d’une application MVC, nous laissant un peu démuni sur la construction d’un serveur Rest, qui constitue pourtant l’un des cas d’usage nominaux. C’est bien sur ce cas d’usage et pas un autre que se focalise ce volume. Mais il va plus loin en couvrant l’intégralité de l’architecture microservices grâce à la stack Neflix et à son intégration dans Spring.

Je commence à froncer les sourcils à partir de 300 pages, mais les 350 de celui-ci se digèrent assez bien, malgré des chapitres aussi en moyenne plus volumineux que ce que j’apprécie généralement : ce volume en compte 10. Les 35 pages de l’introduction s’avalent très bien, on y a droit à une vue générale de l’architecture des applications microservices avec Spring Boot. C’est à la fois plus concret que ce que l’on croise généralement et aussi fort bien illustré, une constante du livre. Certes on n’a pas produit de code (mais l’auteur nous en dispense des fragments) mais on a un plan précis de ce qui nous attends.

La trentaine de pages du chapitre 2 nous amène vers le « hello world » du microservice et même un peu plus loin avec un certain nombre de considérations liées au déploiement. Tout cela s’avale très bien et on peut déjà se salir les mains avec succès. Cela dit, moi j’aurais fait deux chapitres… C’est également une trentaine de pages qui nous attends avec le chapitre 3, où l’on prend de plein fouet la stack Netflix, plus exactement, Eureka, à partir duquel l’auteur nous amène à construire un serveur de configuration. L’architecture de déploiement prends soudain beaucoup plus de complexité, mais c’est somme toute le destin des architectures microservices.

Comme on peut s’y attendre, cela se complique encore au chapitre 4 avec le Service Discovery. Il y est encore question d’Eureka. Le début du chapitre va bien, où l’architecture est détaillée, ainsi que les objectifs visés. Cela se complique vers la fin, d’autant plus avec les deux librairies de Client Discovery. Espérons que les futures versions de Spring Cloud simplifieront cela… Le chapitre 5 et les patterns de résilience sont un soulagement pour moi, j’ai de nouveau les pieds qui touchent le sol. C’est la librairie Hystrix qui supporte ces patterns (circuit breaker, bulkhead, fallbacks). Mais l’essentiel est dans les patterns eux-mêmes. Le chapitre pique un peu sur la fin avec les éléments de configuration avancée d’Hystrix, même si les auteurs font un bon boulot à rendre cela clair.

Notre architecture Cloud est loin d’être terminée. Le chapitre 6 introduit un proxy server servant de Service Gateway (qu’il faudra évidemment connecter à Eureka) : Zuul. Tout comme Eureka, c’est un nouveau serveur à créer sur un socle Netflix. Le point chaud est la configuration des routes et c’est là où Zuul s’appuie sur le service discovery, à savoir Eureka ! Au premier niveau, à savoir la configuration des routes, cela reste simple d’abord et on se demande même pourquoi on devrait développer notre propre serveur plutôt que simplement configurer des routes. La réponse arrive en seconde partie de chapitre avec les filtres et surtout les corrélations d’Ids. Un chapitre qui aurait lui aussi mérité d’être coupé en deux.

Le chapitre 7 était fort attendu : sécuriser l’accès à l’application. Cela commence en douceur avec la construction d’un serveur sur le socle EagleEye (on commence à avoir l’habitude), puis l’ajout de Spring Security à l’application avec l’ajout des grants sur les services. J’oserais dire que l’on s’y attendait. Là aussi j’aurais apprécié un chapitre découpé en deux : la seconde partie avec la propagation de token OAuth2 (Zuul, le retour) et surtout les JavaScript Web Token (dont on comprend vite qu’il est difficile d’y échapper) rende la fin du chapitre moins confortable.

Pour vraiment se conformer au modèle Microservice de Newman, il faut supporter une communication Event-Driven. C’est ce que couvre le chapitre 8 avec Spring Cloud Stream accolé à Apache Kafka. Le chapitre serait assez reposant, les cinématiques de production et consommation étant clairement détaillées et illustrées par exemple, si le cas d’étude était moins ambitieux. Un cache distribué s’adossant à Redis n’est pas l’idéal pour cela.

Notre avant dernier chapitre est consacré aux logs partagés et à tout l’outillage pour opérer des corrélations et suivre des transactions entre de multiples services. Intéressant et puissant, mais pas très facile à digérer ! L’ouvrage se referme par le volet déploiement. Ici rien de relatif à Spring, on y a droit à l’approche de l’auteur pour déployer sur AWS. A savoir un backbone sur Travis CI, puis pas mal de Python pour tout scripter. Apparemment, l’utilisation d’outils comme Ansible n’est pas son trip.

L’ouvrage est dense, car le sujet l’est aussi. Il ne s’agit pas ici de seulement développer une application microservice, ce qui est globalement traité en fin de chapitre 4, mais de construire toute l’architecture état de l’art. Quelque chose qu’on ne peut guère digérer en une seule fois. Mais le texte fait un très bon boulot, même s’il est à consommer en plusieurs fois !

Spring Microservices in Action, par John Carnell

Référence complète : Spring Microservices in Action – John Carnell – Manning 2017 – ISBN : 978 1 61729 398 6

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.