Project-as-a-Service (Belastingdienst)
InfoQ report (KubeCon + CloudNativeCon Europe) on the Dutch tax authority (Belastingdienst)‘s internal-platform pattern, presented by Jerry van Hulst & Marcel Kerker. It’s a concrete instance of the internal-developer-platform idea and the answer side of the kubernetes-integration-tax: where the integration tax names the problem (every team wires ~20–30 CNCF tools differently — “the ‘Wild West’ even within the same cluster”), Project-as-a-Service is a cure — make the integrated “right way” the default, self-service way.
The mechanism
- A single YAML config provisions a team a pre-configured environment — “namespaces and RBAC to
resource quota” — via a Kubernetes operator (
belastingdienst/opr-paas). Automation-first; no manual setup. - Golden Path standardization — “making the ‘right way’ the easiest way to build software” — the load-bearing idea (see internal-developer-platform). It’s a reconcile-from-declaration loop, a gitops-shaped answer applied to project provisioning rather than app config.
The org/people half (not just tooling)
The platform-as-a-product story is as much social as technical:
- Enablement over support — shift from a helpdesk model to building team self-sufficiency.
- Communities of Practice — knowledge-sharing across 99+ DevOps teams (directly attacks the integration tax’s “knowledge fragmentation”: teams solving logging/ingress incompatibly).
- Accelerator Hackathons — platform experts pair full-day with teams for hands-on onboarding.
- Planned next: AI-driven auto-answers to free engineers for high-value enablement (an aiops-adjacent application to the platform-support workflow).
Why it matters here
It promotes platform-engineering from “assemble the tools” to “productize the assembly”: the IDP
- golden paths are how an org pays down the integration tax at scale instead of re-paying it per team. A rare named, real-world (enterprise, 99+ teams) data point for the platform-as-a-product thesis, beside the wiki’s mostly-conceptual sources.
Caveat
Conference talk via a secondary report (InfoQ); benefits (“reduced friction significantly”) are qualitative, not measured (no MTTR/onboarding-time numbers) — the spoke’s standing quantification gap.
Related
internal-developer-platform · platform-engineering · kubernetes-integration-tax · gitops · kubernetes · platform-ops · synthesis