Infra comes from Latin — below. Structure — the foundation, what supports everything else. Infrastructure is what lies below and carries. This etymology is not a grammatical detail — it is a functional definition. Infrastructure is the low layer, physical, tangible, that conditions the existence of every layer above it. It cannot be code. It can be managed by code, described by code, documented by code. But it remains metal, cable, electricity, heat and disks that fail.

This is not a semantic debate. When the word "infrastructure" loses its physical dimension in the everyday language of technical teams, engineers trained in that linguistic environment do not learn to think in physical layers. They learn to think in cloud resources. When the real failure comes — the one that is in the cable, in the network card, in the redundant power supply that no longer is — nobody knows where to look. Because nobody learned that this is where you look.

"Configuration as Code" — precise, exact, unambiguous. The declarative, versioned description of cloud resource configuration. This word would have described the same practice without claiming that code can be physical infrastructure. It was not chosen. "Infrastructure as Code" was preferred — because it gives the illusion that mastering Terraform means mastering infrastructure. And this illusion serves the interests of those who sell access to the real infrastructure.

A developer and a systems engineer have fundamentally different skills, acquired through different paths, exercised in different contexts. Their collaboration is valuable. Their fusion under a single title does not create a more complete profile — it creates a blurrier one. A "DevOps engineer" who excels at CI/CD may know nothing about managing a network incident at 3am. A "DevOps engineer" who masters system diagnosis may write mediocre code. Fusing the names did not fuse the skills. It diluted the evaluation criteria for both.

DevOps was followed by FinOps, SecOps, MLOps, DataOps, GitOps, CloudOps, PlatformOps. Each new "Ops" suffix promises the same thing: the fusion of two worlds that worked in silos. Each new suffix dilutes the meaning of the word "operations" a little further. When everything is called "Ops", the word no longer designates anything precise. And when "operations" no longer designates anything precise, real operational skills — those that maintain systems in production at night — become invisible in frameworks, job descriptions and training plans.

Thousands of engineers trained since 2015 learned to "provision infrastructure" without ever touching a physical server, cabling a switch, or diagnosing a network fault on bare metal. They learned to manipulate abstractions — cloud resources, Terraform files, CI/CD pipelines. These skills are real and useful. But they stop at the API layer. Below the API layer there is a physical infrastructure that nobody taught them existed — because the vocabulary gave them the illusion that it did not exist, or did not need to be known.

Organisations that migrated "to the cloud to achieve economies of scale" typically discover, 18 to 36 months after migration, that their infrastructure costs have increased rather than decreased. Part of this increase is structural — cloud pricing models are designed to grow with usage. But another part is avoidable and stems directly from ignorance of the physical layer: overprovisioning because nobody knows how to size, egress fees ignored because nobody understood there were exit charges, cloud-native architectures replicating on-premises patterns without optimising them.

The market is critically short of engineers capable of mastering infrastructure from the physical layer to the application layer — from electricity to service. This profile existed. It was called systems administrator, infrastructure engineer, SRE. It was progressively replaced in job descriptions by "DevOps engineers" and "cloud engineers" whose skills stop at the API layer. The complete profile did not disappear because the competence became impossible to acquire. It disappeared because the vocabulary stopped valuing it — and the market follows vocabulary.

AWS, Azure and GCP benefit directly from the belief that mastering Terraform or CloudFormation equates to mastering infrastructure. If engineers believe that infrastructure is code, they do not need to understand what lies beneath the code. And if they do not need to understand what lies beneath the code, they never have reason to ask whether what lies beneath the code might belong to someone other than a hyperscaler. The AWS console that "provisions infra" is a rental interface, not a mastery tool. The vocabulary erases the distinction.

Two actors benefit from profession dilution. Employers who replace two specialists with one cheaper generalist — the "DevOps" title justifies paying less for two distinct expertises under a single salary. And tool publishers who sell "DevOps" platforms claiming to solve through tooling what only culture and competence can solve. The word "DevOps" has become a market. Like all markets, it is shaped by the actors who benefit from it.

Call "Configuration as Code" what is declarative configuration of virtual resources. Reserve the word "Infrastructure" for what it designates — the physical, tangible layer that carries everything else. This distinction is not a matter of style — it is a matter of operational precision. An engineer who knows that Terraform manages configuration, not infrastructure, knows there is a layer below that they cannot see and must account for.

Distinguish in job descriptions, skills frameworks and training plans what belongs to development (writing code that solves business problems), infrastructure engineering (mastering the physical layer through to the service layer) and reliability (designing and maintaining systems available in production). These three skills can coexist in one individual — some SREs excel in all three. They cannot be assumed present on the strength of a generic title.

The Foundation of Iron — 26 weeks from electricity to networking — is built on this principle: you cannot master the abstraction if you do not understand what it abstracts. An engineer who learned to cable a switch before learning to configure a VPC understands what a network actually is. An engineer who only ever knew the VPC believes a network is a JSON file. Training on the physical layer is not nostalgia — it is the condition of real understanding.