Pourquoi vous ne devriez pas utiliser Databricks Asset Bundles (DAB)

Le contexte

Depuis quelques années, Databricks pousse activement son outil Databricks Asset Bundles (DAB) comme solution de déploiement pour les projets data. L’argumentaire est séduisant : donner l’autonomie aux équipes data, simplifier les déploiements, éviter la complexité de Terraform. Mais la réalité est bien différente.

DAB en bref

Databricks Asset Bundles est un outil de déploiement qui permet de packager et déployer des ressources Databricks (jobs, workflows, notebooks, etc.) via des fichiers de configuration YAML. L’idée est d’offrir une alternative “plus simple” à Terraform pour les équipes data qui ne maîtrisent pas l’Infrastructure as Code.

Terraform en bref

Terraform est l’outil de référence pour l’Infrastructure as Code, développé par HashiCorp. Il permet de décrire, versionner et déployer n’importe quelle infrastructure via du code déclaratif (HCL). Le provider Databricks pour Terraform existe depuis des années et couvre (presque) l’ensemble des ressources de la plateforme.

L’argumentaire : “Les Data Engineers ne maîtrisent pas Terraform”

C’est l’argument qu’on entend systématiquement pour justifier DAB : “Terraform c’est trop compliqué pour les équipes data, c’est un outil d’infra, les DE (Data Engineers) ne savent pas l’utiliser.” En d’autres termes : “Chacun son périmètre, chacun ses responsabilités, chacun ses méthodes de travail.”

La réalité ? Il faut une journée pour apprendre les bases de Terraform et être autonome. Une seule journée. Vous ne serez pas expert, mais vous saurez créer et déployer 80% de ce dont vous avez besoin. Je l’ai vécu, mes collègues l’ont vécu, des dizaines de Data Engineers l’ont vécu.

Si on estime qu’un Data Engineer est incapable d’apprendre la syntaxe HCL en une journée, on a un sérieux problème de recrutement ou de formation, pas un problème d’outillage.

Pourquoi DAB est une mauvaise idée

1. Un wrapper de Terraform… sans ses fonctionnalités

DAB n’est rien d’autre qu’un wrapper autour du provider Terraform Databricks. Sauf qu’au lieu de bénéficier de toute la puissance de Terraform, vous héritez d’une version édulcorée, bridée, avec moins de fonctionnalités.

2. Pas de modules, pas de réutilisation de code

Terraform permet de créer des modules réutilisables pour standardiser vos déploiements. Besoin d’un pattern de job Databricks avec monitoring, alerting et retry ? Créez un module, appelez-le partout.

Avec DAB ? Vous allez copier-coller votre configuration YAML à chaque fois.

3. Le remote state ? Poussé dans le workspace Databricks

Le state Terraform est l’un des éléments les plus critiques de votre infrastructure. Avec Terraform, vous le versionnez dans S3, Gitlab … avec chiffrement, verrouillage et historique complet.

Avec DAB ? Le state est poussé directement dans le workspace Databricks. Pas de versioning natif, pas d’historique accessible. Vous êtes obligés de créer un job de backup custom pour ne pas tout perdre.

4. Pas de linting ni d’analyse de sécurité native

Terraform bénéficie d’un écosystème mature : terraform validate, tflint, checkov, kics, tfsec… Des dizaines d’outils pour analyser la qualité et la sécurité de votre code avant même de le déployer.

Avec DAB ? Vous devez créer vos propres règles custom.

5. Obligation de spécifier les targets/environnements

DAB vous force à spécifier explicitement les targets et environnements dans votre code. C’est exactement l’inverse du principe fondamental de l’IaC : le code doit être agnostique de l’environnement dans lequel il tourne.

Avec Terraform, votre code reste le même, seules les variables changent. Dev, staging, prod : même code, configurations différentes. Propre, maintenable, scalable.

6. Include limité à un seul niveau

Besoin de structurer votre code avec des inclusions multiples ? Terraform le fait nativement avec les modules imbriqués.

DAB ? Un seul niveau d’include. Cette limitation vous contraint dans votre architecture et vous empêche de structurer votre code de manière modulaire et scalable comme vous le feriez naturellement avec Terraform.

7. Couverture incomplète des Service Principals

Toutes les ressources Databricks ne sont pas prises en charge par DAB pour la création de Service Principals. Vous allez devoir jongler entre DAB et d’autres outils pour gérer vos identités. Quelle cohérence !

8. Mixage de technologies dès qu’on sort du périmètre Databricks

Scénario réel : votre workflow Databricks doit lire des données depuis Kafka ou OpenSearch. Vous avez besoin d’un rôle IAM AWS (rappelons que Databricks ne fonctionne qu’avec AWS, Azure & GCP).

Avec Terraform ? Tout dans le même code : le rôle IAM, les policies, le job Databricks, les permissions. Un seul terraform apply.

Avec DAB ? Vous devez mixer DAB pour Databricks et Terraform (ou autre) pour l’IAM. Deux outils, deux workflows, deux states, deux CI/CD. Le cauchemar.

9. Pas de mono-repo multi-environnements natif

Impossible nativement d’avoir un mono-repo qui gère les artifacts de déploiement pour tous vos environnements. Impossible qu’un repo A appelle un artifact DAB publié dans un repo B.

Avec Terraform ? Les modules distants, les registries Terraform, tout est là depuis des années.

┌─────────────────────────────────────────┐
│         Avec Terraform                   │
│                                          │
│  Repo A (modules)                        │
│    └─ modules/                           │
│         ├─ databricks-job/               │
│         └─ databricks-cluster/           │
│                                          │
│  Repo B (prod)                           │
│    └─ main.tf                            │
│         └─ module "job" {                │
│             source = "git::repo-a"       │
│           }                              │
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
│         Avec DAB                         │
│                                          │
│  Repo A                                  │
│    └─ databricks.yml                     │
│         (copier-coller nécessaire)       │
│                                          │
│  Repo B                                  │
│    └─ databricks.yml                     │
│         (duplication du code)            │
│                                          │
│  ❌ Pas de réutilisation possible        │
└─────────────────────────────────────────┘

10. Une CI/CD dédiée à créer et maintenir

Vous serez contraint de créer une CI/CD spécifique pour DAB. Alors que vos autres composants d’infrastructure utilisent déjà Terraform avec des pipelines rodés et testés.

Plus de complexité, plus de maintenance, plus de documentation à écrire.

Donc pourquoi DAB existe ?

Je suis convaincu que Databricks est sincère dans sa démarche : simplifier le déploiement pour les Data Engineers et leur donner plus d’autonomie. L’intention est louable.

Mais le résultat n’est pas au rendez-vous. En voulant créer un outil “plus simple”, ils ont créé un wrapper limité qui bride les fonctionnalités de Terraform sans apporter de réelle valeur ajoutée. Au final, vous perdez en flexibilité, en maintenabilité et en compatibilité avec l’écosystème IaC existant.

Le problème de fond reste le même : former une équipe data à Terraform prend une journée. Contourner les limitations de DAB vous fera perdre du temps à votre équipe DevOps.

Conclusion

Databricks Asset Bundles est une régression. C’est un wrapper limité de Terraform qui vous fait perdre en fonctionnalités, en flexibilité et en maintenabilité, tout ça pour une “simplification” qui n’en est pas une.

Si vos équipes data ne savent pas utiliser Terraform, formez-les. Une journée suffit. Vous gagnerez en autonomie, en qualité et en cohérence avec le reste de votre infrastructure.