Edge, fog and cloud

Start with something you do every week. When you press play on Netflix in Dhahran, the video bytes do not cross an ocean from a data center in the United States. Netflix runs its own delivery network, Open Connect, and places caching appliances inside the networks of internet service providers and at Internet Exchange Points. The first bytes of your episode travel a few kilometres and a few router hops, not thousands of kilometres and dozens of hops.

In the client-server model of the earlier parts, the Server looked like one box at the far end of the line. The Netflix example shows why that picture is too simple. Between the Client and the origin data center there are several stops, and each stop is a possible home for code or data. Moving work from one stop to another moves you along a continuum of latencies. A stop closer to the client means a shorter path, so less Propagation delay and fewer routers where a packet can wait in a queue.

The consequence for users is striking. The same service, running the same code, can make one user happy and another angry, and the only difference is where the service runs relative to each of them. A viewer served from a cache in their own city sees the video start at once; a viewer served from another continent watches a spinner. Placement is therefore not an operations detail. It is part of the design of the application.

The idea is older than cloud computing. Mahadev Satyanarayanan traces edge computing back to content delivery networks (CDNs) such as Akamai in the late 1990s: a CDN uses nodes close to users to prefetch and cache web content. Edge computing generalises that idea. Instead of only caching bytes near users, you run arbitrary code there. The rest of this part names the stops on the line and the trade each one offers; the course as a whole is about deciding what to put at each one, which is the heart of the Edge-to-cloud (E2C) continuum.

To reason about placement you need names for the stops. Follow one request from a smart doorbell outward. The doorbell's own small chip decides that the button was pressed. The event goes to your home Wi-Fi router. From there it reaches a site run by your mobile or broadband operator nearby, for example an AWS Wavelength Zone, which places AWS compute and storage at the edge of a carrier's 5G network. Next it may reach a metro micro data center that collects events from many homes. Finally it lands in an AWS Region, inside one of its Availability Zones.

Those stops group into three coarse layers. The Cloud is farthest from the client. The Fog is the middle: mini data centers or intermediate nodes that process data partially. The Edge is closest to the client. Each Layer then splits into sublayers, which gives a seven-stage chain:

1. Device: the phone, sensor or doorbell itself.
2. Mist: tiny compute on or right beside the device.
3. Near edge: the home router or on-premises gateway.
4. Far edge: a nearby telco data center or carrier site.
5. Fog: metro nodes, micro data centers and aggregation nodes.
6. Regional cloud: a cloud region close to the user's country.
7. Cloud: the full hyperscale infrastructure of availability zones and regions.

The chain is a spectrum, not a set of sealed boxes, which is exactly why it is called a continuum. Each stage is simply one more Server layer where you could run part of your application, and the boundaries between neighbouring stages are soft.

The standards agree on the shape and admit the edges are fuzzy. The term fog comes from Bonomi and colleagues at Cisco in 2012, who wrote that fog computing extends the cloud paradigm to the edge of the network. NIST SP 500-325 later formalised it: fog nodes sit between smart end devices and centralised cloud services, and can be physical (gateways, switches, routers, servers) or virtual (virtual switches, virtual machines, cloudlets). It describes mist as a lightweight, rudimentary form of fog computing that uses microcomputers and microcontrollers to feed fog nodes, and it does not treat mist as a mandatory layer.

The cloud sublayers, precisely

Unlike fog and mist, the cloud's own sublayers have exact definitions from the providers. Learn them from AWS, since the terms are used across the industry.

Real products at each layer

Commercial offerings make the stages concrete. Notice that the far edge alone has two flavours: sites inside a carrier's network, and sites in metro data centers near large populations.

Names alone do not tell you where to run anything. What makes the continuum useful is that every stage offers a different bargain, and the bargain changes steadily as you move outward. Put a real part at each layer and the bargain becomes concrete. A Raspberry Pi Pico can decide "button pressed, turn on the light" instantly, and not much more; an AWS Region pools entire data centers. The steps between them fill in the gradient.

Two gradients running in opposite directions

Read the table top to bottom and two things change together. Proximity falls and resources rise. Each step outward serves more users over a wider area with bigger hardware, but sits further away. Bonomi and colleagues put it in one line: the higher the tier, the wider the geographical coverage and the longer the time scale.

The role column follows from the resources column. An immediate decision needs no network at all, so it can live on a tiny chip. Aggregation needs a view of many sources, so it lives where many streams meet. Large-scale computation needs pooled capacity, so it lives in a data center. In Bonomi's smart grid example, the first tier runs control loops that react in milliseconds to sub-seconds, higher tiers run real-time analytics over seconds to minutes and transactional analytics over days, and the cloud keeps the data that must last.

Why the latency side of the trade is physics

The cost of moving outward is latency, and a head-tracked virtual reality headset shows how hard that cost can bite. Satyanarayanan reports that the display must respond to head movement in under 16 ms to feel stable. Citing Ang Li and colleagues, he gives an average round-trip time of 74 ms from 260 vantage points to their best Amazon EC2 data center, before the wireless first hop is even added. A VR application that renders in a distant cloud region therefore cannot meet its target, whatever the server does. The same application rendering on a cloudlet or far edge site one or two hops away can.

The reason comes straight from the previous part. The one-way latency to a layer can never be lower than the Latency lower bound, the distance divided by the speed of light. On top of that, every router on the way adds Queueing delay and processing. The Edge is one or a few hops away, the Fog is a metro away, and the Cloud may be a continent away. So latency, like resources, grows as you move outward: small at the edge, medium in the fog, large in the cloud.

How low is low enough? Human perception gives useful targets. Satyanarayanan cites that people take about 370 to 620 ms to recognise a face and 300 to 450 ms to recognise speech, but only about 4 ms to tell that a sound is a human voice. He concludes that an end-to-end latency of a few tens of milliseconds is a safe but achievable goal. That is what a far edge footprint buys: Cloudflare reports that 95% of the connected population is within 50 ms of one of its data centers, and most are within 20 ms.

One nuance matters at PhD level. "Close" is about the network, not just the map. Satyanarayanan defines logical proximity by low latency, low jitter and high bandwidth, and warns that the question "how close is physically close enough?" has no abstract answer. A fog node behind a congested link can respond more slowly than a well-connected cloud availability zone, so the small, medium and large ordering is typical, not guaranteed.

You now have both halves of the trade: processing power and storage increase from edge to fog to cloud, in the same direction as latency. Every step toward the cloud buys capacity and costs latency. That turns placement into a real decision, and the decision has three inputs: the latency requirement of the task, its processing and storage needs, and cost.

Picture a neighbourhood of smart doorbell cameras. Each camera, at the Edge, compares consecutive frames to detect motion, which is cheap arithmetic, and sends nothing while nothing moves. A fog node in the neighbourhood combines motion events from 200 cameras and door sensors to spot a pattern across streets, which is sensor data processing. The Cloud trains and hosts the large recognition model and keeps months of clips. One application, three layers, each doing the part it is equipped for.

The pattern generalises into a rule of thumb: put each task on the layer closest to the client that still has enough resources for it, and push data outward only when you need more compute, more storage or a wider view. Bonomi and colleagues describe the fog tier doing exactly this, filtering data to be consumed locally and sending the rest to higher tiers. Filtering early also saves bandwidth, since raw video is expensive to ship; Satyanarayanan lists scalability through edge analytics as a key benefit of cloudlets. Splitting one Service pipeline across layers like this is what the next part calls a Mapping.

Treat the typical roles (motion at the edge, sensor processing in the fog, AI in the cloud) as tendencies, not rules. Training and very large models belong in the cloud, but inference increasingly runs at the edge: a Jetson Orin Nano Super delivers 67 TOPS within 7 to 25 W. Edge platforms are not unlimited either. A Cloudflare Worker gets 128 MB of memory per isolate and, on the free plan, 10 ms of CPU time per request.

Cost is the third axis. AWS states that Local Zone resources are priced differently from the same resources in their parent Region. Red Hat describes the move toward the edge as an increase in the number of distributed locations but a decrease in each location's size, which means many small sites to buy, power and manage.