Pourquoi votre infrastructure-as-code ne tient pas ses promesses ?

Les promesses qui poussent à adopter l'IaC pour les infrastructures Cloud, sont grandes et elles méritent d’être remises au centre du débat. Partant de ces promesses, nous analyserons ensuite les critiques qui s'élèvent sous la forme des 7 murs principaux que vous rencontrerez. Pour finir, nous verrons quels sont les KPIs nécessaires pour suivre l’atteinte de ces promesses.

Quelles sont les promesses de l’infra-as-code ?

Le principe de l’infrastructure-as-code est, comme son nom l’indique, d’utiliser du code au sens du développement pour décrire l’infrastructure. Voici les principaux avantages que vous devez attendre de son adoption :

• Automatisation
• Reproductibilité des déploiements à la demande
• Réduction drastique des tâches manuelles, sources d’erreur
• Reproductibilité et testabilité des infrastructures
• Gestion de la complexité exponentielle des architectures
• Simplification de la mise à l’échelle
• Suivi et traçabilité des modifications d’infrastructures via le versionning

Il existe aussi quelques effets de bords bénéfiques comme la documentation auto-porteuse des infrastructures par exemple, et le rapprochement entre les Devs et les Ops, mais nous y reviendrons plus tard. Enfin, l’infrastructure-as-code vous donne une plus grande attractivité sur le marché pour trouver les compétences qui vous permettront de maintenir et de faire évoluer vos infrastructures Cloud.

Par extension, pour les organisations ayant atteint une grande maturité, l’infra-as-code permet l’adoption du modèle GitOps, qui utilise Git pour lier les applications et leurs infrastructures au sein d’une même chaîne de CI/CD.

Mais attention : “Aucun plan ne survit à son implémentation !”.

Quels sont les 7 murs de l’infra-as-code  ?

Les échecs sont rarement partagés, la toile regorge de références, de retours d’expériences et d’analyses glorifiant l’infra-as-code. L’absence de visibilité sur les échecs ne signifie pas pour autant qu’ils n’existent pas.

La presse, Gartner, Forbes, les spécialistes éditeurs, Cloud Provider et les ESN, sont unanimes : l'infra-as-code ça marche. Voyons maintenant ce qui se passe mal.

Une explosion du temps passé à livrer

Les équipes tâtonnent, prennent un temps qui paraît conséquent à décrire, par le code, les infrastructures. Lorsqu’enfin une automatisation est livrée, elle ne fonctionne pas à 100% et nécessite d’être retravaillée.

Au risque d’enfoncer des portes ouvertes, je pense nécessaire de le préciser via ce vieil adage publicitaire : “sans maîtrise, la puissance n’est rien !”.

Le passage à l’IaC doit être accompagné, et il ne s’agit pas seulement de maîtriser l’outil retenu pour votre automatisation. La difficulté du passage d’une interface graphique ou d’un scripting maison réalisé par des non-développeurs, au code implique :

• une connaissance fine des APIs de la plateforme
• une culture de base sur l’outillage retenu pour l’IaC
• des bonnes pratiques de développement

En infra-as-code, il faut, par exemple, manipuler tous les paramètres des composants à provisionner sur la plateforme. Cet ensemble de variables est rarement exposé via les interfaces graphiques. Il faut lutter contre ses habitudes et faire un effort de compréhension et d'apprentissage approfondi par rapport à l’approche sans automatisation.

Le code est trop verbeux et complexe

Une levée de bouclier à laquelle vous devez vous préparer se résume à cette phrase : “ça me prend 2 min de le faire à la main, et c’est plus simple !”. L’automatisation peut s’avérer complexe à mettre en place, particulièrement pendant le temps de montée en compétence. En l’état actuel des choses, les langages sont verbeux et syntaxiquement lourds. Si vous ajoutez à cela la complexité dans la gestion des sources et le besoin de refactoring régulier, vous pouvez bien vite tomber dans l’échec.  Un bon templating, de la modularisation et l’usage intensif de variable vous aidera à simplifier, alléger le travail, à moyen terme.

Automatiser une tâche qui prend quelques minutes et doit être répétée des centaines de fois, permet de gagner un temps précieux. Il faut toutefois bien comprendre que cela nécessite un effort.

Le danger de l’absolutisme

Nous avons tous rencontré ce type de problème : le choix du tout automatisé est entériné et il devient dogmatique. Il faut coûte que coûte tout décrire en infra-as-code pour assurer la fameuse couverture à 100%. Prenez garde ici, il existe des limites ! La volonté du tout automatique nécessite comme toute règle des exceptions et ne doit pas se faire au détriment de la prise de recul.

Certains pans de l’infrastructure ne sont tout bonnement pas faits pour être automatisés. Vous risquez de passer un temps excessif à tenter de coder des composants qui ne seront pas utilisés. Une bonne pratique pour éviter cet excès est de se concentrer sur l’automatisation des composants qui sont créés et détruits de façon répétitive.

Le support n’est pas complet

Voici un problème en lien avec le précédent, mais il est vrai que les outils d’infrastructure-as-code ne couvrent pas 100% des possibilités. Le degré de couverture fonctionnelle dépend de la cible et de la fréquence de mise à jour du composant en question. Celles et ceux qui utilisent le Cloud le savent bien, les services évoluent en permanence, les solutions d’IaC suivent avec un décalage certain (plusieurs semaines) les mises à jour. Notez bien ici que ce point est vrai pour des solutions éditeurs comme Terraform aussi bien que pour l’outillage des fournisseurs Cloud directement. Ne vous trompez pas, vous aurez bien plus de difficultés à suivre les mises à jour des services que vous utilisez qu’à intégrer ces mises à jour dans votre code d’infrastructure.

Un problème de stabilité

Le principe des outils d’IaC est de gérer et de maintenir l’état de l’infrastructure en concordance avec ce qui est décrit dans le code. Malheureusement, tout n’est pas merveilleux, et parfois les déploiements échouent ! Les causes possibles sont nombreuses :

• décalage entre le dernier état connu et l’état réel
• bug(s) dans le code d’infrastructure
• bug dans l’outil
• limitations de l’infrastructure
• …

Si les déploiements échouent, il y a fort à parier que la remédiation prendra du temps. Si vous avez la chance d’utiliser un outil supportant le rollback, mauvaise nouvelle, son fonctionnement est lui aussi faillible.

Il n’existe pas de solution miracle à ces problèmes, sinon de vous appuyer sur les pratiques d’amélioration continue, sur votre bon sens, et sur la mise en place de garde-fous pour éviter que les mêmes erreurs ne se reproduisent éternellement.

“Les Devs et/ou les Ops font n’importe quoi !”

Un point de blocage traditionnel est directement inhérent aux organisations en silos. Le code est mis en commun, mais les équipes ne parviennent pas à s’accorder et ne partagent pas assez.  Cela vous mène droit à l’échec, et exacerbe les tensions. Les déploiements échouent de façon récurrente car les modifications du code ne sont pas alignées. Ne faites jamais l’impasse sur la collaboration entre les équipes. L’infrastructure-as-code peut et doit devenir un vecteur de rapprochement entre Devs et Ops !

Ce n’est pas du code !

Les détracteurs de l’infra-as-code vous assènent certainement cet argument massue.

Soyons clair, c’est vrai ! La grande majorité des outils reposent sur un langage de configuration descriptif tel que le XML, le JSON, le YAML, teintés de sucres syntaxiques. Pour résumer de façon très simplifiée, les langages d’IaC sont des templates permettant de décrire des configurations variabilisées. Malgré cet état de fait, vous devez considérer et travailler vos sources comme du code développé et non comme du scripting.

En effet, elles doivent être correctement :

• versionnées
• vérifiées
• formatées
• intégrées aux chaînes de CI/CD
• développées

Vous devez tirer parti de l’ensemble des pratiques issues du monde du développement. Le code source d’une infrastructure Cloud, comme celui d’une application, est vivant : il est sujet au refactoring, aux tests, à la qualité syntaxique, à la modularisation, … Notez d’ailleurs que l’utilisation de langages de développement courants (Python, JS, Java, …) se propage via Pulumi ou AWS CDK par exemple.

Les promesses sont-elles tenues ?

Nous l’avons vu, il existe de nombreuses façons d’échouer avec l’infra-as-code. Son adoption peut devenir un enfer ! Pourtant, il y a deux bonnes nouvelles :

• Dans la grande majorité des cas, le succès est au bout du chemin.
• Les problèmes rencontrés ne viennent pas de l'infra-as-code en elle-même, mais de l’humain, de l’organisation et du manque de bonnes pratiques.

Pour vérifier factuellement la tenue de ces promesses, vous devez suivre des KPIs tels que :

• le Mean Time To Recovery (MTTR)
• le nombre de déploiements par trimestre (périodicité à adapter)
• le temps moyen de livraison de fonctionnalités,
• la durée moyenne des déploiements
• le taux de bug en production (ratio du nombre de défauts découverts en production sur le nombre de déploiements par période).

Ces métriques essentielles vous serviront à suivre une tendance et à identifier des plans d’actions pour accompagner la transformation.

Liens utiles :

• GitOps
• AWS CDK
• Pulumi
• Mean Time To Recovery

Vous souhaitez monter en compétence sur Terraform ? Nos experts vous proposent  une formation sur le sujet.

Inscrivez-vous vite sur training@wescale.fr les places sont limitées !