Crossplane vs Terraform : La Bataille pour le Contrôle de l'Infrastructure

Terraform est le roi de l'Infrastructure as Code (IaC) depuis des années. Mais un nouveau challenger, Crossplane, gagne du terrain en apportant la gestion de l'infrastructure directement au sein de Kubernetes.

Terraform : Le Standard Éprouvé

• Langage : HCL (HashiCorp Configuration Language).
• Workflow : Plan et Apply. L'état (state) est stocké dans un fichier.
• Points forts : Écosystème de providers massif, lisible, largement adopté.
• Points faibles : Gestion des fichiers de state, pas de correction native de la dérive (drift).

Crossplane : Le Challenger Kubernetes-natif

• Langage : YAML (Custom Resources Kubernetes).
• Workflow : Boucle de contrôle (Control Loop). Crossplane réconcilie en continu l'état réel avec l'état souhaité.
• Points forts : Détection native de la dérive, gestion unifiée apps et infra, utilise le RBAC Kubernetes.
• Points faibles : Courbe d'apprentissage pour les non-utilisateurs de Kubernetes, verbosité du YAML.

Ce qui change vraiment (au-delà du langage)

Le différentiel le plus important n’est pas HCL vs YAML, mais le modèle opérationnel :

• avec Terraform, vous appliquez une intention à un instant T (puis vous gérez l’écart via des plan)
• avec Crossplane, vous déléguez une intention à un contrôleur qui réconcilie en continu

Cela influence la façon dont vous gérez la dérive, les permissions et l’auditabilité.

Un guide de décision en 3 questions

1. Votre “source of truth” est-elle Kubernetes ? Si oui, Crossplane s’intègre naturellement (RBAC, GitOps, namespaces).
2. Avez-vous beaucoup de ressources hors Kubernetes ? IAM, réseau, comptes/projets cloud, SaaS : Terraform reste souvent plus simple.
3. Voulez-vous exposer de l’infra en libre-service ? Crossplane brille quand vous proposez des abstractions : “créer une base de données” devient une ressource Kubernetes.

Pièges fréquents

• Crossplane sans design produit : si vous exposez des CRDs trop proches des providers, vous recréez de la complexité au lieu de l’absorber.
• Terraform sans garde-fous : sans conventions, modules, CI et politiques, le “plan/apply” devient un chantier permanent.

Lequel choisir ?

• Choisissez Terraform si vous avez une grande variété de ressources hors Kubernetes ou si votre équipe maîtrise déjà le HCL.
• Choisissez Crossplane si vous êtes "tout-Kubernetes" et que vous souhaitez gérer votre infrastructure avec les mêmes outils et patterns que vos applications.

Conclusion

Le choix entre Terraform et Crossplane dépend de votre écosystème actuel et de votre modèle opérationnel cible. Terraform reste le leader polyvalent, tandis que Crossplane offre une vision séduisante d’une infrastructure gérée comme vos workloads : via une API déclarative et une boucle de contrôle.

En pratique, il est courant de combiner les deux : Terraform pour les fondations, Crossplane pour des abstractions self-service côté Kubernetes.