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.

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 single (or a collection of) batch job(s)

A System is made of one or more . Each component represents one of the elements in the system, whose are involved in the optimization or whose are collected to evaluate the results of such optimization.

Construct

A system is described by the following properties:

• The full micro-services stack of an application

• a name that uniquely identifies the system

• a description that clarifies what the system refers to

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

Commands

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

User Interface

The Akamas UI displays systems (depending on the user privileges on the defined ) in a specific top-level menu.

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 Optimization Packs. 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 Creating custom optimization pack page.

Construct

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

• a name that uniquely identifies the component type within the system

• a description that clarifies what the component type refers to

• a parameter definitions array (more on Parameters later)

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

Commands

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

User Interface

When visualizing system components the component type is displayed.

The following figure shows the out-of-the-box JVM component types related to the JVM optimization pack.

A telemetry provider is a software object that represents a data source of metrics. A telemetry instance 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)

• CSV files

A telemetry provider is a platform-wide entity that can be reused across systems to ease the integration with metrics sources.

Akamas provides a number of out-of-the-box . Custom telemetry providers can also be created.

Construct

The construct to be used to define a telemetry provider 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.

A telemetry instance is an instance of a telemetry provider 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.

Construct

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

Commands

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

User Interface

Telemetry instances are displayed in the Akamas UI when drilling down each system component.

The optimization goal defines the objective of an optimization study 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:

• an optimization objective: either maximize or minimize

• a scoring function (scalar): either a single metric or a formula defined by one or more metrics

One or more constraints can be associated with a goal

• a formula defined on one or more metrics, referring to either absolute values (absolute constraints) or relative to a baseline value (relative constraints)

Notice that relative constraints are only supported by while absolute constraints are supported by both offline and .

Goals and constraints are not an as they are defined as part of an optimization study. The construct to be used to define a goal and its constraints are described in the page of the section.

Commands

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

User Interface

Goals and constraints are displayed in the Akamas UI when drilling down each optimization study.

The detail of the formula used to define the goal may also be displayed:

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;

• Viewers (read permission) can only access optimization results but cannot create or modify workspace resources.

Workspaces and accesses are managed by users with administrative privileges. A user with administrator privileges can manage licenses, users, workspaces, and install/deinstall Optimization Packs, and Telemetry Providers.

Workspaces can be defined according to different criteria, such as:

• By department (e.g. Performance, Development)

• By initiative (e.g. Poc, Training)

• By application (e.g. Registry, Banking..)

A workspace is described by the following property:

• a name that uniquely identifies the workspace

Commands

A workspace is an that can be managed via CLI using the See also this page devoted to commands on .

User Interface

The workspace a study belongs to is always displayed. Filters can be used to select only studies belonging to specific workspaces

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 component represents an element of a . 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 that are involved in the optimization and the 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.

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):

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

with the following properties:

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

Operator arguments

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

with the following properties:

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:

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

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).

The NodeJS optimization pack provides support for optimizing Docker containers.

Component Types

The following component types are supported for Docker.

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.

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 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.

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

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

• Heap

• JIT

Similarly, the bundled metrics provide visibility on the following aspects of tuned applications:

• Heap and memory utilization

• Garbage collection

• Execution threads

Component Types

The optimization pack supports the most used versions of OpenJDK and Oracle HotSpot JVM.

Installing

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

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

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 workloadsSelection is a structure used to define the metrics that are used by Akamas to model workloads as part of a live optimization study.

workloadsSelection:
  - name: component1.metric1
  - name: component2.metric2:p95

with the following fields:

Notice that workload metrics must have been defined in the metricsSelection. Variables used in the name field can include an aggregation. The following aggregations are available: avg, min, max, sum, p90, p95, p99.

Examples

The following refers to a workload represented by the metric transactions_throughput of the konakart component with multiple aggregations:

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.

The Go optimization pack provides support for optimizing Go applications.

Component Types

The following component types are supported for Go applications.

Installing

Here’s the command to install the Go 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 .

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 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:

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)

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:

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

Metrics

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:

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.

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

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 page describes the Optimization Pack for the Kubernetes Cluster component type.

Metrics

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

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 page describes the Optimization Pack for the Kubernetes Workload component type.

Metrics

Parameters

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

• Heap

• JIT

Similarly, the bundled metrics provide visibility on the following aspects of tuned applications:

• Heap and memory utilization

• Garbage Collection

• Execution threads

Component Types

The optimization pack supports the most used versions of JVM.

Installing

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

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

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

Component Types

The following component types are supported for DotNet.

Installing

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

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

with the following properties:

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:

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

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

Parameters 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 section documents the out-of-the-box workflow operators.

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

with the following properties for the global section

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

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

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

Web Application

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

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:

The SparkLivy operator uses Livy to run Spark applications on a Spark instance.

Operator arguments