Qu’est-ce que l’infrastructure en tant que code pour le NetOps ?

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

À mesure que les approches DevOps s’immiscent dans les opérations réseau, elles apportent avec elles une nouvelle terminologie. Ce jargon peut dérouter les équipes NetOps qui ne l’ont jamais rencontré auparavant, ainsi que les responsables informatiques poussés à adopter cette méthodologie.

Parmi ces termes figure la notion d’infrastructure en tant que code. Dans l’univers des développeurs, l’infrastructure désigne principalement les plateformes, les serveurs et les systèmes de conteneurs sur lesquels les applications sont déployées et au sein desquels elles sont mises à l’échelle. L’infrastructure correspond avant tout aux ressources de calcul.

De l’autre côté du mur se trouve un ensemble d’infrastructures plus vaste et plus robuste qui, outre les ressources de calcul, englobe le stockage, la sécurité et les réseaux. Après tout, les opérations couvrent quatre domaines, qui doivent tous fonctionner de manière synchronisée pour assurer un déploiement continu et permettre le type d’optimisation que les responsables informatiques et métiers attendent de la transformation numérique. Cela signifie qu’en production, l’infrastructure en tant que code englobe un éventail de systèmes, d’équipements et de services bien plus large qu’en développement. Le déploiement d’une application implique généralement, d’une manière ou d’une autre, l’infrastructure de chacun de ces quatre domaines opérationnels. L’infrastructure en tant que code est donc un peu plus complexe à mettre en œuvre en production, mais elle a aussi un impact plus important sur l’efficacité et la rapidité.

En effet, l’automatisation peut éliminer les temps d’attente entre les différentes étapes, qui sont trop souvent à l’origine d’inefficacités lors des déploiements, notamment lorsque les processus manuels sont perturbés par les congés, les arrêts maladie et les pauses déjeuner.

C’EST UNE COMPARAISON

L’infrastructure en tant que code est une comparaison ; autrement dit, nous ne souhaitons pas réellement — du moins, pas pour l’instant — transformer nos systèmes de réseau et de services applicatifs en code que nous compilerions puis déploierions. Pour la plupart des entreprises, ce serait insensé et compromettrait la stabilité et la fiabilité du réseau d’entreprise. Nous souhaitons toutefois profiter des avantages d’un système qui dissocie la configuration et les profils des systèmes sur lesquels ils s’exécutent.

Cela signifie qu’il faut dissocier les configurations, les politiques et les profils du matériel ou du logiciel sur lequel ils sont déployés.

C’est cet ensemble qui est alors considéré comme des « artefacts de déploiement » et qui peut être traité exactement comme du code. Cela signifie que ces artefacts peuvent être stockés et gérés dans des dépôts, versionnés et soumis à une revue. Ils peuvent être récupérés, clonés et validés de la même manière qu’un développeur récupère, clone et valide du code depuis et vers un dépôt (comme Github).

Nous devons également inclure les « artefacts d’automatisation ». Il s’agit des scripts et des fichiers associés qui décrivent les tâches d’automatisation correspondant à l’outil d’automatisation de votre choix. Avec Ansible, ce sont des playbooks. Avec Chef, une recette. Avec Puppet, un manifeste. Il peut aussi s’agir d’un simple script Python.

Pour BIG-IP et un nombre croissant de systèmes hébergés sur le réseau, cela inclut également des modèles (iApp) permettant de décrire plus précisément des configurations complexes ou standardisées. L’utilisation d’un modèle peut être avantageuse dans ce cas, car il peut prendre en charge des options et des services applicatifs qui ne sont peut-être pas encore pris en charge par l’ensemble d’outils principal.

Avec les artefacts de déploiement, les artefacts d’automatisation constituent l’ensemble que nous appelons « infrastructure en tant que code ». Nous partons du principe que vous pouvez provisionner un système, puis exécuter un processus d’automatisation sur celui-ci afin de le configurer comme vous le souhaitez.

Lorsqu’elle est associée à une approche par application des services réseau et applicatifs, l’approche de l’infrastructure en tant que code peut réduire considérablement les risques liés aux déploiements fréquents. En isolant les configurations et en limitant leur incidence à un seul système, les conséquences d’un déploiement défaillant sont pratiquement éliminées. Cela favorise à son tour l’adoption de calendriers propres à chaque application, mieux adaptés aux besoins de l’entreprise et aux attentes des utilisateurs.

Pour les organisations qui privilégient le cloud, l’adoption d’une approche d’infrastructure en tant que code peut faciliter la migration d’un centre de données vers le cloud, ou d’un cloud à un autre. La configuration étant dissociée du système, elle peut en principe être déployée sur un système similaire ailleurs.

Il existe de nombreuses bonnes raisons d’entreprendre la transition vers une approche d’infrastructure en tant que code, et très peu de raisons valables de ne pas le faire. L’infrastructure en tant que code est l’un des moyens les plus efficaces de mettre en place le réseau agile dont les entreprises ont besoin pour réussir dans une économie numérique multicloud axée sur les applications.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie