This guide provides a Glossary describing Akamas key concepts with their associated construct templates, command line commands, and user interfaces.

This guide also provides references to:

• Construct templates

• Workflow Operators structure and operators

• metric mapping

• metrics and parameters

• to administer Akamas, manage users, authenticate and manage its resources

This section provides a definition of Akamas' key concepts and terms and also provides references to the related construct properties, commands, and user interfaces.

The Windowing field in a study specifies the windowing policy to be adopted to score the experiments of an optimization study.

The two available windowing strategies have different structures:

• Trim windowing: trim the temporal interval of a trial, both from the start and the end of a specified temporal amount - this is the default strategy

• : discard temporal intervals in which a given metric is not stable and selects the temporal interval in which a metric is maximized or minimized.

In case the windowing strategy is not specified, the entire time window is considered.

The MetricSelection field in a study specifies the metrics of the system. Such selection has only the purpose to specify which metrics need to be tracked while running the study and does not affect the optimization.

In case this selection is not specified, all metrics are considered.

A metrics selection can either assume the value of all to indicate that all the available metrics of the system of the study should be tracked, or can assume the value of a list of the names of metrics of the system that should be tracked prepended with the name of the component.

Example

The following fragment is an example:

A metric is a measured property of a system.

Examples of a metric include:

• the response time of an application

• the utilization of a CPU

A system represents of the entire system which is the target of optimization.

A system is a single object irrespective of the number or type of entities or layers that are in the scope of the optimization. It can be used to model and describe a wide set of entities like:

• An N-layers application

• A single micro-service

A telemetry provider is a software object that represents a data source of metrics. A is a specific instance of a telemetry provider that refers to a specific data source.

Examples of telemetry providers are:

• monitoring tools (e.g. Prometheus or Dynatrace)

• load testing tools (e.g. LoadRunner or Neoload)

Telemetry Providers are defined using a YAML manifest with the following structure:

with the following properties:

The workloadsSelection is a structure used to define the metrics that are used by Akamas to model workloads as part of a live optimization study.

with the following fields:

A component type is a blueprint for a component that describes the type of entity the component refers to. In Akamas, a component needs to be associated with a component type, from which the component inherits its metrics and parameters.

Component types are platform entities (i.e.: shared among all the users) usually provided off the shelf and shipped within the . Typically, different component types within the same optimization pack are used to model different versions/releases of the same technology.

Akamas' users with appropriate privileges can create custom component types and optimization packs, as described on the page.

The optimization goal defines the objective of an to be achieved by changing the system parameters to modify the system behavior while also satisfying any defined optimization constraints on the system metrics, possibly representing SLOs.

Construct

A goal is defined by:

A workspace is a virtual environment that groups systems, workflows, and studies to restrict user access to them: a user can access these resources only when granted the required permissions to that workspace.

Akamas defines two user roles according to the assigned permission on the workspace:

• Contributors (write permission) can create and manage workspace resources (studies, telemetry instances, systems, and workflows) and can also do exports/imports, view all global resources (Optimization Packs, and Telemetry Providers), and see remaining credits;

All operators accept some common, optional, arguments that allow you to control how the operator is executed within your workflow.

The following table reports all the arguments that can be used with any operator.

A telemetry instance is an instance of a that collects data from a specific instance of the data source.

A telemetry instance is an instance of a telemetry provider, providing the required information on how to connect and collect a given set of metrics from a specific data source.

While telemetry providers are platform-wide entities, telemetry instances are defined at each system level.

The DotNet optimization pack provides support for optimizing MS .Net applications.

Component Types

The following component types are supported for DotNet.

While Akamas leverages similar AI methods for both live optimizations and optimization studies, the way these methods are applied is radically different. Indeed, for optimization studies running in pre-production environments, the approach is to explore the configuration space by also accepting potential failed experiments, to identify regions that do not correspond to viable configurations. Of course, this approach cannot be accepted for live optimization running in production environments. For this purpose, Akamas live optimization uses observations of configuration changes combined with the automatic detection of workload contexts and provides several customizable safety policies when recommending configurations to be approved, revisited, and applied.

Akamas provides a few customizable optimizer options (refer to the options described on the Optimize step page of the reference guide) that should be configured so as to make configurations recommended in live optimization and applied to production environments as safe as possible.

Exploration factor

Akamas provides an optimizer option known as the exploration factor that only allows gradual changes to the parameters. This gradual optimization allows Akamas to observe how these changes impact the system behavior before applying the following gradual changes.

By properly configuring the optimizer, Akamas can gradually explore regions of the configuration space and slowly approach any potentially risky regions, thus avoiding recommending any configurations that may negatively impact the system. Gradual optimization takes into account the maximum recommended change for each parameter. This is defined as a percentage (default is 5%) with respect to the baseline value. For example, in the case of a container whose CPU limit is 1000 millicores, the corresponding maximum allowed change is 50 millicores. It is important to notice that this does not represent an absolute cap, as Akamas also takes into account any good configurations observed. For example, in the event of a traffic peak, Akamas would recommend a good configuration that was observed working fine for a similar workload in the past, even if the change is higher than 5% of the current configuration value.

Notice that this feature would not work for categorical parameters (e.g. JVM GC Type) as their values do not change incrementally. Therefore, when it comes to these parameters, Akamas by default takes a conservative approach of only recommending configurations with categorical parameters taking already observed before values. This still allows some never-observed values to be recommended as users are allowed to modify values also for categorical parameters when operating in human-in-the-loop mode. Once Akamas has observed that that specific configuration is working fine, the corresponding value can then be recommended. For example, a user might modify the recommended configuration for GC Type from Serial to Parallel. Once Parallel has been observed as working fine, Akamas would consider it for future recommendations of GC Type, while other values (e.g. G1) would not be considered until verified as safe recommendations.

The exploration factor can be customized for each live optimization individually and changed while live optimizations are running.

Safety factor

Akamas provides an optimizer option known as the safety factor designed to prevent Akamas from selecting configurations (even if slowly approaching them) that may impact the ability to match defined SLOs. For example, when optimizing container CPU limits, lower and lower CPU limits might be recommended, up to the point that the limit becomes too low that the application performance degrades.

Akamas takes into account the magnitude of constraint breaches: a severe breach is considered more negative than a minor breach. For example, in the case of an SLO of 200 ms on response time, a configuration causing a 1 sec response time is assigned a very different penalty than a configuration causing a 210 ms response time. Moreover, Akamas leverages the smart constraint evaluation feature that takes into account if a configuration is causing constraints to approach their corresponding thresholds. For example, in the case of an SLO of 200 ms on response time, a configuration changing response time from 170 ms to 190 ms is considered more problematic than one causing a change from 100 ms to 120 ms. The first one is considered by Akamas as corresponding to a gray area that should not be explored.

The safety factor is also used when starting the study in order to validate the behavior of the baseline to identify the safety of exploring configurations close to the baseline. If the baseline presents some constraint violations, then even exploring configurations close to the baseline might cause a risk. If Akamas identifies that, in the baseline configuration, more than (safety_factor*number_of_trials) manifest constraint violations then the optimization is stopped.

If your baseline has some trials failing constraint validation we suggest you analyze them before proceeding with the optimization

The safety factor is set by default to 0.5 and can be customized for each live optimization individually and changed while live optimizations are running.

Outlier detection

It is also worth mentioning that Akamas also features an outlier detection capability to compensate for production environments typically being noisy and much less stable than staging environments, thus displaying highly fluctuating performance metrics. As a consequence, constraints may fail from time to time, even for perfectly good configurations. This may be due to a variety of causes, such as shared infrastructure on the cloud, slowness of external systems, etc.

A component represents an element of a system. Typically, systems are made up of different entities and layers which can be modeled by components. In other words, a system can be considered a collection of related components.

Notice that a component is a black-box definition of each entity involved in an optimization study, so detailed modeling of the entities being involved in the optimization is not required. The only relevant elements are the parameters that are involved in the optimization and the metrics that are collected to evaluate the results of such an optimization.

Notice that only the entities that are directly involved in the optimization need to be modeled and defined within Akamas. An entity is involved in an optimization study if it is optimized or monitored by Akamas, where "optimized" means that Akamas is optimizing at least one of its parameters, and "monitored" means that Akamas is monitoring at least one of its metrics.

Construct

A component is described by the following mandatory properties (other properties can be defined but are not mandatory):

• a name that uniquely identifies the component within the system

• a description that clarifies what the component refers to

• a component type that identifies the technology of the component (see )

In general, a component contains a set of each of the following:

• parameter(s) in the scope of the optimization

• metric(s) needed to define the optimization goal

• metric(s) needed to define the optimization constraints

The construct to be used to define a component is described on the page.

Commands

A component is an that can be managed via CLI using the

User Interface

The Akamas UI shows more details about components by drilling down their respective system.

A workflow is a set of tasks that run in sequence to evaluate a configuration as part of an optimization study. A task is a single action performed within a workflow.

Workflows allow you to automate Akamas optimization studies, by automatically executing a sequence of tasks such as initializing an environment, triggering load testing, restoring a database, applying configurations, and much more.

These are examples of common tasks:

• Launch remote commands via SSH

• Apply parameter values in configuration files

• Execute Spark jobs via spark-submit API

• Start performance tests by integrating with external tools such as Neoload

Workflows are first-class entities that can be defined globally and then used in multiple optimization studies.

Akamas provides several that can be used to perform tasks in a workflow. Some operators are general-purpose, such as those executing a command or script on a specific host, while others provide native integrations with specific technologies and tools, such as Spark History Server or load testing tools.

Construct

The construct to be used to define a workflow is described on the page.

Commands

A telemetry provider is an that can be managed via CLI using the

User Interface

The Akamas UI shows systems in a specific top-level menu.

The list of tasks is displayed when drilling down to each specific workflow.

A windowing policy of type trim trims the temporal interval of a trial, both from the start and from the end of a specified temporal amount (e.g., 3 seconds).

The trim windowing has the following structure:

In case a windowing policy is not specified, the default windowing corresponding to trim[0s,0s] is considered.

Example

The following fragment shows a windowing strategy of type "trim" where the time window is specified to start 10s after the beginning of the trial and to end immediately before the end of the trial:

An optimization study (or study for short) represents an optimization initiative aimed at optimizing a goal on a target system. A study instructs Akamas about the space to explore and the KPIs used to evaluate whether a con configuration is good or bad

Akamas supports two types of optimizations:

• Offline Optimization Studies are optimization studies where the workload is simulated by leveraging a load-testing tool.

• are applied to systems that need to be optimized in production with respect to varying workloads observed while running live. For example, a microservices application can be optimized live by having Kubernetes and JVM parameters dynamically tuned for multiple microservices so as to minimize costs while matching response time objectives.

Construct

A study is described by the following properties

• system: the under optimization

• parameters: the set of being optimized

• metrics: the set of to be collected

The construct to be used to define an optimization is described on the page.

Commands

An optimization study is an that can be managed via CLI using the

User Interface

The Akamas UI shows optimization studies in 2 specific top-level menus: one for offline optimization studies and another for live optimization studies.

Components are defined using a YAML manifest with the following structure:

and properties:

Examples

Example of a component for OpenJDK11:

Example of a component for the Linux operating system:

The ParameterSelection field in a study specifies which parameters of the system should be tuned while running the optimization study.

In case this selection is not specified, all parameters are considered.

A parameter selection can either assume the value of all to indicate that all the available parameters of the system of the study should be tuned, or can assume the value of a list with items of the shape like the one below:

Notice that, by default, every parameter specified in the parameters selection of a study is applied. This can be modified, by leveraging the options.

Example

The following fragment is an example:

A KPI is a metric that is worth considering when analyzing the result of an offline optimization study, looking for (sub)optimal configurations generated by Akamas AI to be applied.

Akamas automatically considers any metric referred to in the defined optimization goal and constraints for an offline optimization study as a KPI. Moreover, any other metrics of the system component can be specified as a KPI for an offline optimization study.

Construct

A KPI is defined as follows (from the UI or the CLI):

KPIs are not an as they are defined as part of an optimization study. The construct to define KPIs is described on the page of the section.

Commands

KPIs are not an and are always defined as part of an optimization study.

User Interface

The number and first KPIs are displayed in the Akamas UI in the header of each offline optimization study.

The full list of KPIs is displayed by drilling down to the KPIs section.

From this section, it is possible to modify the list of KPIs and change their names and other attributes.

An optimization pack is a software object that provides a convenient facility for encapsulating all the knowledge (e.g. metrics, parameters with their default values and domain ranges) required to apply Akamas optimizations to a set of entities associated with the same technology.

Notice that while optimization packs are very convenient for modeling systems and creating studies, it is not required for these entities to be covered by an optimization pack.

Akamas provides a library of out-the-box optimization packs and new custom optimization packs can be easily added (no coding is required).

Construct

An optimization pack needs to include the entities that encapsulate technology-specific information related to the supported component types:

• supported component types

• parameters and metrics for each component type

• supported telemetry providers (optional)

Commands

An optimization pack is an that can be managed via CLI using the

User Interface

The Akamas UI shows systems in a specific top-level menu.

An optimization pack encapsulates one or more of the following technology-specific elements:

• Component Types: these represent the type of the component(s) included, each with its associated parameters and metrics

• Telemetry Providers: that define where to collect metrics

An optimization pack enables Akamas users to optimize a technology without necessarily being an expert in that technology and to code their knowledge about a technology or a specific application to be reused in multiple optimization studies to ease the modeling process.

The Steps field in a study specifies the sequence of steps executed while running the study. These steps are run in exactly the same order in which they will be executed.

The following types of steps are available:

• Baseline: performs an experiment and sets it as a baseline for all the other ones

• : imports experiments from other studies

• : performs an experiment with a specific configuration

• : performs experiments and generates optimized configurations

Notice that the structure corresponding to the steps is different for the different types of steps.

The Sleep operator pauses a workflow for a given amount of time.

Operator arguments

Examples

Pause a workflow for 30 seconds

The Web Application optimization pack provides a component type apt for monitoring the performances from the end-user perspective of a generic web application, to evaluate the configuration of the technologies in the underlying stack.

The bundled component type provides Akamas with performance metrics representing concepts like throughput, response time, error rate, and user load, split into different levels of detail such as transaction, page, and single request.

Component Types

Installing

Here’s the command to install the Web Application optimization pack using the Akamas CLI:

The Node JS optimization pack enables the ability to optimize applications based on Node running in V8.

The following component types are supported for NodeJS applications.

Installing

Here’s the command to install the Node JS optimization pack using the Akamas CLI:

For more information on the process of installing or upgrading an optimization pack refer to .

The Cassandra optimization pack provides support for optimizing WebSphere middleware.

Component Types

The following component types are supported for WebSphere middleware.

Installing

Here’s the command to install the WebSphere optimization pack using the Akamas CLI:

This page describes the Optimization Pack for the Kubernetes Namespace component type.

Metrics

Parameters

There are no parameters for the Kubernetes Namespace component type.

The NodeJS optimization pack provides support for optimizing Docker containers.

Component Types

The following component types are supported for Docker.

Installing

Here’s the command to install the Docker optimization pack using the Akamas CLI:

The renderParameters and doNotRenderParameters can be used to specify which configuration parameters should be rendered when doing experiments within a step.

Parameter rendering can be defined at the step level for baseline, preset, and optimize steps. This is not possible for bootstrap steps as bootstrapped experiments are not executed.

The Java-OpenJDK optimization pack enables the ability to optimize Java applications based on the OpenJDK and Oracle HotSpot JVM. Through this optimization pack, Akamas is able to tackle the problem of performance of JVM-based applications from both the point of view of cost savings and quality of service.

To achieve these goals the optimization pack provides parameters that focus on the following areas:

• Garbage collection

The OpenJ9 optimization pack enables the ability to optimize Java applications based on the Eclipse OpenJ9 VM, formerly known as IBM J9. Through this optimization pack, Akamas is able to tackle the problem of performance of JVM-based applications from both the point of view of cost savings and quality of service.

To achieve these goals the optimization pack provides parameters that focus on the following areas:

• Garbage collection

This page describes the Optimization Pack for the Kubernetes Cluster component type.

Metrics

This page describes the Optimization Pack for the Kubernetes Pod component type.

Metrics

The Kubernetes optimization pack allows optimizing containerized applications running on a Kubernetes cluster. Through this optimization pack, Akamas is able to tackle the problem of distributing resources to containerized applications in order to minimize waste and ensure the quality of service.

To achieve these goals the optimization pack provides parameters that focus on the following areas:

• Memory allocation

This section documents the mapping between the metrics provided by Telemetry Providers and the Akamas metrics for each supported component type.

The Go optimization pack provides support for optimizing Go applications.

Component Types

The following component types are supported for Go applications.

Systems are defined using a YAML manifest with the following structure:

with the following properties:

Telemetry instances are defined using a YAML manifest with the following structure:

with the following properties for the global section

and the metrics section

This section documents the out-of-the-box workflow operators.

The kpis field in a study specifies which metrics should be considered as KPI for an offline optimization study.

In case this selection is not specified, all metrics mentioned in the goal and constraint of the optimization study are considered.

A KPI is defined as follows:

Notice that the textual badge displayed in the Akamas UI use "Best name".

Example

The following fragment is an example of a list of KPIs:

This section describes all the structures that can be used to define resources and objects in Akamas.

A baseline step performs an experiment (a baseline experiment) and marks it as the initial experiment of a study. The purpose of the step is to build a reference configuration that Akamas can use to measure the effectiveness of an optimization conducted towards a system.

When a bootstrap step imports an experiment from another study, the step copies not only the experiment but also its trials and the system metrics generated during its execution.

The bootstrap step has the following structure:

where the from field should have the following structure:

with:

• study contains the name or ID of the study from which to import experiments

• experiments contains the numbers of the experiments from which to import

Examples

The following is an example of a bootstrap step that imports four experiments from two studies:

You can also import all the experiments of a study by omitting the experiments field:

This page describes the Optimization Pack for the Kubernetes Workload component type.

Metrics

Parameters

A parameter is a property of the system that can be applied and tuned to change the system's behavior. Akamas optimizes systems by changing parameters to achieve the stated while respecting the defined .

Examples of a parameter include:

• Configuration knobs (e.g. JVM garbage collection type)

Parameters are defined using a YAML manifest with the following structure:

with the following properties:

A baseline step performs an experiment (a baseline experiment) and marks it as the initial experiment of a study. The purpose of the step is to build a reference configuration that Akamas can use to measure the effectiveness of an optimization conducted towards a system.

A baseline step offers three options when it comes to selecting the configuration of the baseline experiment:

• Use a configuration made with the default values of the parameters taken from the system of the study

An optimize step generates optimized configurations according to the defined optimization strategy. During this step, Akamas AI is used to generate such optimized configurations.

The optimize step has the following structure:

Workflow are defined using a YAML manifest with the following structure:

with the following properties:

The Linux optimization pack helps you optimize Linux-based systems. The optimization pack provides component types for various Linux distributions, thus enabling performance improvements on a plethora of different configurations.

Through this optimization pack, Akamas is able to tackle the problem of performance of Linux-based systems from both the point of you of cost savings, as well as quality and level of service: the included component types bring in parameters that act on the memory footprint of systems, on their ability to sustain higher levels of traffic, on their capacity of leveraging all the available resources and on their potential for lower latency transactions.

Each component type providers parameters that cover four main areas of tuning:

• CPU tasks scheduling (for example, if to auto-group and schedule together similar tasks)

This page describes the mapping between metrics provided by Load Runner to Akamas metrics for each supported component type.

Web Application

This section documents Akamas out-of-the-box optimization packs.

A preset step performs a single experiment with a specific configuration. The purpose of this step is to help you quickly understand how good is a particular configuration.

A preset step offers two options when selecting the configuration of the experiment to be executed:

• Use a configuration taken from an experiment of a study (can be the same study)

• Use a custom configuration

The preset step has the following structure:

where the from field should have the following structure:

with

• study contains the name or ID of the study from which to take the configuration. In the case this is omitted, the same study of the step is considered for experiments from which taking configurations

• experiments contains the number of the experiment from which to take the configuration

Examples

Custom configuration

You can provide a custom configuration by setting values:

Configuration from another study

You can select a configuration taken from another study by setting from:

Configuration from the same study

You can select a configuration taken from the same study by setting from but by omitting the study field:

Notice: the from and experiments fields are defined as a list, but can only contain one element.

This page describes the Optimization Pack for Web Applications.

Metrics

Performance metrics

Error metrics

Load metrics

Parameters

There are no parameters for Web Applications.

This page describes the Optimization Pack for the component type Go 1.

Metrics

Parameters

A windowing policy of type stability discards temporal intervals in which a given metric is not stable, and selects, among the remaining intervals, the ones in which another target metric is maximized or minimized. Stability windowing can be sample-based or time-frame based.

The stability windowing has the following structure:

This page describes the Optimization Pack for the component type (Docker) Container.

Metrics