La clé de la réussite en travaillant avec un système distribué basé sur des microservices est de se concentrer sur le processus distribué en tant que tout, et non sur les microservices eux-mêmes. D'après Eric Ess, les services sont l'aspect le moins important, comme il l'expliquait pendant la Microservices Conference à Londres, dans sa présentation sur la manière de monitorer les processus distribués chez jet.com.
Chez Jet, un processus dont le point de départ est un utilisateur et qui implique quelques microservices pour se terminer est appelé processus distribué. Ess, directeur de l'ingénierie, explique et note que c'est un terme clé pour eux quant à l'exécution des requêtes clients par leurs systèmes.
Jet possède environ 800 microservices en production aujourd'hui conduisant à une topologie de communication complexe. De ce fait, il n'est pas possible pour une équipe de savoir ce qui se passe en dehors de leur périmètre, tout comme il n'est pas possible pour une seule personne de comprendre l'ensemble de l'architecture des systèmes. Malgré cette complexité, quand il y a des problèmes en production, il est essentiel de comprendre où se situe la cause racine, et le service qui en est la source.
Pour dépasser ce défi, ils travaillent sur deux éléments :
- La compréhension du comportement d'un seul processus, par quels microservices il passe et ce qu'il fait - c'est à dire le suivi des différents types de processus à mesure de leurs avancements dans le système à travers les microservices interagissant avec les autres.
- La validation des processus en définissant les flux attendus pour un processus donné, puis la validation que l'exécution correspond au chemin attendu. Ess note que même un processus ne générant pas d'erreurs peut avoir un comportement déviant. Un exemple est un bug en test A/B qui oriente le processus vers le mauvais chemin, impliquant un biais dans les données de test.
Ess souligne qu'en se concentrant sur le processus distribué dans son ensemble, et pas uniquement sur les microservices, ils peuvent les oublier. Les microservices ne sont plus qu'un moyen pour le déroulement du processus vers le service suivant et une étape vers la fin du processus. Leur attention est orientée vers l'état actuel du processus et ce qui lui arrive.
Ceci implique un état d'esprit différent, avec des ingénieurs se concentrant sur le comportement du processus dans le système, et non sur le microservice ou la manière dont il devrait se comporter en recevant un message. Une équipe ne construit pas des microservices individuels, mais des microservices qui interagissent avec d'autres.
Il y a beaucoup d'outils disponibles pour évaluer les microservices ou un système, mais pas pour évaluer le processus, ou le comportement du processus dans son exécution. De plus, Jet utilise F# et comme il est difficile de trouver des outils adéquats dans ce langage, ils ont dû créer les leurs.
Pour fournir une vision du système et des processus tournants, ils ont créé un protocole de communication (Dr Orpheus) qui propose un ensemble de métadonnées en entête passant dans chaque message et quelques règles sur ce qu'un microservice doit faire lorsqu'il reçoit un message avec ces métadonnées. Ils construisent également XRay, un moteur de télémétrie de flux processus / data qui opère quelques traitements d'événements complexes (CEP), en collectant les données émises par tous les microservices au fil de l'eau. Les équipes de développement et business peuvent suivre tous les processus et réagir quand il y a des comportements anormaux, ne respectant pas le chemin attendu, allant trop lentement ou bloquant d'autres services.
La prochaine Microservices Conference se tiendra à Londres les 6 et 7 novembre 2017.