L’Infrastructure as Code n’est plus une option !

L’Infrastructure as Code n’est plus une option !

150 150 Team Gekko

La vague DevOps a amené dans son sillage de nouveaux outils dédiés à l’automatisation et au pilotage par API des serveurs et autres composants : c’est l’Infrastructure as Code, une tendance de fond qui amène à repenser la production IT dans son ensemble. Mais quels en sont les enjeux, pourquoi faut-il s’y intéresser et comment se mettre en ordre de marche ?

L’infrastructure as code consiste à programmer l’ensemble des opérations liées au déploiement, à l’évolution ou à la maintenance des environnements dans lesquels les applications seront exécutées. Dit autrement, l’objectif est de décrire l’infrastructure dans son ensemble, des machines virtuelles aux différents services déployés, pour ensuite piloter son fonctionnement et ses évolutions grâce à des scripts.

Dans un environnement de production IT traditionnel, on commence par évaluer les ressources nécessaires avant de dessiner l’architecture, provisionner les ressources, paramétrer l’environnement d’exécution, créer ses services et finalement déployer l’application. En cas de besoin, le business demandera à l’IT de nouvelles ressources qui seront provisionnées selon le même cycle, en profitant parfois de l’élasticité du Cloud. Les incidents sont traités par une équipe support dédiée. Quand un élément pose problème, on rollback le temps de corriger le tir, on redéploie. Dans l’absolu, ça fonctionne, mais à l’heure de l’agile et du DevOps, on a besoin de mieux.

Faire évoluer son infrastructure au même rythme que l’application

En mathématiques, le concept d’idempotence suppose qu’une opération a toujours le même résultat quand elle est appliquée dans des conditions identiques, et ce quel que soit le nombre de fois où elle est répétée. Ramené à la production IT, l’idempotence signifie que l’on peut se fier à une procédure d’approvisionnement quand on sait qu’elle est fiable et la déclencher à l’aide d’un pan de code dès lors que l’on dispose de composants pilotables via des APIs.

On fait ainsi abstraction des détails techniques, de la même façon qu’on n’a pas besoin d’entrer manuellement des paramètres dans la console pour lancer une instance sur un Cloud public. L’infra as code ne se limite cependant pas à provisionner automatiquement des serveurs ou gérer des failovers : elle apporte au monde de la production IT l’ensemble des pratiques issues du monde logiciel.

Comme on travaille sur du code, les procédures sont à la fois reproductibles et documentées : on peut les faire évoluer, les versionner ou les adapter à des besoins précis, en utilisant les mêmes dépôts et les mêmes systèmes de permissions que les équipes de dev. Cette centralisation ouvre également la voie aux processus d’intégration et de livraison continues (CI/CD), qui réduisent le temps de réponse nécessaire pour adapter l’infra à la demande applicative.

Développer une infra spécifique à partir de patterns

Un objet est par définition réutilisable. Quand nous développons une méthode d’approvisionnement, elle devient un pattern que l’on va pouvoir mettre à profit sur une autre application à partir du moment où elle est dans une cinématique similaire. On cesse de voir l’infra comme un énorme bloc : elle devient un assemblage de modules plus ou moins génériques dont les paramètres vont être ajustés en fonction des exigences particulières de l’application.

Dans notre vision de l’infra as code, recourir à des patterns ne veut pas dire qu’on tombe dans une forme de standardisation ou de servicisation des infrastructures produites. Au contraire : disposer d’une bibliothèque d’environ 500 modèles capables de couvrir la portion générique du projet nous permet de nous concentrer en priorité sur la partie spécifique qui va amener la valeur ajoutée. Et si nous avons besoin d’un ajustement sur un composant générique, nous le dupliquons et créons une nouvelle branche, exactement comme on le ferait sur un applicatif. On arrive de cette façon à concevoir des infrastructures parfaitement spécifiées, taillées pour fonctionner au plus près de l’application, alors qu’elles exploitent 80% de composants génériques.

Le besoin business doit piloter le projet

Les bénéfices de cette industrialisation sont immédiats en termes de coûts comme de process. D’un côté, l’automatisation élimine une bonne partie du besoin de supervision manuelle et réduit le nombre d’incidents. De l’autre, le code rapproche l’infra du business, de la même façon que le déploiement par feature permet d’accélérer le développement. Dans les deux cas, on livre du code, et les outils se chargent du reste.

En parlant d’outils… faut-il partir sur Ansible, Terraform, Cloud Formation ou un autre ? La question n’est pas triviale : une techno peut paraître séduisante parce qu’elle donne des résultats rapides, mais l’essai n’est pas transformé si elle manque les enjeux à long terme. Gekko est partisan d’une approche non dogmatique, même si nous avons tous nos petites préférences. Le bon outil, c’est celui que l’on maîtrise et qui rend les services demandés. L’objectif de l’infra as code consiste précisément à ne plus laisser la techno dicter ses choix : c’est le besoin business qui doit piloter. On sélectionnera donc un ou plusieurs outils en fonction des contraintes de l’application, de son éventuel fonctionnement multiplateformes, etc.

Reste à voir comment se mettre en ordre de marche. A ce niveau, l’adhésion est la pierre angulaire de la réussite, puisque l’automatisation va nécessairement faire bouger les lignes en termes de missions et de limites de responsabilités. Tout l’enjeu consiste à s’approprier ensemble l’infra as code, afin que l’attention puisse se porter sur l’amélioration de l’exploitation et l’application proprement dite.

Laisser une réponse