Linkedin Github

Workflow Orchestration Across Edge-Cloud Clusters With Ryax

Orchestrating Workflows Across Cloud, Edge, On-Prem, and HPC

Ryax provides the orchestration layer for executing data analytics, AI, LLM, and HPC workflows across heterogeneous infrastructure. A workflow can combine actions running on Kubernetes sites for cloud, edge, or on-premises execution, and actions offloaded to Slurm-managed HPC resources when the workload requires it.

The platform separates application logic from placement decisions. For each action, users can define hard constraints, such as a specific site, Kubernetes node pool, or Slurm partition. When the placement decision should be optimized instead of fixed manually, users can express objectives and weights. Ryax then evaluates the available resources against scheduling objectives such as cost, energy, and performance.

This gives CAPE a practical execution model for the edge-cloud-HPC continuum. Developers can package actions once, compose them into workflows, and let the platform delegate execution to the appropriate orchestrator. Kubernetes remains the standard path for cloud-native execution. Slurm support enables HPC offloading while keeping the workflow visible from the same Ryax interface.

Ryax also centralizes observability for distributed runs. Users can inspect logs for actions executed on remote sites and monitor resource usage through a shared dashboard. This matters for CAPE because orchestration is not only about starting work on different clusters. It is also about making placement, execution, debugging, and monitoring understandable across multiple infrastructure domains.

Constraints and Objectives

Placement in Ryax is configured per action, independently of the action code, from the workflow Deploy view. The user first selects the target orchestrator, Kubernetes for cloud-native, edge, and on-premises sites, or Slurm for HPC sites, and that selection drives the placement options that become available. Because Ryax abstracts the orchestrator, the same action code is packaged differently depending on the target: as Docker-based containers for Kubernetes deployments, or as Singularity/Apptainer images submitted through an SSH connection and an adapted sbatch script for Slurm. Globally, the runner service on the master Ryax site orchestrates the workflow and delegates each action to the configured orchestrator of the selected site.

Constraints express hard placement requirements. The administrator exposes a catalogue of sites and, within each, the available Kubernetes node-pools or Slurm partitions. By activating a selection at the site, node-pool, or partition level, the user pins an action to that location, and Ryax deploys it exactly there. This is the right model when an action has a non-negotiable requirement; data locality, a licensed environment, specialized accelerators, or a partition reserved for a given class of jobs.

Objectives are for the cases where the optimal location is not known in advance, or where the decision should adapt to current conditions. Instead of pinning a site, the user assigns weights to scheduling objectives, and Ryax applies a score-based multi-objective scheduler: each candidate site carries per-objective scores, which are combined with the user-supplied weights into an overall score that ranks the eligible resources and selects the most adapted placement. Three objectives are currently supported, each set as a weight per action:

  • Cost minimization; a higher weight favors sites and resources with lower cost.
  • Energy efficiency improvement; a higher weight favors more energy-efficient sites and resources.
  • Performance optimization; a higher weight favors higher-performing sites and    resources.

 

Weights are combined rather than exclusive: for example, 100% energy, 50% cost, and 30% performance steers the scheduler toward energy-efficient nodes while still giving some importance to cost and less to raw performance. In short, constraints answer where an action must run, objectives answer which placement best balances cost, energy, and performance, and Ryax’s centralized observability then reports what happened after the action was delegated to each site.

 

Summary

Ryax orchestrates workflows across cloud, edge, on-premises Kubernetes, and Slurm-managed HPC sites. Users can either pin actions to specific sites, node pools, or partitions, or express weighted objectives such as cost, energy, and performance and let the scheduler choose an adapted placement. The same platform view then follows execution, logs, and resource monitoring across the distributed run.

For CAPE, Ryax provides a concrete bridge between application workflows and heterogeneous infrastructure. Kubernetes handles cloud-native execution, Slurm enables HPC offloading, and Ryax keeps the workflow, placement choices, and observability in one operational layer.