Edge & Fog Computing · Study deck

Cloudlets: Local Compute Pools

Picture a repair headset that needs a large vision model.

Edge Eddie is your guide for this deck.

archcloudlets

Edge Eddie, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain how cloudlets differ from remote cloud services, general fog nodes, and simple edge gateways.
Describe a cloudlet session lifecycle from discovery through cleanup.
Evaluate when a workload should run on the device, cloudlet, fog node, or cloud.
Explain why VM synthesis, container layering, and model pre-positioning all solve the same startup problem.

Major section

In 60 Seconds · Start Simple

Borrow Nearby Compute, Keep State Clear: Picture a repair headset that needs a large vision model.

The headset cannot carry enough compute, and a distant service may answer too slowly.
A small computer pool at the site can run the hard task nearby.
A cloudlet is that nearby pool.
It accepts short work sessions for local devices.

Major section

Cloudlets: Local Compute Pools · How Cloudlets Differ

Cloudlets were introduced to make powerful computation available one local network hop from mobile users.

The Negotiate step selects a base VM and uploads the compact overlay, after which The Launch VM step applies it with assigned CPU and memory.
Captures data, provides the user interface, and keeps a minimum local mode.

Fog cloudlet VM lifecycle: a mobile device discovers a nearby cloudlet, negotiates a base VM and uploads an overlay, launches and executes the VM, then discards the session.

Major section

Cloudlet Session Architecture · Do Not Treat Proximity as Trust

A production cloudlet architecture needs more than a server placed near users.

It needs a session contract.
The cloudlet admits a session only if it has capacity, compatible runtime layers, current policy, and a trusted identity path.
The session runs in a VM, container, sandbox, or other isolated environment.

Major section

VM Synthesis, Containers, and Pre-Positioned Layers

Classic cloudlet literature emphasized VM synthesis: a cloudlet keeps a base VM image locally, and the client or management system supplies a smaller overlay that personalizes the runtime.

Many modern implementations use container layers, application bundles, model caches, or sandbox snapshots instead.
Destroy or reset the session after use.

Cloudlet architecture for VM synthesis: a mobile client discovers a cloudlet via mDNS, requests VM synthesis, and the infrastructure server fetches a base VM plus overlay to launch the session.

Major section

VM Synthesis, Containers, and Pre-Positioned Layers (continued)

Its request reaches the VM Synthesis Launcher, whose handler fetches a Base VM and then an overlay from the Infrastructure Server; KVM Hypervisor launches the combined instance.

Those labelled steps identify what must be pre-positioned, what crosses the local network, and where launch-time evidence should be collected.
Discover a candidate cloudlet.: The device or local controller finds an approved nearby cloudlet and learns which runtimes, models, policies, and services are available.
Large common layers should already be cached.

Major section

Workload Fit

Cloudlets are most valuable when the workload has a local reason to exist.

A cloudlet is rarely justified by fashion alone.
Augmented reality, cognitive assistance, inspection guidance, room-scale collaboration, and local video interpretation often need nearby results while raw streams remain local.
Emergency response kits, mobile labs, field operations, and temporary venues may need useful compute even when the WAN is weak or unavailable.

Major section

Worked Example: Mixed-Reality Maintenance Room

A university engineering lab uses smart glasses to guide students through equipment maintenance.

The room has a local cloudlet with approved models, safety policy, and a mixed-reality runtime.
The campus cloud keeps student accounts, lab records, and model release history.
Room-scale recognition and overlays need nearby response, and raw camera views should stay in the lab network.

Major section

Worked Example: GigaSight Privacy-Preserving Video Analytics

Proximity is not only a speed argument.

A campus or neighborhood runs video cameras, motion sensors, thermal sensors, and utility meters that stream continuously.
puts a cloudlet at the first point of contact for that raw data, so the cloud only ever sees what the cloudlet decides to release.
The same proximity keeps interactive latency low and gives the site a fallback service if the cloud path fails or is attacked.

Major section

Label the Cloudlet Path · Common Anti-Patterns

Temporary session VMs become the only place where important records live.

When cleanup, failure, or replacement happens, the records disappear or leak.
Every nearby client is accepted until CPU, memory, storage, network, or accelerator capacity collapses.
Good designs reject, queue, or degrade before overload.
A minimum local path should be part of the product behavior.

Major section

Latency Budget and Handoff Trace

The reason to pay for a cloudlet is not "nearby" as a slogan.

The cloud GPU kernel may be fast, but the WAN round trip and jitter arrive before every interactive result.
The local GPU may be smaller, but the one-hop network path leaves more of the budget for inference and rendering.
A cloud GPU that runs a kernel in 12 ms is still a poor fit for a tight interaction loop if the network path adds 80 ms or more before inference starts.

Major section

Summary · Concept Relationships

Cloudlets are specialized fog resources for nearby, session-oriented compute.

Their strength is not merely low distance from the user; it is the combination of local placement, pre-positioned runtime layers, isolated temporary sessions, explicit state ownership, and reliable cleanup.
The principle that local session state can be removed and rebuilt.
Durable state must have a named owner elsewhere.

Deck summary

Key takeaways

Borrow Nearby Compute, Keep State Clear: Picture a repair headset that needs a large vision model.

Cloudlets were introduced to make powerful computation available one local network hop from mobile users.
A production cloudlet architecture needs more than a server placed near users.
Classic cloudlet literature emphasized VM synthesis: a cloudlet keeps a base VM image locally, and the client or management system supplies a smaller overlay that personalizes the runtime.
Its request reaches the VM Synthesis Launcher, whose handler fetches a Base VM and then an overlay from the Infrastructure Server; KVM Hypervisor launches the combined instance.

Retrieval practice

Recall check 1 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q1What best describes a cloudlet in edge and fog architecture?

AA remote hyperscale cloud service used for durable records, central governance, and cross-site analytics over the wide-area network

BA passive edge cache that stores nearby content but does not admit isolated compute sessions or execute workload logic

CA small trusted compute pool near devices that admits short sessions, runs nearby work, and syncs durable state elsewhere

DA single constrained sensor node that owns sensing, fallback behavior, and the entire application without shared compute

Show answer

Answer: C A cloudlet is a small trusted compute pool near devices, running short-lived sessions while durable state is synced elsewhere.

Retrieval practice

Recall check 2 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q2A museum wants visitors' smart glasses to recognize exhibits, overlay directions, and keep raw camera frames inside the building. Which placement is the best fit for the recognition task?

ARun the full recognition pipeline on a nearby cloudlet and sync only durable visit records or approved summaries

BSend every camera frame to a remote cloud service because the cloud has the most capacity

CStore all visitor state permanently on the cloudlet because it is close to the glasses

DAvoid any offload and require the glasses to perform all work locally

Show answer

Answer: A The task benefits from nearby compute, local data handling, and a short-lived session.

Retrieval practice

Recall check 3 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q3A worker finishes an inspection session that used a cloudlet-hosted mixed-reality runtime. Which behavior best matches the cloudlet soft-state model?

AKeep the previous runtime alive for the next worker, including cached files and identity context from the finished session

BStop the session, sync approved inspection records to the system of record, wipe temporary runtime state, and release resources

CKeep the only inspection record inside the cloudlet VM because local storage is faster than the governed system of record

DDisable authentication and cleanup logging once the user leaves because the session no longer accepts new requests

Show answer

Answer: B Cloudlet session state is disposable.

Retrieval practice

Recall check 4 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q4Place each cloudlet-session responsibility where it lives so you can offload nearby without losing fallback, isolation, or durable evidence.

ADevice: capture and fallback

BDevice: long-term archive

CDevice: fleet policy owner

DDevice: base image registry

Show answer

Answer: A Separate device fallback, admitted cloudlet work, and durable cloud records so you can prove an offload session is safe from entry through cleanup.

Retrieval practice

Recall check 5 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q5A trace shows a cloud GPU kernel takes 12 ms, but the WAN path adds 80-120 ms before inference starts. A nearby cloudlet GPU takes 18 ms and adds 4 ms of local network delay. What does the trace prove?

AThe remote cloud path is better because its 12 ms kernel leaves more compute headroom than the cloudlet's 18 ms kernel

BThe cloudlet path is better because it removes the WAN delay that dominates the loop, even with a slightly slower kernel

CBoth paths are equivalent because GPU kernel time is the only latency term that users notice in interactive AR

DCleanup and admission are optional once a nearby accelerator can satisfy the rendering loop during one demo

Show answer

Answer: B The trace proves that full-path latency matters more than isolated accelerator speed.

Retrieval practice

Recall check 6 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q6Which statement best describes a production-quality cloudlet design?

AIt admits clients based on measured local network delay, then lets the shared runtime allocate compute as incoming sessions need it

BIt keeps common runtime layers local, admits only safe workloads, syncs durable outputs to their source of truth, and cleans temporary sessions

CIt retains durable outputs in session VMs to avoid remote-write latency and relies on those VMs remaining available after clients leave

DIt avoids cloud services entirely because a cloudlet replaces governance, model training, and cross-site analytics

Show answer

Answer: B This captures the core cloudlet responsibilities: pre-positioning, admission, state ownership, and cleanup.

Print reference

Answers 1 of 2

Answer key.

C · A cloudlet is a small trusted compute pool near devices, running short-lived sessions while durable state is synced elsewhere.
A · The task benefits from nearby compute, local data handling, and a short-lived session.
B · Cloudlet session state is disposable.
A · Separate device fallback, admitted cloudlet work, and durable cloud records so you can prove an offload session is safe from entry through cleanup.
B · The trace proves that full-path latency matters more than isolated accelerator speed.

Print reference

Answers 2 of 2

Answer key.

B · This captures the core cloudlet responsibilities: pre-positioning, admission, state ownership, and cleanup.