Pourquoi adopter la démarche infra as code ?

Inside GroupActualité
L’Infrastructure as Code, ou IaC, est un mode de configuration destiné à approvisionner et administrer automatiquement une infrastructure informatique.

Elle ne nécessite que l’usage du code, et s’affranchit des processus manuels. Matthieu Strohl, Lead cloud, nous donne sa vision de l’IaC, qui s’inscrit dans une démarche d’intégration continue, et plus généralement DevOps.

Pouvez-vous nous donner votre vision de l’Infra as Code ?

L’infra as code permet d’accélérer, de fiabiliser et d’automatiser le déploiement et la mise en production. Elle donne cette possibilité de partir d’une page blanche pour déployer une infrastructure spécifiquement pensée pour une application. Elle sera ainsi flexible pour ses Use Cases ou ses Workloads. Elle permet également aux développeurs de travailler sur une infrastructure qui se rapproche beaucoup de celle de la production, quel que soit l’environnement. Ils codent dans des conditions « réelles ». L’IaC peut être vu comme une couche supplémentaire d’automatisation du taylorisme habituellement rencontré, et s’inscrit dans une démarche d’intégration continue. Car ce serait faire la moitié du chemin de dire que la mise en œuvre des applications est automatisée sans aller jusqu’à l’infra.

Quels sont les autres avantages de la démarche Infra as Code ?

Un design bien ajusté. Prenons l’exemple des conteneurs et des machines virtuelles (VM), qui se trouvent à l’intersection de l’applicatif et de l’infra. Les standards de sécurité et d’usages font que les entreprises tendent à avoir leur propre image, commune pour les VM, ou de base pour les conteneurs. Ces images doivent être maîtrisées en interne, et l’infra as code permet d’élaborer un design qui va coller très précisément au besoin.

L’IaC est une démarche qui permet de ne pas se concentrer uniquement sur le but primaire, c’est-à-dire déployer de l’infrastructure. Elle donne en effet cette possibilité de déployer aussi une approche service. Elle peut amener par exemple de la sécurisation avec le DevSecOps, du FinOps, ou des mécaniques bien pensées de scaling et de gestion de la ressource. L’IaC permet aux équipes infras de faire beaucoup plus.

Nous ne parlons donc plus seulement de rationalisation, de fiabilisation ou de sécurisation, mais également de performances. Ainsi, à travers l’IaC et l’automatisation, les entreprises peuvent accélérer leur time to market ou leur time to business. 

Est-ce que l’Infra as Code s’adapte à toutes les infrastructures ?

Aujourd’hui les outils le permettent. Terraform par exemple propose une multitude d’interfaçages qui permet d’adresser quasiment toutes les infrastructures. C’est le langage par excellence de l’IaC, qui permet de déployer une infra en 3 commandes. Il existe tout de même des cas où certains équipements restent difficilement pilotables, comme des équipements réseaux par exemple. Mais les Ops et les DevOps peuvent créer des couches d’abstractions quand elles n’existent pas. Je pense que c’est aussi une partie de notre travail que de faire évoluer les choses quand certaines solutions n’existent pas encore. Il faut alors les créer et de les restituer à la communauté. Car quand nous utilisons un outil comme Terraform, 90% du travail a déjà été fait par quelqu’un qui a eu la bonne volonté de le partager. La démarche DevOps vise l’échange et une montée en compétence continus.

Existe-t-il des freins hors infrastructure à l’usage de l’infra as code ? 

Le plus gros problème peut se trouver dans la philosophie, l’approche et les processus du client. Il existe encore beaucoup de services qui restent bloqués sur le fait qu’une infrastructure ne pourrait se gérer que depuis une console, ou directement dans le datacenter. Ne pas vouloir se remettre en question peut donc être un frein. Il faut challenger ses processus en les mettant à plat. Il faut se dire « aujourd’hui j’ai un outil à disposition qui est l’IaC, comment je peux l’utiliser pour rendre mes processus plus efficients ». Cela permet également d’apporter de la valeur ajoutée au travail. Concrètement, après la phase de code et la première itération, le développeur peut se demander ce qu’il peut faire de plus. Comme ajouter des vérifications en amont ou du hardening. Mais sans automatisation et sans IaC, le développeur ne se posera jamais ces questions qui permettent d’aller encore plus loin. Car jamais il n’aura le temps de se les poser.

Y a-t-il des outils Infra as code à privilégier ?  

Cela dépend essentiellement de l’approche IaC, impérative ou déclarative. J’utilise Ansible pour l’impératif, et Terraform pour le déclaratif. L’approche impérative apporte le principe de l’idempotence. Cela signifie qu'une opération a toujours le même effet qu'on l'applique une ou plusieurs fois. Elle a ma préférence, car elle permet de garantir que les choses seront telles qu’elles ont été pensées à l’origine. Par définition, une production bouge régulièrement. Et quelqu’un peut créer un incident et oublier de revenir en arrière, oublier de nettoyer le code… L’approche déclarative ne va pas forcément traiter ces problèmes, alors que l’approche impérative peut aisément garantir qu’il n’y aura pas d’altération.

Mais de manière plus générale, il faut toujours avoir une approche agnostique. Il ne faut pas se dire « je suis sûr Azure je n’irais jamais sur AWS » par exemple. Je choisis toujours la solution qui m’apporte le plus de facilité à intégrer le changement. L’outil Terraform peut faire de l’AWS, du GCP, de l’Alibaba, de l’On-premise… Il permet d’adresser presque toutes les infrastructures qu’elles soient virtuelles ou physiques. Si cette solution couvre 98% du besoin, je m’accommoderai des 2% restants. Mon crédo c’est la flexibilité, car s’il faut opérer de gros changements, il y a 99% de chance que ce soit plus simple avec un outil open source.

Vous souhaitez échanger avec nos experts autour de vos enjeux et de l’infra as code, c’est par ici !

Je choisis toujours la solution qui m’apporte le plus de facilité à intégrer le changement