Project-as-a-Service (Belastingdienst)

InfoQ report by Ben Linders, published 11 June 2026 (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.

The stack it is built on (recorded 2026-08-12)

The report names the components: OpenShift over Kubernetes, Tekton for pipelines, Argo CD for delivery, Backstage as the developer portal, Kustomize for config, and ChatOps for the support surface. This matters more than a tool list: Argo CD is one of the two reference reconcilers on gitops, so the “reconcile-from-declaration” reading above is not an analogy the wiki imposed — the platform is literally running a GitOps reconciler underneath its provisioning operator. Backstage plus a self-service operator is the internal-developer-platform pattern in its most common concrete form.

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.

Re-read 2026-08-12 confirmed the gap rather than closing it. Going back to the article for numbers returned the same single figure it always carried — 99+ DevOps teams — and no time-to-provision, no onboarding duration, no before/after of any kind. Two months on, the most-cited real-world instance of platform-as-a-product in this spoke still reports its scale and not its effect.

Regraded stable. This is a dated news report: re-reading the URL returns the June text, so the volatile flag it carried since ingest could never fire. Per QUALITY.md, whether the Belastingdienst platform still looks like this is a question for a new source, not a re-read of this one.

internal-developer-platform · platform-engineering · kubernetes-integration-tax · gitops · kubernetes · platform-ops · synthesis