Polaris SLO Framework

The Polaris SLO Framework project aims to provide Service Level Objectives (SLOs) for the Edge-Cloud continuum.

Service Level Agreements (SLAs) are very common in cloud computing. Each SLA consists of one or more Service Level Objectives, which are measurable capacity guarantees. Most SLOs in today’s cloud environments are very low-level (e.g., average CPU or memory usage, throughput).

Elasticity is a fundamental property of cloud computing. It is commonly understood as provisioning more resources for an application as the load grows and deprovisioning resources as the demand drops. However, this resource elasticity is only one of three possible elasticity dimensions. The other two are cost elasticity (i.e., how much is a customer willing to pay for a service) and quality elasticity (e.g., the desired accuracy of the prediction of a machine learning model).

The goal of the Polaris project is to bring high-level SLOs to the Edge-Cloud continuum and enable customers to leverage all three levels of elasticity.

Documentation

The main documentation can be found here.

Videos and Demos

This video provides an introduction to the Polaris Framework and the concepts behind it. Specifically, it discusses:

Polaris Framework Concepts Video Preview

The following videos showcase the demos of the Polaris Framework and its CLI:

Additional demos can be found in this repository.

Scientific Publications

For more details and background, please see our scientific publications:

Motivating Example

Suppose a service provider (i.e., a cloud provider) wants to offer a Content Management System as-a-Service to its customers. The CMS-as-a-Service that is being offered consists of the following services: a database, a headless backend (REST API only), and a frontend user interface. Each service may expose one or more metrics, which can be simple ones like CPU usage or complex ones. These metrics can be used by the service provider to set up SLOs.

Motivating Example

Service consumers, i.e., Customers, who deploy the CMS-as-a-Service are not really interested in having an average CPU utiliztion of 80%, but instead want to have a “good performance for an acceptable cost”. Ideally they would like to specify a simple configuration that guarantees them a good performance without making their eyes pop out when they see the bill at the end of the month.

To this end, a cost efficiency SLO could be offered by the provider. Based on this article, we define the cost efficiency of a cloud application as the number of requests per second faster than N milliseconds divided by the total cost of the service. The cost efficiency could be exported by one or more services of the deployment as a custom metric and the service provider can use it as a base for creating an SLO that can be configured by the service consumers. Polaris can then take care of automatically of scaling all services within the CMS-as-a-Service workload, based on this cost efficiency SLO.

A service consumer can now deploy the CMS-as-a-Service as a workload in his/her cloud subscription. To configure the SLO, the consumer configures an SLO Mapping, which associates the cost efficiency SLO to the particular workload and supplies the desired cost efficiency as configuration values.

Beyond Simple Scaling

Polaris does not only allow the development and configuration of complex SLOs, it also allows service consumers the choose the exact elasticity strategy they want to use when their SLO is violated. The most common form (see here) of scaling in today’s clouds is horizontal scaling, i.e., adding additional instances of a service (scaling out) or removing unneeded instances of the service (scaling in).

The service provider can offer multiple elasticity strategies, e.g.,

SLO Mappings allow service consumers to choose which elasticity strategy they want to use with their SLO, as long as their input/output data types match.

Features

The Polaris project offers the following features:

SLO Script consists of an orchestrator-independent core library and connector libraries for specific orchestrators. Currently, there is a connector for Kubernetes.

Repository Organization

This is a polyglot monorepository. All code for this project is contained in this repository.

Directory Contents
deployment YAML files for quickly deploying Polaris CRDs and controllers
docs Documentation files
python Python code, e.g., predicted metric controller base
testbeds Configurations and demo applications, we use for testing
ts TypeScript code, i.e., all SLO Script libraries, SLO controllers, etc.

Building, Running, and Debugging

For details, on how to build, run and debug the Polaris components, please see the README of the TypeScript components.

Deployment

You need a running Kubernetes cluster with a Prometheus installation to use Polaris. Instructions on setting up such a cluster can be found here.

To quickly deploy the default set of elasticity strategies shipped with Polaris, open a terminal in the root folder of the repository and execute the following command:

kubectl apply -f ./deployment

This will deploy the HorizontalElasticityStrategy and VerticalElasticityStrategy CRDs and controllers. More detailed build and deployment instructions can be found here.

Maintaining gh-pages

The project’s website is hosted using GitHub pages.

# Clone the polaris repository once more, this time into the ./gh-pages folder and check out the gh-pages branch.
git clone -b gh-pages git@github.com:polaris-slo-cloud/polaris.git ./gh-pages

# Run the update script to copy the current state from the docs folder to gh-pages and to regenerate the typedoc documentation.
./update-gh-pages.sh

# Go into the gh-pages directory and push the branch
cd gh-pages
git add .
git commit -m "Update gh-pages"
git push origin

Our Users

The Polaris SLO Framework project is actively used by the orchestration layer of the RAINBOW project to bring complex SLOs to Fog Computing.