Project-as-a-Service: How One Team Replaced Total Autonomy with a Paved Road on OpenShift

When Jerry van Hulst and Marcel Kerker presented Ghost in the Platform at KubeCon & CloudNativeCon Europe, they described a trajectory familiar to anyone who has run an internal Kubernetes platform: start with maximum freedom, watch it produce maximum friction, then spend years engineering that friction back out. Their answer was a Project-as-a-Service operator and a deliberate shift from running a helpdesk to running an enablement program.

What they built, and what it cost

The story begins in 2017 with a small team standing up an OpenShift proof of concept. The operating philosophy was total developer autonomy. "We provided the platform, and developers were responsible for the entire lifecycle," Van Hulst explained. For early adopters, this worked. The people who showed up first were enthusiasts who wanted control over their namespaces, their ingress, their pipelines, and they were happy to pay the configuration cost to get it.

By 2019 the model started to crack along two predictable fault lines.

The first was cognitive load. Kubernetes does not give you an application platform out of the box. It gives you primitives, namespaces, RBAC bindings, resource quotas, network policies, ingress controllers, and a CI/CD toolchain you assemble yourself. Each of those is a decision, and each decision is a place to get it wrong. Newer teams, the ones who joined after the early enthusiasts, found the learning curve too steep. Van Hulst described the result as a "Kubernetes tax": teams spending more time operating the platform than writing the code the platform was supposed to ship.

The second fault line was knowledge fragmentation. With no standardization, every team solved the same problems independently. Logging, ingress, secrets, and access control each got reinvented per team, often per service. "It was the Wild West even within the same cluster, which made it a headache for us to support and for teams to run," Van Hulst said. Two teams in the same cluster could have completely different ingress configurations, which means two different failure modes, two different debugging procedures, and two different sets of questions landing in the platform team's queue.

The combined effect inverted the original goal. Total freedom, intended to make teams fast, was making them slow. That realization pushed the team toward what the platform engineering community now calls a paved road: a default path that is opinionated, supported, and easy enough that choosing it is the obvious move.

The Project-as-a-Service operator

The current platform centers on an automation-first philosophy, and that philosophy reaches all the way into onboarding. The Project-as-a-Service operator lets a team describe the environment it wants in a single YAML file. From that declaration, the operator provisions the standard set of building blocks a team needs to start: namespaces, RBAC, and resource quotas, among other defaults.

This is a meaningful architectural choice rather than a convenience feature. By expressing a project as a custom resource and letting an operator reconcile it, the platform turns onboarding from a manual, ticket-driven sequence into a declarative artifact. The YAML file becomes the source of truth for what a project is. It can be version controlled, reviewed, diffed, and reapplied. When the platform team wants to change the default RBAC posture or adjust quota policy across the fleet, they change the operator's reconciliation logic rather than chasing dozens of hand-built namespaces.

The contrast with the old process is stark. In the interview, Van Hulst described the original onboarding as "a manual, high-touch process to roll out new environments. Between us prepping the clusters and developers manually configuring their apps, it took forever for a team to actually start delivering value on the platform." A single YAML file replacing days of cluster prep and per-app configuration is the entire point of the operator pattern: encode the expertise once, then let the control loop apply it consistently.

Enablement over support

The operator handles provisioning. It does not, by itself, teach a team how to run software on the platform, and this is where Kerker drew the sharper distinction. "Instead of just functioning as a helpdesk that solves support tickets, our ultimate goal is to build genuine self-sufficiency within engineering teams," he said. "We want them to feel confident and capable."

With more than 99 DevOps teams on the platform, scaling that knowledge is its own engineering problem. The team's approach is structural rather than ad hoc:

• Communities of Practice, where teams learn from each other rather than routing every question through the platform team.
• A regular Container User Group (CUG) to demo new platform features and keep teams aware of what is available.
• Larger Containerization Days with plenary sessions and external speakers covering emerging technology.
• Targeted, self-paced workshops on the concrete tools teams actually use: Tekton for pipelines, ArgoCD for GitOps delivery, Identity and Access Management, RightSizing for resource tuning, and Kustomize for configuration management.

The initiative Kerker singled out as most impactful is the Accelerator Hackathon. "Rather than just handing over documentation, our platform experts sit side-by-side with a development team for a full day," he said. "We roll up our sleeves and work together to fast-track their first app onto the platform." This is enablement as a contact sport. Documentation scales cheaply but transfers knowledge poorly; a full day of pair work scales expensively but actually gets an app to production and leaves the team able to repeat the process. The bet is that the up-front cost of the hands-on day is recovered many times over in tickets that never get filed.

The lessons, stated plainly

Two reflections from the interview capture the shift better than any framework diagram.

Van Hulst, coming from infrastructure, described his old mental model: "If I gave you access to the server, my job is done." Cloud-native work broke that assumption. "If I give a developer a namespace but they have to spend three days configuring ingress and CI/CD, I haven't really helped them. My personal lesson is that my job isn't just to provide infrastructure, it's to remove the friction that stops code from reaching production."

Kerker's lesson was about standardization as the lever for adoption. "If every single team has to figure out the plumbing themselves, adoption grinds to a halt. By standardizing our processes, we remove that friction, prevent teams from reinventing the wheel, and make the platform significantly easier and more intuitive to embrace." There is a tension worth naming here: standardization and autonomy pull against each other, and the early platform erred fully toward autonomy. The correction is not to eliminate freedom but to make the standard path so frictionless that most teams take it voluntarily, leaving genuine deviation for cases that warrant it.

Where the platform is heading

The forward plan continues the theme of reducing cognitive load. The team intends to double down on what they call the Golden Path, making the right way the easiest way to build software. Concretely, that means deeper integration into Backstage, the open-source developer portal, and extending their CI/CD starters so that "developers have everything they need right out of the box."

They are also folding AI into operations, specifically AI-driven auto-answers for ChatOps and support tickets. The reasoning is consistent with the rest of their strategy: "By automating the resolution of repetitive questions, we give developers instant help, while freeing up platform engineers to focus on high-value enablement instead of basic support," Kerker said. Repetitive questions are exactly the load that prevents a small platform team from doing the side-by-side work that moves the needle, so automating answers protects the team's most valuable activity.

Finally, the roadmap itself is community-driven. The team prioritizes features requested by users and keeps listening to development teams to make sure they are building capabilities that solve day-to-day problems rather than hypothetical ones. For anyone running an internal platform, the arc here is instructive: the technology that scaled was a declarative operator, but the practice that scaled was treating developers as customers whose friction is the platform team's actual product.