Technical Articles series: Orchestration in Swarmchestrate -a brief introduction

(3 min read)

The Swarmchestrate orchestration system is a middleware; as an input it receives the descriptions of microservice-based applications along their Quality of Service (QoS) goals, constraints, etc.; as an output it deploys the applications at the most optimal resources, and ensures that the QoS goals of the applications will be consistently met by performing the necessary reconfiguration when and if required. Being the outcome of a Research & Innovation endeavour, Swarmchestrate follows an application-centric approach to optimise application goals, e.g., it aims to find cost-effective resources for the application owners rather than boost profit for resource providers. In Swarmchestrate, once an application is submitted, the optimally chosen resources will form a swarm, hosting application components. Once deployed, they will manage themselves based on the self-organising concept of swarm intelligence. The figure below depicts a high-level architectural view.

architectural view of application deployment in Swarmchestrate

The overall system is distributed into the following four key sections:

  1. Application View allows application operators to describe their applications in TOSCA format. The description will mainly include the definition of application microservices, resource requirements for the application, monitoring specifications, and the QoS goals.
  2. Resource View adopts a two-layered approach: 1) Resources, representing the actual computational resources provided by different providers, e.g., Amazon, Microsoft, etc.; and 2) Capacities, representing the logical grouping of resources, that are made available to Swarmchestrate by an entity called capacity provider. Any resource in Swarmchestrate is part of a capacity.
  3. Knowledge Management is a distributed knowledge base, responsible for managing information related to resource descriptions, system interactions and decision-making. The resources can be discoverable based on various contextual attributes and trust factors for the Swarms’ formation and reconfigurations. The functionalities of the Knowledge Management System will be used by the Resource View and the Orchestration Space.
  4. Orchestration Space (OS) is a distributed entity with no central control. In Swarmchestrate, the applications will be submitted to the Orchestration Space –the confluence of three concepts: decentralisation, Swarms and intelligence– for achieving efficient, optimised and trusted orchestration of applications in the Cloud-Edge ecosystem. The interface to the OS is a set of Resource agents (RAs) running in the space independently, however, connected through a P2P network. RA is a system component with the core purpose of providing access to the resources of a specific capacity provider.

The initialisation of the Swarmchestrate system will set up a Swarmchestrate ecosystem, facilitating the related processes such as resource capacity registration, application submission, runtime management, and application termination. The figure above depicts the processes of capacity registration with the Knowledge Base and the procedure of how the application deployment will be carried out. The registration process involves the capacity provider describing the resources as part of the capacity. The resource description consists of specifications such as processing capability, memory, hardware type, etc., and various required contextual attributes, e.g., usage price per time unit, locality, etc. The application deployment process initiates when an application owner submits the TOSCA description of an application to one of the RAs. Once submitted, the respective RA will be responsible for the deployment of that application using the following sub-processes: 1) Collecting resource offers, where all possible offers are collected from all available RAs; 2) Resource selection, where the available offers are evaluated based on application goals provided in the TOSCA description to select the optimal set of resources amongst the available ones; 3) Lead Swarm Agent (SA) deployment, responsible for the initiation of the swarm–group of resources that are intelligently selected such that they together provide the highest chances of fulfilling the QoS goals of the submitted application–formation process; and 4) Application deployment, where the lead SA completes the swarm formation process and deploys the application.

Editor: Amjad Ullah, Edinburgh Napier University