L'Infrastructure as Code est l’un des nombreux avantages offerts par la virtualisation des infrastructures proposée par les fournisseurs de Cloud ou de systèmes de virtualisation.

Là où le processus d’achat ainsi que l’organisation de la logistique, des interventions physiques et des précautions de sécurité ad hoc entrainaient des délais incompressibles (parfois de plusieurs mois), la virtualisation permet quant à elle de réaliser directement la livraison d’une infrastructure juste après sa définition.

L’IaC consiste à définir l’infrastructure dans un langage descriptif dont l’interprétation par le programme associé permet de construire l’infrastructure décrite et ainsi produire les ressources virtuelles qui constituent le système cible (Serveurs, Bases de données, Routeurs, Répartiteur de charge…).

Il existe de nombreux programmes capable d’interpréter du code d’infrastructure et de provisionner les infrastuctures. Certains sont propres à un fournisseur de solution Cloud ou de virtualisation, tandis que d’autres plus généralistes comme Terraform permettent de produire de l’infrastructure mixte ou multi-cloud.

Le gain de temps (et donc d’argent), lié à l’élimination des contraintes physiques, est donc considérable, mais ce n’est pas le seul avantage de l’IaC.

Entre l’idée d’origine et la mise en production de sa solution IS/IT, le besoin peut évoluer et impacter l’infrastructure, il en va de même lorsqu’une solution est en production et que l’activité d’une entreprise évolue (internationalisation, augmentation de volumes, …).

L’IaC apporte là aussi un gain puisqu’elle permet, toujours dans des délais extrèmement courts, d’ajouter, modifier ou supprimer des composants de l’infrastructure.

Cela offre, notamment en phase de définition de l’architecture, la possibilité d’expérimenter différentes solutions puisqu’en quelques minutes on peut détruire ou reconstruire une architecture complète même avec des centaines de composants.

Mais cela donne également, en production, la possibilité d’ajuster rapidement les capacités (scalabilité horizontale), à la hausse en cas de pics d’activité supérieurs à ce qui a pu être anticipé dans l’étude d’architecture pour la scalabilité verticale, comme à la baisse pour coller aux périodes plus calmes et optimiser les coûts.

Un autre avantage majeur offert par l’IaC est la répétabilité qui élimine par la même occasion le risque d’erreur lié à l’humain. Moyennant une paramétrisation adaptée du code, une infrastructure peut être “clonée” en quelques minutes pour construire un environnement de test identique à la production et qui pourra être détruit une fois les validations effectuées.

L’IaC est-ce l’outil ultime ?

Evidemment non, l’IaC ne résoud bien que le problème de provisionning des infrastructures. Mais une fois les composants produits, une étape de configuration est nécessaire et d'autres outils (dits de Configuration as Code ou CaC) sont bien plus adaptés pour cette tâche (Ansible, Packer, Chef,…).

S’agissant de code, il doit être géré en configuration pour pouvoir suivre les changements et leur raison ainsi que ses versions tout en permettant une collaboration des acteurs de l’infrastructure (équipes système, équipes réseau, équipes services, …).

C’est vraiment tout rose l’IaC ?

Evidemment non, la mise en oeuvre d’une chaine de production automatisée de l’infrastructure peut poser des problèmes en cas d’intervention manuelle sur les ressources produites. Il faut donc bien gérer l’organisation des interventions et les autorisations.

Un autre écueil est l'obsolescence progressive du code qui a servi à générer les services managés, car ces derniers sont souvent configurés pour se mettre à jour automatiquement au moins dans les versions mineures.

Dans ces deux cas, une mise à niveau du code est nécessaire pour éviter de perdre les modifications manuelles ou les mises à niveaux.

Quand utiliser l’IaC ?

Coder une infrastructure n’est pas trivial, il faut des compétences plus ou moins approfondies sur chacun des composants à déployer (serveurs, réseau, sécurité, services managés…) mais surtout, cela demande un effort non négligeable de codage et de tests qui doit pouvoir être rentabilisé.

Si une architecture est simple et ne doit être produite qu’une seule fois (voire 2 pour une environnement de validation), il est probable que l’IaC n’en vaille pas le coût. Produire l’infrastructure de validation manuellement et en extraire une version codée dans le format propre du fournisseur de Cloud peut être suffisant pour produire l’infrastructure de production moyennant quelques ajustements.

Par contre dès qu’une architecture ou même quelques composants vont devoir être générés de façon répétée, l’IaC devient vite rentable et un codage modulaire va améliorer sa réutilisabilité et donc sa rentabilité.

Une autre bonne raison d’utiliser l’IaC peut être l’incertitude sur le choix de l’hébergeur, ou une migration vers un autre hébergeur.

Si vous avez écrit une IaC pour déployer sur Amazon Web Services et que vous voulez migrer vers Microsoft Azure, il sera plus rapide de transformer le code pour AWS en code pour Azure que de tout ré-ècrire.

Cerise sur le gâteau

L’air de rien, l’IaC peut constituer un élément crucial d’un plan de recouvrement sur désastre (DRP). Associé à un processus de sauvegarde robuste, il donne la faculté de reconstruire tout un système à l’identique dans des délais très courts, ce qui constitue une protection presque imparable contre les désastres tels que les ransomware.