The PLEDGER consortium has prepared several demos to showcase integration with the different core components.
The demo described in this post is also available on [YouTube] and shows the integration among the following core components:
• ConfService, managing the configuration of the DSS
• DSS, responsible for the decisions about scaling, offloading and resource/latency optimizations
• Orchestrator (E2CO), that actuates the DSS decisions over the infrastructures
• SLA Lite, monitoring Apps and sending notifications of SLA violations
• Benchmarking, responsible for the benchmarks of the different infrastructures
• AppProfiler, profiling the Apps and notifying which is the best Benchmark for a given App
• Stream Handler, used as an async communication bus based on Kafka
The components involved are also described in the following picture, where the green arrows represent connections through the Stream Handler using Kafka, the red arrows direct connection using JDBC protocol and blue arrows showing direct API calls.
In this demo, a service provider wants an App to run and fulfil some SLAs and to run the App on the edge as much as possible. The goal is to show how a test App is configured, started, monitored, offloaded from edge to cloud and back to reduce SLA violations.
We use infrastructure from different partners (FILL, ENG, i2CAT). In particular, the configuration used is the following:
• A Service Provider from one edge infrastructure owner (FILL)
• Infrastructures are already configured: edge (FILL, based on Docker) and multiple cloud (ENG, i2CAT, both based on Kubernetes)
• Apps are already configured, along with their Services, SLA, Guarantees and Deployment Options
• The App used for the demo is “media-consumption”, made of two Services with different constraints: “energy-consumption” has to run on the edge; “air-consumption” should run on the edge (high priority), otherwise on the cloud (low priority) with the best performance
• The Service “air-consumption” is Nginx.
• The SLA and Guarantees are configured to generate an alert when the cpu load increase. CPU load is simulated with “ab” tool
• Data from Benchmarks and AppProfiler label matching have been already received by the DSS and used to choose the best Node where to run the App.
This demo demonstrates:
• the infrastructures configured in the ConfService and the Service Provider preferences to keep an App on the edge as primary option
• an App, with Service, SLA, Guarantees and Deployment Options
• E2CO and SLA Lite swagger consoles to see the configuration received by the ConfService
• an App started and deployed on the edge
• the App monitored, and an SLA violation is received when some load is artificially generated
• the DSS choosing the best Benchmark tool for a Service using label matching set manually or by the AppProfiler
• the DSS choosing the node with highest score for the selected Benchmark tool
• the App monitoring continues, with no SLA violations
the DSS triggering an offload back to the edge
