Waarom Declarative Automation Bundles de nieuwe standaard zijn voor Databricks-projecten
Databricks is de afgelopen jaren enorm veranderd. Waar het platform ooit vooral draaide om notebooks en losse jobs, wordt het steeds meer een volwaardig softwareontwikkelplatform. Een van de grootste stappen in die ontwikkeling is de introductie van Declarative Automation Bundles (DABs).
Misschien ken je ze nog onder hun oude naam: Databricks Asset Bundles. De naamswijziging is eigenlijk niet zo interessant. Veel interessanter is wat Bundles mogelijk maken en waarom ze de manier waarop je Databricks-oplossingen ontwikkelt fundamenteel veranderen.
Het probleem met traditionele Databricks-projecten
Veel Databricks-projecten beginnen klein. Je maakt een notebook, zet een job in elkaar via de UI en klikt een pipeline bij elkaar. Voor één engineer en één omgeving werkt dat prima. Maar zodra een project groeit, ontstaan er al snel problemen. Jobs worden handmatig aangepast, test en productie lopen uit elkaar en niemand weet meer precies welke configuratie actief is.
Zodra een wijziging alleen in de workspace bestaat en niet in Git, heb je technische schuld opgebouwd. Die wijziging is niet gereviewd, niet reproduceerbaar en vaak lastig terug te draaien. Op dat moment zijn er eigenlijk twee waarheden ontstaan: de code in Git en de configuratie in de workspace.
Alles in code
Declarative Automation Bundles lossen dat probleem op door niet alleen je notebooks of Python-code te beheren, maar je complete Databricks-project. Een Bundle kan onder andere bevatten:
- Lakeflow Jobs en Pipelines
- Dashboards en SQL-alerts
- Unity Catalog schema's en volumes
- Apps en Model Serving Endpoints
- Vector Search Indexes en Genie Agents
- Lakebase Postgres-projecten
- Permisses en deployment targets
In plaats van deze resources handmatig aan te maken, beschrijf je simpelweg hoe jouw omgeving eruit moet zien. Dat gebeurt declaratief. Je zegt niet: maak een job. Je zegt: dit is hoe mijn Databricks-omgeving eruit hoort te zien. De Databricks CLI zorgt vervolgens dat de werkelijke omgeving overeenkomt met die gewenste situatie.
Waarom declaratief zoveel krachtiger is
Het woord declaratief klinkt misschien als een technisch detail, maar de impact is veel groter dan dat. Doordat niet alleen je broncode, maar ook je Databricks-resources in Git worden beheerd, ontstaat één centrale bron van waarheid voor je complete oplossing. Infrastructuur kan net als applicatiecode worden gereviewd via pull requests, elke wijziging is versiebeheerbaar en deployments worden reproduceerbaar. Ontwikkel-, test- en productieomgevingen blijven consistent, wijzigingen zijn eenvoudig terug te draaien en samenwerken wordt een stuk eenvoudiger.
Dat maakt projecten niet alleen betrouwbaarder, maar ook beter onderhoudbaar. Een nieuwe engineer hoeft niet langer uit te zoeken welke jobs ooit handmatig zijn aangepast of waarom een pipeline in productie afwijkt van die in test. De volledige configuratie van de oplossing staat immers vastgelegd in de repository.
Meer dan alleen CI/CD
Vaak worden Bundles gezien als een hulpmiddel voor CI/CD. Dat is maar een deel van het verhaal. De echte winst zit in het feit dat een Databricks-project steeds meer gaat lijken op een regulier softwareproject. Je repository bevat niet alleen Python-code, maar ook infrastructuur, configuratie, permissies, deployment-instellingen en tests. Daardoor verdwijnen losse scripts en handmatige configuraties steeds verder naar de achtergrond. Dat sluit veel beter aan bij moderne software engineering-principes zoals Infrastructure as Code en GitOps.
Databricks zet hier volledig op in
Ook Databricks zelf laat zien dat dit de standaardrichting is. Waar Bundles voorheen onder water gebruikmaakten van Terraform, gebruikt de nieuwste deployment-engine sinds kort een directe koppeling met de Databricks API en wordt Terraform voor bundle deployments uitgefaseerd. Daardoor worden deployments eenvoudiger, sneller en kunnen nieuwe resource-types sneller worden ondersteund. Dat laat zien dat Bundles niet langer een handige extra zijn, maar de manier waarop Databricks verwacht dat projecten worden gebouwd.
Begin klein
Gebruik je vandaag de dag nog handmatig aangemaakte jobs of pipelines? Dan hoef je niet alles in één keer om te zetten. Begin met één belangrijke job of pipeline en neem die op in een Bundle. Zodra dat werkt, kun je steeds meer onderdelen declaratief beheren. Zo groeit je project stap voor stap naar een volledig beheerde Databricks-omgeving zonder een grote migratie.
Conclusie
Voor mij zijn Declarative Automation Bundles veel meer dan een nieuwe deploymenttool. Ze zorgen ervoor dat een Databricks-oplossing niet langer bestaat uit losse notebooks en handmatig aangemaakte resources, maar uit een volledig softwareproject waarin broncode, infrastructuur, configuratie en deployments samen worden beheerd. Dat maakt projecten beter onderhoudbaar, eenvoudiger schaalbaar en veel betrouwbaarder. Juist daarom zie ik Declarative Automation Bundles als een van de belangrijkste ontwikkelingen binnen Databricks van de afgelopen jaren. Niet vanwege de nieuwe naam, maar omdat ze Databricks dichter dan ooit bij moderne software engineering brengen. Als je nu een nieuw project start, zou een declaratieve aanpak het uitgangspunt moeten zijn en geen keuze.
