Microservices : comment adopter la bonne "monitoring attitude" ?

Dans la mouvance de la forte croissance du cloud, les microservices sont devenus l'une des principales normes de développement des applications. Quelles sont leurs spécificités en matière de monitoring ?

Les enjeux de l'adoption d'une architecture de microservices

La première étape d'une transformation digitale consiste, pour la plupart des entreprises, à migrer leurs applications existantes monolithiques vers une plateforme cloud, selon une approche « lift-and-shift » qui permet une transition rapide et économique sur le court terme. Mais les coûts d'exploitation des logiciels non-optimisés pour le cloud peuvent, sur le long terme, dépasser les coûts de développement. D'où l'intérêt d'adopter, dans un second temps, une architecture de microservices, afin de mieux tirer profit de l'agilité et la scalabilité d'une infrastructure cloud.

Dans une architecture de microservices, les applications sont composées de petits services indépendants. Combinée à une démarche d'intégration et de livraison continue (CI/CD), elle permet d'accélérer les développements, et rationaliser la livraison d'applications plus stables, plus flexibles et de meilleure qualité.

Mais la migration d'une application monolithique à une architecture de microservices est un processus incrémental qui implique des changements technologiques, architecturaux et culturels profonds. Selon une étude menée par O'Reilly Media, en collaboration avec Dynatrace, les principaux défis identifiés par les entreprises en la matière concernent l'intégration des systèmes existants, ainsi que l'identification et la maîtrise de la complexité des dépendances applicatives. Et pour 41 % d'entre elles, le monitoring des applications.

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 monitoring applicatif est en effet essentiel pour garantir la qualité du code et du service fourni. Mais les architectures de microservices introduisent de nouveaux enjeux et de nouvelles problématiques que les entreprises doivent impérativement prendre en compte dans le cadre de leur APM (Application Performance Management). 

1/ Identifier la granularité et la localité

C'est un véritable défi architectural que de décider de la granularité de nouveaux microservices au sein d'une application, autrement dit de leur taille, mais aussi de leur champ et de leurs limites. Le monitoring peut aider à identifier les services étroitement couplés ou 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.

Les architectes peuvent alors décider de combiner deux services en un, ou d'utiliser les mécanismes d'une plateforme pour garantir la colocation (par exemple, des pods Kubernetes).

  2/ Mesurer les impacts des appels de fonctions distants

Les fonctions où tout réside en mémoire dans une application monolithique deviennent des appels de service distants dans le cloud. Ce qui signifie que les paramètres doivent embarquer toutes les données, et non pas uniquement leurs références.

Ce qui soulève un certain nombre de problèmes qui dépendent largement de la localisation et de la charge réseau générée par un service : quelle est la taille des données par rapport à une référence en mémoire ? Quel volume de ressources est utilisé pour la sérialisation-désérialisation, et pour l'encodage ? Comment traiter les réponses volumineuses ? Faut-il privilégier une mise en cache ou une pagination ? Localement ou à distance ? Le monitoring fournit à la fois une base de référence empirique et des tendances pour l'ensemble de ces questions. 

3/ Monitorer le réseau

Le monitoring de réseau est primordial 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.

Mais bien que les prérequis en matière de maintenance et d'administration des composants des réseaux physiques sous-jacents (câbles, routeurs, etc.) diminuent, les réseaux virtuels apportent, quant à eux, des coûts supplémentaires en introduisant un surcoût de ressources réseau et CPU.

4/ Prendre en charge des technologies polyglottes

Les solutions de monitoring doivent être capables de couvrir des technologies polyglottes, puisque les développeurs privilégient désormais une approche multi langage. Elles doivent suivre les transactions à travers différentes technologies, qu'il s'agisse d'une technologie 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.

  5/ Monitorer les conteneurs

Le monitoring 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 sont démarrés dynamiquement - par exemple, avec des outils d'orchestration comme Kubernetes - ce qui rend impossible une configuration statique d'agents de monitoring.

  6/ Monitorer la plateforme

En complément du point précédent, les solutions de monitoring doivent être capables de distinguer la performance de l'application de la performance de l'infrastructure dynamique. Par exemple, des appels de microservices sur le réseau ont une latence. Mais la couche de contrôle (par exemple, Kubernetes Master) utilise lui-aussi le réseau. Ce qui pourrait être considéré comme un bruit de fond est pourtant non négligeable et peut avoir un impact.

En général, les technologies cloud sont jeunes, et comme toute technologie émergente, elles doivent être monitorées avec beaucoup d'attention, parce qu'elles sont potentiellement porteuses d'erreurs catastrophiques.

Les microservices sont typiquement développés et exploités par plusieurs équipes indépendantes, aux agendas différents. Utiliser une solution de monitoring intégrée, qui couvre les processus d'ingénierie, du développement jusqu'à l'exploitation, permet non seulement de mieux analyser les problèmes, mais aussi de favoriser la mise en œuvre et l'enrichissement d'une culture agile DevOps, tout en fournissant aux responsables métiers une visibilité inégalée.