Compute where the physics is unforgiving

The first data hall I ever designed did not sit in a business park. It sat a few hundred metres from a refinery flare stack, inside a zone where a stray spark is a legal event, not an inconvenience. You do not get to iterate your way to a working design in a place like that. You get it right on paper, or people get hurt.

The constraint comes first

Heavy industry does not care about your reference architecture. The plant runs continuously, the environment is corrosive, and large parts of the site are classified as explosive atmospheres. Before a single cabinet goes in, you are reading the area classification drawings: ATEX and IECEx zones, Class I Division hazardous locations, the boundaries where ordinary equipment is simply not allowed to be energised.

So the compute goes where the physics permits, and you engineer the enclosure to meet the zone rather than pretend the zone is not there. Ruggedised, containerised, modular data centres, purpose built and dropped onto the pad. Positive-pressure enclosures to keep the atmosphere out. Sealed and rated gear. Redundant cooling that assumes ambient conditions that would cook a normal server room. This was edge compute years before the industry gave it that name. The edge was a wellhead, a pumping station, a processing train.

Why the compute could not just live in the city

The obvious question from head office was always the same: why not put all of this in a proper data centre and run a link out to the plant? Because the plant does not wait for a round trip. Industrial control is a real-time conversation. SCADA systems, safety instrumented systems, and the control loops that keep pressure and temperature inside their envelopes need answers in milliseconds, and they need those answers even when the wider network is having a bad day.

That is what pushed OT and IT together on these sites long before it was fashionable. The control network and the enterprise network had to share physical infrastructure without sharing failure modes. I spent a lot of those years designing the boundary between them: deterministic, low-latency networking on the plant side, with a hardened path back to corporate for the data that genuinely needed to leave.

The backbone

Connecting these sites was its own engineering problem. Remote locations, long distances, and no tolerance for a single cut fibre taking a plant blind. The answer was a proper optical backbone: dark fibre where we could get it, DWDM to carry many services over one pair, and MPLS across the wide area to keep traffic classes separated and predictable.

Redundancy was not a slide in a deck. It was N+1 on the mechanical and electrical plant, 2N on the paths that could not fail, and a target of Tier III or Tier IV availability depending on what the site could justify. We watched PUE because power in a remote location is expensive and sometimes self-generated. And we thought hard about data sovereignty, because some of this data was never allowed to leave the operator’s own ground.

None of it looked like AI. All of it taught me the same lesson I use now: decide where the compute physically lives by starting from the constraint, not the diagram. The unforgiving environments teach you fastest.