L’infrastructure as code a fait son apparition dans nos SI pour réconcilier ou révolutionner à la fois le dev et l’ops, découvrons ici les facteurs clefs de succès de cette méthode.

… sous réserve d’étroite collaboration au départ

L’Infrastructure as Code révolutionne l’ingénierie logicielle en apportant notamment une cohérence entre les environnements qui manquait jusqu’ici au versionning et aux tests. Cela dit, l’IaC emporte également une transformation des méthodes qui implique un peu de prudence et ne doit pas faire oublier le rôle primordial des ingénieurs infrastructure, au profit des équipes de développement. 

L’IaC, plus vite et mieux 

L’Infrastructure as Code ou IaC a pour objectif de codifier l’infrastructure mise à disposition des applications de l’entreprise. Elle permet notamment de reproduire de façon automatisée la même enveloppe technique, et ce continuellement si besoin, sur tous les environnements utiles (environnements de développement, d’intégration, de pré-production ou de production).  

Schématiquement, l’IaC et l’uniformisation qu’elle permet ont pour premier avantage d’accélérer considérablement le déploiement des environnements tout en garantissant leur cohérence.  

Cette course à la vitesse peut parfois laisser songeur. Il y a 10 ans, la vélocité était déjà la promesse du Cloud à travers un PaaS proposant une modélisation prédéfinie. Si, en effet, la DSI a pu transformer ses méthodes en profondeur, satisfaisant autant ses équipes de développement que les métiers, force est de reconnaître que les processus pouvaient encore être améliorés.  

Rapidement, à travers le DevOps, s’est posée la problématique des réplications à l’identique des environnements et à travers elles, les nécessaires documents de description des ressources, les explications à apporter aux équipes Ops sur les choix opérés et les éternelles discussions qui en découlent. Brefs, de multiples grains de sable qui venaient régulièrement enrayer la machine.  

L’IaC aboutit à confier aux équipes de développement la maîtrise de bout en bout des opérations, en leur permettant de codifier toute l’infrastructure désirée pour les applications créées. Et bien plus encore.  

Les cas d’usage de l’Infrastructure as Code avec le dev et l’ops

Dans un processus DevOps, le déploiement rapide de nouvelles applications passe donc en premier lieu par la capacité de l’entreprise à automatiser les ressources (et leur provisionnement) et à créer des environnements cohérents.  

Au-delà, les entreprises peuvent y trouver de nombreux cas d’usage.  

À travers le concept de microservices en conteneurs, l’entreprise peut profiter de flexibilité horizontale. Ce sera le cas toutes les fois qu’une application d’ordinaire peu fréquentée le devient sur une période donnée. Un événement récurrent peut contribuer à ce genre de situation (événement sportif, période électorale, etc.). L’IaC permet de reproduire à de multiples reprises l’environnement de production afin d’absorber les pics de fréquentation, très aisément et en un laps de temps extrêmement court.  

L’Infrastructure as Code aura également tout son intérêt dans les situations de montée de version, pour profiter en phase de testing ou de mise en production d’un environnement répliqué intégral de la production. 

On retrouvera les mêmes bénéfices de cohérence et de rapidité quand il s’agit de créer des environnements de formation, que l’on souhaite paralléliser pour recevoir de multiples langues.  

Cette capacité de création rapide à l’identique se double d’une possibilité de destruction automatisée des ressources. Pour toutes les entreprises qui ont pu essuyer les plâtres d’une consommation excessive du Cloud, la suppression automatique des environnements est peut-être d’ailleurs le point clé du choix de l’IaC. C’est en tout cas une brique socle d’une stratégie FinOps, en particulier pour les grands consommateurs Cloud et Cloud hybride.  

L’accessibilité de l’Infrastructure as Code en entreprise pour le dev et l’ops

L’IaC s’adresse aux entreprises dont la maturité dans le Cloud est acquise, au moins en partie, ne serait-ce que parce qu’elle suppose une nouvelle façon de penser l’infrastructure. Cela dit, la question peut se poser de vouloir automatiser en masse l’ensemble de ses environnements. Si l’adoption précoce de nouvelles technologies n’est pas le sport préféré des entreprises françaises, il arrive d’en croiser de plus aventureuses que d’autres.  

On conseillera pourtant de ne porter son attention que sur les projets et non sur les environnements déjà créés. Si le passage à l’IaC sur de l’existant n’est pas infaisable sur le papier, le principe d’idempotence, c’est-à-dire la définition de l’environnement cible au cœur de l’IaC, suppose de renseigner l’environnement logiciel (Terraform par exemple) sur l’ensemble des ressources mises à disposition. Cela signifie modéliser l’entièreté du parc (réseau, stockage, serveur, etc.) en brique de base exploitable dans l’outil d’IaC. Et cela peut représenter énormément de travail.  

Si le risque d’échec est élevé sur l’existant, il n’en va pas de même pour les environnements à venir. Toutefois, il existe quelques bonnes pratiques collaboratives que l’on a trop tendance à négliger.  

La fin du travail d’équipe ?

Avec l’IaC, on pourrait penser que les équipes de Dev deviennent omnipotentes, une idée sous-tendue par la reproductibilité automatique, leur permettant de s’affranchir de l’ingénieur système, de l’administrateur de bases de données et de l’administrateur réseau et stockage. Il est vrai que les développeurs peuvent désormais tout faire seuls dans le Cloud mais est-ce vraiment une si bonne idée que cela ?  

D’une part, la planification initiale d’une Infrastructure as a Service exige un certain volume de discussions avec l’ensemble des parties prenantes d’une infrastructure informatique, ou, à tout le moins, une connaissance fine de la construction des modules dont on disposera sur étagère et qui composeront ensuite le Terraform (s’il s’agit de l’outil choisi).  

D’autre part, rares sont les entreprises aujourd’hui à ne pas avoir développé des politiques spécifiques dont le respect s’impose, quelle que soit l’infrastructure. Autrement dit, il appartiendra aux développeurs de s’intéresser de près à l’ensemble des règles édictées au nom de la protection du système et des données avant de définir leurs environnements.  

En conséquence de quoi, l’IaC ne peut pas se passer d’un travail initial pleinement collectif, faisant intervenir au titre de la connaissance aussi élémentaire qu’incontournable, l’ensemble des administrateurs concernés, bases de données, stockage, réseau, architectes applicatifs. C’est pourquoi, et contrairement à ce que laisse entendre l’IaC, il est important que la responsabilité de l’introduction de ces solutions soit endossée par le responsable d’infrastructure, le plus en mesure de réunir toutes les compétences requises lors des phases de lancement.  

Partagez cet article !