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.

A Kubernetes cluster typically consists of trusted nodes, running within the confines of a physically secure datacenter. With recent advances in edge orchestration, this is no longer the case. This poses a new challenge: how can we trust a device that an attacker has physical access to? This paper presents an architecture and open-source implementation that securely enrolls edge devices as trusted Kubernetes worker nodes. By providing boot attestation rooted in a hardware Trusted Platform Module, a strong base of trust is provided. A new custom controller directs a modified version of Keylime to cross the cloud-edge gap and securely deliver unique cluster credentials required to enroll an edge worker. The controller dynamically grants and revokes these credentials based on attestation events, preventing a possibly compromised node from accessing sensitive cluster resources. We provide both a qualitative and a quantitative evaluation of the architecture. The qualitative scenarios prove its ability to attest and enroll an edge device with role-based access control (RBAC) permissions that dynamically adjust to attestation events. The quantitative evaluation reflects an average of 10.28 seconds delay incurred on the startup time of the edge node due to attestation for a total average enrollment time of 20.91 seconds. The presented architecture thus provides a strong base of trust, securing a physically exposed edge device and paving the way for a robust and resilient edge computing ecosystem.

Artificial Intelligence for IT Operations (AIOps) addresses the rising complexity of cloud computing and Internet of Things by assisting DevOps engineers to monitor and maintain applications. Machine Learning is an essential part of AIOps, enabling it to perform Anomaly Detection and Root Cause Analysis. These techniques are often executed in centralized components, however, which requires transferring vast amounts of data to a central location. This increase in network traffic causes strain on the network and results in higher latency. This paper leverages edge computing to address this issue by deploying ML models closer to the monitored services, reducing the network overhead. This paper investigates two architectural approaches: a sidecar architecture and a federated architecture, and highlights their advantages and shortcomings in different scenarios. Taking this into account, it proposes a framework that orchestrates the deployment and management of distributed edge ML models. Additionally, the paper introduces a Python library to assist data scientists during the development of AIOps techniques and concludes with a thorough evaluation of the resulting framework towards resource consumption and scalability. The results indicate up to 98.3% reduction in network usage depending on the configuration used while maintaining a minimal increase in resource usage at the edge.

Abstract Internet of Things (IoT) technologies, when adequately integrated, cater for logistics optimisation and operations' environmental impact monitoring, both key aspects for today's EU ports management. This article presents Obelisk, a scalable and multi‐tenant cloud‐based IoT integration platform used in the EU H2020 PortForward project. The landscape of IoT protocols being particularly fragmented, the first role of Obelisk is to provide uniform access to data originating from a myriad of devices and protocols. Interoperability is achieved through adapters that provide flexibility and evolvability in protocol and format mapping. Additionally, due to ports operating in a hub model with various interacting actors, a second role of Obelisk is to secure access to data. This is achieved through encryption and isolation for data transport and processing, respectively, while user access control is ensured through authentication and authorisation standards. Finally, as ports IoTisation will further evolve, a third need for Obelisk is to scale with the data volumes it must ingest and process. Platform scalability is achieved by means of a reactive micro‐services based design. Those three essential characteristics are detailed in this article with a specific focus on how to achieve IoT data platform scalability. By means of an air quality monitoring use‐case deployed in the city of Antwerp, the scalability of the platform is evaluated. The evaluation shows that the proposed reactive micro‐service based design allows for horizontal scaling of the platform as well as for logarithmic time complexity of its service time.

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.

Automated management and orchestration of cloud applications have become increasingly important, partly due to the large skills shortage in IT operations and the increasing complexity of cloud applications. Cloud modeling languages play an important role in this, both for describing the structure of a cloud application and specifying the management actions around it. The TOSCA cloud model standard recently defined declarative workflows as the preferred way to specify these management actions but, as noted in the standard itself, this is far from ideal. This paper draws lessons from six years of using declarative workflows in Juju for deploying and managing complex platforms such as OpenStack and Kubernetes in production. This confirms the limitations: declarative workflows are inflexible, hard to reuse, and allow for related components to become silently incompatible. This paper proposes the reactive pattern to solve these issues by enabling the creation of emergent workflows using declarative flags and handlers, which can be easily grouped into reusable layers. After more than two years of using this pattern in production as part of our charms. reactive framework, it is clear that it enables reusability and ensures compatibility: 67% of reactive charms share parts of the management workflow and 73% of reactive charms share a relationship workflow.

The data science skills shortage means that those who have the knowledge are under constant pressure to do more with less. While the data science tools are improving at a staggering pace, the operational tools around them can not keep up. Even researchers at Google state that the issue of automatic configuration and dependency management of services is still an “open, hard problem”. This manifests itself in data scientists either constantly having to solve operational challenges or having to be in constant close collaboration with a skilled operations team. This paper addresses the operational challenges behind deploying and managing workflows on top of analytics platforms by starting from three key requirements: data scientists want to model their workflows in a reusable way, this model should be automatically deployed, managed and connected to other services, and this solution should be compatible with existing cloud modeling languages, infrastructure, analytics platforms and tools. The paper explores where the state-of-the-art falls short in meeting these requirements, proposes an architecture to solve the open challenges, and implements and evaluates this architecture.