Tom Goethals

In recent years, microservice-based applications have shifted towards cloud-edge computing, taking advantage of green energy, lower latencies, and local computational resources. Simultaneously, various alternatives to containers, such as unikernels and WebAssembly, have emerged and are gradually being adopted by container-based orchestration software such as Kubernetes. However, solutions that integrate such alternatives are not generic: they only integrate a single specific non-container option, and generally do not allow for mixed-workload pods with both container and non-container workloads. Importantly, no solution is currently capable of integrating mixed-workload pods with all the features of pod networking as standardized by Kubernetes. This article presents a generic, runtime-agnostic solution which provides mixed-workload pods with all the standard behavioral features of pod networking. The core functionality of the proposed solution is sub-pod networking, which sets up small independent subnets for each pod rather than providing them a single IP address, and which is based on eBPF programs for efficient and secure traffic processing. The architecture is implemented in Feather, a Kubernetes-compatible orchestration agent which supports both containerd and OSv unikernels, and evaluations show that the end-to-end latency overhead of the implementation for various types of network traffic ranges from just 22μs to 200μs, and scales predictably with the number of non-container workloads in a pod. Additionally, the implementation has no significant memory overhead, and CPU overhead is 2Gbps to 6.4Gbps per percentage of a single core, depending on runtime and evaluation scenario.

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.

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 ≈0.5% to 5% total CPU load, depending on traffic direction and protocols used.

The use of AI on Smart applications and in the organization of the network edge presents a rapidly advancing research field, with a great variety of challenges and opportunities. This article aims to provide a holistic review of studies from 2019 to 2021 related to the Intelligent Edge, a concept comprising both the use of AI to organize edge networks (Edge Intelligence) and Smart applications in the edge. An introduction is given to the technologies required to understand the state of the art of AI in edge networks, and a taxonomy is provided with “Enabling Technology” for Edge Intelligence, “Organization” of the edge using AI, and AI “Applications” in the edge as its main topics. Research trend data from 2015 to 2020 is presented for various subdivisions of these topics, showing both absolute and relative research interest in each subtopic. The “Organization” aspect, being the main focus of this article, has a more fine-grained subdivision, explaining all contributing factors in detail. The trends indicate an exponential increase in research interest in nearly all subtopics, but significant differences between them. For each subdivision of the taxonomy a number of selected studies from 2019 to 2021 are gathered to form a high-level illustration of the state of the art of Edge Intelligence. From these selected studies and the trend data, a number of short-term challenges and high-level visions for Edge Intelligence are formulated, providing a basis for future work.

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.

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.