Parameters and constraints

One of the key elements that define an optimization study is the parameters set. We have already seen in the study section how to define the set of optimized parameters here we dig deeper on this topic.

Akamas supports four types of parameters:

• Integer parameters are those that can only assume an integer value (e.g. the number of cores on a VM instance).

• Real parameters can assume real values (e.g. 0.2) and are mostly used when dealing with percentages.

• Categorical parameters map those elements that do not have a strict ordering such as GC types (e.g. Parallel, G1, Serial) or booleans.

• Ordinal parameters are similar to categorical ones as they also support a set of literal values but they are also ordered. An example is VM instance size (e.g. small, medium, large, xlarge..).

You can read more on parameters and how they are managed in the reference documentation section.

Most of the time you should not bother with defining parameters, as this information is already defined in the Optimization Packs.

When creating new optimization studies you should first select a set of parameters to include in the optimization process. The set might depend on many factors such as:

• The potential impact of a parameter on the defined goal (e.g. if my goal is to reduce the cost of running an application it might be a good idea to include parameters related to resource usage).

• The layers selected for the optimization. Optimizing multiple layers at the same time might bring more benefits as the configurations of both layers are aligned.

• The Akamas' ability to change those parameters (e.g. if my deployment process does not support the definition of some parameters because, as an example, are managed by an external group, I should avoid adding them).

Domains

Besides defining the set of parameters users can also select the domain for the optimization and add a set of constraints.

Optimization packs already include information on the possible values for a parameter but in some situations, it is necessary to shrink it. As an example, the parameter that defines the amount of CPU that a container can use (the cpu_limit ) might vary a lot depending on the underlying cluster and the application. If the cluster that hosts the application only contains nodes with up to 10 CPUs it might be worth limiting the domain of this parameter for the optimization study to that value to avoid failures when deploying the application and speed up the optimization process. If you forget to set this domain restriction Akamas will learn it by itself but it will need to try to deploy a container with a higher CPU limit to find out that that's not possible.

Constraints

In many situations, parameters have dependencies between each other. As an example, suppose you want to optimize at the same time the size of a container and the Java runtime that executes the application inside of it. Both layers have some parameters that affect how much memory can be used, for the container layer this parameter is called memory_limit and for the JVM is called jvm_heap_size. Configurations that have a jvm_heap_size value higher than the memory_limit might lead to out-of-memory errors.

You can define this relationship by specifying a constraint as in the example below:

parameterConstraints:
  - name: Heap should be lower than the container memory limit
    formula: container.memory_limit > jvm.jvm_heap_size + 50

These constraints instruct Akamas to avoid generating configurations that bring the jvm_heap_size parameter close to the memory_limit leaving a gap of 50Mb.

Constraints usually depend on the set of parameters chosen for the optimization. You can find more information about common constraints for the supported technologies in the documentation of the related optimization pack or the optimization guides.