Composable Data Stack voor IT-architecten

Positionering

CDS is een declaratieve control plane voor dataplatforms op compile-time. Je legt de gewenste architectuur vast als versiebeheerbare YAML, en CDS genereert daar deployment-artefacten uit. CDS draait zelf niets: het is een compiler en geen runtime-orchestrator. Zo blijft de scheiding tussen ontwerp, validatie en uitvoering helder.

Architectuurprincipes

Contract-first koppeling: modules praten niet rechtstreeks met elkaar. Een provider biedt een benoemd contract aan, een consumer declareert wat hij nodig heeft, en het profiel legt de binding vast. Een implementatie vervangen raakt daardoor alleen het profiel.
Isolatie: een module bevat nooit de servicenaam van een andere module. Cross-module afhankelijkheden lopen via bindings. dependsOn bepaalt alleen de opstartvolgorde.
Gesloten configuratieschema’s: elke module definieert zijn eigen configuratieruimte, inclusief defaults. Onbekende instellingen worden geweigerd.
Provider-neutraal: de stack is een samenstelling van capabilities (warehouse, orkestratie, identity, observability) en niet van producten.

Lagen

Laag	Rol
Profiel	Selectie van modules en topologie voor een omgeving
Module	Configuratieschema, contracten en implementatietemplate
Contract	Interface tussen modules (shared/contracts/)
Pipeline	load → validate → plan → render
Target	Docker Compose, Kubernetes (renderer in ontwikkeling)

Pipeline en garanties

Validate: vorm, modulepaden, dependency-graph, secrets, contractcompatibiliteit. Modulebronnen moeten relatief zijn en binnen modules/ liggen.
Plan: defaults worden gematerialiseerd en contracten opgelost tot een cds/v1alpha1-Plan, een tussenrepresentatie die los staat van het doelplatform.
Render: interpolatie en naamgeving (namespacing per module) leveren één consistent model.

Elke fout is een gestructureerde diagnostic met stabiele code en datapad. Latere stappen draaien niet door na een foutmelding.

Security- en compliance-by-design

Secrets: waarden worden nooit in plannen of gerenderde artefacten opgenomen. Alleen ${CDS_*}-placeholders worden uitgegeven, en pas de runtime lost ze op.
Policy as data: cds test past een regelset toe (rule-set.json, met schema), zodat beleid reviewbaar en uitbreidbaar is.
Hardening-baseline: non-root images, read-only root, dropped capabilities, resource limits, netwerksegmentatie en hash-locked dependencies.
Aantoonbaarheid: rapportage ondersteunt audits. De routekaart richt zich op de Cyber Resilience Act en Nederlandse publieke-sectoreisen.

Wat dit je als architect oplevert

Governance: de architectuur staat in code, met pull-request-review, diff-baar en traceerbaar.
Vendor-onafhankelijkheid: contracten maken exit en herplatformen mogelijk zonder herontwerp.
Reproduceerbaarheid: dezelfde input geeft dezelfde output voor ontwikkel-, test- en productieprofielen.
Uitbreidbaarheid: eigen modules en profielen kunnen in externe roots staan (CDS_MODULE_PATH, CDS_PROFILE_PATH).

Randvoorwaarden en kanttekeningen

CDS beheert de definitie van de stack: profielen, modules en contracten, inclusief het ophalen en bijwerken ervan. De uitvoering draait op Docker Compose, Kubernetes of je eigen tooling. CDS is geen runtime-orchestrator.
Monitoring en observability worden aangeboden als modules binnen de stack, zoals dashboards en log- en trace-verzameling, en niet als ingebouwde functie van CDS zelf. Welke beschikbaar zijn, staat op de roadmap.
Het formaat heet v1alpha1, dus houd rekening met wijzigingen in het schema.
Kubernetes-ondersteuning, back-up/herstel en TLS-contracten staan op de roadmap en zijn nog niet allemaal beschikbaar.

Aanbevolen aanpak

Begin met een bestaand referentieprofiel en draai cds test.
Leg je eigen contracten en beveiligingsregels vast.
Voeg CDS toe aan CI, zodat elke wijziging eerst valideert.
Breid uit met eigen modules waar bestaande niet passen.

Ook uitgelegd voor

Terug naar Composable Data Stack (CDS) · Broncode op GitHub · Contact