(2 min read)
The Swarmchestrate orchestration system is a middleware platform which accepts microservice-based applications together with their QoS goals, constraints, and other deployment requirements. It deploys these applications by identifying the most suitable resources and continuously ensures that QoS objectives are met by performing reconfigurations whenever necessary. In this blog post we present a walkthrough of our first end-to-end prototype; this prototype demonstrates the full orchestration workflow —from application submission, to resource discovery and provisioning— through to the deployment of both the application components and the required system services.
As illustrated in the figure, the process begins with a high-level application description expressed using the TOSCA 2.0 specification, which we refer to as the Swarmchestrate Application Template (SAT). This SAT description is submitted to a network of three independent Resource Agents (RAs), each providing access to resources offered by a specific provider.
End-to-end orchestration flow (© Swarmchestrate consortium 2024-2026)
Upon receiving the SAT, the handling RA (aws-uk in this example) broadcasts the request to its peers to compile all valid combinations of resources capable of fulfilling the application’s requirements —R1 and R2 in this case. Each RA evaluates its available capacity and returns a response specifying which requirements it can satisfy, along with additional resource metadata such as price, energy consumption, and latency.
These responses are aggregated into a complete set of feasible resource offers, which is then passed to a ranking algorithm. The algorithm evaluates each offer against the QoS objectives defined in the SAT and returns a sorted list, with the top-ranked offer selected as the winner.
The resources identified in the winning offer are then provisioned for the application. The aws-uk RA initiates the instantiation process by selecting a lead resource —responsible for hosting the Kubernetes control plane. In principle, this selection depends on factors such as resource size, network performance, and type; however, for our prototype we simply selected the cloud resource with the highest CPU and memory configuration.
Once selected, the aws-uk RA coordinates with the corresponding RA to instantiate the lead resource and automatically configure the Kubernetes control plane. The remaining resources (one additional resource in this prototype) are then instantiated and automatically joined to the cluster. Finally, the system deploys the application components —according to the hosting directives defined in the SAT— along with the necessary system services, such as the knowledge base and the swarm agent.
Architectural view of application deployment (© Swarmchestrate consortium 2024-2026)