La motivation principale de l’Intent-Based Networking (IBN) est de permettre aux entreprises d’opérer leurs infrastructures réseaux de façon fiable, en maitrisant les couts tout en offrant plus d’agilité et de contrôle en termes de fonctionnalités et de choix de matériels. L’idée semble simple, tandis que la difficulté réside dans la faon de “composer” les différents éléments de l’infrastructure dans le but de servir un besoin métier, le tout, en prenant en compte les caractères changeants du business et de l’infrastructure qui le sert.

Par “composition” on entend le fait de pouvoir créer un ensemble coherent plus complexe que la simple somme des éléments qui le composent. C’est le caractère scale-out bien connu des infrastructures data-center et qui concerne aussi bien le calcul, le stockage que le réseau. Le but ultime étant de faire apparaître tout le data-center comme un composant de calcul. Mais ceci est une dimension du problème, l’autre étant comment prendre en compte les différents contraintes métier.

Les capacités des infrastructures ainsi que les mécanismes permettant de les consommer sont sujets, en permanence, au changement. S’agissant des contraintes et besoins du métier, le problème est encore plus complexe tant en termes de fréquences que de complexités des changements. A change fois qu’un changement apparait, vous devez re-considérer cet aspect de composition. Si vous supprimez un élément, est-ce que la somme des éléments restant continuent a opérer comme un ensemble homogène ? De la même façon, lorsque vous ajoutez ou modifier un élément comment vous assurer que le nouvel ensemble soit toujours valide ?

Prenant l’exemple d’un composant de calcul unitaire (une machine virtuelle par exemple). Certains des aspects critiques qu’un système d’exploitation doit prendre en charge sont le partitionnement des ressources et l’isolation. Mais avec un data center agissant comme un énorme nœud de virtualisation en mode scale-out, ce même système d’exploitation maintenant distribué, doit d’abord mettre en œuvre une “composition” des différents éléments puis ensuite s’atteler au partitionnement des ressources et l’isolation. Bien évidement, si vous n’êtes pas en mesure de gérer cette composition en présence de changements soit de règles business et/ou soit liées a l’infrastructure, vous ne serez pas en mesure de consommer ces précieuses ressources de calcul.

Lorsque nous avons initialement évoqué notre vision de l’IBN, un des aspects fréquemment évoqués par les analystes traitait de l’orchestration, mais cela va bien au-delà. L’orchestration n’est que l’exécution d’un workflow de taches, sans nécessairement se préoccuper des états opérationnels. Ainsi dans le modèle traditionnel, il était supposé qu’une entité crée ce que l’on appelle la “Single source of truth”, (signifie, entre autres, ce que doit être l’état désiré de l’infrastructure) et qu’il renseigne celle-ci dans l’outil qui exécutera cette orchestration. Avec l’IBN, cette fameuse  Single source of truth  émane de l’intention même de l’opérateur de l’infrastructure, elle est d’ailleurs au cœur même de la plateforme et sert de point focal a partir duquel tout est dérivé.

Définition: Qu’est-ce que l’intent (l’intention) ? Si l’on devait chercher une définition, cela serait: “Une spécification déclarative d’un résultat désiré”. Par résultat désiré, on entend l’automatisation complète du cycle de vie du réseaux, lequel se composent de quatre phases : le design, le Build, le déploiement et la validation.

De faon générale, l’intent décrit le “quoi ?” sans se préoccuper du “ comment ? “. Un point clé, est que l’intent est par essence dynamique, d’où cette nécessité pour l’IBN d’être en mesure d’assurer que les demandes exprimés par l’intent soient satisfaites en présence continue de changements. Lesquels changements peuvent émaner du business (changement de besoins) ou de l’infrastructure elle même (changements d’état opérationnel d’un des éléments).

Afin de s’assurer de toujours satisfaire les demandes de l’intent, un IBNS (Intent-based Networking system) doit être lui même la “single source of truth” sur laquelle on doit pouvoir raisonner en présence d’un changement.

Sans cela, vous aurez a fournir un énergie et un temps considérables à coordonner différentes “source of truth” et l complexité interne a cette synchronisation, considérant différents formats et syntaxes.

D’aucuns disent “en software tout est possible” ainsi il doit être possible de réaliser cette logique de raisonnement précédemment évoquée. On pourrait imaginer écrire un script qui consoliderait toute les sources of truth disséminées dans différents systèmes et donc effectuer ce raisonnement dont on a tant besoin pour déterminer ce que doivent être nos états opérationnels cibles. Pourquoi pas ? La complexité d’un tel programme serait très vite exponentielle, ajoutez a cela le caractère changeant de l’intent et le tout deviens vite ingérable.

Raisonner sur l’intent de façon programmatique est bien la clé pour pouvoir automatiser l’ensemble du cycle de vie: Design, le Build (incluant l’allocation des ressources), la validation sémantique, la génération des configurations, la gééeration des états attendus (expectation rendering), l’exécution de tests, la détection d’anomalies, la gestion des changements (validation et acceptation ou refus de demande de changements).

Raisonner sur l’intent est un processus qui doit donc pouvoir être testé et maintenu en présence de changements. Pour y arriver une solution IBN doit posséder les caractéristiques suivantes:

  • La possibilité d’augmenter facilement le schéma de la “single source of truth” afin d’adresser de nouveaux besoins métiers et capacités de l’infrastructure.
  • La capacité de décomposer de façon programmatique la “single source of truth” en de multiples sous-ensembles. Cette décomposition est importante pour gérer la complexité liée au facteur d’échelle, car une architecture conçue pour avoir chaque élément logique de raisonnement qui réagit a chaque changement de l’intent ne pourra être scalable.
  • La possibilité pour les différents composants de communiquer entre eux lorsqu’un changement se manifeste.
  • La possibilité pour les administrateurs réseaux de matérialiser leur expertise de façon programmatique et de la communiquer à l’intent.
  • La capacité d’ajouter le support de nouvelles fonctionnalités offertes par l’infrastructure.
  • La capacité d’ajouter le support de nouvelles métriques de télémétrie
  • La capacité de mettre en œuvre de l’intent-based analytics afin d’extraire des informations tangibles depuis de la télémétrie brute.

Ces 8 points doivent constituer votre cahier des charges pour évaluer une solution d’IBN. En résumé, le langage vous servant a définir l’intent (et donc cette single source of truth) et raisonner au travers doit faire partie intégrante de la solution d’IBN. Cela est important car ca signifie moins de code a maintenir (et donc de bugs a gérer), moins de tests a écrire etc … En somme plus d’agilité.

L’IBN adopte les meilleures approches de développement software au service de la gestion du cycle de vie des infrastructures réseaux complexes. Le bénéfice que vous tirerez a bâtir autour d’une architecture robuste se manifesterons par une rapidité de mise a disposition de nouvelles fonctionnalités  (feature velocity). L’autre avantage clé est liée a l’indépendance vis-a-vis du matériel. Ne perdez pas de temps, tester l’Intent-Based Networking et découvrez par vous même les bénéfices au cela apportera a votre organisation et l’agilité dont elle pourra bénéficier.

_____________
Sasha Ratkovic est CTO/Fondateur d’Apstra.