Dans cet article, nous verrons:

1. Comment monitorer ses microservices  ?

2. Comment tester les microservices ?

3. Quels outils utiliser pour monitorer vos services ?

La première étape d’une transformation digitale consiste, pour la plupart des entreprises, à migrer leurs applications existantes monolithiques vers une plateforme Cloud, qui permet une transition rapide et économique sur le court terme avec cependant le risque non négligeable que l’application ne soit pas optimisée pour le Cloud. Quand on sait que les coûts d’exploitation d’un logiciel non-optimisé pour le Cloud peuvent, sur le long terme, dépasser les coûts de développement, on comprend vite l’intérêt d’une architecture de microservices, qui permet de mieux tirer parti de l’agilité et de la scalabilité d’une infrastructure Cloud.

En revanche, c’est un véritable défi que de choisir le bon niveau de granularité de nouveaux microservices au sein d’une application, non seulement leur taille, mais aussi leur champ d’application et leurs limites.

L’autre défi majeur que pose le développement de microservices est la capacité à tracer l’opération d’un client à travers tous les services impliqués dans le traitement. Le traçage facilite le débogage, l’analyse des performances, les tests A/B et d’autres diagnostics standards.

Dans un contexte de microservices, le monitoring a plusieurs objectifs :

• Surveiller le bon fonctionnement de l’infrastructure ;
• Surveiller le fonctionnement des appels entre microservices ;
• Surveiller le respect du niveau de service (SLA -Service Level Agreements) ;
• Cartographier dynamiquement la répartition des microservices sur l’infrastructure et les versions de services déployées

Mais aussi

• Aider à identifier les services étroitement couplés ou ceux qui génèrent de nombreux appels de services, en observant la fréquence des appels, à partir du comportement des utilisateurs et du système pour bien définir le niveau de granularité

Enfin, les microservices étant développés et exploités par plusieurs équipes indépendantes, aux agendas différents, utiliser une solution de monitoring intégrée donne de la visibilité aux responsables métiers. Elle permet de :

• Couvrir les processus d’ingénierie, du développement jusqu’à l’exploitation,
• Mieux analyser les éventuels problèmes
• Favoriser la mise en œuvre et l’enrichissement d’une culture agile DevOps

Le monitoring fournit à la fois une base de référence et des réponses à certaines questions de type :

Quel volume de ressources pour la sérialisation-désérialisation, pour l’encodage ? Comment traiter les réponses volumineuses ? Faut-il privilégier une mise en cache ou une pagination ?

Comment monitorer ses microservices ?

Le monitoring doit être pris en compte très en amont du projet. Ci-après 6 grandes catégories, qui loin d’être exhaustives, peuvent évoluer en fonction des nécessités.

• Le Monitoring du Service Bus, si vous utilisez un bus de messages, pour observer la consommation des messages et l’état des services en général. Le système est alors plus tolérant aux pannes, si un service tombe le bus conservera le message qui sera alors consommé à la remise en place du service.
• Le Monitoring du SLA (Service-Level Agreement), qui sert à mesurer le temps des réponses pour les utilisateurs d’un système et à faire respecter les engagements dans le cadre d’un contrat.
• Le Monitoring système, qui vise à mesurer les réelles disponibilités, tant de la CPU (Central Processing Unit), que de la mémoire ou des espaces de stockage ; pour s’assurer que tous les composants interagissent correctement en temps souhaité.
• Le Monitoring des métiers (activités), qui analyse en temps réel via des protocoles complexes (XML) la production et les flux échangés entre les différentes applications client.
• Le Monitoring de l’Utilisateur et/ou de son expérience qui analyse les pratiques des utilisateurs en capturant les échanges.
• Le Monitoring technique des activités, c’est un peu la boite à outil du développeur aussi appelé les outils d’APM (Application Performance Management).

La surveillance du réseau est primordiale puisque les appels entre les microservices transitent sur le réseau. Les réseaux dits software-defined (SDNs) et les réseaux Overlay prennent de plus en plus d’importance avec les PaaS et les déploiements dynamiques.

Les solutions de monitoring doivent être capables de couvrir toutes les technologies, puisque les développeurs privilégient désormais une approche multi langage. Elles doivent suivre les transactions de front-end mobile, d’une API gateway Node.js, d’un back-end Java ou .NET, ou encore d’une base de données MongoDB.

Le monitoring des microservices doit également prendre en compte l’émergence des technologies de conteneurs. Autrement dit, il doit être capable de couvrir et de monitorer automatiquement les conteneurs et les services qui s’y trouvent.

Les conteneurs étant démarrés dynamiquement, avec des outils d’orchestration comme Kubernetes par exemple, cela rend impossible une configuration statique d’agents de monitoring.

Comme l’explique Ange Guyader Team Leader et expert microservices

Le monitoring est très important dans le cadre de l’architecture microservices. Me nombre de points d’entrées, le nombre de services, les API gateway, les broker de message sont autant de point qui pourront poser un problème et il sera nécessaire de monitorer finement tous les éléments pour définir des procédures de corrections. Ces mêmes procédures pourront même parfois être automatisées au travers d’une démarche DevOps en utilisant par exemple les fonctionnalités offertes par la containerisation ou les orchestrateurs (remplacement de code défectueux, etc…)

Comment tester ses microservices ?

Plus nous avançons dans la digitalisation, plus les systèmes sont complexes, répartis sur plusieurs microservices. Même une simple application de commerce électronique peut avoir des services de commande, de catalogue de produits, de gestion des stocks et d’expédition. Avec l’accélération des cycles de développement, la complexité croissante des applications et l’augmentation des dépendances à mesure que les applications grandissent, le test et la surveillance logiciels sont essentiels pour garantir la qualité du code et du service fourni.

Alors que la surveillance est passive avec des capteurs sur le logiciel en fonctionnement pour signaler les éventuels problèmes, le test est

ctif et cherche activement les bogues.

Mais comment aborder le test ?

Faut-il tester tous les microservices, faut-il faire un test du système dans son ensemble, les interactions entre les services doivent-elles être testées ? La réponse à ces questions permet de mettre en place une démarche de test correspondant au besoin.

Dans une architecture microservices, le plus complexe est de tester le comportement d’un ensemble de microservices. Cela nécessite d’initialiser le microservice à tester, ainsi que les microservices liés, ou d’écrire des doublures de tests pour isoler le service à tester.

Selon Ange Guyader,

Plus le niveau de tests est élevé plus ils seront coûteux, à la fois à la mise en place et en termes de temps d’exécution. De plus, cela n’est pas forcément compatible avec la vision d’un découplage fort tel que représenté par l’architecture microservices. L’importance des tests de performance/montée en charge devra être prise en compte. On choisit généralement l’architecture microservices pour ces avantages et il serait dommage de ne pas tester cette partie, que ce soit la capacité à monter en charge ou encore la capacité à distribuer des calculs par exemple

Les tests des applications microservices doivent être automatisés et associés au processus d’intégration et de déploiement. Un microservice étant autonome et indépendant, il peut être déployé individuellement lorsque les tests sont concluants.

De par la nature des architectures de microservices, un plan de test exige de définir les caractéristiques de scénarios d’utilisation concrets et de garantir le bon fonctionnement et la disponibilité continue en cas de charge importante ou de défaillance des ressources. Il est possible de tester les architectures de microservices très tôt dans le cycle de développement.

Pour résumer les enjeux des tests de microservices par rapport à ceux d’applications monolithiques :

• Ecrire des tests est plus coûteux et plus complexe lorsque l’on teste le fonctionnement intégré d’un ensemble de microservices. Il faut potentiellement déployer et préparer plusieurs jeux de données de tests et démarrer plusieurs processus.
• Le développement et le déploiement de microservices couplé à l’écriture des tests permet d’implémenter des pratiques de déploiement continu.
• Compte tenu du nombre de services déployés dans une architecture constituée de microservices, il peut être difficile de recréer un environnement de production complet pour les tests.
• Les équipes de développement et de test DevOps s’orientent vers l’automatisation des tests API et l’intégration de leurs outils de test aux infrastructures CI telles que Jenkins.

De plus, les microservices sont fréquemment intégrés via des communications asynchrones qui ajoutent encore à la complexité des tests (le délai nécessaire à la propagation d’un événement devant être pris en compte dans les scénarios de test).

Dans un tel contexte, il est difficile d’être certain que les tests couvrent effectivement toutes les subtilités de l’environnement de production.

C’est pourquoi le monitoring est complémentaire du test et permet de déceler rapidement des anomalies de production. Un retour en arrière ou une mise à jour corrective peuvent alors être rapidement décidés en vue de maintenir le bon fonctionnement de l’application.

Quels outils utiliser pour monitorer vos microservices ?

Pour le monitoring de l’infrastructure, vous pouvez combiner Kibana, ElasticSearch, LogStash :

Kibana : Plateforme de visualisation graphique de données qui peut être spécialisé sur les logs systèmes (ou tout autre log pertinent).

ElasticSearch : Moteur de recherche distribué accessible via REST/JSon.

Logstash : Outil d’agrégation de données ou de logs y compris pour des formats de logs personnalisés sur mesure.

Splunk est une autre solution commerciale concurrente.

Implémenter le monitoring du flux de requêtes/réponses entre microservices nécessite souvent une instrumentation des appels de manière à réconcilier le flux de requêtes/réponses :

Stack Netflix : Servo permet de récolter des données, depuis l’intérieur d’un microservice grâce à des jauges, compteurs, timers, etc.

Stack Twitter : Zipkin est un système de traçage, déployable dans Docker, permettant d’agréger les temps de latence entre les différents microservices. Les microservices doivent, pour être monitorés, être préalablement instrumentés par la librairie Twitter Finaggle

Dans toute application complexe, il se peut que vous rencontriez un problème. Dans une application de microservices, le suivi du bon déroulement des opérations doit se faire dans plusieurs dizaines, voire plusieurs centaines de services. Pour faciliter la compréhension, il est recommandé de collecter des données de télémétrie à partir de l’application. Ces données peuvent être divisées en journaux d’activité et métriques.

Les journaux d’activité sont des enregistrements textuels des événements qui surviennent pendant l’exécution de l’application : déclarations de trace, activité de serveur web particulièrement utiles pour l’analyse de la cause.

Les mesures sont des valeurs numériques pour observer le système en temps réel ou pour analyser les tendances à différents niveaux de l’architecture, de l’infrastructure physique à l’application, notamment :

Mesures de niveau nœud, comprenant l’utilisation de l’UC, de la mémoire, du réseau, du disque et du système de fichiers. Elles permettent de comprendre l’allocation des ressources pour chacun des nœuds et de corriger les valeurs hors norme.

Métriques du conteneur grâce à Azure monitor par exemple. Ces données d’utilisation des ressources vous permettent de déterminer les meilleurs paramétrages de ressource pour vos groupes de conteneurs.

Métriques de l’application qui permettent de comprendre le comportement d’un service. Il s’agit par exemple du nombre de requêtes HTTP entrantes en file d’attente, de la latence des requêtes ou de la longueur de la file d’attente de messages ou toutes mesures personnalisées spécifiques au domaine,

Métriques de service dépendantes tels que les services PaaS gérés ou les services SaaS lorsqu’ils fournissent des mesures.

Certains outils peuvent faciliter l’utilisation de métriques comme :

Des bibliothèques logicielles Metrics : elles permettent d’envoyer les métriques d’un service. Elles sont disponibles dans plusieurs langages de programmation.

Graphite : il permet d’envoyer des métriques d’un serveur ou d’un service en temps réel. Il permet aussi de monitorer les métriques avec des graphiques.

Mais aussi tous les outils de Service Bus et notamment Microsoft Azure Service Bus

• Traçage automatique du Client .NET Service Bus
• Outil de monitoring des performances, notamment le suivi automatique des requêtes et des dépendances avec Azure Application Insights
• Ou encore suivi des opérations personnalisées avec le kit DSK .NET d’Application Insights