De moderne data stack heeft een compositieprobleem. Orchestratie, opslag, transformatie, BI, security en observability zijn stuk voor stuk prima tools geworden — maar de koppelingen ertussen leven in environment variables, in de hoofden van engineers, of in custom code die bij elke toolwissel breekt. De Moeilijkste vraag is niet langer “welke tool is het beste?”, maar “hoe passen deze tools in elkaar, en kunnen we later nog van gedachten veranderen?”
Dat is precies waar de Composable Data Stack (CDS) op inspeelt: een open framework waarin je een platform samenstelt uit modules die via expliciete contracten met elkaar praten. In deze post: wat CDS vandaag al kan, wat de aanstaande Kubernetes-MVP bewijst, en waarom dit framework breder is dan alleen data warehousing — richting een volwaardig Haven-platform voor álle applicaties van een gemeente.
Wat CDS nu al heeft
Modules en contracten. Elke module (een container image + module.yaml) declareert welke contracten hij levert (provides) en gebruikt (consumes). Het contractnetwerk is de ruggengraat van het hele systeem. Stabiele modules staan in modules/:
| Categorie | Module | Contract |
| identity | Keycloak | oidc-provider, http-service |
| secrets | Vault | secrets-provider |
| security | Istio | service-mesh |
| integration | Traefik | reverse-proxy |
| storage | Garage | object-storage |
| cache | KeyDB | cache-service |
| backup | restic | backup-target |
| warehouse | Postgres, DuckDB | sql-database, file-database |
| orchestration | Dagster | http-service |
| transformation / bi | dbt, Superset | http-service, docs-service |
Daarnaast staan in modules-experimental/ al modules voor hele andere typen platformcapaciteit:
| Categorie (experimental) | Module | Contract |
| gitops | FluxCD | gitops-target |
| observability | Loki, OTel-collector | log-sink, metrics-sink, trace-sink |
| observability | Grafana, Marquez | http-service, lineage-sink |
| ingestion | dlt | backup-source (pipelinestate als backup-bron) |
| orchestration | Airflow | http-service, scheduler, metadata-db-client |
| warehouse | postgres-operator | sql-database (operator-managed) |
| backup | object-storage | consumeert object-storage (backup naar S3-compatible store) |
Profielen als pure bedrading. Een profiel is niets meer dan modules die via contractRef aan elkaar gekoppeld worden — local-haven-reference combineert bijvoorbeeld Keycloak + Postgres + Traefik in een Haven-conforme opzet, zonder één handgeschreven routebestand.
Een CLI met fail-closed gates. cds validate, security, preflight, plan, render, up — met expliciete E-/W-errorcodes, een lokaal audit trail, en twee render targets: Docker Compose én Kubernetes/Helm (--target helm, inclusief NetworkPolicy-generatie en een k3d-harness).
Een maturity model. cds maturity rapporteert per profiel een tier — Basic, Automated, Observed, Secured, Resilient — op basis van welke platformcontracten er écht zijn opgelost.
Al gebouwde afstemming op de public sector. De FDS data-provider contract (open-data-provider), NIS2/Cyberbeveiligingswet-gebaseerde cds security-checks, CRA-readiness (SBOM, release evidence gate), OpenLineage lineage voor Dagster, en de Common Ground/Haven mapping in docs/common-ground-alignment.md.
Wat de MVP test
In docs/plan/k8s-haven-mvp.md staat een runbook dat in één cyclus, vanaf een schone machine met alleen Docker, vier claims bewijst:
- Kubernetes werkt end-to-end: installeer de CLI vanaf PyPI, zet een lokale k3d-cluster op, en draai een profiel via
--target helmdoor de volledige lifecycle (up→state→down), met opgenomen evidence. - De deployment is production-ready: het productie-profiel doorstaat de fail-closed gates (
validate,security,preflight) en de 13-controls production hardening checklist. - Haven-parity is gemeten, niet geclaimd:
cds maturitymeet de Haven+ baseline-capabilities (GitOps, observability, security, database operator, backup, networking) één voor één. Elke blokkerende gap is verplicht werk in de cyclus — de gates 0 t/m 5 pauzeren tot het bijbehorende issue dicht is. - De cyclus eindigt in een v1.0.0 release.
Bewuste non-goals: géén claim van gecertificeerde Haven+ compliance, géén multi-cloud, géén CDSProfile CRD/operator — en de Compose-path blijft onaangetast als tweede render target.
Wat er in de toekomst mogelijk is
Hier wordt het interessant. De engine van CDS — module.yaml + contracten + profielen — is al applicatie-agnostisch. Alleen de naam en een paar categorieën (warehouse, transformation, bi) suggereren data warehousing. In de praktijk zijn identity, secrets, security, storage, cache, backup en ingress herbruikbaar voor élke applicatie.
De logische volgende stap is daarom een veralgemenisering naar een Composable Haven Framework: Haven+ is dan niet het product, maar één profiel-familie boven op een generieke contract-engine. Concreet:
- Een nieuwe categorie
modules/application/met applicatiemodules die platformcontracten consumeren (sql-database,oidc-provider,secrets-provider,object-storage) en zelfhttp-servicepublishen — denk aan een zaaksysteem (OpenZaak), een CRM, een finance-app of een integratie-applicatie. - Nieuwe contract kinds waar applicaties om vragen:
message-queue(RabbitMQ/Kafka),event-source/webhook-target. - Nieuwe profielen als pure compositie:
local-haven-crm= Postgres + Keycloak + Traefik + Vault + de app. TLS, SSO, secrets, backup en observability komen gratis mee via het contractnetwerk.
Kortom: CDS is vandaag een werkende, geteste data stack met een Kubernetes/Helm target en een MVP die Haven-parity meetbaar maakt richting v1.0.0. En de architectuur laat zien dat hetzelfde framework morgen net zo goed een gemeentebrede platformlaag kan zijn waarop zaaksystemen, CRM en integratie-applicaties draaien — Haven+ als één van de vele profiel-families, in plaats van het hele verhaal.
Wil je meedoen? De repo staat op GitHub: RonaldHensbergen/composable-data-stack. De quickstart in de README kost minder dan tien minuten.