Terraform vs Bicep voor Azure Databricks: welke tool voor welk deel

Platformteams die hun Azure-landingszone in Bicep hebben gestandaardiseerd, stellen mij geregeld dezelfde vraag: kunnen we Azure Databricks niet gewoon óók in Bicep uitrollen? Het korte antwoord: Bicep brengt u tot de deur van de workspace, en geen stap verder. Wie het hele platform als code wil beheren, komt bij Terraform uit. De enige uitzondering bespreek ik aan het eind, en die vraagt om een stevige dosis Databricks Asset Bundles.

Bicep stopt bij de deur van de workspace

De resource provider Microsoft.Databricks kent welgeteld vijf resource-types: de workspace zelf, access connectors, private endpoint connections, private link resources en VNet-peerings. Dat is alles. Geen clusters, geen jobs, geen catalogs, geen rechten.

Voor dat deel is Bicep prima. Een workspace met VNet-injectie en een access connector voor Unity Catalog is een handvol regels:

resource workspace 'Microsoft.Databricks/workspaces@2024-05-01' = {
  name: 'dbw-dataplatform-prd'
  location: 'westeurope'
  sku: { name: 'premium' }
  properties: {
    managedResourceGroupId: managedRg.id
    parameters: {
      customVirtualNetworkId: { value: vnet.id }
      customPublicSubnetName: { value: 'snet-dbw-public' }
      customPrivateSubnetName: { value: 'snet-dbw-private' }
      enableNoPublicIp: { value: true }
    }
  }
}

Samen met het VNet, de NSG’s, private endpoints en Key Vault is dit de laag waar ARM over gaat, en dus de laag waar Bicep thuis is.

Alles daarbinnen praat geen ARM

Het echte werk begint pas ná de workspace: de metastore-koppeling, storage credentials, external locations, catalogs en grants, cluster policies, SQL-warehouses, groepen en service principals. Die objecten leven niet in Azure Resource Manager maar achter de Databricks REST API’s, en daar heeft Bicep geen enkele ingang toe.

De Databricks Terraform-provider heeft als doel al die REST API’s te ondersteunen, en dekt in de praktijk alles wat u voor een platform-inrichting nodig heeft. Het patroon dat ik bij klanten neerzet: de azurerm-provider maakt de workspace en de access connector, de databricks-provider bouwt daarbinnen verder, en Terraform geeft de referenties automatisch door:

resource "databricks_storage_credential" "lake" {
  name = "cred-datalake-prd"
  azure_managed_identity {
    access_connector_id = azurerm_databricks_access_connector.uc.id
  }
}

resource "databricks_catalog" "sales" {
  name         = "sales_prd"
  storage_root = "abfss://catalogs@stdataplatformprd.dfs.core.windows.net/sales"
}

resource "databricks_grant" "sales_engineers" {
  catalog    = databricks_catalog.sales.name
  principal  = "data-engineers"
  privileges = ["USE_CATALOG", "USE_SCHEMA", "SELECT"]
}

Probeer dit in Bicep en u eindigt met deployment scripts die curl naar de Databricks-API doen. Dat is geen infrastructuur als code meer, dat is een shellscript met een YAML-jas aan.

Drie lagen, drie eigenaren

De discussie wordt zuiverder als u het platform in lagen knipt:

• De landingszone: VNet, subnets, NSG’s, private endpoints, de workspace zelf, de access connector. Dit is ARM-territorium. Bicep als uw organisatie dat als standaard heeft, anders azurerm in Terraform.
• De platformlaag: metastore-koppeling, storage credentials, external locations, catalogs, grants, cluster policies, warehouses, groepen. Hier bestaat geen Bicep-optie. Dit is de Databricks Terraform-provider, beheerd door het platformteam.
• De projectlaag: jobs, pipelines, dashboards en de schema’s van één team. Dit hoort niet in centrale Terraform-state thuis, want ontwikkelteams itereren hier dagelijks. Dit is het domein van Databricks Asset Bundles, inmiddels hernoemd naar Declarative Automation Bundles: YAML naast de code, uitgerold via de Databricks CLI in de CI/CD-pipeline van het team zelf.

Terraform in de projectlaag kan wél, maar ik raad het af: elke job-wijziging door de state en de pull request-molen van het platformteam duwen maakt van uw snelste laag uw traagste.

De DAB-zware route: kan het zonder Terraform?

Er is één configuratie waarin u Terraform kunt overslaan, en die is DAB-zwaarder dan de meeste teams beseffen. Bundles kunnen inmiddels veel meer dan jobs en pipelines: ook schema’s, volumes, SQL-warehouses, external locations en zelfs catalogs. Bicep voor de landingszone plus bundles voor vrijwel alles daarbinnen is dus technisch haalbaar.

Maar dezelfde documentatie is eerlijk over de gaten: de metastore, storage credentials, gebruikers en groepen, en connections kunnen bundles níet beheren. Precies de fundamenten van uw governance regelt u dan met de hand of met losse scripts. En bundles zijn per project gescoped: tien teams betekent tien plekken waar platformconfiguratie kan gaan afwijken, zonder centrale state die drift zichtbaar maakt.

Kies deze route alleen als Terraform organisatorisch echt onhaalbaar is en uw accountconfiguratie klein en stabiel is. Het is een werkbare uitzondering, geen aanrader.

Nooit alleen Bicep

De beslisregel die overblijft is kort. Geen Bicep-mandaat? Doe alles in Terraform, met azurerm en databricks naast elkaar, en bundles voor de projectlaag. Wél een Bicep-mandaat? Prima: Bicep voor de landingszone, Terraform voor de platformlaag, en u geeft de workspace-URL en het access connector-ID als output door. Beide combinaties werken goed.

Wat niet werkt is alleen Bicep. Dan heeft u een lege workspace als code en al het waardevolle daarbinnen als klikwerk, en klikwerk is precies wat u met governance vanaf dag één wilde voorkomen.

Tot slot

Bicep en Terraform zijn hier geen concurrenten, ze bedienen verschillende lagen: ARM buiten de workspace, de Databricks-API’s daarbinnen. Twijfelt u hoe u dit in uw organisatie knipt, neem dan contact op.