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

À mesure que les approches DevOps s'immiscent dans les opérations réseau, elles entraînent avec elles une nouvelle terminologie. Ces expressions familières peuvent être déroutantes pour les NetOps qui ne les ont jamais rencontrées auparavant et peuvent dérouter les responsables informatiques qui subissent des pressions pour adopter cette méthodologie.

Parmi elles, la notion d’infrastructure en tant que code. Dans le monde des développeurs, l’infrastructure correspond principalement aux plateformes, aux serveurs et aux systèmes de conteneurs sur lesquels les applications sont déployées et dans lesquelles elles sont mises à l’échelle. L’infrastructure est avant tout informatique.

De l’autre côté du mur se trouve un ensemble d’infrastructures plus large et plus robuste qui couvre le stockage, la sécurité et la mise en réseau en plus du calcul. Après tout, il y a quatre opérations, et toutes doivent fonctionner en synchronisation pour parvenir à un déploiement continu et permettre le type d’optimisation que les dirigeants informatiques et commerciaux recherchent dans le cadre de la transformation numérique. Cela signifie que l’infrastructure en tant que code inclut une gamme beaucoup plus large de systèmes, d’appareils et de services en production qu’en développement. Le déploiement d’une application signifie généralement que l’infrastructure de chacune des quatre opérations sera touchée d’une manière ou d’une autre. Cela rend l’infrastructure en tant que code en production un peu plus délicate, mais a également un impact plus important sur l’efficacité et la vitesse.

C’est parce que l’automatisation peut éliminer les temps d’attente entre les transferts qui sont trop souvent la source d’inefficacités dans les déploiements, en particulier lorsque les processus manuels entrent en conflit avec les vacances, les jours de maladie et les heures de déjeuner.

C'EST UNE SIMILATION

L’infrastructure en tant que code est une comparaison ; ce qui signifie que nous ne voulons pas réellement (du moins pas maintenant) transformer nos systèmes de services réseau et d’application en code que nous construisons puis déployons. Cela serait une folie pour la plupart des entreprises et perturberait la stabilité et la fiabilité du réseau de l’entreprise. Mais nous souhaitons 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 séparer les configurations, les politiques et les profils du matériel ou du logiciel sur lequel ils sont déployés.

C’est cette collection qui est alors considérée comme des « artefacts de déploiement » et peut être traitée comme du code. Cela signifie qu'ils peuvent être stockés et gérés dans des référentiels, versionnés et révisés. Ils peuvent être extraits, clonés et validés de la même manière qu'un développeur extrait, clone et valide du code vers et depuis un référentiel (comme Github).

Nous devrions également inclure les « artefacts d’automatisation ». Il s'agit des scripts et des fichiers associés décrivant les tâches d'automatisation qui accompagnent la boîte à outils d'automatisation de votre choix. Si c’est ça Ansible, ce sont des playbooks. Si c'est Chef, c'est une recette. Pour Puppet, un manifeste. Ou il pourrait s’agir simplement 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) qui peuvent décrire plus en détail des configurations plus complexes ou standardisées. L’utilisation d’un modèle peut être avantageuse ici car il peut prendre en charge des options et des services d’application qui ne sont peut-être pas encore pris en charge par l’ensemble d’outils de base.

Outre les artefacts de déploiement, les artefacts d’automatisation forment la collection que nous appelons « infrastructure en tant que code ». On suppose que vous pouvez provisionner un système et exécuter ensuite un processus d’automatisation sur celui-ci pour le configurer comme vous le souhaitez.

Combinée à une approche par application des services réseau et applicatifs, une approche d’infrastructure en tant que code peut considérablement atténuer le risque de déploiements fréquents. En isolant les configurations et en limitant leur impact à un seul système, l’impact d’un déploiement qui a mal tourné est pratiquement éliminé. Cela encourage à son tour des calendriers par application qui s’alignent mieux sur les besoins de l’entreprise et les demandes des utilisateurs.

Pour les organisations axées sur le cloud, l’adoption d’une approche d’infrastructure en tant que code peut réduire les frictions liées à la migration d’un centre de données vers le cloud ou d’un cloud vers le cloud. Étant donné que la configuration est découplée du système, elle peut apparemment être déployée sur un système similaire ailleurs.

Il existe de nombreuses bonnes raisons de faire l’effort de passer à une approche d’infrastructure en tant que code, et très peu de bonnes raisons de ne pas le faire. L’infrastructure en tant que code est l’un des moyens les plus avantageux de concrétiser le réseau agile dont les organisations ont besoin pour réussir dans une économie numérique multi-cloud axée sur les applications.