Before public cloud became widespread, the boundary between operations teams (system administrators, systems engineers, what we now call SRE) and development teams was clear-cut. This boundary was not arbitrary: it rested on genuine physical competence. The Ops team knew the hardware limits of the datacentre — the power available per rack, thermal capacity, cabling constraints, physical storage limits — and pushed back, with reasons, against any request that threatened those limits.

An unreasonable provisioning request from a Dev team or an outsourced web agency hit a technical red light, set by someone who genuinely understood why the request posed a risk. This refusal created real friction, often experienced as legitimate frustration by Dev teams under commercial deadlines that Ops did not always share.

It would be dishonest to present this older world as perfect. The rigidities of historical Ops also produced real inefficiencies, disproportionate delivery delays, and a sometimes excessively conservative culture. Dev teams' frustration with these delays was not unfounded. It is this legitimate frustration that opened the door to the next promise: what if friction could be removed without removing reliability?

The DevOps philosophy was born, originally, of a sound intention: bringing together two professions that communicated poorly, reducing time to production, and establishing shared responsibility over an application's full lifecycle. This intention is not in question here.

What followed was a structural drift more than an orchestrated plot. The spread of public cloud made it possible to create a hybrid profile — familiar with the basics of the tools Ops used (systems, middleware) and the basics of Dev's craft (agility, a few languages) — without that hybrid profile inheriting the deep physical competence that historically justified hard limits. The result is not a bridge between two complete professions. It is a dilution of both: neither the depth of the old Ops, nor the full depth of Dev, but a cross-cutting competence sufficient to operate within the cloud abstraction without ever needing to understand what lies beneath it.

This is the precise point that distinguishes this diagnosis from mere nostalgia for the old world. The problem is not that hard limits disappeared because people became careless. The problem is that cloud abstraction made the hard limit structurally unworkable, regardless of anyone's individual goodwill.

A command such as an infrastructure deployment produces an immediate, visible effect: a resource appears, a server boots, a console shows a green status. This pattern — minimal action, near-instant gratification, a sense of control — has long been documented in behavioural psychology under the name of immediate or intermittent reinforcement, and has been studied for years in the design of consumer digital interfaces: notifications, game mechanics, social networks.

This document advances a precise and limited thesis: this same immediate-gratification mechanism applies to the cloud provisioning experience. Clicking or running a command and seeing a resource appear instantly produces a sense of power and control disproportionate to the actual effort involved. The more total the abstraction, the faster the gratification, and the more invisible the real cost — financial, technical, physical — becomes at the moment of the action.

The net effect of this mechanism at a company's scale is cumulative: each small individual gratification (a fast deployment, a resource appearing) reinforces the collective habit of reaching for the abstraction rather than evaluating the structural cost. This is a product-design effect that translates into organisational behaviour — not a judgment on anyone's will.

The trio's certification programmes (AWS Certified Solutions Architect, Microsoft Azure Administrator, Google Cloud Professional) are funded, designed, issued and maintained by the cloud providers themselves. This is not an accusation: it is a factual description of their structure. An engineer who invests several months and several hundred euros in an AWS certification has, in effect, professional capital invested in the AWS ecosystem.

This mechanism is documented across the industry under the name vendor certification lock-in. It requires no centralised malicious intent to produce a measurable net effect: a certified professional has a rational and understandable bias toward recommending, in future architecture decisions, the ecosystem in which they invested their time and money. This bias is not a moral failing. It is a logical consequence of the incentive structure.

This thesis is distinct from a conspiracy accusation. It does not claim the trio invented DevOps with the explicit intent of creating this mechanism. It claims that, once the DevOps dynamic was established by the market, the trio structured its certification offering to extract a measurable retention benefit from it — which is rational behaviour for an economic actor, not an anomaly.

The six-layer lock-in model already established in this body of work places the cognitive layer as the deepest and hardest to unlock: not a contractual lock, nor a technical lock, but a lock on mental reference frameworks. A team trained and certified within the trio's ecosystem develops, by construction, a default solution framework centred on that ecosystem.

This mechanism explains an observable and frequent phenomenon: when a company's leadership, already locked into the trio, wishes to explore a return to bare metal or a local hosting provider, internal technical teams often propose, spontaneously and without deliberate intent, solutions that remain within the trio's framework — an alternative managed service, a cost-reduction option within the same ecosystem — rather than a genuine exit option.

This reframing matters because it changes the nature of the appropriate response. If the problem were a matter of individual will (comfort, fear), the appropriate response would be managerial or disciplinary. If the problem is cognitive and structural — a training gap regarding an alternative framework — the appropriate response is pedagogical: broadening the available framework, not punishing the absence of a framework that was never taught.

What follows is not an untested theoretical proposal. It is the restitution of a real vocational training programme, completed in 2005 at a vocational training centre for jobseekers, over a six-month period. This foundation, at the time, trained technicians capable of understanding infrastructure end to end, from the bit up to the operating system, before any later specialisation. It proved itself as an entry point into the profession twenty years ago, and this document's thesis is that it remains relevant today as a structural response to the cognitive lock-in described in Section 5.

Three distinct mechanisms have been described in this document: a behavioural mechanism where product design exploits a documented immediate gratification effect, an economic mechanism where certifications produce structural loyalty without centralised malicious intent, and a cognitive mechanism where the absence of an alternative framework prevents, by construction, the spontaneous proposal of solutions outside the trio. None of the three rests on an accusation of individual ill will.

This distinction has a direct practical consequence. If the problem were one of will, the response would be disciplinary. Since the problem is structural — product design, economic incentive, cognitive gap — the appropriate response is equally structural: a training programme that rebuilds the missing framework.

This document does not claim that this training programme is, on its own, a complete or sufficient solution. It claims that it is a necessary lever, documented by a real precedent — a programme that already existed and already produced results twenty years ago — and that this lever responds precisely to the cognitive mechanism identified in Section 5, rather than to a mechanism of will that was never the true cause of the problem.