Terraform @ Scale n’est pas une question d’utilisation de l’outil. C’est une question d’Operating Model.
Sans modèle de gouvernance structuré, on obtient :
- des forks de modules non maîtrisés
- des standards de sécurité divergents
- des responsabilités floues
- des risques opérationnels en hausse
- des surfaces d’attaque réglementaires
- un impact financier significatif dû à des mauvaises configurations
Cet article de clôture de notre série décrit de manière synthétique :
- un Terraform Operating Model transversal
- des principes de gouvernance et de structure
- des responsabilités organisationnelles
- l’intégration CI/CD et Policy
- l’agrégation des risques au niveau de l’entreprise
- un blueprint complet pour Terraform @ Scale
Public cible : CIO, CISO, Head of Platform Engineering, Cloud Architects.
Lire la suite : Terraform @ Scale - Partie 8 : Guide opérationnel pour décideurs et architectes
"Versionnage ? Oh, je prends toujours la dernière version - qu’est-ce qui pourrait bien mal tourner ?"
C’est précisément ce genre d’attitude qui explique pourquoi certains ingénieurs sont réveillés à 3 heures du matin par un appel d’urgence. Et pourquoi, le lendemain matin, tout le monde regarde ses chaussures pendant le Daily Stand-up.
Avant que cela ne vous arrive aussi, parlons-en brièvement dans le dernier volet de notre série « Terraform @ Scale ».
Lire la suite : Terraform @ Scale - Partie 7 : Bonnes pratiques pour le versionnage des modules
"Au diable la visibilité - tant que ça marche !"
C’est avec cet état d’esprit que la plupart des équipes de Platform Engineering courent à leur perte. C’est un peu comme cuisiner les yeux bandés dans une cuisine inconnue : ça peut fonctionner un moment, mais lorsque ça brûle, c’est pour de bon.
Et rien n’est pire que de voir des visages désemparés lorsque tout part en fumée.
Dans les deux parties précédentes, nous avons abordé la douleur liée aux dépendances. Voyons aujourd’hui quelles sont les options dont nous disposons pour repêcher un projet déjà tombé dans le puits avant qu’il ne soit trop tard.
Dans l’article précédent, nous avons examiné la complexité cachée des modules imbriqués et l’effet domino, et nous avons pris conscience des conséquences désagréables que cela peut entraîner dans l’exploitation et le lifecycle-management. On peut ouvrir toute grande la porte à ce type de problèmes en commettant des erreurs de débutant – surtout l’erreur de regrouper plusieurs, voire tous les modules Terraform dans un dépôt Git commun. Avec un peu plus de séniorité et une planification soignée, on peut cependant minimiser ces problèmes dès le départ.
Voyons dans cette partie comment gérer ces dépendances en pratique, sans que la douleur ne devienne insupportable.
Lire la suite : Terraform @ Scale - Partie 6b : Gestion pratique des modules imbriqués
Quand une simple mise à jour de module paralyse 47 équipes...
Nous sommes lundi matin, 10h30. L’équipe de Platform Engineering d’un grand fournisseur de Managed Cloud Services vient de publier une mise à jour « inoffensive » du module de base pour les instances VM, passant de la version v1.3.2 à la v1.4.0. Le changement ? Un nouveau tag Freeform obligatoire pour l’affectation des ressources à des centres de coûts.
Ce que personne n’a anticipé : l’ingénieur senior qui, autrefois en tant que décideur, avait insisté avec véhémence pour déposer tous les modules Terraform dans un seul dépôt Git. « La gestion de versions, c’est trop de micro-management. Comme ça, c’est plus ordonné. Et cela demande moins de travail », avait-il dit à l’époque.
Le même lundi, à 15h00 : 47 équipes de clients différents signalent déjà que leurs pipelines CI/CD échouent. La raison ? Leurs root-modules référencent les modules mis à jour par le fournisseur, mais personne n’a implémenté les nouveaux paramètres dans ses propres root-modules. Le contrôle de conformité du fournisseur est actif et rejette les exécutions Terraform en raison des tags obligatoires manquants. Ce qui devait être une amélioration s’est transformé en un arrêt organisationnel complet avec un impact massif sur les clients d’hébergement.
Bienvenue dans le monde des dépendances entre modules avec Terraform @ Scale.
Lire la suite : Terraform @ Scale - Partie 6a : Comprendre et gérer les modules imbriqués