Avis d’expert de Eric GATTERER – Directeur Technique Digital Factory – groupe Blue Soft
Avec l’Infrastructure as Code, c’est une petite révolution de l’ingénierie logicielle qui s’opère, vers une véritable cohérence entre les environnements informatiques déployés dans l’organisation. Mais avant de se lancer : prudence ! Les changements profonds de méthodes, s’ils apparaissent positifs, ne doivent en rien occulter le rôle fondamental des ingénieurs infrastructure.
Infrastructure as Code : au-delà du DevOps
Déployer une infrastructure aussi facilement qu’une application, en utilisant simplement du code, c’est le rêve de nombreux développeurs. C’est aussi toute la promesse de l’Infrastructure as Code (IaC). Ou presque : en réalité, il s’agit de « codifier » l’infrastructure mise à disposition des applications de l’entreprise, pour ensuite pouvoir la reproduire de façon automatisée et en continu, au gré des besoins, sur tous types d’environnements utiles (développement, intégration, pré-production ou production).
De fait, les bénéfices sont assez évidents : outre l’uniformisation de tous les environnements, leur déploiement s’en trouve particulièrement accéléré. Une vélocité permise par le Cloud (et notamment à travers la modélisation prédéfinie du PaaS) il y a déjà plusieurs années, et dont l’IaC est un véritable aboutissement. En effet, le DevOps à lui seul n’a pas réussi à régler les problématiques de réplication des environnements et à totalement fluidifier les échanges entre développeurs et équipes Ops.
Avec l’IaC, les développeurs se retrouvent à la tête de toute la chaîne des opérations pour les applications qu’ils créent. Mais l’IaC trouve également son intérêt dans de nombreuses autres situations.
Les cas d’usage de l’IaC
Automatiser les ressources (et leur provisionnement) et créer des environnements cohérents sont les premiers facteurs de mise en œuvre de l’IaC, qui trouve bien d’autres finalités dans l’organisation. À commencer par la gestion des pics de charge. Soldes, ventes flash, événement sportif, période électorale, etc. : de nombreuses raisons peuvent solliciter temporairement une application plus que d’habitude. Dans ce contexte, l’IaC permet de reproduire à de multiples reprises l’environnement de production, pour absorber les pics de fréquentation.
De la même façon, l’Infrastructure as Code est utile aux situations de montée de version : un environnement intégralement répliqué garantit des phases de testing ou de mise en production parfaitement réussies. Une IaC également utile à la création d’environnements de formation ou encore à la réplication d’environnements multilingues.
À l’inverse, la destruction automatisée des ressources assure aux organisations une meilleure maîtrise des coûts du Cloud. Jusqu’à en faire un des points clés 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’IaC, plus propice aux environnements futurs
Si, en soi, rien n’est impossible, nul n’y est tenu : se lancer dans l’IaC sur des environnements préalablement créés est un exercice de haute voltige, y compris pour des organisations déjà très matures en matière de Cloud.
En effet, l’IaC exige la modélisation du parc existant (réseau, stockage, serveurs, etc.) en brique de base exploitable par l’outil, c’est le principe d’idempotence. L’exercice de définition de l’environnement cible au cœur de l’IaC et son renseignement dans l’environnement logiciel représente une lourde charge de travail et reste particulièrement à risque sur un projet existant. Mieux vaut se concentrer sur les environnements futurs, destinés et pensés pour l’automatisation.
Toutefois, et malgré la prudence, une collaboration inter-équipes reste de mise pour limiter les risques d’échec.
Pas d’IaC… sans responsable d’infrastructure
Avec l’IaC, les équipes de Dev deviennent-elles pour autant omnipotentes ? La reproductibilité automatique tend à le confirmer puisqu’elles peuvent dès lors s’affranchir de l’ingénieur système, de l’administrateur de bases de données et de l’administrateur réseau et stockage.
Dans les faits, la planification initiale d’une Infrastructure as a Service nécessite de s’accorder entre les parties prenantes d’une infrastructure informatique. A minima sur la construction des modules dont on disposera sur étagère et qui composeront ensuite le Terraform (s’il s’agit de l’outil choisi). Sans compter que la plupart des entreprises ont adopté des politiques spécifiques dont le respect s’impose, quelle que soit l’infrastructure. En d’autres termes, c’est bien 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.
Par conséquent, si en phase d’exploitation, les développeurs deviennent autonomes, l’IaC doit pouvoir compter sur un travail initial collectif incontournable avec l’ensemble des administrateurs concernés, bases de données, stockage, réseau, architectes applicatifs. Contrairement à ce que son patronyme laisse supposer, l’IaC ne connaîtra donc le succès qu’à la condition qu’elle soit portée au départ par le responsable d’infrastructure, le plus à même de réunir toutes les compétences requises au lancement, pour une fluidité opérationnelle parfaite en phase d’exploitation.