Est-ce que les APIs des éditeurs XaaS sont vraiment utiles pour le monitoring IT ?

Définition de « API »: mot magique que tout commercial dans l’IT doit sortir dès qu’on lui demande si son application peut s’interfacer avec une autre.

Réponse correcte ! (la plupart du temps)

Imaginez maintenant l’équipe IT implémentant la solution et qui se dit maintenant: “alors comment on va faire pour connecter cet outil et cet autre ?”. Vous y êtes. C’est comme de recevoir un meuble suédois en kit: maintenant il faut le monter !

Dites vous que les équipes IT doivent monter autant de type de meuble qu’il y a d’applications dans leur environnement IT et vous comprendrez vite que cela devient très chronophage. Cela demande finalement des compétences spécifiques et consomme des ressources qui seraient sans doute plus utiles à des tâches proches du business de leur entreprise. De plus, toutes les entreprises n’ont pas envie d’y consacrer de ressources ou n’en on tout simplement pas les moyens.

Alors les questions que l’on nous pose très souvent: à quoi sert le Senhub ? Pour qui ? Quel est son marché ? vont vite trouver leurs réponses dans ce qui suit.

Y a t il une problématique d’interopérabilité ?

Les études statistiques sur le marché du monitoring IT sont finalement assez rares.

Nous avons cependant déniché un baromètre 2021-2023 commandé par l’éditeur Centreon auprès de Vanson Bourne sur un panel de 600 professionnels de l’IT en Europe et Amérique du nord (entreprises de plus de 500 collaborateurs). Vous pouvez la télécharger ici.

Premier chiffre très surprenant : seulement 61% de leur système d’information est supervisé.

27% des personnes interrogées jugent la visibilité sur les performances de leur SI excellente. Il en reste donc beaucoup dans le flou !

Dernier chiffre et le plus significatif pour nous: 59% des répondants ne sont pas satisfaits de leur outil avec comme motif numéro 1 une mauvaise intégration des outils et leur incapacité à fournir une visibilité unifiée de leur SI.

Comme nous sommes optimistes et bienveillants, nous pourrions dire que Senhub s’adresse donc à 59% des entreprises EU et US !

La vérité est sans doute un peu plus nuancée. Néanmoins, cela indique bien que l’interopérabilité entre les outils de pilotage du SI est un vrai sujet.

Comprendre cette problématique

Pour tout éditeur, proposer des APIs permettant de récupérer des données depuis ou vers son application est désormais obligatoire. Fini le monde du reverse engineering ou on attaquait les bases de données en direct pour se servir et faire ses petites modifications. Les APIs apportent la protection des données et de leurs modèles. Elles sont aussi le standard qui permet les échanges sécurisés au travers du Web. Bref Internet et le Cloud, en particulier, serait bien différent (voir inexistant) sans elles.

Mais pour un éditeur, proposer ses propres APIs est-ce suffisant ?

Je crois que depuis très longtemps la réponse est non. La preuve: les éditeurs proposent des SDK dans les principaux langages pour faciliter la vie des développeurs. Si les APIs évoluent, l’éditeur met à jour son SDK que les développeurs intègrent sans effort dans leurs applications.

Quand vous êtes utilisateurs d’une solution de monitoring IT, il y a un os: vous n’êtes pas le développeur de la solution. Donc si votre besoin est de collecter des métriques chez un Cloud provider ou auprès d’une application en SaaS comment faites-vous ?

Le monde de la débrouille

Tous les utilisateurs ne sont pas égaux. Certains ont la possibilité d’acheter des solutions de monitoring très chères et qui couvrent leurs moindres besoins. D’autres peuvent s’adjoindre les services de sociétés capables d’adapter une solution à leurs enjeux. A l’opposé, beaucoup n’ont pas de gros besoins et se satisfont d’une petite solution bon marché ou open source tel quel.

Mais quid de l’immense majorité des équipes IT entre ces 2 extrêmes a qui on demande efficacité et réactivité et pour lesquelles un outil centralisé de monitoring est un véritable enjeu ?

L’objectif des IT Ops, pour être efficace, est de bâtir un cockpit de pilotage ou toutes les informations importantes remontent.
A partir de là, ils peuvent définir et mettre en œuvre une stratégie d’alerte unifiée dans laquelle la bonne personne est prévenue d’un incident relevant de son expertise dans les meilleurs délais et faire en sorte qu’elle dispose des métriques lui permettant de résoudre rapidement le problème. N’oublions pas au passage qu’une application indisponible coûte de l’argent et/ou impacte le chiffre d’affaires de l’entreprise.

Depuis ce même cockpit, les IT Ops vont pouvoir extraire toutes les informations qui leur sont demandées. Qui ne doit pas aujourd’hui produire un dashboard de l’état de santé des applications ou des rapports de disponibilité permettant de s’assurer du respect des SLAs ?

Il faut donc que cette catégorie majoritaire d’utilisateurs résolve ce problème d’interopérabilité.

Est-ce que les APIs des éditeurs XaaS sont vraiment utiles pour le monitoring IT ?

Je veux dire par là que si vous n’êtes pas un cloud provider comme Azure ou Amazon, est ce que vos utilisateurs vont faire l’effort d’utiliser vos APIs ?

Et bien ça dépend.

Nous sommes ici clairement dans un rapport coût/bénéfice. Les utilisateurs feront l’effort s’ils ont un enjeu particulier avec l’application concernée ou s’ils trouvent un moyen rapide et pas cher pour le faire. Sinon ils s’en occuperont quand ils auront un stagiaire sous la main et ce sera du “nice to have”.

Parlons un peu technique. Développer un connecteur ça veut dire quoi ?

Cela implique déjà que dans l’équipe il y ait des gens qui sachent développer un script en Powershell, Python, Perl ou tout autre langage permettant de consommer des APIs.
Il leur faut ensuite comprendre la documentation des APIs, identifier les informations intéressantes à collecter et écrire le script qui les collectera, les agrègera et les mettra en forme pour que l’outil de monitoring puisse les interpréter correctement quand il lancera le script.
Il ne faut pas oublier non plus que le connecteur doit être maintenu. Les éditeurs font évoluer leurs APIs et de manière parfois un peu brutale.
Le tout multiplié par le nombre d’éditeurs de solution intégrées au SI.

Pas si simple, et surtout très chronophage…

Donc pour un éditeur, sauf à considérer que ses APIs sont là pour épater la galerie, il a tout intérêt à faciliter leurs consommations par ses utilisateurs surtout s’il considère qu’il s’agit d’un avantage concurrentiel.

Conclusion: Senhub, ça fait quoi et pour qui ?

Senhub résout l’ensemble des problématiques exposées plus haut. Il met à disposition des connecteurs sur étagère, conçus et maintenus par des experts du monitoring IT.

L’équipe IT Ops n’a aucun effort de développement ni de maintenance à fournir puisque Senhub répond à son outil de monitoring dans son format natif.

Si les APIs ou l’outil de monitoring évoluent, le Senhub s’adapte et garantit ainsi la continuité du flux de métriques.

Pour un éditeur SaaS, c’est le SDK ultime pour être directement compatible avec PRTG, Zabbix, Prometheus, Nagios et ses forks.

En conclusion, Senhub participe significativement chez nos clients à améliorer l’intégration des outils de pilotage du SI avec pour axe principal l’outil de monitoring. Il rend possible l’interopérabilité pour toutes les bourses et permet aux équipes IT de se concentrer sur leur métier et ne plus perdre de temps à batailler avec les APIs des éditeurs SaaS.