Engineering Elasticity Policies
for Cloud-native Applications
with Slingshot
This page provides a documentation of the Slingshot approach for engineering elasticity policies for cloud-native applications. The approach is based on the following components:
The approach builds upon the Palladio approach (palladio-simulator.com) and contributes the following components:
- The Scaling Policy Definition (SPD) language to model your scaling policies at the architectural-level.
[⇢ The SPD Language Concepts]
[⇢ Configuration of SPD with PCM]
- The Slingshot Simulator that has the necessary plugins for simulating PCM and SPD.
[⇢ The Slingshot Simulator]
The picture below shows a high-level overview of the approach and flow of activities. 
The Palladio Component Model for modelling static system configurations
Other roles that exist in the Palladio development process model the system through the different static viewpoints (e.g., Component Repository, System Model, Resource and Allocation Model).
The SPD Modelling Language
The self-adaptive system architect models the elasticity of the system through the SPD language. The SPD language allows defining policies that target different elements in the model, for example, a policy may target the infrastructure, or it may target one of the services. In addition, the SPD language features the following:
- it allows to model different triggers based on stimuli that stems from the simulation (e.g., CPU utilization measurement data).
- it allows to model different constraints which may be scoped for the policy or the target group (e.g., Cooldown Constraint for a policy, GroupSize Constraint for the target group)
- it allows to model different types of adjustments (e.g., Step Adjustment of 1, everytime the policy is triggered one container is addedd)
Simulating Elasticity Policies
Last but not least, the self-adaptive system architect evaluates the policies through the Slingshot simulator. All the models are given as an input to the Slingshot simulator that simulates the system and provides the results to the architect for further analysis and refinement of the SPDs. To be able to do so, the architect needs to create a mapping, through an auxiliary model (defined by another meta-model), of the SPD models and the static viewpoints of the system. The mapping is done once and defines the target groups which could be used in the SPD models. [⇢ Tutorial, Analysis]