Continuum computing has emerged as a paradigm to improve various aspects of service orchestration by offloading computation from the cloud to the network edge. However, edge orchestration poses two significant challenges compared to cloud computing. On one hand, cloud software scheduling algorithms make suboptimal decisions when applied to the network edge, as edge devices and networks are more hetereogeneous than cloud data centers, and orchestration requires different parameters. On the other hand, most orchestration platforms assume highly centralized cloud data centers, with each server running many easily migrated software instances, whereas edge devices have limited hardware capabilities and migration of tasks between devices is significantly slower than in the cloud. As a result, there is a need for a decentralized orchestration platform that allows scheduling algorithms to take into account a wide variety of device properties and deployment requirements in placement decisions. This article presents Flocky, a decentralized device discovery and service orchestration framework based on Open Application Model (OAM), to address this gap. The architecture of Flocky is elaborated, showing how OAM enables flexible intent modeling in the edge, and combined with a Gossip-like algorithm allows individual edge devices to discover devices in their neighborhoods, map their capabilities, and optimally deploy parts of applications to individual nodes. Evaluation shows Flocky to be highly scalable and mainly dependent on local node density, with nodes discovering over 97% of their viable neighbours on average within two discovery rounds, while using 84% less memory than a centralized orchestrator such as Kubernetes.

The rapid expansion of Internet of Things (IoT), edge, and embedded devices in the past decade has introduced numerous challenges in terms of security and configuration management. Simultaneously, advances in cloud-native development practices have greatly enhanced the development experience and facilitated quicker updates, thereby enhancing application security. However, applying these advances to IoT, edge, and embedded devices remains a complex task, primarily due to the heterogeneous environments and the need to support devices with extended lifespans. WebAssembly and the WebAssembly System Interface (WASI) has emerged as a promising technology to bridge this gap. As WebAssembly becomes more popular on IoT, edge, and embedded devices, there is a growing demand for hardware interface support in WebAssembly programs. This work presents WASI proposals and proof-of-concept implementations to enable hardware interaction with I2C and USB, which are two commonly used protocols in IoT, directly from WebAssembly applications. This is achieved by running the device drivers within WebAssembly as well. A thorough evaluation of the proof of concepts shows that WASI-USB introduces a minimal overhead of at most 8% compared to native operating system USB APIs. However, the results show that runtime initialization overhead can be significant in low-latency applications.

Recent years have seen the adoption of workload orchestration into the network edge. Cloud orchestrators such as Kubernetes have been extended to edge computing, providing the virtual infrastructure to efficiently manage containerized workloads across the edge-cloud continuum. However, cloud-based orchestrators are resource intensive, sometimes occupying the bulk of resources of an edge device even when idle. While various Kubernetes-based solutions, such as K3s and KubeEdge, have been developed with a specific focus on edge computing, they remain limited to container runtimes. This paper proposes a Kubernetes-compatible solution for edge workload packaging, distribution, and execution, named Feather, which extends edge workloads beyond containers. Feather is based on Virtual Kubelets, superseding previous work from FLEDGE. It is capable of operating in existing Kubernetes clusters, with minimal, optional additions to the Kubernetes PodSpec to enable multi-runtime images and execution. Both Containerd and OSv unikernel backends are implemented, and evaluations show that unikernel workloads can be executed highly efficiently, with a memory reduction of up to 20% for Java applications at the cost of up to 25% CPU power. Evaluations also show that Feather itself is suitable for most modern edge devices, with the x86 version only requiring 58-62 MiB of memory for the agent itself.

In recent years, workload containerisation has been extended to the edge, bringing with it the need for flexible overlay networking. However, current container networking solutions are generally designed for the cloud, aimed at relatively static clusters with centralized generation of container subnet addresses and assigning them to nodes. Added to that existing tunneling solutions, such as Virtual Private Networks (VPN), also have centralized components. Conversely, the network edge is geo-dispersed and has a volatile topology,with edge nodes typically hidden behind routers, in private networks. To enable large-scale networking at the edge, there is need for decentralized self-management of container network addresses and overlay tunnels. This manuscript presents Warrens, a framework for fully decentralized and self-organizing cloud-edge container networks. Warrens enables communication between edge nodes in different private networks by enabling connectionless tunnels, supported by decentralized self-assignment of container IP addresses, with the assignment scheme minimizing address conflict to a negligible level. Warrens has been implemented in two variants using kernel-level eBPF for processing speed, and user-level Golang for wider compatibility. Warrens is shown to be highly scalable compared to a typical VPN solution, and performance evaluations demonstrate it can handle a full network load on both x64 devices and a Raspberry Pi with$\approx 0.5\%$to 5% total CPU load, depending on traffic direction and protocols used.

The cloud native paradigm is emerging as a pathway to developing applications for intrinsic operation on the cloud. This prompted application modularity, leveraging the adoption of the microservices architecture. Meanwhile, fog computing is emerging as a geo-dispersed cloud, bringing services closer to the end-user for localization and improved responsiveness. Transitioning to fog-native applications, i.e. managing microservice workflows over the fog, is a non-trivial challenge. On one hand, engineering workflows require awareness of the dependencies across microservices, as they impact the perceived quality of service. On the other hand, the heterogeneity of capacities, energy prices and supply, introduce challenges that can negate the sought advantages of the fog. This work proposes a novel algorithm based on Alternating Direction Method of Multipliers for intent-based workflow mapping and admission, iADMM. The performance of the algorithm is evaluated analytically and experimentally and compared to a baseline compute-network cost minimization alternative. Evaluation results show that iADMM achieves near optimal decisions in minimizing operational costs without violating workflow intents.

In recent years, the continuing growth of the network edge, along with increasing user demands, has led to the need for increasingly complex and responsive management strategies for edge services. Many of these strategies are cloud-based, offering near-perfect solutions at the cost of requiring massive computational power, or edge-based, offering reactive strategies to changing edge conditions. This paper presents a decentralized, pro-active Quality of Experience (QoE) based architecture designed to run on edge nodes, which allows nodes to predict optimal service providers (fog nodes) in advance and request their services. The concepts behind the components of the architecture are explained, as well as geometry-inspired design decisions to limit model size. Evaluations on an NVIDIA Jetson Nano show that the architecture can predict optimal service providers for an edge node in real-time for 5 to 20 QoS (Quality of Service) and QoE parameters, with at least 50 potential fog nodes, and that overall QoE resulting from its use is improved by 1% to 18% over previous work such as SoSwirly, depending on the scenario.

In recent years, containers have gained popularity as a lightweight virtualization technology. This rise in popularity has gone hand in hand with the adoption of microservice architectures, mostly thanks to the scalable, ethereal, and isolated nature of containers. More recently, edge devices have become powerful enough to be able to run containerized microservices, while remaining flexible enough in terms of size and power to be deployed almost anywhere. This has triggered research into several container placement strategies involving edge networks, leading to concepts such as osmotic computing. While these container placement strategies are optimal in terms of workload placement, current container orchestrators are often not suitable for running on edge devices due to their high resource requirements. In this article, FLEDGE is presented as a Kubernetes-compatible container orchestrator based on Virtual Kubelets, aimed primarily at container orchestration on low-resource edge devices. Several aspects of low-resource container orchestration are examined, such as the choice of container runtime and how to realize container networking. A number of evaluations are performed to determine how FLEDGE compares to Kubernetes and K3S in terms of resource requirements, showing that it needs around 60MiB memory and 78MiB storage to run on a Raspberry Pi 3, including all dependencies, which is significantly less than both studied alternatives.

In recent years, computing workloads have shifted from the cloud to the fog and edge, as IoT devices are becoming powerful enough to run containerized services. While the fog and edge computing can increase energy efficiency, reduce network traffic and provide better end user experience, the scale and volatility of the fog and edge also present new problems for service scheduling. In the edge, there are orders of magnitude more devices than in cloud data centers, and conditions are often less stable. Additionally, unlike in data centers, the network topology of the edge often changes, requiring a real-time approach to scheduling. In this demonstration, an implementation of a highly scalable orchestrator named “Swirly” is presented. The challenge of fog service scheduling is illustrated by using this implementation to organize software services in near real-time and on-demand in a virtual representation of a real-world industry park. Performance indicators are presented to show that this solution can scale up to 300.000 edge nodes.

Recent trends have caused a shift from services deployed solely in monolithic data centers in the cloud to services deployed in the fog (e.g. roadside units for smart highways, support services for IoT devices). Simultaneously, the variety and number of IoT devices has grown rapidly, along with their reliance on cloud services. Additionally, many of these devices are now themselves capable of running containers, allowing them to execute some services previously deployed in the fog. The combination of IoT devices and fog computing has many advantages in terms of efficiency and user experience, but the scale, volatile topology and heterogeneous network conditions of the fog and the edge also present problems for service deployment scheduling. Cloud service scheduling often takes a wide array of parameters into account to calculate optimal solutions. However, the algorithms used are not generally capable of handling the scale and volatility of the fog. This paper presents a scheduling algorithm, named "Swirly", for large scale fog and edge networks, which is capable of adapting to changes in network conditions and connected devices. The algorithm details are presented and implemented as a service using the Kubernetes API. This implementation is validated and benchmarked, showing that a single threaded Swirly service is easily capable of managing service meshes for at least 300.000 devices in soft real-time.

The main goal of a smart city is to enhance the quality of life of its inhabitants by providing services using Information and Communications Technology (ICT) components in a city. ICT components include not only Internet of Things (IoT) data sources spread across the city, but also traditional non-IoT data sources. Managing all ICT components in a smart city can be challenging and results in many complexities. Consequently, there is a need for ICT management architectures. Traditional solutions are often based on a centralized ICT architecture using Cloud technologies. Recently, the number of ICT components, services, and their corresponding complexities are growing, leading to large-scale ICT architectures. Centralized Cloud solutions cannot cope with the ever-expanding demands of this kind of architectures. The limitations of the centralized approaches necessitate the design of a new ICT architecture, using distributed technologies, for every layer and element of the city. Many solutions for management from Edge-to-Cloud (E2C) through distributed technologies are forthcoming, including Decentralized-to-Centralized ICT (DC2C-ICT) and Distributed-to-Centralized ICT (D2C-ICT) architectures. The DC2C-ICT architecture and its components work on their own tasks and are solely communicating with a centralized platform. On the other hand, components of the D2C-ICT architecture can work together to provide the services for the citizens across different layers from E2C. Therefore, the D2CICT architecture is less dependent on the central Cloud-based entity, but harder to design and manage. In this paper, an “Edge-to-Cloud-as-a-Service (E2CaaS) ” model is proposed together with a model on how to build efficient software services in smart cities through different layers of E2C. The most important tasks for building these services are the management of“Data/Database,” “Resources,” and “Network Communication and Cybersecurity issues”.

In crisis situations, it is important to be able to quickly gather information from various sources to form a complete and accurate picture of the situation. However, the different policies of participating companies often make it difficult to connect their information sources quickly, or to allow software to be deployed on their networks in a uniform way. The difficulty in deploying software is exacerbated by the fact that companies often use different software platforms in their existing networks. In this paper, Flexible federated Unified Service Environment (FUSE) is presented as a solution for joining multiple domains into a microservice based ad hoc federation, and for deploying and managing container-based software on the devices of a federation. The resource requirements for setting up a FUSE federation are examined, and a video streaming application is deployed to demonstrate the performance of software deployed on an example federation. The results show that FUSE can be deployed in 10 minutes or less, and that it can support multiple video streams under normal network conditions, making it a viable solution for the problem of quick and easy cross-domain federation.

For years, containers have been a popular choice for lightweight virtualization in the cloud. With the rise of more powerful and flexible edge devices, container deployment strategies have arisen that leverage the computational power of edge devices for optimal workload distribution. This move from a secure data center network to heterogenous public and private networks presents some issues in terms of security and network topology that can be partially solved by using a Virtual Private Network (VPN) to connect edge nodes to the cloud. In this paper, the scalability of VPN software is evaluated to determine if and how it can be used in large-scale clusters containing edge nodes. Benchmarks are performed to determine the maximum number of VPN-connected nodes and the influence of network degradation on VPN performance, primarily using traffic typical for edge devices generating IoT data. Some high level conclusions are drawn from the results, indicating that WireGuard is an excellent choice of VPN software to connect edge nodes in a cluster. Analysis of the results also shows the strengths and weaknesses of other VPN software.