Dernière modification le 17 juin 2021
Vous vous souvenez des étapes de l’implémentation DevOps pour les infrastructures réseaux déjà présentées dans cet article. Bien que tout ceci puisse vous faire penser à du marketing ou même à du buzzword, il s’agit bien de réalités terrains qui sont concrètement mises en oeuvre avec des étapes intermédiaires supplémentaires.
Si nous remontons dans l’histoire, le scripting n’est pas un phénomène nouveau. Dès le début de ma carrière, j’utilisai déjà le scripting pour automatiser les déploiements. Il s’agissait de programmes écrits en perl (1987) ou en Visual Basic (1991) finalement associé avec SecureCRT (1995) dont l’objectif était d’envoyer des commandes CLI sur les équipements et d’analyser les réponses (méthode appelée Screen Scraping). Ce qui a changé avec le temps, c’est le fait d’utiliser des protocoles de communication optimisés (NETCONF, RESTCONF ou gNMI) et des formats de données adaptés (XML, JSON ou protobuf), pour parler de « Human-driven Automation ».
Bien que de nombreuses idées fondamentales des approches DevOps, comme les pratiques Lean, le mode Agile ou le cycle Plan-Do-Check-Act de la roue de Deming, ont été popularisés dans les années 1990, le terme DevOps que nous connaissons est né en 2009. Après avoir été appliqué aux développement, puis au système, le DevOps a finalement été appliqué au réseau. Le mouvement NetDevOps avait pour objectif de supprimer le goulot d’étranglement que représentait le réseau dans les cycles rapides d’adaptation imposés par les applications et les infrastructures de serveurs en mouvements permanents pour suivre les besoins métiers et marchés. Le NetDevOps propose l’idée de considérer l’infrastructure réseau en tant que IaC (Infrastructure as Code) ou plus spécifiquement NaC (Network as Code), avec tous les principes techniques, technologiques, méthodologiques, organisationnels et humains sous-jacents. Le NetDevOps a apporté un tournant dans les nouveaux profils de compétences nécessaires à son application concrète.
Le réseau n’échappe pas à cet autre mouvement qu’est le XaaS (Everything-as-a-Service) pour finalement habiller le tout d’une interface utilisateur, de préférence une interface graphique. Il faut noter que le terme NaaS (Network as a Service) couvre également des offres commerciales dans lesquelles le client n’investit plus dans les matériels, mais paye un abonnement pour un service facturé à la consommation, mais ce n’est pas de cette définition dont je parle ici. La naissance du NaaS a exposé l’automatisation réseau via des portails en libre service. Ils ont rapidement montré des limites, car il manque souvent des moyens pour valider les données qui sont entrées dans la « Source de Vérité » et il manque également les moyens de rétroaction appropriés pour connaître l’état réel du réseau. Il ne s’agit pas seulement de parler de tests unitaires, mais plus de tests d’acceptation, c’est à dire de vérifier que l’infrastructure réseau se comporte bien comme on l’attend.
Cette réflexion a donné lieu à la naissance du concept IBN (Intent-Based Networking) implémenté à l’étape du « Event-driven Automation » pour la première fois en 2017 dans un document du Gartner. Avec une approche IBN, il devient possible de définir l’état prévu dans lequel le réseau doit fonctionner et de vérifier en permanence que le réseau fonctionne comme prévu. Non seulement les systèmes IBN automatisent les tâches fastidieuses et offrent une visibilité en temps réel sur l’activité d’un réseau pour valider une intention donnée, mais ils prédisent également les écarts potentiels par rapport à cette intention et prescrivent l’action requise pour garantir cette intention. Cette approche plus intelligente rend le réseau plus rapide et plus agile et réduit les erreurs. Cette capacité à s’auto-surveiller et à s’auto-corriger est un élément central du réseau IBN. Plus l’intelligence artificielle se glissera dans le code produit pour la rétroaction et plus on s’acheminera vers le « Machine-driven Automation », voire le « Self-driven Automation ». L’intelligence artificielle ne sera probablement pas une étape en tant que tel, mais elle se glissera discrètement dans le code pour améliorer le service, exactement comme sur nos smartphones.
Comme pour le NetDevOps, IBN est une déclinaison du SDN (Software Defined Network). En effet, même si la définition d’origine du SDN portée par l’ONF (Open Network Foundation) est « séparation physique du plan de contrôle du réseau et du plan de transfert, avec un plan de contrôle qui gère plusieurs périphériques », le quatrième principe « programmabilité des services réseau » englobe tous les concepts évoqués dans cet article.