MiLA4U Architecture - confcodesubmit/MiLA4U GitHub Wiki

MiLA4U Architecture

The overall architecture of MiLA4U consists of three layers, namely Edge, Fog and the Cloud.

The set of IoT devices (sensors and actuators) can be found at the Edge layer. Sensors send the data sensed to the Fog layer based on data transfer frequency. They also periodically send their QoS data, i.e., battery level, memory consumption, etc.

At the Fog layer the lightweight computations on the sensed data and further architectural adaptations/re-configurations on the IoT devices, are performed. It consists of multiple Compute Node's made by a Compute and an IoT Adapter components. The former is responsible for performing preliminary computations on the sensed data, such as data aggregation, cleaning, etc. The IoT Adapter is responsible for handling the adaptation concerns at the device level. To this aim, it makes use of QoS goals and ensures that these goals are met by continuously monitoring and analysing the QoS data obtained from the devices. In case of any deviations from the defined QoS goals, it identifies a suitable adaptation plan based on the operational context of the IoT devices and the run-time metrics of microservices that are directly or indirectly associated with the IoT devices. The information on the microservices run-time metrics is received periodically from the QoS Analyzer component in the Cloud layer. The selected plan is then used to perform device level adaptation, such as reduce the sensor data transfer frequency, modify the communication protocol, etc.

Heavyweight computations are performed at the Cloud layer. It consists of four main layers.

  1. Application Infrastructure Layer: Its purpose is to execute Application level adaptation is based on users goals. The application's functionalities are combined by the users as abstract goals that can be refined at run-time through a dynamic selection of microservices whose execution allows users to achieve their goals. It consists of three main components. The i)User Goal Parser parses the abstract user goals and translates them to the format as required by the ii)Service Manager. Goals are specified via the goal model (as discussed in the paper). The Service Manager uses the parsed user goals to identify the microservices related to the functionalities specified in the user goals. It employs a service selection algorithm to dynamically select microservices. The API Gateway it performs the routing of the requests from the Service Manager to the corresponding microservices.

  2. Microservice Layer: It consists of the set of microservices implementing the functionalities of a given microservice-based IoT system, each deployed on a container.

  3. Management Infrastructure Layer: It is responsible for gathering different run-time metrics of the different microservices (memory consumed, context information such as location, ip, etc.) and the container environments. It further provides information on the status of the microservices, manages them, and executes adaptation, if needed. It consists of i) Log Aggregator, ii) Container Manager and iii) Metrics Collector for extracting run-time logs (to extract QoS information), managing container lifecycle and collecting run-time metrics of the microservices respectively (memory consumed, context information such as location, ip, etc.).

  4. Adaptation Infrastructure Layer: This is a dedicated layer consisting of several components that provide mechanisms for effectively supporting adaptations at different levels. They are responsible for collecting the context and QoS data from the Fog and Management Infrastructure layers. They leverage these data to continuously identify the need for adaptation and further decide on the best adaptation strategy based on the overall QoS goals of the system. Three different data stores are provided. i)IoT QoS Store for storing the QoS of the different IoT devices obtained from Fog layer; ii)Service QoS Store for storing the QoS information of the microservices available from the Metrics Collector and iii)Context QoS Store for storing the context information on microservices obtained from the Metrics Collector and Container Manager . The Data Processor processes the different types of real-time QoS data obtained from the various data store components. It performs operations such as data aggregation, transformation, and cleaning to support the analysis activities of the QoS Analyzer. The QoS Analyzer is responsible for identifying the need for adaptation of microservices based on a set of QoS goals as well the data obtained from the Data Processor component. These QoS goals define the acceptable range of QoS values for different QoS attributes of the microservices. The QoS Analyzer follows a two-step process. First, it periodically extracts the average QoS values of each microservices from the Data Processor. This information is used to identify the need for adaptation based on the QoS goals, and further sent to the Decision Maker. Second, it analyzes the contextual information of microservices to generate a mapping between microservices and their corresponding arrival rate. This mapping, along with the QoS goals for IoT devices, This is further communicated to the IoT Adapter component. The Decision Maker is responsible for performing two activities. First, it uses context-driven QoS aware instance ranking algorithm to dynamically rank the instances of microservices based on their QoS values, to facilitate efficient north-south and east-west communications. These rankings are regularly performed and sent to the Service Manager to support an effective dynamic selection of microservices. Second, it is also responsible for enacting adaptation of microservices based on information from the QoS Analyzer (e.g., dynamically scaling microservices, restarting microservices, etc.). Finally, the Adaptation Initiator acts as a bridge between the Decision Maker and the Management Infrastructure, by forwarding the adaptation request to the higher layer.