Gilles Portier, Dynatrace : « un APM moderne adopte une démarche DevOps »

Le monde de l’analyse de performance applicative bouge pour prendre en considération les différentes couches de l’IT. Gilles Portier de Dynatrace revient sur cette transformation du secteur de l’APM.

Environnements applicatifs de plus en plus complexes, infrastructures matérielles et virtuelles multiples… la maîtrise de la performance applicative devient un challenge toujours plus complexe. Comment optimiser des transactions traversant de multiples couches matérielles, virtuelles, applicatives… sous diverses technologies, et de bout en bout ? Les solutions de gestion de la performance applicative ou APM (Application Performance management) s’attachent désormais à surveiller le comportement à la fois des utilisateurs et des applications.
Explications avec Gilles Portier, consultant avant-vente APM chez Dynatrace.
Cette dernière est désormais un société à part entière consacrée à l’optimisation applicative, tandis que l’activité mainframe a été regroupée au sein de la société Compuware.

Gilles Portier - Dynatrace
Gilles Portier – Dynatrace

Silicon.fr : Pourquoi affirmez-vous qu’il y a plusieurs sortes de solutions pour mesurer les performances des applications ?

Gilles Portier:  Selon les analystes, l’APM apporte la capacité de mesurer les performances des applications : disponibilité de l’application dans le temps, etc. Exerçant depuis plus de 40 ans dans le domaine, Dynatrace préfère se fier à ce que ressent réellement l’utilisateur. En effet, la supervision des applications en fonction de l’infrastructure montre vite ses limites.

L’entreprise ajoute parfois du matériel ou de la bande passante en espérant faire disparaître les problèmes. Or, cela s’avère généralement peu ou pas efficace, car 75% des problèmes proviennent des applications elles-mêmes. Autre limite, certaines solutions APM ne différencient pas les problèmes venant de l’infrastructure matérielle et ceux provenant de l’application. Parfois, des solutions ponctuelles comme l’équilibrage de charge (load-balancing) sur plusieurs serveurs ne font que masquer provisoirement les problèmes.

Ainsi, les mesures liées à la disponibilité des équipements (serveurs, réseaux, etc.) peuvent se révéler très positives semblant montrer que les applications fonctionnent bien, alors que l’utilisateur n’est pas satisfait. D’où la nécessité de mesurer ce que perçoit l’utilisateur. N’est-ce pas l’objectif initial ?

Avec l’approche basée sur l’expérience utilisateur, quelles limites faut-il contourner ?

Une difficulté apparaît pour mesurer le ressenti, car l’entreprise ne connait pas forcément l’utilisateur : prospect, visiteur, internaute, etc. Difficile alors de savoir ce qu’il perçoit.
Par ailleurs, les environnements sont de plus en plus complexes : équipements, environnements, applications multi-tiers… Entre le clic d’un utilisateur et la réponse de l’application, la transaction traverse de multiples couches logicielles, parois externes à l’entreprise et donc non maîtrisées par la DSI.

En outre, même avec des employés, le terminal client utilisé n’est pas forcément celui de l’entreprise (smartphones, tablettes, PC familial…). Nous avons souvent constaté que l’interface mobile d’applications mainframes robustes pose des problèmes de performances.

Pourquoi la supervision des équipements ne suffit-elle plus ?

Avec des solutions de gestion de la performance basées principalement sur la disponibilité des équipements matériels, tout se passe comme si le médecin intervenait pour pratiquer directement une opération sur le malade. Pourtant, un diagnostic devrait intervenir en amont afin de mettre en évidence les symptômes, les corréler et les mesurer ensuite en continu.
Sinon, les utilisateurs continuent à se plaindre de l’application, et la DSI met en avant ses tableaux de bord prouvant que tout va bien… et le dialogue de sourds se poursuit, exacerbant les tensions.

Il convient donc d’établir un premier diagnostic rapide (médecin généraliste) afin de révéler les symptômes. Ensuite, on fait intervenir les spécialistes en fonction des symptômes : middleware, applications, infrastructure matérielle… Les solutions APM modernes favorisent une démarche Devops salutaire pour comprendre et optimiser les applications au service de l’utilisateur.

Comment fonctionnent ces solutions, face à un utilisateur qui peut aussi être à l’origine du problème ?

Certes, il arrive que certains utilisateurs fassent des choses qui plombent les performances de l’application, le plus souvent de façon involontaire. Par exemple, en générant des requêtes lourdes sur une application analytique ou de e-commerce.

D’où l’importance de définir des règles sur les actions autorisées et des analyses régulières des transactions pour optimiser les performances des applications et affiner ces règles.
Le système consiste à superviser en continu les transactions de bout en bout, afin d’en analyser les parcours. Le système aide alors à établir des mesures moyennes acceptables selon divers critères : temps de réponse, disponibilité, parcours, interactions entre applications, etc. Cette base permet alors de mesurer les décalages et d’alerter afin d’en détecter les origines possibles. Avec le temps, la solution s’enrichit de règles propres à l’application et devient donc de plus en plus pertinente.

En cas de problème, l’entreprise met en place une cellule de crise avec les spécialistes middleware, système, applications… internes ou externes (éditeurs, prestataires, opérateurs en télécommunication, etc.). Une collaboration efficace pour vérifier et optimiser les éléments de l’application concernée.

Une solution APM propose une analyse neutre du problème, et non basée sur l’avis d’utilisateurs parfois peu objectifs. En outre, les symptômes sont mesurés.

Concrètement, quels éléments techniques contribuent-ils au fonctionnement de ces solutions APM de dernière génération ?

Pour rendre possible une supervision de bout en bout, des sondes sous forme d’agent logiciel s’installent automatiquement sur les postes clients. Par exemple, sur le site laredoute.fr, ce bout de code se charge avec la page Web et effectue immédiatement des mesures : temps de chargement, clics, parcours, etc. Des informations qui remontent avec le flux applicatif, avec un impact négligeable. Enfin, ces données sont traitées par le logiciel APM côté serveur. Et tout cela s’effectue donc à la volée via le serveur Web.

Côté serveur, l’agent s’installe comme un service applicatif du serveur Web, sans avoir à coder une seule ligne.Et les informations sont systématiquement stockées pour analyse sur une période choisie, afin de détecter les incidents, les tendances, etc.

Dans la panoplie des outils AMP, pas facile de s’y retrouver. Pouvez-vous nous aider à mieux comprendre ce panorama ?

En fait, il existe trois catégories d’outils. Ceux de type robots servent à déployer des scripts de simulation afin de réaliser des tests de stress ou plus évolués hors production. Ce que propose Synthetic Monitoring.

Installés sur les serveurs et sur les clients (de façon automatisée et transparente), les agents logiciels collectent des informations en continu pour les analyser soit en continu, soit a posteriori (User Experience Management ou Application Monitoring).

Enfin, les sondes réseau sont déployées dans le datacenter. Elles s’exécutent directement sur le réseau et analysent l’infrastructure matérielle jusqu’au niveau applicatif afin d’établir un diagnostic global. Ce type de solution est particulièrement efficace dans des environnements complexes impliquant de multiples infrastructures et applications, y compris ou des technologies différentes. Ces sondes intelligentes basées sur des règles sont également auto-apprenantes.

A lire aussi :

Véronique Mondollot, Compuware : « Le rachat par Thoma Bravo marque la fin et le début d’une histoire »

Compuware vendu à Thoma Bravo pour 2,5 milliards de dollars