Terraform ou Crossplane : Quel outil contrôle réellement votre cloud ?

L'illusion de la vérité unique en infrastructure

Le rituel est toujours le même : un vendredi après-midi à dix-sept heures, un développeur pressé modifie à la main la taille d'une instance de base de données directement sur la console Cloud pour résoudre un problème de performance immédiat. Le lundi matin, votre pipeline de déploiement automatique se déclenche, détecte cette modification non enregistrée, et écrase sauvagement la configuration pour rétablir l'état initial, provoquant instantanément une nouvelle panne de production. Cette situation absurde met en lumière la limite fondamentale de l'approche traditionnelle de l'Infrastructure as Code (IaC) : le décalage temporel et structurel entre la réalité de vos ressources cloud et l'état théorique décrit dans vos fichiers de configuration.

Pendant des années, nous avons accepté cette dérive comme une fatalité opérationnelle inhérente à la gestion d'infrastructure, colmatant les brèches à coup de tâches planifiées exécutant des analyses de détection de dérive en boucle. Cependant, l'émergence d'architectures basées sur un Control Plane natif transforme radicalement la manière dont nous concevons le cycle de vie de nos ressources virtuelles. La confrontation entre la vision statique, basée sur l'exécution ponctuelle de scripts, et la vision dynamique, portée par une réconciliation continue en arrière-plan, redéfinit en profondeur le rôle de l'ingénieur DevOps moderne.

Le paradigme statique de Terraform face à la réconciliation de Crossplane

Terraform et le mirage du state figé

Terraform repose sur un modèle d'exécution séquentiel déclenché par l'utilisateur ou par un outil d'intégration continue. Lorsque vous lancez une commande, l'outil compare votre code local avec un fichier de statut persisté, interroge les API des fournisseurs de services pour détecter les différences, puis applique les changements nécessaires. Ce processus fonctionne parfaitement pour créer une infrastructure initiale, mais s'avère incapable de garantir l'intégrité de vos ressources en temps réel dès lors que l'exécution de la commande est terminée.

Considérons un fichier de configuration Terraform classique définissant une base de données avec des paramètres de sécurité critiques. Une fois le code appliqué, Terraform s'endort et perd toute visibilité sur ce qui se passe réellement en production jusqu'à sa prochaine exécution manuelle ou automatisée.

resource "aws_db_instance" "production_db" {
  allocated_storage    = 100
  engine               = "postgres"
  engine_version       = "15.4"
  instance_class       = "db.r6g.xlarge"
  username             = "db_admin"
  password             = var.database_password
  skip_final_snapshot  = false
  publicly_accessible  = false
}

Si un intervenant extérieur ou un processus tiers modifie le paramètre d'accessibilité publique pour le passer à vrai, votre base de données se retrouve exposée à internet sans que votre système de déploiement n'en soit alerté. La dérive peut ainsi persister pendant des jours, voire des semaines, créant une faille de sécurité majeure au sein de votre réseau.

Crossplane et la puissance de la boucle de contrôle infinie

Crossplane aborde le problème sous un angle totalement différent en s'appuyant sur l'architecture robuste de Kubernetes. Au lieu de traiter l'infrastructure comme un ensemble de ressources à provisionner ponctuellement, Crossplane transforme votre cluster Kubernetes en un véritable Control Plane universel capable de gérer n'importe quelle ressource externe comme s'il s'agissait d'un simple conteneur applicatif.

Grâce aux définitions de ressources personnalisées (CRD), Crossplane déclare des objets représentant vos composants d'infrastructure. Le contrôleur interne de Crossplane exécute en permanence une Reconciliation Loop qui compare toutes les quelques secondes l'état désiré défini dans le cluster avec l'état réel de l'infrastructure cloud chez votre fournisseur.

apiVersion: database.aws.upbound.io/v1beta1
kind: RDSInstance
metadata:
  name: production-db
spec:
  forProvider:
    region: eu-west-3
    allocatedStorage: 100
    engine: postgres
    engineVersion: "15.4"
    instanceClass: db.r6g.xlarge
    masterUsername: db_admin
    masterPasswordSecretRef:
      name: db-credentials
      key: password
      namespace: default
    publiclyAccessible: false
  writeConnectionSecretToRef:
    name: db-conn-details
    namespace: default

Avec cette approche déclarative continue, toute tentative de modification manuelle de l'accessibilité publique sur la console AWS est immédiatement détectée par le contrôleur Crossplane. En l'espace de quelques minutes, le contrôleur émet une requête corrective auprès de l'API AWS pour restaurer la valeur définie dans le cluster, neutralisant ainsi automatiquement toute dérive de configuration sans aucune intervention humaine.

Analyse comparative : cas d'usage réels et douleurs de production

La gestion de la dérive en conditions réelles

Pour mesurer concrètement l'écart entre ces deux approches, imaginons la détection d'une dérive sur un compartiment de stockage dont le chiffrement a été désactivé par erreur par une application de maintenance défaillante. Voici comment réagit un pipeline de déploiement traditionnel basé sur Terraform face à cet incident.

# Événement de dérive détecté lors du run nocturne de Terraform
step: Run Terraform Plan
command: terraform plan -detailed-exitcode

Résultat:

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  ~ update in-place

  ~ aws_s3_bucket_server_side_encryption_configuration.encryption
      ~ rule {
          ~ apply_server_side_encryption_by_default {
              ~ sse_algorithm     = "AES256" -> "None"
            }
        }

Error: Process completed with exit code 2. Drift detected! Action required.

Dans ce scénario Terraform, l'alerte n'est levée qu'au moment de l'exécution du pipeline planifié. Pendant tout l'intervalle séparant l'erreur de manipulation et le déclenchement du pipeline, les données sensibles sont restées stockées sans chiffrement actif. À l'inverse, Crossplane intercepte cette anomalie de manière asynchrone et autonome, limitant la fenêtre d'exposition à la durée d'un cycle de réconciliation standard.

Le coût d'administration des deux solutions

L'adoption de Crossplane introduit cependant une complexité opérationnelle non négligeable. Alors que Terraform est un outil en ligne de commande léger qui s'exécute localement ou dans un simple conteneur éphémère de CI/CD, Crossplane nécessite un cluster Kubernetes hautement disponible pour fonctionner. Ce cluster doit être géré, surveillé, sauvegardé et sécurisé, ce qui représente une surcharge de travail importante pour les équipes d'ingénierie.

L'architecture sous le capot

Flux de déploiement et d'orchestration

Pour bien comprendre comment les données et les ordres transitent dans les deux systèmes, analysons le comportement de chaque outil lorsqu'une ressource cloud doit être provisionnée puis maintenue à jour face aux aléas de la production. La différence fondamentale réside dans l'emplacement du moteur de décision.

Le schéma ci-dessus met en évidence la rupture de chaîne caractéristique de Terraform : une fois la ressource provisionnée, aucun lien actif n'existe entre le code source et le monde réel jusqu'au prochain passage du pipeline de déploiement. À l'opposé, le modèle Crossplane s'appuie sur une boucle hermétique où le contrôleur interroge en permanence l'état de la ressource cloud pour l'aligner sur la spécification stockée dans la base de données interne de Kubernetes. Cette intégration native permet également d'exploiter la puissance des outils de GitOps comme ArgoCD pour synchroniser vos configurations d'infrastructure de la même manière que vos services applicatifs.

Le verdict du terrain : comment choisir son camp

Quand conserver Terraform dans votre infrastructure

Malgré l'élégance théorique de la réconciliation continue, Terraform reste le choix le plus pragmatique pour une grande majorité d'entreprises, en particulier celles dont l'architecture ne repose pas majoritairement sur Kubernetes. Si votre infrastructure se résume à quelques serveurs virtuels, une base de données managée et un réseau privé virtuel, l'introduction de Crossplane s'apparenterait à utiliser un marteau-pilon pour écraser une mouche.

De plus, l'écosystème de providers de Terraform est d'une maturité incomparable. Qu'il s'agisse de configurer un fournisseur SaaS obscur, de gérer des comptes utilisateurs sur une plateforme tierce ou de manipuler des infrastructures physiques sur site, vous trouverez presque toujours un provider officiel documenté et éprouvé par la communauté, là où Crossplane se concentre principalement sur les grands fournisseurs de cloud public.

Quand basculer sur Crossplane

Le basculement vers Crossplane devient pertinent dès lors que vous visez l'auto-service pour vos équipes de développement. Dans les organisations de grande taille, les développeurs doivent souvent attendre l'approbation d'un ticket par l'équipe d'infrastructure pour obtenir une base de données ou un accès de stockage pour leur nouvelle fonctionnalité. Crossplane permet de créer des abstractions personnalisées appelées compositions, masquant la complexité technique sous-jacente.

En définissant des modèles d'infrastructure réutilisables, vos développeurs peuvent déclarer leurs besoins directement dans leurs manifestes Kubernetes applicatifs sous la forme de requêtes de ressources simples, sans avoir besoin d'apprendre la syntaxe de Terraform ni de comprendre l'architecture réseau globale de l'entreprise.

Vers une convergence des outils d'infrastructure

La confrontation entre Terraform et Crossplane ne doit pas être perçue comme une guerre de religion technologique, mais plutôt comme l'adaptation de nos outils à des architectures applicatives de plus en plus dynamiques. L'approche statique de Terraform répond parfaitement aux besoins de stabilité et de contrôle rigide des fondations de votre système d'information, tandis que l'approche dynamique de Crossplane excelle dans l'agilité et l'automatisation fine des ressources consommées par vos applications conteneurisées.

Pour le professionnel DevOps, l'enjeu des prochaines années réside dans la capacité à orchestrer ces deux paradigmes de concert. Comprendre les forces et les limites de chaque modèle vous évitera de subir les pannes liées aux dérives silencieuses tout en vous prémunissant contre la complexité opérationnelle parfois étouffante des systèmes entièrement gérés par des boucles de contrôle.