La supervision réseau du futur ne se souciera plus des infrastructures et résidera dans l’«observabilité»

paessler - claire kago
Par Claire Kago, Chanel & Inside Sales Manager France chez Paessler AG

Les opérateurs IT d’aujourd’hui se doivent d’intégrer à leurs services une supervision réseau transparente, fonctionnelle et efficace. Avec la progression des innovations technologiques à un rythme rapide et les défis complexes et exigeants qu’elles engendrent, ils doivent faire preuve d’agilité et d’adaptation.

 

Pour préparer l’avenir, il faut d’abord comprendre les changements les plus notables de ces dernières années en matière d’opérations IT.La virtualisation représente le premier de ces changements. C’est ce qui nous a fait passer d’un seul serveur « bare metal » exécutant quelques applications à un serveur unique faisant tourner à lui seul de nombreux « serveurs » virtualisés. Ces serveurs ont pu être obtenus en virtualisant le matériel sous-jacent du serveur, permettant aux opérateurs d’exécuter plusieurs « serveurs » sur un seul serveur physique. Les bénéfices obtenus sont une charge de travail plus équilibrée sur l’ensemble de l’infrastructure et moins d’investissement initial pour l’entreprise grâce au regroupement des machines virtuelles (VM) sur moins de serveurs physiques.

Le deuxième changement s’est produit avec l’avènement et l’adoption massive des containers. Ceux-ci fonctionnent de façon assez similaire à la virtualisation, à la différence qu’ils portent l’abstraction à un niveau supérieur. Au lieu de simplement virtualiser le matériel et d’exécuter des systèmes d’exploitation complets sur chaque machine virtuelle, les containers fonctionnent par-dessus le système d’exploitation d’un hôte ou d’un nœud. Ce qui signifie que de nombreuses charges de travail s’exécutent sur un seul système d’exploitation. L’idée est ainsi d’avoir un « serveur » capable de faire tourner de nombreux containers et d’équilibrer la charge entre les serveurs pour gagner en efficacité.

Enfin, le changement le plus récent est apparu avec les Functions as a Service (FaaS), appelés également « serverless », car le besoin de maintenance d’un serveur au sein de l’entreprise disparait. Cela ne veut pas dire qu’il n’y a pas de serveur quelque part qui exécute les fonctions de l’entreprise, mais quelqu’un d’autre s’assure simplement que cela fonctionne. Les FaaS permettent aux développeurs de logiciels d’écrire uniquement leur logique métier, puis de l’uploader sur le service FaaS d’un fournisseur de cloud public tel que AWS. Le fonctionnement des serveurs qui alimentent les containers est ainsi totalement abstrait pour les entreprises, qui peuvent dès lors se concentrer uniquement sur le développement de leurs applications.

 

Les infrastructures ne seront bientôt plus un sujet de préoccupation 

En raison de l’abstraction du matériel et de la nature éphémère des applications modernes, les infrastructures perdront de leur importance dans les prochaines années. Plus nous enlevons nos applications et nos opérations des serveurs physiques « bare metal », moins nous avons besoin de nous en préoccuper.

Si un opérateur IT exécute une application de façon totalement « serverless » sur un cloud public, il n’est pas nécessaire pour lui de se soucier de l’infrastructure en place, mais en contrepartie, il n’est pas en mesure de la superviser, même s’il le souhaitait. Il n’y a ainsi aucun moyen d’accéder aux métriques du réseau ou des serveurs derrière les containers qui exécutent le code. Dans ce cas, ce que l’on va chercher à superviser est la performance du code en tant que tel.

De même, dans le cas des containers, les équipes DevOps qui exécutent des applications dans un cluster Kubernetes construit ou un cluster géré dans le cloud, ne devraient plus avoir à penser au matériel qui le fait fonctionner. De plus en plus, la gestion des clusters K8 et assimilés sera « externalisée » vers le cloud, et ces clusters gérant l’exécution d’applications ne se préoccuperont pas vraiment de savoir quelles sont ces entreprises qui les font fonctionner sur leurs matériels.

Avec l’abstraction de l’informatique, le matériel et son fonctionnement deviennent de simples commodités et l’externalisation de cette tâche apparaît ainsi comme logique.

 

L’observabilité représente le futur de la supervision

La question qui se pose alors est de savoir à quoi ressemblera l’avenir de la supervision. Pour y répondre, il est nécessaire de se concentrer sur les applications en elles-mêmes plutôt que sur les charges de travail qui s’exécutent sur l’infrastructure. Un terme est apparu récemment pour tenter d’englober cette idée : l’observabilité.

Actuellement, la plupart des administrateurs systèmes configurent une supervision traditionnelle  (capteurs et tableaux de bord) pour surveiller les types de défaillances basées sur des expériences antérieures, afin d’anticiper les opérations susceptibles d’échouer. Le cerveau humain espère en effet naturellement que ce qui s’est déroulé dans le passé va correspondre à ce qui se passera dans le futur, et qu’il est donc nécessaire de surveiller ces données. Mais si l’on ne surveille que les statistiques des bases de données et des hôtes exécutant l’application, certains problèmes ne peuvent pas être détectés et résolus.

De son côté, l’observabilité consiste à surveiller ce qui peut parfois causer la ruine d’une entreprise : les « inconnues inconnues » de son environnement. En d’autres termes, ce sont des choses dont on n’est pas conscient, que l’on ne comprend pas et que l’on ne surveille pas.

L’observabilité comprend ainsi des métriques, logs et traces directement extraits ou envoyés depuis une charge de travail ou une application, afin d’être analysés à la volée. A partir de ces sorties externes et ces données, il devient possible de déduire l’état actuel d’un système et de disposer d’un contexte pour comprendre son état. Mais si l’on souhaite observer un système ou une application en profondeur, il est indispensable de disposer de données brutes extrêmement cardinales, afin de pouvoir poser des questions différentes des habituelles et ainsi véritablement détecter le problème quand il survient.
Une fois qu’un opérateur IT a identifié la partie de l’application à l’origine du dysfonctionnement, il peut consulter les logs de flux de données et déterminer si le problème est lié à un nœud particulier de la base de données. Un trafic de données inhabituel peut alors être facile à détecter, notamment si les écritures provoquent des délais d’attente. Pour pouvoir ainsi réagir aux événements « inconnus inconnus » qui peuvent et vont se produire, il est donc nécessaire de rendre les systèmes plus observables.

Au final, la manière dont les opérateurs supervisent leurs réseaux doit continuer à évoluer, au fur et à mesure qu’ils s’éloignent des serveurs classiques « bare metal », que cela leur plaise ou non. Comme il devient de moins en moins possible de s’appuyer sur les infrastructures, il demeure essentiel pour le secteur IT de rester ouvert au changement. Pour les opérateurs IT, le défi est de s’adapter ou de perdre toute pertinence à l’avenir.

%d blogueurs aiment cette page :