APM vs aaNPM – Décortiquer le marketing BS

Marketing, sentiments partagés! J’attends vraiment les nouvelles publicités du Super Bowl (certaines relèvent du pur génie) dans quelques semaines, mais je n’aime pas toute la confusion que le marketing a tendance à créer dans le monde de la technologie. Dans l’article d’aujourd’hui, je vais essayer de décortiquer le marketing BS et d’articuler clairement les différences entre APM (Application Performance Management) et aaNPM (Application Aware Network Performance Management). Je ne vais pas essayer de vous convaincre de la primauté de l’un sur l’autre. Il ne s’agit pas d’une vente, juste d’une session éducative.

Définitions

APM – Gartner a travaillé durement pour essayer de définir clairement le domaine de l’APM. Selon Gartner, les outils APM contiennent les 5 dimensions suivantes:

  • End-user experience monitoring (EUM), soit la manière dont l’application fonctionne selon ce que l’utilisateur final voit.
  • Modeling et display runtime de l’architecture d’application (une vue sur le flux logique de l’application à tout moment)
  • La définition du profil de transaction d’un utilisateur défini (suivre l’activité d’un utilisateur dans toute l’application)
  • Suivi approfondi des composantes dans un contexte d’application (exécution du code d’application, exécution de requête SQL, comportement des messages, etc…)
  • Statistiques

aaNPM – Une fois encore, Gartner a créé une définition pour ce segment de marché qui peut être lue ici

« Ces solutions permettent une récolte passive de paquets du trafic de réseau et doit inclure les caractéristiques suivantes, en plus de la technologie de récolte de paquets:

  • Recevoir et  exécuter une ou plusieurs des ces sources de données de flux : NetFlow, sFlow et l’Internet Protocol Flow Information Export (IPFIX).
  • Fournir des roll-ups and des tableaux de bord de données collectées dans des visées commerciales, qui consistent en des displays de performance centrés sur l’application.
  • Suivi de l’exécution en mode toujours on, et générer des alarmes basées sur des seuils générés de manière manuelle ou automatique.
  • Offrir des capacités d’analyse de protocole pour décoder et comprendre les applications multiple, y compris voix, vidéo, protocoles HTTP et database. L’outil doit fournir des informations sur l’expérience de l’utilisateur final pour ces applications.
  • Avoir la capacité de décrypter un trafic crypté si les clés appropriées sont fournies avec la solution.

Réalité

Qu’est-ce que ces définitions veulent dire pour parler simplement?

Les outils APM sont typiquement utilisés par les équipes de support, d’infrastructure et de développement pour rapidement identifier, isoler et réparer les problèmes liés aux applications. Ces équipes ont souvent un haut niveau de compréhension de la manière dont les réseaux fonctionnent, mais pas la connaissance détaillée requise pour résoudre des problèmes de réseau. Elles vivent de codage d’application, de points d’intégration, et des mesures de composantes (serveur, OS, VM, JVM, etc…). Elles appellent l’équipe de réseau quand elles pensent qu’il y a un problème de réseau (en se basant on l’espère sur des indicateurs de réseau de haut niveau). Ces équipes n’ont d’habitude aucun contrôle sur le réseau et doivent suivre le processus des équipes de réseau pour pouvoir connecter un appareil au réseau. Les outils APM ne vous aident pas à régler les problèmes de réseau.

Les outils aaNPM sont, par définition, des renifleurs de paquet réseau. La majorité de ces outils (NetScout, Cisco, Fluke Networks, Network Instruments, etc.) sont des appliances hardware que vous connectez à votre réseau. Elles ont besoin d’être connectées à chaque segment du réseau sur lequel vous souhaitez récolter des paquets ou elles doivent être alimentées en flux de paquets filtrés et regroupés par des appareils NPB (Network Packet Broker). Les outils aaNPM sont riches en détails de niveau réseau, avec quelques données d’application précieuses (mesures EUM, détails de transaction et flux d’application). Les outils aaNPM aident les ingénieurs à régler des problèmes de réseau qui se manifestent en tant que problèmes d’application. Les outils aaNPM ne sont pas capables de résoudre les problèmes de codage car ils n’ont pas d’accès au codage de l’application.

Si je faisais partie d’une équipe de support réseau, je voudrais savoir si les applications ont été touchées par des problèmes de réseau pour pourvoir prioriser les réglages correctement et avoir un point de référence si une équipe de support d’application me contacte.

Convergence des équipes de réseau et d’application

On m’a demandé si je vois les équipes de réseau et d’application converger de la même manière que les équipes de développement et d’infrastructure suite au mouvement DevOps. Je ne l’ai pas vu dans chaque entreprise avec laquelle j’ai collaboré. Selon mon expérience professionnelle dans l’infrastructure pour le compte de différentes entreprises par le passé, les équipes de réseau et les équipes de support d’application pensent de manière très différente. Est-ce possible pour ces équipes de travailler à l’unisson? Non, mais je pense que ce sera moins difficile dans quelques années.

Et à propos du SDN (Software Defined Networking)Je pense que la plupart des ingénieurs voient le SDN comme une menace pour eux, que ce soit vrai ou non. Quoi qu’il en soit, le SDN aura besoin de temps pour devenir opérationnel et dans l’intervalle les équipes de réseau et d’application vont demeurer séparées.

J’espère que cela vous a été utile pour décortiquer le marketing utilisé par beaucoup de vendeurs pour augmenter leur portée. Vos besoins pourraient requérir APM, aaNPM, une combinaison des deux, ou une autre technologie qui n’a pas été abordée aujourd’hui. La technologie est là pour régler des problèmes. Je vous recommande fortement de commencer par définir vos problèmes et ensuite passer en revue les meilleures solutions disponibles pour vous aider à les résoudre.