Les solutions de surveillance des performances du réseau et de surveillance des performances des applications (NPM / APM) sont les principaux outils des opérations informatiques pour dépanner et optimiser les performances du réseau et des applications. Les applications SaaS sont différentes à bien des égards des applications privées traditionnelles. Ils sont si différents que les solutions NPM et APM ne peuvent pas voir de nombreux problèmes de performances SaaS ou leurs causes sous-jacentes.

Qu’est-ce qui a changé ? Les applications SaaS ne sont pas seulement hébergées sur une infrastructure qui échappe au contrôle de l’informatique, elles favorisent également l’adoption de la sécurité, de l’accès et de la mise en réseau basés sur le cloud avec SASE, SWG, CASB et SD WAN qui permettent et ont un impact sur une main-d’œuvre distribuée. 

Le cofondateur de Kadiska, Boris Rogier , a été invité à partager son expertise sur le SaaS et la surveillance de la performance des applications Web lors du récent ITSM and Digital Transformation Summit. Cet article résume les points clés de cette présentation qui couvrent les défis auxquels sont confrontés les outils de surveillance hérités et les raisons pour lesquelles une nouvelle approche de surveillance des performances SaaS est nécessaire pour offrir une expérience numérique productive aux employés sur site et travaillant à domicile.

L’écart de visibilité informatique moderne

Revenons à l’époque où la plupart des applications d’entreprise étaient accessibles via un réseau privé à partir d’emplacements sur site.

C’était une époque où la plupart des entreprises avaient en fait une assez bonne visibilité sur l’expérience utilisateur. Puis, avec l’arrivée de la transformation numérique, le processus de cloudification a commencé. Nous avons soudainement ajouté un certain nombre de nouvelles technologies et options d’infrastructure qui étaient extrêmement bénéfiques du point de vue du déploiement, de la mondialisation, des coûts et de la flexibilité… mais elles s’accompagnent également de lacunes en matière de visibilité.

Le Déplacement des charges de travail des centres de données privés vers les clouds publics s’est accompagné de l’adoption majoritaire du SaaS. Cela a introduit un changement significatif dans la manière et l’endroit où les applications sont hébergées. Et du point de vue de l’accès, le lien critique entre les utilisateurs et l’application, nous avons commencé à utiliser des réseaux publics basés sur Internet parallèlement aux circuits privés traditionnellement utilisés.

La dynamique des réseaux SD WAN et les approches qui ont été introduites pour sécuriser le travail des utilisateurs à domicile, telles que les passerelles Web sécurisées, les CASB et les solutions SASE en général, sont devenues soit un remplacement, soit une alternative aux VPN et à la connectivité privée.


Ce sont les principaux changements qui ont entraîné des lacunes de visibilité importantes que nos outils de surveillance traditionnels ont eu du mal à combler. Même après un certain nombre d’années, ils n’ont pas été en mesure d’évoluer pour surveiller efficacement ce nouvel environnement d’infrastructure numérique.

La surveillance APM repose sur le contrôle de la plate-forme

Par exemple, APM ne peut pas vraiment s’adapter aux plateformes SaaS et PaaS car vous ne pouvez pas les instrumenter comme vous le feriez avec des applications privées. Lorsque les applications s’exécutent dans des environnements privés, les serveurs, le code et les systèmes étaient entièrement sous le contrôle de votre informatique et de vos développeurs. Ce n’est plus le cas avec le SaaS et les applications hébergées sur PaaS. Même les applications privées intègrent désormais souvent des composants et des services tiers, ce qui limite également les options pour les instrumenter.

La surveillance NPM s’appuie sur l’analyse du trafic

NPM fait face à un autre ensemble de défis. Le premier étant similaire à l’APM : les solutions de surveillance des performances réseau ne peuvent pas vraiment être implémentées dans les plateformes SaaS et cloud car vous ne pouvez pas y capturer efficacement le trafic. Ils n’ont donc pas la possibilité de générer des mesures de visibilité.

Le deuxième grand défi est le cryptage. Le trafic SaaS et des applications Web traverse désormais des réseaux publics où vous ne pouvez pas le laisser passer « en clair ». Le chiffrement TLS 1.3 d’aujourd’hui est omniprésent et beaucoup plus difficile à déchiffrer et à gagner en visibilité que les formes de chiffrement antérieures.

Le dernier défi est le fonctionnement de ces nouveaux réseaux. Les réseaux publics sont dynamiques par définition. Ainsi, le chemin que vous suivez peut changer à tout moment en raison du routage BGP, mais il peut également changer en fonction de l’emplacement de l’utilisateur et des exigences d’équilibrage de charge, de manière significative.

Cela signifie que les personnes d’une région peuvent également être redirigées vers des hôtes d’un pays ou même d’un continent différent en fonction de l’endroit où elles se trouvent, de l’opérateur qu’elles utilisent pour se connecter à ces applications et des plates-formes telles que CASB / SASE et SD WAN. Comme nous le verrons, cela rend la capture et la corrélation du trafic presque impossibles à l’aide de techniques centralisées sur lesquelles reposent les solutions NPM.

Pris ensemble, cela crée un nouvel ensemble de complexités qui rendent l’obtention de la visibilité beaucoup plus complexe qu’elle ne l’était auparavant. Certains diraient presque impossible. 

Surveillance des performances SaaS : ce qui ne fonctionne pas  

Double-cliquons sur les limites des solutions traditionnelles de surveillance des performances en ce qui concerne les applications modernes SaaS et basées sur le cloud, et pourquoi elles rencontrent certaines difficultés.

Lacunes de la surveillance des performances NPM

Chiffrement

Les solutions de surveillance des performances du réseau tirent des informations de l’analyse du trafic. Comme nous l’avons souligné, le cryptage est un obstacle majeur à la pertinence de cette approche. Cela empêche ces outils de comprendre le comportement qui est essentiel pour signaler l’expérience utilisateur et le temps de réponse du serveur.

Il n’y a aucun moyen d’utiliser réellement l’analyse du trafic si vous ne surmontez pas le problème de cryptage. Et dans presque tous les cas, le décryptage n’est pas une option viable. Lorsque vous regardez des services tiers tels que SaaS et PaaS, vous ne pouvez pas trouver un moyen de déchiffrer tout le trafic provenant de tous les hôtes impliqués.

Capture de trafic

Le déchiffrement est un défi important avec TLS 1.3, mais la mise en œuvre d’une capture de trafic efficace est elle-même un défi encore plus important, car le trafic côté hôte et côté utilisateur n’est plus centralisé. Du côté du cloud, la capture du trafic est très complexe, car les charges de travail peuvent se déplacer, être partagées et réparties sur plusieurs pods ou même sites. C’est très distribué. Vous avez une énorme étendue géographique à couvrir. Il est presque inconcevable de capter tout le trafic d’un point de vue technique et économique.

Si vous essayez d’implémenter la capture du trafic côté utilisateur, c’est tout aussi difficile. Auparavant, c’était simple lorsque les gens et le trafic étaient concentrés en un seul endroit. Mais ce n’est plus le cas. Les gens travaillent à domicile. Les gens travaillent dans de nombreuses succursales, des espaces de coworking. Ils changent fréquemment de lieu : dans une enquête de ce webinaire, nous avons appris que plus de 80 % des participants travaillaient en mode hybride – certains jours à la maison, certains jours au bureau.

SD WAN et CASB rendent la capture encore plus vexante. Les chemins de trafic changent dynamiquement non seulement à cause des réseaux, mais aussi à cause de l’effet des redirections et de la répartition des différentes plateformes. 

Cela signifie donc que même si vous disposez d’une certaine forme de mesures liées à la contribution du réseau à l’expérience utilisateur, vous ne savez pas comment cela est lié ou pourquoi cela se produit. Vous n’avez pas une connaissance approfondie de la superposition et des sous-couches du réseau pour agir et résoudre les problèmes.

Nouveaux protocoles

Enfin, les nouveaux protocoles comme HTTP/2 et HTTP/3– ou QUIC – sont rarement pris en charge par les solutions NPM et apportent en fait un ensemble supplémentaire de défis de visibilité à part entière. En autorisant le téléchargement de trafic parallèle et en contournant les poignées de main et les transactions TCP traditionnelles, les solutions NPM sans prise en charge du protocole mis à jour ne sont pas en mesure de fournir des mesures clés de l’expérience utilisateur.

Pourquoi les tests synthétiques sont insuffisants Les tests synthétiques

constituent une façon traditionnelle d’évaluer les performances des applications Web. Cela implique de rejouer des scénarios à l’aide d’une automatisation de processus robotique qui simule l’interaction de l’utilisateur avec une application et de surveiller la réponse. Par exemple, vous pouvez vérifier si les utilisateurs peuvent se connecter, cliquer sur un bouton, accéder aux menus et aux fonctionnalités et vérifier si la réactivité était dans les normes ou les SLA qui ont été configurés manuellement par l’équipe de performance informatique. Vous pouvez en savoir plus sur les tests synthétiques et leur comparaison avec la surveillance des utilisateurs réels (RUM) dans cet article.

Scripts et scénarios

Il y a deux problèmes avec cette approche. La première est que si vous ne contrôlez pas l’application, vous ne pouvez pas vous assurer que les scénarios et les scripts que vous créez resteront valides ou même pertinents dans le temps. Les frais généraux de maintenance pour maintenir les scénarios à jour sont coûteux, car les applications SaaS changent tout le temps. Un seul changement d’élément de menu peut empêcher l’exécution d’un script. Si vous êtes comme la plupart des entreprises qui s’appuient sur le SaaS pour 80 % de leurs applications métier, c’est-à-dire 50 applications SaaS ou plus pour une grande entreprise, il n’est pas vraiment pratique d’utiliser des tests synthétiques.

Applications à page unique

Deuxièmement, les tests synthétiques n’ont pas été inventés pour les «applications à page unique, où un utilisateur charge la page principale puis interagit avec elle via des transactions à partir d’appels d’API Javascript. Pensez à Google Drive ou à Gmail qui n’ont qu’une seule page sur laquelle vous pouvez passer toute la journée à travailler. Si les tests synthétiques déterminent les performances de l’application à partir des temps de chargement des pages et qu’il n’y a qu’une seule page à surveiller, aucune mesure ne peut réellement être effectuée.


Real User Monitoring (RUM) vs SaaS et applications Web

RUM est l’autre façon traditionnelle d’examiner les performances des applications Web. Elle consiste à placer un script dans l’application, puis à collecter des données depuis l’appareil ou les navigateurs de l’utilisateur. Cela fonctionne bien si vous avez accès au code de l’application et de la plate-forme d’hébergement, mais ce n’est pas le cas pour les applications SaaS ou celles construites sur des environnements PaaS.

Cela est également vrai pour les applications packagées exécutées sur n’importe quel environnement, public ou privé. Tant que le fournisseur ne vous offre pas la possibilité d’insérer réellement ce script et de collecter des données, les outils seront aveugles. Cela rend la mise en œuvre de RUM très difficile.

Le problème avec les agents

Il existe des problèmes supplémentaires introduits par les solutions RUM qui reposent sur des agents logiciels installés sur les appareils des utilisateurs finaux. Ces agents peuvent avoir un impact sur les performances des appareils en consommant des ressources et ont également montré des failles de sécurité. Les agents sont généralement conçus pour s’exécuter sur des machines Windows, déployés via des politiques centrales. Alors que nous constatons que le BYOD, les Chromebooks et les tablettes sont désormais utilisés par un nombre croissant d’employés, les agents deviennent de moins en moins efficaces pour capturer l’expérience utilisateur, en particulier dans un environnement de travail à domicile.

En résumé, les approches traditionnelles de la surveillance des applications et du réseau sur lesquelles nous nous sommes appuyés pour fournir une vision claire de l’expérience utilisateur et de ses impacts ne correspondent pas à la nouvelle architecture des applications SaaS et Web modernes


Une nouvelle approche de la surveillance des performances des applications SaaS

Bien que les anciens outils NPM et APM aient du mal à maintenir la visibilité sur les applications SaaS et Web, en particulier dans le contexte du travail à domicile et des employés hautement distribués, la surveillance de l’expérience numérique a également évolué.

Les approches modernes adoptent des techniques basées sur le cloud pour combler les lacunes de visibilité, tout en offrant une vue complète de l’infrastructure de bout en bout : de l’application au réseau en passant par l’utilisateur et ses appareils. Cela permet aux opérations réseau et informatiques d’être rapidement alertées des dégradations de performances ayant un impact sur les performances SaaS, d’évaluer l’impact sur l’utilisateur et l’étendue du problème, de diagnostiquer rapidement la couche et l’emplacement responsables et de vérifier qu’il est résolu.


Au lieu de s’appuyer sur une approche unique : passive ou synthétique, données d’application ou de réseau, l’expérience numérique moderne et les outils de surveillance du réseau combinent des données provenant de plusieurs sources pour obtenir une image complète. En corrélant le traçage réseau actif approfondi avec l’expérience utilisateur surveillée directement à partir de leurs navigateurs, les relations entre les dégradations et l’infrastructure sous-jacente sont révélées. Cette approche sans agent est simple à déployer, tout en surmontant les principaux défis associés à l’instrumentation côté serveur et à l’analyse du trafic.

Apprenez-en plus sur l’approche unique de Kadiska en matière de surveillance des performances des applications SaaS et Web, et sur la rapidité avec laquelle elle peut fournir des informations sur votre réseau dans la rediffusion du webinaire et dans ces courtes démos vidéo.