The placement problem fog computing solved before 'edge AI' had a name

"Edge AI" reads like a phrase invented for a slide. It is on every deck now: run the model near the sensor, not in a distant datacentre. What the decks rarely mention is that the argument underneath it is not new. My final-year project at university implemented a fog computing architecture in Node.js, and worked out where to place the fog layer inside a Software-Defined Networking environment. That was a decade before "edge AI" needed a name.

The problem it actually solves

The naive design for a sensor network is the one everyone reaches for first: every device ships its raw readings to the cloud, and the cloud does everything — storage, aggregation, decisions. It works, right up until the sensor count and the sample rate make the round trip the bottleneck.

Three costs stack up. Latency — a control loop that has to leave the building, cross the internet, get processed and come back is not a control loop for anything that needs to react within tens of milliseconds. Bandwidth — most raw sensor data is redundant most of the time, and hauling all of it upward to discard 99% of it in the cloud is a strange way to spend a network. Availability — a system that cannot function without a live path to a distant datacentre has manufactured a single point of failure out of the internet itself.

Fog computing's answer is to insert a layer between the devices and the cloud — physically closer to where the data is produced — that can filter, aggregate and act on data locally, and only send upward what actually needs to leave the building: summaries, exceptions, anything that has to be durable. The premise is simple to state: push computation toward where the data is produced, rather than hauling the data to where the computation happens to live.

The part that is actually hard: placement

Stating the premise is the easy part. The hard part, and the part my project spent most of its time on, is deciding where the fog layer should physically sit — which node in the network topology gets the processing job, for which slice of devices, and how that assignment changes as load and topology shift.

This is why the project put the fog layer inside a Software-Defined Networking environment rather than a fixed one. SDN separates the control plane — the logic that decides how traffic should flow — from the data plane that actually moves the packets. That separation is what makes placement a solvable, programmable problem instead of a wiring decision made once and left alone: the controller has a global view of the topology and can reassign where processing happens as conditions change, the same way it can reroute traffic.

Get the placement wrong and fog computing buys you nothing. Put the fog node too far from the devices and you have re-invented the cloud with extra hops. Put too much logic on it and you have re-invented an edge server with none of the cloud's elasticity. The interesting design space sits in between, and it is a genuine trade-off, not a default: how much state the fog layer holds, how it degrades when the uplink to the cloud drops, and how placement decisions get remade as the network underneath it changes.

The same question, different workload

I did not expect that project to still be the model I reach for a decade later, but it is. The systems I am responsible for now are real-time communication and inference workloads, and both ask the identical placement question fog computing asked: how far from the data should the computation sit?

A WebRTC media server answering that question badly adds a hop's worth of latency to every participant in a call. An inference workload answering it badly means shipping raw audio, video or sensor data to a model that could have run beside the source — spending bandwidth and adding a network dependency for a decision that did not need to leave the device. "Edge AI" is this same trade-off, restated for a workload that happens to be a model instead of a control loop: run it near the data when the round trip does not pay for itself, keep it upstream when the workload needs scale or state the edge cannot hold.

The vocabulary changed — fog, then edge, then edge AI — because the workloads changed and each generation needed its own name for the market to notice. The architecture question underneath all three has not moved: given a piece of computation and a piece of data, decide how far apart they are allowed to be, and be able to change your mind as conditions do. That is what a final-year Node.js project taught me to ask before I had a production system to ask it about, and it is the question I am still answering.

---

Related: the research note on fog and edge computing.