A CIO who spent five years evangelising the DevOps transformation of their organisation — merging teams, eliminating "silos," celebrating deployment velocity — cannot retreat without publicly admitting they were wrong. Not cowardice. The Sunk Cost Fallacy documented by Kahneman (2011) and Thaler (1980): the tendency to continue a commitment not because it is rational, but because one has already invested too much to turn back.

The investment is double. Financial first — migrations, training, certifications. But above all public — LinkedIn posts, conferences, internal use cases, the professional reputation built on this transformation. Retreating means erasing five years of professional posture before peers and the CEO. The fear of losing face is stronger than economic rationality. This is the lock that blocks the cloud exit before a rack has even been opened.

The decision to merge infra and dev teams in 2019 was correct with 2019 information. The DevOps movement had real arguments — breaking delivery silos, reducing time to market, making teams responsible for quality in production. These arguments remain partially true.

What has changed is the documentation. The CLOUD Act clarified. Egress fees measured. The TSMC geopolitical risk identified. The absence of Capacity Planning quantified in invoices. The loss of low-level skills measurable in job postings (−34% Linux). The 2026 decision is different because the information is different — not because the decision-maker was incompetent in 2019.

Revising one's position in light of new data is not capitulation. It is the very definition of good management. That is what the Operation Dindon corpus provides: the new data. The rest is an engineering decision.

The DevOps movement, born in the late 2000s, responded to a documented and real problem: development and operations teams worked in watertight silos. The developer delivered an artefact "over the wall." The ops team installed it without understanding what they were installing. Time to production was measured in weeks, sometimes months. Production incidents were diplomatic crises as much as technical ones.

DevOps resolved this. Continuous integration, continuous delivery, infrastructure as code, automated testing, shared responsibility for production quality — these are real contributions that improved software quality and reduced delivery times. This study does not contest these achievements.

What the DevOps movement did not anticipate: by breaking delivery silos, it also broke competence silos. The organisational merger of teams progressively led to the merger of roles, then the merger of decision-making responsibilities. The "full-stack" developer became the "full-infra" developer — not through acquired competence, but through scope drift.

Documentable result: a developer deploying on Lambda without understanding what runs underneath is not a DevOps engineer — they are someone given a remote control without being shown the television. They can change channels. They cannot repair the set. And when the set breaks down — when lock-in is installed — they do not see it coming.

The loss is double. The developer loses consciousness of low-level layers. The organisation loses the infrastructure engineer as a guard against irreversible decisions. Nobody does Capacity Planning anymore. Nobody reads Terms before choosing a managed service. Nobody asks "can this component run outside AWS without a rewrite?" — because nobody has the skills to understand the answer.

Terraform, CloudFormation, Pulumi — twenty lines of HCL or YAML to instantiate a managed Kubernetes cluster (EKS), a DynamoDB database, an SQS queue, a complete VPC network. To a developer, this script looks like code. It has syntax, variables, loops, reusable modules. It lives in Git, is reviewed in Pull Requests, tested in CI/CD pipelines.

That is exactly the problem. IaC transformed the physics of infrastructure into applicative syntax. Writing resource "aws_dynamodb_table" "users", the developer feels they are declaring a data structure — not signing a proprietary contractual commitment, not creating a ten-year software lock-in, not excluding any future deployment on another infrastructure without complete rewrite.

Code dissolved the consciousness of hardware. Behind twenty lines of HCL lies a datacentre in Virginia, chips fabricated by TSMC, a contract subject to California law, and egress fees patiently waiting for data to accumulate.

A bug in application code: git revert · rollback in minutes · previous state accessible in Git history.

An error in an IaC script instantiating a proprietary managed service: data is inside it · application architecture depends on this service · Terraform's "git revert" does not repatriate the data · technical debt is contractually locked.

These two errors have the same syntactic form — a line of code. They do not have the same risk nature. IaC made this difference invisible. That is why the infrastructure engineer must be present in IaC script reviews — not to say no, but to name what the code represents physically and contractually.

The DevOps merge was not only driven by good managerial intentions. It was actively theorised, marketed and financed by hyperscalers under the banners of Serverless (AWS Lambda, 2014) and NoOps — "Build, we handle the rest." These promises have a precise target: the developer. Their declared objective: eliminate infrastructure friction. Their real effect: neutralise the infrastructure engineer as an internal opponent to cloud capture.

An infrastructure engineer who understands hardware is the primary obstacle to selling managed cloud services. They ask uncomfortable questions: What runs underneath? Where is the data? What does the contract say about egress? Can we migrate? Eliminating them organisationally — by merging their role under the developer's, by having them "evolve" toward AWS certifications, by renaming their profession "cloud engineer" — solves the commercial problem on the hyperscaler side.

2006-2010: the DevOps movement emerges to break delivery silos. Legitimate objective.

2012-2015: AWS, Google and Microsoft adopt and amplify the DevOps discourse in their conferences and certifications. They add the "cloud-native" layer — the idea that real DevOps happens on cloud. Hyperscaler certifications progressively replace neutral infra certifications (Linux Foundation, Red Hat).

2014-2018: Lambda (AWS), Cloud Functions (Google), Azure Functions. Serverless is presented as DevOps's next step — no more server management. The infrastructure engineer becomes progressively superfluous in this narrative.

2018-2024: organisations massively merge their infra and dev teams under DevOps "tribes." Capacity Planning disappears. Low-level skills disappear. The Linux job market collapses (−34%). Capture is complete.

The chronology is not a conspiracy theory — it is a market observation. Hyperscalers followed a rational commercial logic. Organisations followed a good-faith managerial logic. The result is documented in 64 Operation Dindon corpus studies.

The infrastructure engineer had an invisible but critical function: Capacity Planning. Before deploying a service, they estimated the load, sized the resources, anticipated peaks, calculated the monthly cost at scale. This function was not glamorous — it did not generate impressive boardroom demos. But it was the financial guardrail of the architecture.

When the infrastructure engineer was merged under the developer's umbrella, this function disappeared. The cloud engineer — often a developer retrained with an AWS Solutions Architect certification — no longer plans capacity. They consume it blindly. Lambda scales automatically — that is the promise. What the promise does not say: Lambda also scales the invoice, non-linearly, without default alerts.

A developer deploys a Lambda function that queries DynamoDB sequentially rather than by batch. The function is triggered 10 million times per day. Cost estimated by the developer: "Lambda is almost free at Free Tier." Real cost at scale: the combination of Lambda invocations + DynamoDB reads + data transfer can represent thousands of euros per month depending on the exact architecture.

An infrastructure engineer would have estimated this cost before deployment. Capacity planning is the translation of software architecture into real costs — before they are invoiced. Without this competence in the team, the CFO discovers costs at month-end. Not before.

The CFO is the only decision-maker who physically feels the consequences of the infra/dev merge — in the form of non-linearly growing cloud invoices, unforeseen exit costs, TCO never calculated. They are also the easiest to convince with data: show the cloud invoice curve over 36 months, overlay the progressive disappearance of the dedicated infra team, and let the correlation speak.

Rebuilding the infra/dev boundary is not only a technical or organisational decision — it is a financial decision. The infrastructure engineer is the CFO's guardrail. Their disappearance has a cost. This cost is measurable, documented, and growing.

Recreating a watertight boundary between infra and dev without a protocol immediately reactivates the legendary "Devs vs Ops" war: the JIRA ticket sleeping for three weeks, the infra team reflexively saying no, the dev team circumventing out of frustration. This war existed. It produced the DevOps movement. The goal is not to return to 2005.

The boundary to rebuild is not a wall. It is an interface — an organisational API that allows the two professions to collaborate without dissolving into each other.

The sovereign Internal Developer Platform (IDP) is the operational answer. The infrastructure engineer no longer says "no" — they provide. They design and make available to developers abstract infrastructure bricks that are agnostic and reversible: a database brick that can run on PostgreSQL bare-metal or on cloud, a message queue brick that can be RabbitMQ or SQS depending on context, an authentication brick not locked to Cognito.

The sovereign brick rule: every component provided by the internal platform must be able to answer "yes" to the question "can it run outside AWS without a rewrite?" If the answer is no, the choice is deliberate, documented, and assumed by both parties — not suffered by default because "it was easy to deploy."

The IDP solves the organisational problem. It does not solve the epistemological problem: a developer using an IDP brick without understanding what is underneath remains unable to recognise an architectural lock-in when they create one.

The solution is not to train every developer to manage a Kubernetes cluster. It is to show them once, physically, what resource "aws_dynamodb_table" triggers underneath — like the teacher who takes out a satellite dish so the student understands sine and cosine. Not to make them an infrastructure engineer. So they can read a cloud invoice, recognise an inode, understand why an IaC script is not a git revert.