Comparaison des solutions IaC¶

Cette page alimente un ADR (Architecture Decision Record) pour le choix d'un outil d'Infrastructure as Code. Les solutions evaluees couvrent des approches différentes du provisioning d'infrastructure.

Panorama des approches¶

Le marche IaC se divise en trois familles d'approches :

Grille de comparaison¶

Analyse détaillée¶

OpenTofu — DSL declaratif open source¶

Forces :

• Fork open source de Terraform, maintenu par la Linux Foundation
• Compatible avec l'ecosysteme Terraform existant (providers, modules, registry)
• HCL est un langage declaratif conçu pour l'IaC : lisible et predictible
• 4 000+ providers couvrant tous les clouds et services majeurs
• State management mature avec locking, encryption et backends multiples
• Communauté en forte croissance depuis le changement de licence de Terraform

Faiblesses :

• HCL est un langage a apprendre (pas un langage général-purpose)
• Logique conditionnelle limitee par rapport à un langage de programmation
• Drift detection uniquement a l'execution de tofu plan

Cas d'usage : provisioning multi-cloud, équipes ops, ecosysteme Terraform existant.

Pulumi — Général-purpose languages¶

Forces :

• Utilisation de langages connus (Python, TypeScript, Go, C#, Java)
• Logique de programmation complète (boucles, conditions, fonctions)
• Tests unitaires et d'integration avec les frameworks habituels
• Terraform bridge pour réutiliser les providers Terraform
• Crossguard pour les policies as code

Faiblesses :

• State par defaut dans Pulumi Cloud (SaaS, dependance éditeur)
• Self-hosted backend disponible mais moins integre
• Ecosysteme natif plus restreint (150+ providers vs 4 000+)
• Complexité accrue : un langage général-purpose peut produire du code IaC complexe
• Verbeux pour des cas simples qui sont concis en HCL

Cas d'usage : équipes de développeurs preferant leurs langages, IaC complexe avec logique metier.

Crossplane — Kubernetes-native IaC¶

Forces :

• Fonctionne comme un opérateur Kubernetes natif (CRDs + reconciliation continue)
• Drift detection en temps reel (reconciliation loop)
• Compositions pour abstraire et réutiliser des patterns d'infra
• Modèle GitOps natif (les CRDs sont des manifestes YAML)
• CNCF Incubating, adoption croissante

Faiblesses :

• Necessite un cluster Kubernetes comme plan de contrôle
• Courbe d'apprentissage elevee (CRDs, compositions, XRDs)
• Debugging complexe (chaîne de reconciliation multi-niveaux)
• Ecosysteme de providers encore en maturation
• Surpoids si l'équipe ne gère pas déjà Kubernetes

Cas d'usage : organisations Kubernetes-first, plateformes internes, IaC GitOps.

AWS CDK — IaC spécifique AWS¶

Forces :

• Langages général-purpose (TypeScript, Python, Java, Go, C#)
• Constructs de haut niveau (L2/L3) qui encapsulent les bonnes pratiques AWS
• Integration native avec CloudFormation et les services AWS
• CDK for Terraform (cdktf) pour aller au-delà d'AWS

Faiblesses :

• Limite a AWS (CloudFormation en backend)
• State gère par CloudFormation (limites de taille, rollbacks complexes)
• Pas de multi-cloud natif
• cdktf est une surcouche, pas un remplacement

Cas d'usage : équipes 100% AWS, développeurs TypeScript/Python souhaitant rester sur AWS.

Ansible — IaC mode¶

Forces :

• Pas de state a gérer (idempotence via les modules)
• Syntaxe YAML familiere, faible courbe d'apprentissage
• Collections Galaxy pour tous les clouds (amazon.aws, google.cloud, azure.azcollection)
• Combine provisioning et configuration dans un seul outil
• Tres large communauté, 12+ ans de maturité

Faiblesses :

• Pas de state : pas de plan pour previsualiser les changements
• Drift detection inexistante (pas de reconciliation)
• Lent pour le provisioning d'infrastructure complexe (execution séquentielle)
• Les modules cloud sont moins riches que les providers Terraform/OpenTofu
• Approche imperative : l'ordre des tâches compte

Cas d'usage : équipes existantes Ansible, infra simple, combinaison provisioning + configuration.

Decision recommandee¶

Choix principal : OpenTofu¶

Decision : adopter OpenTofu comme outil principal d'Infrastructure as Code.

Justification :

Alternatives valides¶

Pulumi si :

• L'équipe est composee de développeurs qui préfèrent écrire en Python/TypeScript
• L'IaC necessite une logique metier complexe (boucles dynamiques, appels API)
• Les tests unitaires de l'infra sont une priorité

Crossplane si :

• L'organisation est Kubernetes-first avec un cluster dedie au plan de contrôle
• La reconciliation continue (drift detection temps reel) est un besoin critique
• L'équipe plateforme souhaite exposer des abstractions d'infra en self-service