L'infrastructure comme Workflow : au-delà de Terraform statique

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

Gérer les opérations cloud du Day 2. Traiter l'infrastructure comme un processus métier avec état, de longue durée.

Les limites de l'« Infrastructure as Code » : Day 1 contre Day 2

Nous aimons Terraform (IaC). Il a résolu le problème du provisionnement « Day 1 ». Vous décrivez votre état désiré (10 instances EC2, 1 RDS, 1 VPC), vous exécutez terraform apply, et le fournisseur cloud s'exécute. C'est parfait pour des ressources statiques. C'est déclaratif, idempotent, et versionné. C'est le socle du DevOps moderne.

Mais la réalité des opérations cloud, c'est que c'est le Day 2 qui concentre la complexité. Le Day 1, c'est le mariage ; le Day 2, c'est la vie de couple. Le Day 2 concerne les processus, pas seulement les ressources. Il s'agit du cycle de vie vivant et respirant du système à mesure qu'il évolue dans le temps.

Considérez le cycle de vie d'une mise à niveau critique de base de données. Ce n'est pas un événement statique ; c'est un workflow :

1. Préparation : instantané (snapshot) de la BD primaire vers S3, par sécurité.

2. Attente : vous devez attendre la fin du snapshot. Pour une base de données de plusieurs To, cela peut prendre 30 à 45 minutes.

3. Provisionnement : démarrez une nouvelle instance de BD à partir du snapshot, avec la nouvelle version du moteur.

4. Attente : attendez que la nouvelle instance devienne « Available » et « Healthy ».

5. Migration : connectez-vous à la nouvelle instance et exécutez un script de migration de schéma (Flyway ou Liquibase). Cela peut prendre 1 heure.

6. Vérification : exécutez une série de smoke tests sur la nouvelle BD pour garantir l'intégrité des données.

7. Bascule : en cas de succès, mettez à jour le CNAME DNS pour pointer vers la nouvelle BD.

8. Rollback : si une étape échoue, vous devez restaurer le DNS et détruire l'instance défaillante.

Terraform ne peut pas exprimer cela. Il est déclaratif, pas impératif. Il ne sait pas « attendre 30 minutes » ou « exécuter un script SQL et vérifier le code de sortie ». Pour gérer cela, les équipes ont généralement recours à envelopper Terraform dans des pipelines Jenkins, des jobs CircleCI, ou des scripts Python. Nous revoilà dans la « crise du Glue Code » (Partie 1), mais cette fois pour l'infrastructure. Ces scripts sont fragiles, sans état, et impossibles à déboguer lorsqu'ils échouent à mi-chemin d'une opération de 4 heures.

Traiter les opérations comme des workflows durables

Chez SchemaBridge, nous pensons que les opérations d'infrastructure sont des workflows métier. Elles ont les mêmes exigences qu'un flux de traitement de paiement : fiabilité, auditabilité, gestion d'état, et récupération d'erreurs.

En déplaçant vos opérations Day 2 vers SchemaBridge, vous gagnez la puissance d'un orchestrateur durable pour votre cloud :

Le pattern « Control Plane » : s'intégrer avec AWS, K8s et Terraform

SchemaBridge ne remplace pas Terraform ; il l'orchestre. Nous utilisons le pattern Control Plane pour unifier les mondes statique et dynamique.

1. Le déclencheur : un développeur commite du code ou déclenche manuellement un workflow « Provision Dev Env » depuis le portail développeur interne (Backstage).

2. Le provisionnement : SchemaBridge appelle l'API Terraform Cloud (ou exécute un terraform apply dans un Secure Worker) pour créer les ressources physiques.

3. L'attente : le workflow sonde l'API Terraform jusqu'à ce que l'exécution soit correctement « Applied ». Il gère la nature asynchrone du cloud.

4. Le post-provisionnement (la « couche logique ») : une fois l'infrastructure existante, SchemaBridge se connecte au nouveau cluster Kubernetes, exécute les migrations de BD, initialise les données de test, et lance les tests d'acceptation.

Ce pattern vous permet de garder vos ressources définies en HCL (HashiCorp Configuration Language) tout en gardant votre logique opérationnelle définie dans un graphe visuel.

Les environnements éphémères : le Graal de la vélocité des développeurs

Toute équipe d'ingénierie moderne veut des environnements éphémères — une réplique complète de la production pour chaque Pull Request (PR). Cela permet une véritable isolation et empêche les bugs d'arriver avant même leur fusion sur main.

Les approches traditionnelles échouent car elles sont difficiles à nettoyer. Vous démarrez des ressources pour la PR-123, mais le développeur oublie de fermer la PR, ou le script de nettoyage échoue. Votre facture cloud explose à cause d'« instances RDS zombies » et de « load balancers orphelins ».

Avec SchemaBridge, un environnement est un workflow avec un cycle de vie défini.

1. Démarrage : lancement des ressources (RDS, Redis, services ECS).

2. Attente : le workflow entre dans un état d'attente. Il attend que la PR soit fusionnée OU qu'un TTL prédéfini (par ex., 24 heures) s'écoule.

3. Nettoyage : lorsque le signal arrive ou que la minuterie expire, le workflow se réveille automatiquement et exécute terraform destroy.

Comme la logique de nettoyage fait partie de la même instance de workflow durable que la logique de création, il est impossible de l'oublier. Même si l'intégralité du cluster SchemaBridge redémarre, il se souviendra qu'il doit détruire l'environnement de la PR-123 à 17h00. C'est le « ramasse-miettes du cloud ».

Étude de cas : déploiement Blue/Green sans intervention pour le trading haute fréquence

Nous avons travaillé avec une société de trading haute fréquence qui devait mettre à jour son moteur d'appariement principal sans la moindre microseconde d'indisponibilité.

Le défi

Une mise à jour progressive (rolling update) Kubernetes standard n'était pas assez sûre, car ils devaient vérifier l'exactitude financière de la nouvelle version sur des données en direct pendant 10 minutes avant de basculer le trafic. Ils avaient besoin d'un déploiement complexe en « Shadow Mode ».

La solution SchemaBridge

Ils ont construit un « workflow de déploiement Blue/Green » dans SchemaBridge :

1. Déployer Green : démarrer la nouvelle version du moteur aux côtés de l'ancienne (Green).

2. Trafic fantôme : configurer l'API Gateway (Partie 9) pour envoyer une copie générique du trafic en direct vers Green (fire-and-forget). Les réponses de Green ne sont pas envoyées aux utilisateurs mais sont capturées.

3. Vérifier : le workflow a surveillé les logs de Green pendant 10 minutes. Il a utilisé JSONata pour comparer les sorties financières de Green par rapport à Blue (la version en direct).

4. Point de décision :

5. Basculer : le workflow met à jour le load balancer pour basculer le trafic utilisateur réel vers Green.

6. Nettoyer : il a attendu encore une heure (pour faciliter un rollback) puis a détruit Blue.

Le résultat

Ils ont réduit leur risque de déploiement à quasiment zéro. L'équipe SRE pouvait déclencher un déploiement et partir déjeuner, sachant que le workflow gérerait automatiquement la vérification complexe, le monitoring et la logique de rollback. Ils sont passés d'un déploiement par semaine à 10 déploiements par jour.

Gestion des coûts : le « workflow » du FinOps

L'optimisation des coûts cloud (FinOps) est souvent un processus manuel qui consiste à harceler les développeurs pour qu'ils éteignent leurs ressources. SchemaBridge vous permet d'automatiser cette gouvernance.

Le pattern « Night Watchman »

Vous pouvez déployer un workflow « Night Watchman » (veilleur de nuit) qui s'exécute chaque soir à 20h00.

1. Scan : isoler toutes les ressources taguées non-production.

2. Vérifier l'activité : vérifier les métriques CloudWatch pour une utilisation CPU < 5 % sur la dernière heure.

3. Extinction : si inactive, arrêter l'instance (sans la terminer).

4. Notifier : envoyer un message Slack au propriétaire : « Nous avons mis en pause votre machine de dev pour économiser de l'argent. Cliquez ici pour la relancer. »

5. Relance : lorsque le développeur clique sur le bouton le matin, un signal (Partie 7) réveille le workflow pour redémarrer l'instance.

Ce workflow simple a permis à l'un de nos clients grands comptes d'économiser $40,000 par mois sur ses coûts AWS EC2.

Comparaison : Jenkins/GitLab CI contre les opérations SchemaBridge

| Fonctionnalité | Pipelines CI/CD (Jenkins) | Opérations SchemaBridge |

| :--- | :--- | :--- |

| État | Éphémère (perdu au redémarrage) | Durable (survit des années) |

| Durée | Minutes/Heures | Jours/Semaines/Mois |

| Logique | Scriptée (Bash/Groovy) | Visuelle (graphe) |

| Approbation | Basique (bouton UI) | Riche (Slack/Email/Webhooks/Mobile) |

| Récupération | Retry depuis le début | Reprise depuis le point d'échec |

| Parallélisme | Limité par les executors | Mise à l'échelle serverless (Partie 3) |

Checklist d'experts pour l'automatisation des opérations

Pour moderniser votre stack opérationnelle, suivez ces heuristiques :

1. Ne scriptez pas les attentes : si vous écrivez sleep 60 en bash pour attendre un ALB, vous vous y prenez mal. Utilisez une boucle de scrutation dans un workflow durable.

2. Automatisez d'abord la suppression : écrivez la logique de nettoyage avant la logique de création. Assurez-vous que chaque événement de création dispose d'un chemin de destruction correspondant.

3. Utilisez des portes d'approbation : n'ayez pas peur de mettre un humain dans la boucle pour les actions à haut risque. Une « pause pour approbation » est une fonctionnalité, pas un bug.

4. Auditez l'opérateur : consignez qui a déclenché l'environnement et pourquoi. Utilisez le contexte du workflow pour taguer les ressources avec le User_ID du demandeur.

5. Traitez les opérations comme du code : versionnez vos workflows opérationnels tout comme votre code applicatif. Utilisez l'intégration git de SchemaBridge pour revoir les changements apportés à votre logique de déploiement.

Conclusion : le cloud est une machine à états

Votre infrastructure n'est pas un tas statique de serveurs ; c'est un composant vivant et respirant de votre activité. En la traitant comme une machine à états, vous pouvez automatiser les danses opérationnelles complexes, à étapes multiples, qui consomment aujourd'hui la vie de votre équipe SRE. Vous pouvez passer d'opérations « à base de tickets » à des opérations « en libre-service », avec sécurité et durabilité intégrées.

Dans la Partie 12, nous nous pencherons sur le « mythe du cold start » et sur la manière d'atteindre une latence sous la milliseconde dans une architecture événementielle serverless, sans garder les serveurs constamment chauds.

Explorer