Wat we leerden van het bouwen van een deployment framework voor moderne data-platformen

Van honderden regels YAML naar een schaalbaar deployment framework

Bij vrijwel ieder data-platform komt vroeg of laat dezelfde uitdaging naar boven: hoe zorg je dat deployments betrouwbaar, herhaalbaar en beheersbaar blijven terwijl het platform groeit?

In het begin lijkt alles overzichtelijk. Een paar pipelines, een ontwikkelomgeving en een productiestraat zijn vaak voldoende om snel resultaten te boeken. Maar zodra meerdere engineers, workloads en omgevingen samenkomen, ontstaat er nieuwe complexiteit. Deployment wordt dan niet langer een ondersteunend proces, maar een essentieel onderdeel van het platform.

Een aantal jaar geleden liepen wij tegen precies dat vraagstuk aan. Bij verschillende projecten zagen we dezelfde uitdagingen terugkomen. Pijplijnen werden gekopieerd, aangepast en opnieuw opgebouwd. Teams maakten vergelijkbare keuzes, maar op net andere manieren. Het gevolg was dat kennis versnipperde en verbeteringen lastig schaalbaar waren.

Dat was de aanleiding voor ons Deployment Framework. Wat begon als een verzameling herbruikbare CI/CD-patronen groeide uit tot een modulaire fundering voor moderne data-platformen. Niet omdat iedere organisatie hetzelfde werkt, maar omdat veel deploymentuitdagingen verrassend veel overeenkomsten hebben.

Het probleem zat niet in de technologie

Toen we de eerste versies van het framework ontwikkelden, ontdekten we iets opvallends. De grootste uitdaging zat meestal niet in de technologie zelf.

Azure DevOps, Terraform, Databricks en Fabric bieden allemaal uitstekende mogelijkheden om deployments te automatiseren. Het echte probleem zat vaak in de manier waarop teams die mogelijkheden inzetten. Iedere omgeving kreeg zijn eigen structuur, iedere pipeline ontwikkelde zich op zijn eigen manier en na verloop van tijd ontstonden meerdere varianten van hetzelfde proces.

Dat lijkt flexibel, maar brengt ook nadelen met zich mee. Nieuwe collega’s moeten opnieuw ontdekken hoe een project in elkaar zit. Verbeteringen moeten op meerdere plekken worden doorgevoerd. En het risico neemt toe dat deployments zich per omgeving anders gaan gedragen.

Daarom hebben we een duidelijke ontwerpkeuze gemaakt: standaardiseren waar het kan, configureren waar het moet.

In plaats van deploymentlogica telkens opnieuw te bouwen, wordt deze centraal beheerd. Projectteams richten zich vervolgens vooral op configuratie en de inhoud van hun workload. Daardoor ontstaat meer voorspelbaarheid zonder flexibiliteit te verliezen.

Waarom we kozen voor templates in plaats van maatwerk

Een van de belangrijkste bouwstenen van het framework is het gebruik van centrale templates.

In veel organisaties bevatten pipelines honderden regels YAML die grotendeels hetzelfde doen. Dat maakt beheer lastig en zorgt ervoor dat verbeteringen telkens opnieuw moeten worden doorgevoerd.

Ons framework draait dit principe om. Vanuit een projectrepository worden centrale templates aangeroepen die vervolgens de benodigde deploymentlogica genereren. Daardoor blijft de projectspecifieke code beperkt, terwijl de onderliggende functionaliteit juist groeit. Tijdens onze kennissessie lieten we zien dat een relatief kleine configuratie uiteindelijk kan uitgroeien tot een deploymentproces van honderden regels YAML zonder dat een engineer die allemaal handmatig hoeft te onderhouden.

De voordelen daarvan worden steeds groter naarmate een platform groeit:

• Consistente deployments tussen teams en projecten
• Minder onderhoud aan pipelines
• Snellere adoptie van verbeteringen
• Eenvoudiger kennisoverdracht
• Lagere kans op configuratiefouten

Het resultaat is dat engineers minder tijd besteden aan deploymentbeheer en meer tijd kunnen besteden aan het ontwikkelen van waardevolle oplossingen.

Schaalbaarheid begint bij de omgevingstructuur

Een andere belangrijke les die we hebben geleerd, is dat veel organisaties het toevoegen van nieuwe omgevingen moeilijker maken dan nodig.

Binnen het framework zijn omgevingen volledig configuratiegedreven. Hierdoor hoeft bij een uitbreiding van bijvoorbeeld development, test, acceptatie en productie niet iedere keer een nieuwe deploymentstraat gebouwd te worden. In de praktijk betekent dit vaak dat een extra configuratiebestand voldoende is om een nieuwe omgeving onderdeel te maken van het proces.

Dat klinkt als een klein detail, maar het laat zien hoe belangrijk ontwerpkeuzes zijn. Wanneer omgevingen vanaf het begin als herbruikbare bouwblokken worden behandeld, blijft een platform ook beheersbaar wanneer het aantal teams, projecten of workloads groeit.

Juist deze schaalbaarheid was een van de belangrijkste redenen om het framework verder door te ontwikkelen.

Eén fundament voor verschillende workloads

Moderne data-platformen bestaan zelden uit één technologie.

Binnen dezelfde omgeving zien we regelmatig een combinatie van infrastructuur, Databricks-workloads, Microsoft Fabric, Function Apps, Container Apps, databases en API-componenten. Elk van deze onderdelen heeft zijn eigen deploymentvereisten.

Toch wilden we voorkomen dat iedere workload een volledig eigen deploymentaanpak kreeg. Daarom hebben we het framework opgebouwd uit drie lagen:

1. CI/CD als fundering
2. Infrastructuur als code
3. Workloads boven op die infrastructuur

Door deze scheiding blijft het mogelijk om nieuwe technologieën toe te voegen zonder het fundament te veranderen. Het framework ondersteunt inmiddels verschillende workloads, terwijl de onderliggende deploymentprincipes grotendeels hetzelfde zijn gebleven.

Dat maakt kennis overdraagbaar. Een engineer die begrijpt hoe één workload wordt uitgerold, herkent veel van dezelfde patronen bij andere workloads.

Security moet onderdeel zijn van het ontwerp

Deployment wordt vaak gezien als een technisch vraagstuk, maar security speelt minstens zo’n belangrijke rol.

Een van de uitgangspunten van het framework is daarom dat gevoelige gegevens nergens onnodig worden opgeslagen. Secrets worden niet vastgelegd in repositories en worden ook niet langdurig opgeslagen binnen pipelines. In plaats daarvan worden ze dynamisch opgehaald vanuit Azure Key Vault wanneer ze nodig zijn.

Daarnaast hebben we de afgelopen jaren de overstap gemaakt naar moderne authenticatiepatronen zoals OIDC. Hierdoor neemt de afhankelijkheid van traditionele service principal secrets af. Dat is niet alleen veiliger, maar voorkomt ook veel operationele problemen rondom verlopen credentials en handmatige rotaties.

Security moet geen extra stap achteraf zijn. Het moet een standaardonderdeel van het deploymentproces zijn.

Een deployment is pas geslaagd als je kunt terugrollen

Misschien wel de belangrijkste les uit alle implementaties is dat succesvol deployen slechts de helft van het verhaal is.

De echte vraag is wat er gebeurt als iets onverwacht fout gaat.

Daarom besteden we veel aandacht aan validatie, health checks en rollbackmechanismen. Verschillende workloads bevatten controles waarmee een deployment direct na uitrol wordt gevalideerd. Wanneer blijkt dat een nieuwe versie niet correct functioneert, moet het mogelijk zijn om snel terug te keren naar een werkende situatie.

Dat vertrouwen is essentieel. Teams die weten dat terugrollen beheersbaar is, durven vaker kleinere wijzigingen uit te brengen. En juist kleinere wijzigingen leiden meestal tot stabielere releases, minder risico en een hogere kwaliteit.

Het framework is nooit af

Misschien klinkt dat vreemd voor iets dat gebaseerd is op standaardisatie, maar een deployment framework is nooit echt klaar.

Nieuwe technologieën, nieuwe workloads en nieuwe inzichten zorgen voortdurend voor verbeteringen. De introductie van Microsoft Fabric, nieuwe authenticatiemodellen, aanvullende teststrategieën en verbeterde deploymentpatronen zijn allemaal voorbeelden van ontwikkelingen die invloed hebben gehad op het framework.

Iedere implementatie levert bovendien nieuwe lessen op. Sommige verbeteringen ontstaan vanuit technische uitdagingen. Andere komen voort uit feedback van engineers die dagelijks met het platform werken.

Juist daardoor blijft het framework relevant. Het groeit mee met de behoeften van moderne data-platformen.

Conclusie: een deployment framework gaat uiteindelijk niet over deployments

Toen we begonnen met het ontwikkelen van het framework, wilden we deployments sneller en consistenter maken.

Gaandeweg ontdekten we dat de grootste waarde ergens anders zit.

Niet in de YAML-bestanden. Niet in de templates. En ook niet in de tooling zelf.

De echte waarde zit in het delen van kennis, het hergebruiken van bewezen patronen en het creëren van een fundering waarop teams sneller kunnen bouwen. Door veelvoorkomende keuzes één keer goed uit te werken, ontstaat een platform dat eenvoudiger schaalbaar, beheersbaar en overdraagbaar wordt.

Wat wij hebben geleerd, is dat succesvolle deployments niet beginnen bij technologie. Ze beginnen bij een consistente manier van werken.

En juist daar kan een deployment framework het verschil maken.

Benieuwd hoe andere data-teams deploymentuitdagingen aanpakken?

We gaan graag in gesprek over ervaringen, best practices en lessen uit de praktijk van CI/CD, Infrastructure as Code en moderne data-platformen.