Domain service aggregator: a structured approach to microservice composition (par Caoilte O’Connor)

Caoilte O’Connor est développeur pour ITV, grand acteur britannique de la télévision. Il nous propose dans cette présentation de partager son retour d’expérience sur la réécriture du service de VOD sous forme de microservices. Le contenu principal de la conférence ne traite pas de l’écriture de microservices, mais bien de stratégie pour les composer.

 

Pour introduction en la matière, Caoilte cite un podcast de James Lewis sur les microservices, expliquant qu’aujourd’hui un développeur de microservice « doit se tenir sur les épaules de géants » (standing on the shoulders of giants). Cela représente la compilation d’années d’expériences et savoir-faire dans de nombreux domaines. C’est une véritable pyramide de savoirs qu’il faut absorber pour en tirer pleinement parti et pouvoir s’en sortir.

 

Le besoin est simple : alimenter les pages du service de VOD d’ITV. Telle les séries diffusées sur ces chaînes, l’histoire se déroule en plusieurs parties, chacune apportant à l’équipe de développement des joies et des peines.

Part1 : API Gateway pattern

Le service de VOD propose de revoir à la demande les émissions diffusées précédemment sur la chaîne. L’utilisateur peut donc choisir des épisodes de séries. Un épisode est composé de plusieurs informations, le titre et résumé, la programmation, les dates de disponibilités des épisodes, et le contenu. Dans leur nouvelle architecture, chaque élément est servi par un microservice. Celui-ci est développé au dessus d’un service « legacy ». La technologie de communication choisie est JSON sur HTTP.

L’API doit être capable d’être consommée par des mobiles, TV et desktop. Pour ce faire, l’équipe décide d’utiliser le pattern API Gateway provenant de Netflix. Son principe est de fournir un unique point d’entrée pour les APIs.

Le développement des applications clientes s’en retrouve facilité. Le détail d’implémentation en microservices est masqué au reste de l’architecture. Seulement voilà, le monolithe est de retour. Ce endpoint unique devient le point de contention de toute l’application. Pour une requête donnée, ce endpoint devra exécuter plusieurs requêtes HTTP aux différents microservices, ce qui revient à utiliser HTTP et des ressources pour faire des jointures ! Le module coince.

Part2 : API Gateway à l’envers

Pour diminuer la complexité de cette brique, réduire son couplage et la rendre plus efficace, l’équipe décide d’inverser les flux ! Quand une requête arrivait dans le endpoint, celui-ci lançait à son tour plusieurs requêtes qui étaient ensuite agrégées et envoyées en une seule fois au client. L’endpoint a donc le rôle de tirer l’information à lui. Pour améliorer le système, l’équipe décide que pousser l’information depuis les services vers le endpoint central au travers de queues.

Chaque service est responsable de gérer son contexte métier et de notifier le endpoint de ses modifications. Ce dernier agrège les modifications au fil de l’eau pour construire les réponses qu’il servira au client. Ce principe est fortement inspiré des architectures CQRS.

Le système est plus simple à développer et à maintenir, le comportement en production est meilleur. Seulement, ce endpoint se retrouve à connaitre tous les contextes métiers de chaque service en recopiant les éléments des différents contextes dans une seule réponse. Il y a encore pour eux trop de couplage.

Part3 : HATEOAS

Pour diminuer encore une fois cette complexité, l’équipe décide alors d’utiliser HATEOAS, l’un des principes REST qui fait couler le plus d’encre. Depuis l’étape 2, le endpoint est fortement lié aux microservices car il doit copier les données pour les consolider. S’il y a une modification dans le schéma d’un sous-service, le code endpoint est aussi impacté.

HATEOAS consiste à remplacer le contenu de chaque partie par un lien qui pointe vers ce contenu. Il est alors de la responsabilité du client d’aller chercher l’information et d’être lié au service. Le endpoint ne sert plus que ce qui est nécessaire.

Les APIs du endpoint sont donc plus légères à servir et facile à mettre en cache. Mais comme tout service REST, se pose un jour la question du versioning de ces liens.

Part4 : Versioning

La première idée est de faire du versioning via le chemin de la requête, typiquement http://monservice.com/api/v1/unicorn. Cela pose un problème pour le endpoint. Prenons le cas d’un service A du endpoint qui fournit des liens vers des services B et C. Quand A, B et C sont tous en v1, tout va bien. Si B décide de passer en version v2, que devient la version de A avec B en v2 et C en v1 : v1, v2, v1.5?

De plus, mettre la version dans le chemin gène la pérennité du lien. Pour cette partie, il n’y avait pas de réponse tranchée. L’approche que l’équipe a choisi la stratégie du header ‘Content-type’. Le leitmotiv: « pas de version pas de JSON ». En effet, lors de la négociation du contenu, si le client ne fournit pas d’information de version, le serveur rend le JSON mêlé dans du HTML. Cela permet d’avoir une API navigable depuis un navigateur mais incompréhensible par une machine. L’idée est astucieuse! Il est alors de la responsabilité du client de choisir quelle version de quelle ressource il est capable de gérer, une approche que je trouve intéressante.

 

Conclusion

C’est avec plein de modestie que Caoilte nous présente ses solutions. Sans volonté de dire que ce qu’il a fait est la règle, il nous présente plutôt sa démarche, ses joies et déceptions de la transition du SI. Je retiens principalement qu’orienter son architecture vers des microservices nécessite à chaque développeur d’être pertinent sur toute la verticalité d’un projet, du développement à son l’exploitation. Le cycle de développement est très court. Cela permet de lancer rapidement son service pour le faire communiquer avec d’autres, entrainant ainsi bon nombre de problématiques habituellement vues plus tard dans le cycle de vie du projet.

REST semble être bien adopté par la communauté pour faire communiquer des services en HTTP. Cette approche a-t-elle trouvé un nouveau terrain de développement?