MtoM Mag - Le journal de l'MtoM.

Chacun y va de son avis, vantant les mérites de telle API ou de telle infrastructure, et on ne compte plus les modèles, recettes, manuels, bibliothèques ou encore référentiels GitHub disponibles. Mais tant que les entreprises négligerons l’importance de l’intégration dans la mise en place d’une automatisation efficace, elles seront confrontées à des difficultés.

De plus en plus aujourd’hui, la gestion informatique raisonne à l’échelle de l’infrastructure toute entière, et non de silos isolés. De fait, la plupart des nouveaux systèmes sont conçus avec l’idée que les applications distribuées sur plusieurs serveurs peuvent être orchestrées sur l’ensemble d’une infrastructure réunissant les ressources de calcul, de stockage et de mise en réseau, en plus des applications elles-mêmes. Ces applications requièrent une infrastructure évolutive capable de s’adapter au changement. Or, si ce changement exige la coordination de ressources qui n’appartiennent pas toutes au réseau, l’automatisation seule ne suffira pas.

Pour dire les choses simplement : à partir du moment où il faut coordonner deux ressources ou plus pour effectuer une tâche, l’intégration devient une obligation. Ainsi, pour automatiser cette tâche, l’automatisation doit inclure l’ensemble des acteurs intégrés. Si le processus n’est pas automatisé, l’intégration n’est pas nécessaire.

Seule, l’automatisation ne suffit pas

L’intégration entre le réseau et l’infrastructure environnante ne se résume pas à choisir un outil (les infrastructures informatiques incluent de plus en plus une multitude d’outils ayant chacun leurs adeptes) et à mettre en place une intégration approfondie.

Le véritable intérêt stratégique pour les opérateurs ne tient pas à l’automatisation ou à l’intégration, mais bien à la combinaison des deux. Depuis des années, la communauté des experts réseau s’est fait le chantre de l’automatisation, en tant que concept général. Cependant, lorsque vous interrogez les clients à ce sujet, la plupart d’entre eux estiment que leur degré général d’automatisation ne dépasse guère le niveau de la ligne de commande.

Lorsque les gens évoquent l’automatisation de réseau, ils pensent immédiatement aux tâches de provisioning. Or, en matière de provisioning, il n’existe tout simplement pas de workflows s’appliquant de façon généralisée et uniforme à un grand nombre de types de déploiement différents. Ainsi, quand vient le moment de décider des processus à automatiser, le choix se réduit invariablement à un petit nombre d’éléments de provisioning universels (principalement les VLAN, et quelques autres éléments, tels que les listes de filtrage).

En réalité, si l’on s’en tient aux processus de provisioning, les opportunités d’amélioration offertes par l’automatisation de réseau, bien que très intéressantes, sont relativement limitées.

En outre, le nombre de processus de provisioning véritablement utiles se réduit encore si ces processus ne vont pas au-delà des limites du réseau. Ainsi, si l’on tient uniquement compte des workflows qui sont issus du réseau, le volume total représenté est suffisamment faible pour que la question se pose : l’automatisation de réseau a-t- elle le moindre impact à l’échelle du marché ?

Surveillance et résolution des problèmes : les vrais enjeux

En réalité, la vaste majorité des tâches à automatiser (du moins au départ) ne concernent généralement pas le provisioning, mais bien la surveillance et la résolution des problèmes.

Dans la vie d’un opérateur de réseau type, le volume des tâches opérationnelles dépasse celui des tâches de provisioning. De plus, ces tâches sont souvent exécutées sous pression (lorsqu’un dysfonctionnement requiert un diagnostic et une résolution rapide).

Il est intéressant de souligner que les workflows de surveillance et de résolution des problèmes ne sont pas dénués de similitudes avec les workflows de provisioning, dans la mesure où il est rare qu’ils commencent ou se terminent au sein du réseau : ils requièrent presque toujours des informations externes, que ce soit via un packet sniffer, un analyseur de flux, voire un outil de contrôle d’application. Quel que soit l’outil, l’idée à retenir est que le workflow implique un changement de contexte entre le réseau et des éléments qui lui sont extérieurs.

Si le réseau est considéré de façon isolée, l’automatisation est intéressante mais pas forcément déterminante, du moins pas au point de définir une opportunité susceptible d’avoir un impact sur le marché. En revanche, en incluant d’autres outils et en élargissant l’infrastructure, elle devient extrêmement utile.

Par exemple, en cas de baisse des performances d’une application (un problème de latence, imaginons), l’utilisateur voudra généralement avoir un aperçu de l’état opérationnel du réseau (statistiques sur l’interface, mémoire tampon, etc.). Dans ce genre de situation, un événement de surveillance sera généré et détecté par un outil de contrôle des performances d’application, lequel déclenchera alors un workflow de dépannage sur les appareils du réseau.

Le secteur commence aujourd’hui à promouvoir l’automatisation de plus en plus fortement, mettant les clients face à une question très intéressante : par où commencer ?

Jusqu’ici, la réponse traditionnelle était : avec des tâches de provisioning prédéfinies. À l’avenir, cependant, le choix dépendra probablement bien plus des outils qui constituent votre infrastructure. L’automatisation doit commencer au plus près de l’utilisateur. Cela signifie que ces outils (que ce soit Ansible, SolarWinds, ThousandEyes, Splunk, Nagios, Wireshark ou d’autres) doivent servir de point de départ à une discussion sérieuse sur l’automatisation.

Pour cela, bien sûr, les initiatives prises par les entreprises doivent accorder une place tout aussi importante à l’intégration qu’à l’automatisation elle-même.