MYRTUS Reference Infrastructure
The three MYRTUS technology pillars
MYRTUS technology results are organised around three pillars that together form a chain from application design to execution. Pillar 1 provides the edge-fog-cloud reference infrastructure on which applications run. Pillar 2 provides MIRTO, the cognitive engine that orchestrates workloads across this infrastructure, deciding where and how each workload is placed and executed. Pillar 3 provides the Design and Programming Environment (DPE), the methodology and toolchain through which applications are developed, optimised and packaged for deployment.
See how the three pillars work together in Concept and Methodologies →
MYRTUS Pillar 1
It is very well known that centralized solutions struggle to meet scalable and low latency scenarios, as well as privacy matters. Therefore, MYRTUS defines a reference infrastructure where a diversity of fog-level and edge-level devices converge with the cloud to form a computing continuum capable of addressing the needs of complex and dynamic systems.
Figure 1. MYRTUS Onion-Like Continuum
Edge layer
Close to sensors and actuators, the edge layer performs low-latency processing near the data sources, on resource-constrained and often heterogeneous devices, including reconfigurable accelerators for demanding tasks such as AI inference. Edge clusters run lightweight Kubernetes (K3s).
In MYRTUS: HMPSoC FPGA-based accelerators, adaptive RISC-V processors with custom computing units, smart traffic cameras.
Fog layer
Between edge and cloud, the fog layer offers more processing and storage than single edge devices while staying close enough to keep latency low. Fog nodes connect edge devices, process and filter their data, provide analytics on medium to long-term data and forward only what is relevant to the cloud. They run K3s or standard Kubernetes (K8s).
In MYRTUS: Fog Micro Data Centers, SenseIQ smart gateway.
Cloud layer
The cloud layer provides intensive computing, long-term storage, subsystem monitoring, coordination, data mining and historical analysis. It runs standard Kubernetes (K8s) and is not tied to a specific provider: any Kubernetes cluster able to join the federation can act as cloud layer.
In MYRTUS: partner-operated Kubernetes clusters, federated with the fog layer.
To establish a continuum of resources, MYRTUS combines two levels of orchestration. At the infrastructure level, Kubernetes manages the resources within each cluster, while Liqo makes the resources of each federated cluster usable from the others. On top of this federated infrastructure, the MIRTO agents decide where and how each workload runs: in the reference configuration, each layer has its own agent, which computes the allocation, passes it to a Deployer that turns it into Kubernetes deployments, and coordinates with the agents of the other layers. This is not only a reference design: clusters operated by different partners at sites across Europe are already federated into a single running continuum.
To create a continuum of information, all layers share one Distributed Knowledge Base (DKB), a common logical view whose data is kept in instances distributed across the infrastructure. This way, data remains close to their consumers but can be shared between layers for analysis and decision-making. Monitoring information collected from all nodes is stored in the DKB, and the Resource Registry built on top of it gives the MIRTO agents an up-to-date view of the available resources.
Figure 2. MYRTUS layered computing continuum infrastructure.
Cross-cutting aspects
The infrastructure relies on a set of cross-cutting aspects and enabling technologies that support its operation across all layers.
Containers and Kubernetes
Applications are packaged as Docker images, which run unchanged on very different hardware, from constrained edge devices to cloud servers. Kubernetes runs these containers in every cluster, and new images reach the infrastructure through a container registry and CI/CD pipelines. Before an image is built, its Dockerfile can optionally be reviewed with an LLM-based optimization tool.
Multi-cluster federation
Liqo federates independent Kubernetes clusters, vertically across the edge, fog and cloud layers and horizontally across sites of the same layer. Each peered cluster appears as a virtual node, so workloads can be offloaded to remote resources through encrypted WireGuard tunnels, while every cluster keeps its own control plane.
Distributed Knowledge Base
The DKB is built on MinIO object storage and replicated across sites, with automatic failover between instances. Components store and retrieve data through a common REST interface, independently of the underlying storage technology.
Monitoring and observability
Monitoring relies on Prometheus and Grafana, which collect metrics from clusters, gateways and cameras, with node-level energy data on the fog. For FPGA-based nodes, MYRTUS developed a dedicated framework that records synchronised power and performance traces of the accelerators.
Privacy and security
Privacy and security functionalities, namely encryption, authentication, key exchange and hashing, are offered at three security levels, from lightweight to post-quantum algorithms. They are packaged as a container attached to each node, and the most suitable implementation is chosen for each application and node, also based on its execution time and energy.
Trust and compliance (Gaia-X)
Building on the Gaia-X Trust Framework, MYRTUS developed a compliance service that checks the Verifiable Credentials of infrastructure providers against MYRTUS-specific rules and issues a signed compliance report. It is designed to be used when a new cluster joins the continuum.
Processing components
Cross-cutting technologies
Technologies that support the infrastructure across all layers.