PaperlayerView exact revision on arXiv

Source-linked AI summary

At the Edge of a Seamless Cloud Experience

Samuel Rac, Mats Brorsson

arXiv:2111.06157v1cs.DC

TL;DR

Edge computing addresses the need to process applications outside data centres, but deployment across heterogeneous edge devices remains fragmented. The paper reviews architecture, execution, and orchestration approaches, including containers and WebAssembly. It concludes that seamless edge computing also requires dynamic networking and orchestration adapted to heterogeneity and node churn.

  • Problem

    Edge deployments span heterogeneous devices and infrastructure levels, while software deployment beyond a few data centres remains fragmented and largely manual.

    Source: §I · pp. 1–2

  • Method

    The paper reviews seamless cloud computing across architecture, heterogeneous execution, and orchestration, discussing containers and WebAssembly for edge execution.

    Source: §I · p. 2, §III · p. 3, §V · p. 7

  • Results

    The paper identifies WebAssembly as a candidate for heterogeneous execution and says Kubernetes-like orchestration needs changes for heterogeneous devices, unreliable connections, node churn, and volatile resources.

    Source: §V · p. 7

  • Takeaways & Limitations

    A seamless edge experience requires flexible, resilient networking that reflects device mobility and heterogeneity, while accounting for devices’ energy needs.

    Source: §V · p. 7

Abstract

from arXiv · show

There is a growing need for low latency for many devices and users. The traditional cloud computing paradigm can not meet this requirement, legitimizing the need for a new paradigm. Edge computing proposes to move computing capacities to the edge of the network, closer to where data is produced and consumed. However, edge computing raises new challenges. At the edge, devices are more heterogeneous than in the data centre, where everything is optimized to achieve economies of scale. Edge devices can be mobile, like a car, which complicates architecture with dynamic topologies. IoT devices produce a considerable amount of data that can be processed at the Edge. In this paper, we discuss the main challenges to be met in edge computing and solutions to achieve a seamless cloud experience. We propose to use technologies like containers and WebAssembly to manage applications' execution on heterogeneous devices.

I. INTRODUCTION

Edge computing moves application processing outside data centres, but extending deployment across the edge remains fragmented and difficult. The paper examines architecture, heterogeneous execution, and orchestration as dimensions of a seamless cloud experience.

I. INTRODUCTION

  • The paper defines Edge computing as application processing outside a data centre, across infrastructure that can span devices, gateways, network edges, and cloud data centres.The infrastructure may include compute and storage at multiple locations along the path.Source: §I · p. 1
  • Software deployment across the infrastructure is described as fragmented and highly manual, with possible placement at several cloud, gateway, network-edge, and device levels.The listed locations include data centres of multiple cloud providers, gateways, network-edge nodes, and edge devices.Source: §I · p. 1
  • Deployments spanning cloud levels beyond one or a few data centres are mostly manual and do not adapt to changing application needs.Kubernetes can maintain desired application state in a cloud, including through node failures and traffic surges, but the paper says this model does not extend seamlessly across the hierarchy.Source: §I · p. 1
  • Edge gateways and devices may use different processor architectures, while accelerators add another layer of heterogeneity.The paper names x86 and ARM processors and accelerators including GPUs, FPGAs, and TPUs.Source: §I · pp. 1–2
  • Developing for this heterogeneous landscape may lead to vendor lock-in, over-provisioning, inferior performance, or higher power consumption.The paper frames easy deployment to edge applications, like deployment to Google GKE Autopilot, as a goal.Source: §I · p. 2
  • The paper explores seamless cloud computing through architecture, execution, and orchestration.These dimensions address connecting components, handling heterogeneous platforms, and managing applications across the infrastructure, respectively.Source: §I · p. 2

II. ARCHITECTURE

A seamless cloud architecture must connect and aggregate multiple infrastructure layers. Cloudlets add a nearby compute tier for mobile devices, with offloading choices shaped by service and resource conditions.

II. ARCHITECTURE

  • Architectural work must identify infrastructure layers and aggregate them into a seamless cloud experience.The paper reviews principles proposed to extend traditional cloud architectures to the edge and intermediate layers.Source: §II · p. 2

1) Cloudlet topology:

  • A Cloudlet is an edge server, computer, or small cluster, typically one hop from mobile devices, forming a three-tier continuum with mobile devices and the Cloud.Cloudlets are designed to provide services to mobile devices.Source: 1) Cloudlet topology · p. 2
  • Transparent offloading between a Cloudlet and traditional Cloud should consider latency, task size, energy, and resource availability.Cloudlets should be close enough to mobile devices to satisfy QoS and should be able to work without Internet connectivity.Source: 1) Cloudlet topology · p. 2

2) Ad-hoc topology:

Edge architecture must accommodate mobility, changing resource availability, and dynamic networking. The section discusses decentralized topologies and networking approaches that can adapt to application and connectivity needs.

2) Ad-hoc topology:

  • Ad-hoc edge computing aims for a dynamic, distributed, decentralized infrastructure that accounts for edge constraints.The architecture is described as resilient and intended to avoid a single point of failure; its implementation should remain lightweight so as not to disturb edge devices.Source: 2) Ad-hoc topology · p. 2
  • Mobility brings unreliable and intermittent connections and changes resource availability; node churn describes resources appearing and disappearing,.Edge-node availability can also depend on device energy management and battery discharge.Source: 2) Ad-hoc topology · p. 2

B. Networking

  • Networking is required for distributed applications, and in-network computing distributes applications through network infrastructure, potentially using switches or routers as small edge nodes.The paper also notes that microservices depend on the network.Source: B. Networking · p. 2
  • SDN can automate network configuration and management, while its separation of control and user planes supports flexibility for mobile, intermittently connected, or bandwidth-limited edge devices.An SDN controller’s high-level network view can help deploy application networking, which can scale with application needs.Source: B. Networking · p. 2
  • Network slicing can allocate bandwidth for different purposes, such as reserving resources for ultra-low latency or serving many users, and can guarantee QoS levels.SDN has a role in deploying network slices.Source: B. Networking · p. 3

III. EXECUTION

Edge execution must span heterogeneous computing platforms, but virtual machines may be too demanding for small devices. The section considers containers and WebAssembly, alongside container-related options for portability, isolation, and accelerator access.

III. EXECUTION

  • The execution challenge is to manage applications across heterogeneous nodes and their multiple computing platforms.The paper sets this against edge computing’s movement of computation toward the network edge.Source: §III · p. 3
  • The paper focuses on containers rather than virtual machines, which may require too much computation power for small edge devices.Containers are presented as a lighter virtualization technology.Source: §III · p. 3
  • WebAssembly is presented as lightweight and fast like containers, while adding sandboxing and architectural independence for untrusted code in multi-tenant settings.Figure 2 compares WebAssembly’s architecture with other cloud-computing models.Source: §III · p. 3, Figure 2 · p. 3

A. Containers

  • Containers offer good edge performance, but Hong and Varghese report that they are not ready for heterogeneity and lack support for accelerators such as GPUs, DPUs, TPUs, and FPGAs.Building containers for multiple targets requires additional steps, and a Linux image cannot directly run on a Windows host.Source: A. Containers · p. 3
  • Kata containers combine lightweight virtual machines with container management, and combining virtual machines with containers is proposed as a possible route to workload isolation, security, and accelerator management.The paper gives Kubernetes as an example of container-style management for Kata containers.Source: A. Containers · p. 3
  • Following OCI standards for container formats and runtimes is presented as a way to simplify application deployment across heterogeneous edge nodes.The paper says Docker containers, Kata containers, and WebAssembly modules are compatible with this structure.Source: 2) Live migration · p. 3

1) OCI:

The section presents live migration as a way to keep applications close to mobile edge devices, and WebAssembly as a portable, sandboxed execution option whose practical performance and uses depend on its runtime.

2) Live migration:

  • Container live migration can help applications follow mobile edge devices, but requires migrating the image, runtime, and context.Xu et al present a tool for Docker container live migration and describe it as more complicated than VM migration.Source: 2) Live migration · p. 3

B. WebAssembly

  • WebAssembly aims to run a common binary across processors, with memory-safe sandboxing and support for many high-level languages.It is described as lightweight and efficient; developers could maintain one codebase and address many devices with a single binary.Source: B. WebAssembly · p. 3
  • WebAssembly runs in major browsers and other runtimes, while WASI seeks to standardize communication between the WebAssembly machine and its host.WASI's goal is compared to POSIX.Source: B. WebAssembly · p. 4
  • Wasmtime implements WASI, but incomplete standards and missing networking functionality currently limit its uses.The text says implementations are already being tested while WASI remains under development.Source: B. WebAssembly · p. 4
  • WebAssembly performance and flexibility vary by runtime: interpretation supports more platforms, JIT favors heavier tasks but enlarges binaries, and AOT offers the best performance.Rapid runtime evolution also makes WASM performance difficult to evaluate.Source: B. WebAssembly · p. 4

1) Running WebAssembly everywhere:

WebAssembly's broad device support could simplify managing heterogeneous edge devices, though language constraints remain. Krustlet and wasmcloud describe ways to run WebAssembly workloads in edge clusters.

1) Running WebAssembly everywhere:

  • A WebAssembly binary can run across many architectures and device types, including resource-limited devices, which can simplify managing a heterogeneous edge swarm.Figure 3 is described as showing the targeted platforms and architectures.Source: 1) Running WebAssembly everywhere · p. 4
  • Most high-level languages can target WebAssembly, but garbage collection is difficult with memory set before execution, and Java cannot yet be used.The passage says high-level virtual-machine languages do not seem well suited to edge devices' memory and CPU constraints.Source: 1) Running WebAssembly everywhere · p. 4

2) Krustlet:

  • Krustlet implements Kubernetes' Kubelet API so heterogeneous nodes can run and schedule WebAssembly modules in a cluster.Modules can be pushed to a registry using OCI standards and run natively with a WASI runtime such as Wasmtime by default.Source: 2) Krustlet · p. 4
  • Krustlet's use of WASI is currently limited by missing networking features as WASI progresses.The passage identifies networking as a missing feature.Source: 2) Krustlet · p. 4
  • Wasmcloud packages reactive actors as small WebAssembly modules that handle messages from capability providers, and actors can be deployed to edge clusters with Krustlet.Capability providers expose interfaces such as HTTP servers, databases, or storage; the actors use privilege-based security.Source: 3) Wasmcloud · p. 4

3) Wasmcloud:

The section surveys accelerators as a way to address edge processing demand, describing trade-offs across GPUs, ASICs, and FPGAs. Their characteristics range from common parallel processing to reconfigurable, low-latency hardware.

C. Accelerators

  • Hardware accelerators target specific use cases and can outperform CPUs while consuming less energy in their application domains; they can also be virtualized or combined with CPUs.GPU, FPGA, and ASIC are identified as main edge accelerators, and CPU-plus-accelerator combinations as heterogeneous platforms.Source: C. Accelerators · pp. 4–5

1) GPU:

  • GPUs accelerate parallel applications and are common across data centres, personal computers, and embedded devices, but are described as the most energy-consuming accelerators.OpenCL and CUDA are named as GPU programming frameworks.Source: 1) GPU · p. 5

2) ASIC:

  • ASICs offer high performance and security in a small, low-power form for specific tasks, but lack flexibility beyond their designed purpose.Source: 2) ASIC · p. 5

3) FPGA:

  • FPGAs can be reconfigured before or during execution, offering low latency and low power for edge devices, while multi-tenant access to reconfigurable hardware may raise security issues.Reconfiguration can be partial or global; the passage also notes that a scheduler could reconfigure an FPGA when a computing unit is unavailable.Source: 3) FPGA · p. 5

IV. ORCHESTRATION AND MANAGEMENT

Edge orchestration must handle volatile, heterogeneous resources and coordinate applications across edge and cloud. The section outlines scheduling needs, resource abstractions, and MEC use cases involving mobility and edge-based AI.

IV. ORCHESTRATION AND MANAGEMENT

  • Edge orchestration must account for resource volatility and heterogeneity, extending cloud orchestration tools and using automation to manage complexity.The infrastructure is described as spanning many kinds of devices, with Kubernetes given as an example of a tool needing improvement for edge challenges.Source: §IV · p. 5

A. Scheduling

  • Edge scheduling must consider many parameters in a distributed, multi-tenant environment, including node architectures, accelerators, application constraints, capabilities, energy, auto-scaling, and auto-discovery.Source: A. Scheduling · p. 5
  • The section proposes standardized containers such as OCI as scheduler-manageable atomic units, with resource abstraction for architecture and accelerators.The units should carry information about available resources, bandwidth, latency, real-time needs, energy, location or context, and accelerators.Source: A. Scheduling · p. 5
  • A scheduler must support applications that split work between edge execution and the cloud's greater computing capabilities.Source: A. Scheduling · p. 5

B. Multi-access Edge Computing

  • MEC can process device data locally, support low-latency services, and migrate tasks as mobile devices move between nodes.The passage also associates local processing with privacy and security benefits and reduced load on networks and data centres.Source: B. Multi-access Edge Computing · p. 5
  • Edge computing can support AI and deep-learning training and inference near data sources, while scheduling research must select suitable nodes and locations.The passage says source data may support better models while saving bandwidth to data centres.Source: B. Multi-access Edge Computing · p. 6
  • KubeEdge extends Kubernetes with a cloud control plane and edge workers, allowing edge nodes to continue working through network failures.The passage notes that KubeEdge considers unreliable connections.Source: B. Multi-access Edge Computing · p. 6

C. Serverless

Serverless offers event-triggered execution and can support edge data processing, but long-running tasks and edge security and hardware heterogeneity remain challenges. WebAssembly and containers are presented as ways to support execution across edge platforms.

C. Serverless

  • Serverless is cost-efficient for event-driven execution but becomes more expensive for long-running tasks, where dedicated servers are better candidates.Only used resources are billed, and no resources are consumed between triggering events.Source: C. Serverless · p. 6
  • Edge serverless can distribute data aggregation and processing across devices and edge nodes before transferring results to cloud storage.The paper notes that aggregation would reduce bandwidth costs to the cloud.Source: C. Serverless · p. 6
  • Serverless at the edge still faces security and hardware-heterogeneity challenges, and interaction with BaaS increases the attack surface.Source: C. Serverless · p. 6
  • Access Delivery Networks extend content delivery networks by placing computation near users as well as content.Source: C. Serverless · p. 6
  • WebAssembly can let developers target edge applications without managing platform architectures, while Sledge uses Wasm and containers offer another deployment route.Sledge supports a shared binary across platforms running Sledge; Nuclio and OpenFaaS use containers and can be scheduled by Kubernetes.Source: C. Serverless · p. 6

D. Automation

Edge automation is proposed as a way to save time and reduce cost, adapting DevOps and deployment practices to heterogeneous infrastructure. Applications should remain location-agnostic, while infrastructure management, CI/CD, and version-controlled deployment practices address distinct operational needs.

D. Automation

  • Infrastructure automation has a role in saving time and reducing cost in edge computing.Source: D. Automation · p. 6

1) Software development and deployment:

2) Infrastructure automation:

Edge infrastructure automation and orchestration must address structural and device heterogeneity, unreliable connections, mobility, and resource volatility. The conclusion identifies networking, portable execution, and Kubernetes-like orchestration as central parts of a seamless cloud experience.

2) Infrastructure automation:

  • Automated node and node-pool management, virtual clusters, virtual networking, and multi-cloud management are proposed to address edge infrastructure heterogeneity.The paper cites GKE Autopilot as an approach that automates management of nodes and node pools.Source: 2) Infrastructure automation · p. 7

V. CONCLUSION

  • Edge architectures need dynamic, resilient topologies that reflect device heterogeneity and energy needs, with networking central to application operation.Source: §V · p. 7
  • WebAssembly is a candidate for platform-independent execution, while accelerator support and higher-level interfaces remain priorities for efficient scheduling.Source: §V · p. 7
  • Device-to-data-centre orchestration needs Kubernetes-like technologies adapted for heterogeneous devices, unreliable connections, node churn, resource volatility, and accelerator access.Source: §V · p. 7
  • The conclusion identifies MEC and 5G as significant edge-computing contexts and calls for edge deployment to feel as easy as using serverless functions.Source: §V · p. 7
Loading 2111.06157v1…