In this guide you will make yourself familiar with Akamas' key concepts and UI.
There are no prerequisites for this guide.
As a preliminary introduction to Akamas watch a quick (2m) video included in the Welcome to Akamas guide.
In Akamas, a System is a single object that represents the entire system under optimization. A system is a single resource, irrespective of the number or type of entities and layers this IT system is structured on. A System is made of one or more Components. Each Component represents one of elements in the system whose parameters (see below) are involved in the optimization or whose metrics (see below) are collected to evaluate the results of such optimization.
The following figure shows how to visualize Systems from the Akamas UI.
A parameter is a property of the system that can be applied and tuned by Akamas. You can look at a parameter as a knob that Akamas can turn to achieve the defined optimization goal. In Akamas parameters are typically defined as the scope of an optimization study (see below).
The following figure shows the parameters of each system component as displayed in the Akamas UI (in the Summary tab of the study).
while the following figure shows detail of each parameter (in the Definition tab of the study).
A metric is a property of the system that can be measured (and collected by Akamas). You can look at a metric as a gauge that Akamas can monitor to assess the effectiveness of the applied configuration with respect to the defined goal of a study. In Akamas metrics are used to define and evaluate the optimization goal (e.g. minimize the heap size) and the optimization constraints (e.g. response time < 1000, error rate <= 10% of a baseline value).
The following figure shows how to visualize system metrics from the Akamas UI.
In Akamas, each Component represents one of the elements in the system to be modeled in an optimization study.
In general, a component will contain a set of each of the followings:
The following figure shows a system (an e-commerce application) with two associated components, representing the JVM and the web application service layer:
In Akamas, an Optimization Pack is a product extension that provides the knowledge needed to optimize a given technology using Akamas. Akamas provides a library of out-the-box optimization packs and new custom optimization packs can be easily added (no programming is required).
The following figure shows how to visualize Optimization Packs available in an Akamas installation.
An optimization pack encapsulates one or more of the following technology-specific elements:
An optimization pack enables Akamas users to optimize a technology without necessarily being an expert of 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.
For example, the following figure shows the out-of-the-box Web Application optimization pack describing the typical metrics (e.g.: response time, throughput or error rate, etc) associated with web-application component types.
In Akamas, a component type represents a specific type of component and, as such, it is linked to a specific set of metrics and parameters. Notice that in Akamas, in order to define a system component, there has to be an associated component type from which the component inherits its metrics and parameters.
Typically, different component types within the same optimization pack are used to model different versions/releases of the same technology. For example, the following figure shows the out-of-the-box JVM component types related to the JVM optimization pack.
In Akamas, a Telemetry Provider represents a data source of metrics. Examples of telemetry providers are monitoring tools (e.g. Prometheus or Dynatrace), load testing tools (e.g. LoadRunner or Neoload), or CSV files. A telemetry provider is a platform-wide entity that can be reused across systems to ease the integration with metrics sources. Telemetry providers can be either provided out-of-the-box by Akamas or created as custom telemetry providers.
The following figure shows how to visualize the telemetry providers available in an Akamas installation.
In Akamas, 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 following figure shows the configuration of a Prometheus telemetry instance (leveraging the out-of-the-box Prometheus telemetry provider).
and the associated metrics
The following figure shows the configuration of a CSV telemetry instance (leveraging the out-of-the-box CSV telemetry provider).
and the associated metrics
Each configuration that needs to be validated by Akamas in an optimization study is an experiment whose results are scored against the defined goal and constraint to guide Akamas AI to identify which configuration to consider next, thus allowing Akamas to find the optimal configuration without having to explore all the possible configurations.
The following figure represents the four phases executed for each experiment:
The first two phases of the experiment need to be defined by a workflow (see the following section) as they require interfacing with the target system, while the following two are automatically performed by Akamas as already defined by the telemetry instances and internal platform mechanisms.
In Akamas, a Workflow is a set of tasks that needs to be executed to evaluate a specific configuration via an experiment as part of an optimization study.
For example, the following figure shows a workflow for an e-commerce application (Konakart) structured on the following tasks:
Notice that both general-purpose (e.g. Executor and File Configurator) and native (e.g. NeoLoad) operators are used in the previous workflow.
Another example is provided by the following figure that illustrates a workflow defined to a Spark environment:
Notice that also in this workflow both general-purpose (e.g. Sleep) and native (e.g. SSHSparkSubmit) operators are used.
In Akamas, a Study is an optimization initiative aimed at optimizing a target system with respect to defined goal and constraints.
A study is defined by:
The following figure shows an example of an optimization study.
Akamas provides default values and domain boundaries for each parameter. Those values can be overridden in the study definition to match or better fulfill the system specs. Moreover, it is possible to define relationships between parameters (eg. heap size > new size for a JVM).
Actualizing and adapting the parameters to the specific characteristics of a system in a study is a best practice that can also accelerate Akamas' ability to identify the optimal configuration.
An Akamas study can include different steps. The most common are:
The following figure represents the typical two steps of a study, where the optimization step is based on 49 experiments in addition to the baseline.
A goal is defined by:
The following figure shows a goal defined as follows:
Another example is represented by the following figure:
Congratulations! You now have knowledge of Akamas' key concepts!
Here are a couple of next steps for you:
© Akamas Spa 2018-present. Akamas and the Akamas logo are registered trademarks of Akamas Spa.