Speakers at KubeCon + CloudNativeCon Europe described how a 2017 OpenShift proof of concept broke down at scale, and what an enablement first operator model is meant to put back in product teams' weeks.
The Kubernetes tax landed all at once. Logging, ingress, storage: every product team was solving the same problems in incompatible ways, inside what was supposed to be a single shared cluster. Engineers on the platform side called it a Wild West. The product teams called it Tuesday.
That is the picture Jerry van Hulst and Marcel Kerker drew in their KubeCon + CloudNativeCon Europe talk "Ghost in the Platform," summarized by Ben Linders for InfoQ. The session was less a product pitch than a postmortem of a platform team's own pivot, from a 2017 OpenShift proof of concept built on near-total developer autonomy to an enablement-first operator model the presenters call Project-as-a-Service.
The origin story matters because the original model was not careless. It was the opposite. The 2017 platform team set out to give product engineers maximum freedom: pick your stack, pick your patterns, pick your own way through the cluster. The bet was that freedom would compound into velocity, and in the early days it did. Adoption looked healthy. The product teams that opted in were the kind of engineers who thrive with elbow room.
The bill came due in 2019. The platform's early adopters were a self-selecting group, comfortable stitching together their own observability and routing. Once the platform had to scale to a broader population of product teams, the cognitive load stopped being a badge and started being a tax. Teams solved the same problems in mutually incompatible ways, the platform team found itself spending more time triaging "why is this not working" than building new capability, and the answers were almost always the same.
That is the inflection the talk names. It is not a failure of developer autonomy, exactly. It is a failure of autonomy to scale past the engineers who arrived pre-equipped to use it. The platform team's read, as reported by InfoQ's summary of the KubeCon presentation, was that the answer was not to take freedom away. It was to make the right way the easiest way.
The mechanism the presenters describe is a posture change on the platform team itself, from support to enablement. In the old model, the platform team handed product teams a cluster, a wiki, and a Slack channel, and waited for tickets. In the new model, the platform team works alongside product teams for the duration of onboarding, with a named operator attached to each project, treating the internal engagement the way an external platform-as-a-service team would treat a customer: defined outcomes, paved roads, automation that turns onboarding into a product rather than a process.
The label the talk lands on is Project-as-a-Service, an internal PaaS-style engagement model distinct from the public-cloud PaaS category. The point of the name is not branding. It is to mark a contract change: the platform team is accountable for the product team's time-to-value, not just for keeping the cluster up. Onboarding steps that used to live in a wiki move into templates and operators that run them by default. Logging, ingress, and storage stop being decisions and start being defaults. The paved road is the point.
There is a temptation, watching this arc, to read it as a swing of the pendulum from chaos back to control. The talk resists that read, and the resistance is the part worth keeping. The shift is not from autonomy to lock-in. It is from autonomy-as-default to enablement-as-default, on the explicit theory that the right way should be the easy way, and that paving the right way is the platform team's job. The constraint shows up at the design layer, not the freedom layer.
There is also a sourcing caveat. The framing is the presenters' own. The talk, as covered by InfoQ, is a single team's conference presentation of its own journey, not a benchmarked study. The labels "Project-as-a-Service" and the named mechanism belong to van Hulst and Kerker's team, and the talk does not, on the available summary, present measured outcomes. Readers mapping the pattern onto their own platforms should treat it as a shape, not a recipe.
The watch item from here is whether the paved road keeps up with the next wave of product teams. The 2017-to-2019 arc, as the talk tells it, is the proof that the autonomy-first model breaks past a certain scale. The enablement-first model is the response. The test the next phase of the platform will set is whether the paved road keeps up with the product surface area, or whether the team ends up back where it started, answering the same "why is this not working" questions with a different wiki.