Akamas is the AI-powered optimization platform designed to maximize service quality and cost efficiency without compromising on application performance. Akamas supports both production environments under live, dynamic workloads, and in test/pre-production environments against any what-if scenario and workload.

Thanks to Akamas, performance engineers, DevOps, CloudOps, FinOps and SRE teams can keep complex applications, such as Kubernetes microservices applications, optimized to avoid any unnecessary cost and any performance risks.

Akamas Optimization platform

The Akamas optimization platform leverages patented AI techniques that can autonomously identify optimal full-stack configurations driven by any custom-defined goals and constraints (SLOs), without any human intervention, any agents, and any code or byte-code changes.

Akamas optimal configurations can be applied either i) under human approval (human-in-the-loop mode) or ii) automatically, as a continuous optimization step in a CI/CD pipeline (in-the-pipe) or iii) autonomously by Akamas (autopilot).

Akamas coverage

Akamas can optimize any system with respect to any set of parameters chosen from the application, middleware, database, cloud, and any other underlying layers.

Akamas provides dozens of out-of-the-box Optimization Packs available for key technologies such as JVM, Go, Kubernetes, Docker, Oracle, MongoDB, ElasticSearch, PostgreSQL, Spark, AWS EC2 and Lambda, and more. Optimization Pack provides parameters, relationships, and metrics to accelerate the optimization process setup and support company-wide best practices. Custom Optimization Packs can be easily created without any coding.

The following figure is illustrative of Akamas coverage for both managed technologies and integrated components of the ecosystem.

Akamas integrations

Akamas can integrate with any ecosystem thanks to out-of-the-box and custom integrations with the following components:

• telemetry & monitoring tools and other sources of KPIs and cost data, such as Dynatrace, Prometheus, CloudWatch, and CSV files

• configuration management tools, repositories and interfaces to apply configurations, such as Ansible, Openshift, and Git

• value stream delivery tools to support a continuous optimization process, such as Jenkins, Dynatrace Cloud Automation, and GitLab

• load testing tools to generate simulated workloads in test/pre-production, such as LoadRunner, NeoLoad, and JMeter

Akamas has been designed around Infrastructure-as-Code (IaC) and DevOps principles. Thanks to a comprehensive set of APIs and integration mechanisms, it is possible to extend the Akamas optimization platform to manage any system and integrate with any ecosystem.

Use Cases

Akamas optimization platform supports a variety of use cases, including:

• Improve Service Quality: optimize application performance (e.g. maximize throughput, minimize response time and job execution time) and stability (lower fluctuations and peaks);

• Increase Business Agility: identify resource bottlenecks in early stages of the delivery cycle, avoid delays due to manual remediations - release higher quality services and reduce production incidents;

• Increase Service Resilience: improve service resilience under higher workloads (e.g. expected business growth) or failure scenarios identified by chaos engineering practices - improve SRE practice;

• Reduce IT Cost / Cloud Bill: reduce on-premise infrastructure cost and cloud bills due to resource over-provisioning - improve cost efficiency of Kubernetes microservices applications;

• Optimize Cloud Migration: safely migrate on-premise applications to cloud environments for optimal cost efficiency evaluate options to migrate to managed services (e.g. AWS Fargate);

• Improve Operational Efficiency: save engineering time spent on manual tuning tasks and enable Performance Engineering teams to do more in less time (and with less external consulting).

This guide introduces Akamas and covers various fundamental topics such as licensing and deployment models, security topics, and maintenance & support services.

Software Licenses

Maintenance & Support Services

Other billable services

Akamas takes security seriously and provides enterprise-grade software where customer data is kept safe at all times. This page describes some of the most important security aspects of Akamas software and information related to processes and tools used by the Akamas company (Akamas S.p.A) to develop its software products.

Information managed by Akamas

Akamas manages the following types of information:

• System configuration and performance metrics: technical data related to optimized systems. Examples of such data include the number of CPUs available in a virtual machine or the memory usage of a Java application server;

• User accounts: accounts assigned to users to securely access the Akamas platform. For each user account, Akamas currently requires an account name and a password. Akamas does not collect any other personal identifying information;

• Service Credentials: credentials used by Akamas to automate manual tasks and to integrate with external tools. In particular, Akamas leverages the following types of interaction:

  • Integration with monitoring and orchestration tools, e.g., collecting IT performance metrics and system configuration. As a best practice, Akamas recommends using dedicated service accounts with minimal read-only privileges.

  • Integration with the target systems to apply changes to configuration parameters. As a best practice, Akamas recommends using dedicated service accounts with minimal privileges to read/write identified parameters.

GDPR Compliance

Akamas is a fully GDPR-compliant product.

Akamas is a company owned by the Moviri Group. The Moviri Group and all its companies are fully compliant with GDPR. Moviri Group Data Privacy Policy and Data Breach Incident Response Plan which apply to all the owned companies can be requested from Akamas Customer Support.

Security certifications

Akamas is an on-premises product and does not transmit any data outside the customer network. Considering the kind of data that is managed within Akamas (see section "Which information is managed by Akamas"), specific security certifications like PCI or HIPAA are not required as the platform does not manage payment or health-related information.

Data encryption

Akamas takes the need for security seriously and understands the importance of encrypting data to keep it safe at rest and in-flight.

In-Flight encryption

All the communications between Akamas UI and CLI and the back-end services are encrypted via HTTPS. The customer can configure Akamas to use customer-provided SSL certificates in all communications.

Communications between Akamas services and other integrated tools within the customer network rely on the security configuration requirements of the integrated tool (e.g.: HTTPS calls to interact with REST services).

At-Rest encryption

Akamas is an on-premises product and runs on dedicated virtual machines within the customer environment. At-rest encryption can be achieved following customer policies and best practices, for example, leveraging operating system-level techniques.

Akamas also provides an application-level encryption layer aimed at extending the scope of at-rest encryption. With this increased level of security, sensitive data managed by Akamas (e.g. passwords, tokens, or keys required to interact with external systems) are safely stored in Akamas databases using industry-standard AES 256-bit encryption.

Encryption option for Akamas on EC2

In the case of Akamas hosted on an AWS machine you may optionally create an EC2 instance with an encrypted EBS volume before installing OS and Akamas, to achieve a higher level of security.

Password management

Password Security

Passwords are securely stored using a one-way hash algorithm.

Password complexity

Akamas comes with a default password policy with the following requirements:

• has a minimum length of 8 characters.

• contains at least 1 uppercase and 1 lowercase character.

• contains at least 1 special character.

• is different from the username.

• must be different from the last password set.

Customers can modify this policy by providing a custom one that matches their internal security policies.

Password rotation

Akamas enforces no password rotation mechanism.

Credential storage

• When running on a Linux installation with KDE's KWallet enabled or GNOME's Keyring enabled, the credentials will be stored in the default wallet/keyring.

• When running on Windows, the credentials will be stored in Windows Credential Locker.

• When running on a macOS, the credential will be stored in Keychain.

• When running on a Linux headless installation, the credentials will be stored in CLEAR TEXT in a file in the current Akamas configuration folder.

Resources visibility model

Akamas provides fine granularity control over resources managed within the platform. In particular, Akamas features two kinds of resources:

• Workspace resources: entities bound to one of the isolated virtual environments (named workspaces) that can only be accessed in reading or writing mode by users to whom the administrators explicitly granted the required privileges. Such resources typically include sensitive data (e.g.: passwords, API tokens). Examples of such resources include the system to be optimized, the set of configurations, optimization studies, etc.

• Shared resources: entities that can be installed and updated by administrators and are available to all Akamas users. Such resources only contain technology-related information (e.g.: the set of performance metrics for a Java application server). Examples of such resources include Optimization Packs, which are libraries of technology components that Akamas can optimize, such as a Java application server.

Akamas Logs

Akamas logs traffic from UI and APIs. Application level logs include user access via APIs and UI and any action taken by Akamas on integrated systems.

Akamas' logs are retained on the dedicated virtual machine within the customer environment, by default, for 7 days. The retention period can be configured according to customer policies. Logs can be accessed either via UI or via log dump within the retention period. Additionally, logs have a format that can be easily integrated with external systems like log engines and SIEM to support forensic analysis.

Code scanning policy

Akamas is developed according to security best practices and the code is scanned regularly (at least daily).

The Akamas development process leverages modern continuous integration approaches and the development pipeline includes SonarQube, a leading security scanning product that includes comprehensive support for established security standards including CWE, SANS, and OWASP. Code scanning is automatically triggered in case of a new build, a release, and every night.

Vulnerability scanning and patch management policy

Akamas features modern micro-service architecture and is delivered as a set of docker containers whose images are hosted on a private Elastic Container Registry (ECR) repository on the AWS cloud. Akamas leverages the vulnerability scanning capabilities of AWS ECR to identify vulnerabilities within the product container images. AWS ECR uses the Common Vulnerabilities and Exposures (CVEs) database from the open-source Clair project.

If a vulnerability is detected, Akamas will perform a security assessment of the security risk in terms of the impact of the vulnerability, and evaluate the necessary steps (e.g.: dependency updates) required to fix the vulnerability within a timeline related to the outcome of the security assessment.

After the assessment, the vulnerability can be fixed by either recommending the upgrade to a new product version or delivering a patch or a hotfix for the current version.

Akamas is an on-premise product running on a dedicated machine within the customer environment:

• on a virtual or physical machine in your data center

• on a virtual machine managed running on a cloud, by any cloud provider (e.g. AWS EC2)

• on your own laptop

Akamas Customer Support Services are delivered by Akamas support engineers, also called Support Agents, who will work remotely with Customer to provide a temporary remedy for the incident and, ultimately, a permanent resolution. Akamas Support Agents automatically escalate issues to the appropriate technical group within Akamas and notify Customers of any relevant progress. Akamas provides Customers with the ability to escalate issues when appropriate.

Please notice that Customer Support services are not to be considered as alternatives to product documentation and training, or to professional and consulting services, so adequate knowledge of Akamas products is assumed when interacting with Akamas Customer Support. Thus, during the resolution of a reported issue Support Agents may redirect Customer to training or professional services (that are not part of the scope of this service).

Akamas offers a Free Trial option to quickly understand Akamas concepts and capabilities and experience the power of its AI-based optimization platform.

You can join Akamas Free Trial quickly:

2. Receive credentials to access your dedicated Akamas server (a cloud instance on AWS EC2) - optimally you can also download & install the Akamas CLI and learn how to fully automate the optimization process;

What you will get:

• Understand the Akamas methodology

• See Akamas AI-powered optimization in action

• Learn to use Akamas by following the how-to guides

• Familiarize yourself with Akamas UI and CLI

• Touch the benefits Akamas can deliver to your organization

Enjoy!

This page is intended as a first introduction to Akamas Maintenance & Support (M&S) Services.

Please refer to the specific contract in place with your Company.

Akamas M&S Services include:

Akamas M&S Services do not include any installation and upgrade services, creation of any custom optimization packs, telemetry providers, or workflow operators, or implementation of any custom features and integrations that are not provided out-of-the-box by the Akamas products.

Refer to your Cloud Provider website for information about cloud hosting options and related cost information.

AWS EC2

Akamas is based on a microservices architecture where each service is deployed as a container and communicates with other services via REST APIs. Akamas can be deployed on a dedicated machine (Akamas Server) or on a Kubernetes cluster.

The following figure represents the high-level Akamas architecture.

Interact with Akamas

Users can interact with Akamas via either the Graphical User Interface (GUI), Command-Line Interface (CLI), or via Application Programmatic Interface (API).

Both the GUI and CLI leverage HTTP/S APIs which pass through an API gateway (based on Kong), which also takes care of authenticating users by interacting with Akamas access management and routing requests to the different services.

The Akamas CLI can be invoked on either the Akamas Server itself or on a different machine (e.g. a laptop or another server) where the Akamas CLI has been installed.

Repositories

Akamas data is securely stored in different databases:

• time series data gathered from telemetry providers are stored in Elasticsearch;

• application logs are also stored in Elasticsearch;

• data related to systems, studies, workflows, and other user-provided data are stored in a Postgres database.

Notice: both Postgres and Elasticsearch and any other service included within Akamas are provided by Akamas as part of the Akamas installation package.

Services

Core Services

The following Spring-based microservices represent Akamas core services:

• System Service: holds information about metrics, parameters, and systems that are being optimized

• Campaign Service: holds information about optimization studies, including configurations and experiments

• Metrics Service: stores raw performance metrics (in Elasticsearch)

• Analyzer Service: automates the analysis of load tests and provides related functionalities such as smart windowing

• Telemetry Service: takes care of integrating different data sources by supporting multiple Telemetry Providers

• Optimizer Service: combines different optimization engines to generate optimized configurations using ML techniques

• Orchestrator Service: manages the execution of user-defined workflows to drive load tests

• User Service: takes care of user management activities such as user creation or password changes

• License Service: takes care of license management activities, optimization pack, and study export.

Ancillary Services

Akamas also provides advanced management features like logging, self-monitoring, licensing, user management, and more.

Different levels of support are provided for software versions of Akamas products, starting from its general availability (GA) date, and depending on the release of following software versions.

Version Numbering

Akamas adopts a three-place numbering scheme MA.MI.SP to designate released versions of its Software, where:

• MA is the Major Version

• MI is the Minor Version

• SP is the Service Pack or Patch number

Support levels

The following table describes the three levels of support for a software version.

End-of-Life (EOL)

At any time, Akamas reserves the right to "end of life" (EOL) a software product and to terminate any Maintenance & Support Services for such product, provided that Licensor has notified the Licensee at least 12 months prior to the above-mentioned termination.

The period of time occurring between the "end of life" notification and the actual termination of Maintenance & Support Services is provided as follows:

• No new enhancements will be introduced.

• No enhancements will be made to support new or updated versions of the platform on which the product runs or which it integrates.

• New hotfixes for problems of high technical impact or business exposure for customers may still be developed. Based on customer input, Akamas Support Agents will determine the degree of impact and exposure and the consequent activities.

• Reasonable efforts will be done to inform the Customer of any fixes, service packs, patches, or workarounds applicable to the reported case if any.

Akamas Customer Support Services provides different standard levels of support. Please verify the level of support specified in the contract in place with your Company.

Severity levels

The following table describes the different severity levels for Customer Support.

Support conditions

The contract in place with the Customer specifies the level of support provided by Akamas Agents, according at least to the following items:

• Maximum number of support seats: this is the maximum number of named users within the Customer organization who can request Akamas Customer Support.

• Language(s): these are the languages that can be used for interacting with Akamas Support Agents - the default is English.

• Channel(s): these are the different communication channels that can be used to interact with Akamas Agents - these may include one or more options among web ticketing, email, phone, and Slack channel.

• Max Initial Response Time: this refers to the time interval occurring from the time a request is opened by Customer to Customer Support and the time a Support Agent responds with a first notification (acknowledgment).

• Severity: this is the level of severity associated with a reported issue, which initially corresponds to the severity level originally indicated by the Customer. Notice that the severity level may change, for example as new information becomes available or if Support Agents and Customer agree to re-evaluate it. Please notice that the severity level may be downgraded by Support Agents if Customer is not able to provide adequate resources or responses to enable Akamas to continue with its resolution efforts.

• Initial Remedy: this refers to any operation aimed at addressing a reported issue by restoring a minimal level of operations, even if it may cause some performance degradation of the Customer service or operations. A workaround is to be considered a valid Initial Remedy.

Please notice that Support Agents may refuse to serve a service request to Customer Support either in case Customer does not have a valid Maintenance & Support subscription or in case the above-mentioned conditions or other conditions stated in the contract in place are not met. In any case, the Customer is expected to provide all the information required by Support Agent in order to serve service requests Customer Support.

Before installing the Akamas Server please make sure to review all the following requirements:

Running in your data center

The following table provides the minimal hardware requirements for the virtual or physical machine used to install the Akamas server in your data center.

Running on AWS EC2

As shown in the following diagram, you can create the Akamas instance in the same AWS region, Virtual Private Cloud (VPC), and private subnet as your own already existing EC2 machines and by creating/configuring a new security group that allows communication between your application instances and Akamas instance. The inbound/outbound rules of this security group must be configured as explained in the Networking Requirements section of this page.

It is recommended to use an m6a.xlarge instance with at least 70GB of disks of type GP2 or GP3 and select the latest LTS version of Ubuntu.

Supported AWS Regions

Akamas can be run in any EC2 region.

AWS Service Limits

Operating System

The following table provides a list of the supported operating systems and their versions.

On RHEL systems Akamas containers might need to be run in privileged mode depending on how Docker was installed on the system.

Software packages

The following table provides a list of the required Software Packages (also referred to as Akamas dependencies) together with their versions.

The exact version of these prerequisites is listed in the following table:

Akamas user

To install and run Akamas it is recommended to create a dedicated user (usually "akamas"). The Akamas user is not required to be in the sudoers list but can be added to the docker (dockeroot) group so it can run docker and docker-compose commands.

Make sure that the Akamas user has the read, write, and execute permissions on /tmp. If your environment does not allow writing to the whole /tmp folder, please create a folder /tmp/build and assign read and write permission to the Akamas user on that folder.

Preliminary steps

Before installing Akamas, please follow these steps:

Installation steps

Please follow these steps to install the Akamas Server:

While some links to official documentation and installation resources are provided here, please make sure to refer to your internal system engineering department to ensure that your company deployment processes and best practices are correctly matched.

Dependencies Setup

As a preliminary step before installing any dependency, it is strongly suggested to create a user named akamas on your machine hosting Akamas Server.

Docker

Follow the reference documentation to install docker on your system.

Verify dependencies

As a quick check to verify that all dependencies have been correctly installed, you can run the following commands

• Docker:

  Copy

  docker run hello-world

• Docker compose :

  Copy

  docker compose --version

• AWS CLI:

  Copy

  aws --version

Akamas is deployed as a set of containerized services running on Docker and managed via Docker Compose. In the online installation mode, the latest version of the Akamas Docker Compose file and all the images required by Docker can be downloaded from the AWS ECR repository.

Get Akamas Docker artifacts

It is suggested first to create a directory akamas in the home directory of your user, and then run the following command to get the latest compose file:

cd ~
mkdir akamas
cd akamas
curl -O https://s3.us-east-2.amazonaws.com/akamas/compose/3.4.0/docker-compose.yml

Configure Akamas environment variables

To login into AWS ECR and pull the most recent Akamas container images you also need to set the AWS authentication variables to the appropriate values provided by Akamas Customer Support Services by running the following command. To configure Akamas, you should set the following environment variables:

To configure Akamas, you should set the following environment variables:

• AKAMAS_CUSTOMER: the customer name matching the one referenced in the Akamas license.

• AWS_ACCESS_KEY_ID: the access key for pulling the Akamas images

• AWS_SECRET_ACCESS_KEY: the secret access key for pulling the Akamas images

• AWS_DEFAULT_REGION: Unless specified by the support team keep the value to us-east-2

• AKAMAS_BASE_URL: the endpoint in the Akamas APIs that will be used to interact with the CLI, typically https://<akamas server DNS address>

To avoid losing your environment variables for future upgrades, it is suggested to keep them in the .env file. Launch the following command from the same folder where the docker-compose.yml is stored, replacing the parameters in the brackets <>:

# Required variables
AKAMAS_CUSTOMER=<your name or your organization name>
AWS_ACCESS_KEY_ID=<your access key id>
AWS_SECRET_ACCESS_KEY=<your secret access key>
AKAMAS_BASE_URL=https://<akamas server DNS address>
AWS_DEFAULT_REGION=us-east-2

# Optional variables
# Database passwords
DEFAULT_DATABASE_PASSWORD=
KEYCLOAK_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_keycloak}
ANALYZER_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_analyzer}
CAMPAIGN_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_campaign}
LICENSE_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_license}
OPTIMIZER_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_optimizer}
ORCHESTRATOR_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_orchestrator}
SYSTEM_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_system}
TELEMETRY_DATABASE_PASSWORD=${DEFAULT_DATABASE_PASSWORD:-akamas_telemetry}

Start Akamas

To log into AWS ECR and pull the most recent Akamas container images you also need to set the AWS authentication variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION) with the values provided by Akamas Customer Support Services. You can leverage the .env file previously created with the following command:

source ./.env
aws ecr get-login-password --region us-east-2 | docker login -u AWS --password-stdin https://485790562880.dkr.ecr.us-east-2.amazonaws.com

You can start installing Akamas server by running the following AWS CLI commands:

docker compose up -d

Akamas is deployed as a set of containerized services running on Docker and managed via Docker Compose. The latest version of the Akamas Docker Compose file and all the images required by Docker can be downloaded from the AWS ECR repository.

Two installation modes are available:

Internet access

Internet access is required for Akamas online installation and updated procedures and allows retrieving the most updated Akamas container images from the Akamas private Amazon Elastic Container Registry (ECR).

If internet access is not available for policies or security reasons, Akamas installation and updates can be executed offline.

Internet access from the Akamas server is not mandatory but it’s strongly recommended.

Ports

The following table provides a list of the ports on the Akamas server that have to be reachable by Akamas administrators and users to properly operate the system.

In the specific case of AWS instance and customer instances sharing the same VPC/Subnet inside AWS, you should:

• open all of the ports listed in the table above for all inbound URLs (0.0.0.0/32) on your AWS security group

• open outbound rules to all traffic and then attach this AWS security group (which must reside inside a private subnet) to the Akamas machine and all customer application AWS machines

Akamas is deployed as a set of containerized services running on Docker and managed via Docker Compose. In the offline installation mode, the latest version of the Akamas Docker Compose file and all the images required by Docker cannot be downloaded from the AWS ECR repository.

Get Akamas Docker artifacts

Get in contact with Akamas Customer Services to get the latest versions of the Akamas artifacts uploaded to a location of your choice on the dedicated Akamas Server.

Akamas installation artifacts will include:

• images.tar.gz: a tarball containing Akamas main images.

• docker-compose.yml: docker-compose file for Akamas.

• akamas: the binary file of the Akamas CLI that will be used to verify the installation.

Import Docker images

A preliminary step in the offline installation mode is to import the shipped Docker images by running the following commands in the same directory where the tar files have been stored:

Mind that this import procedure could take some time!

Configure Akamas environment variables

To configure Akamas, you should set the following environment variables:

• AKAMAS_CUSTOMER: the customer name matching the one referenced in the Akamas license.

• AKAMAS_BASE_URL: the endpoint in the Akamas APIs that will be used to interact with the CLI, typically https://<akamas server DNS address>

To avoid losing your environment variables for future upgrades, it is suggested to keep them in the .env file, stored in the same directory as the docker-compose.yml:

Run installation

To start Akamas you can now simply navigate into the akamas folder and run a docker-compose command:

You may get the following error:

• Ubuntu

• RHEL

This section describes how to setup an Akamas Server behind a proxy server and to allow Docker to connect to the Akamas repository on AWS ECR.

Configure Docker daemon

First, create the /etc/systemd/system/docker.service.d directory if it does not already exists. Then create or update the /etc/systemd/system/docker.service.d/http-proxy.conf file with the variables listed below, taking care of replacing <PROXY> with the address and port (and credentials if needed) of your target proxy server:

Once configured, flush the changes and restart Docker with the following commands:

Configure the Akamas containers

To allow the Akamas services to connect to addresses outside your intranet, the Docker instance needs to be configured to forward the proxy configuration to the Akamas containers.

Update the ~/.docker/config.json file adding the following field to the JSON, taking care to replace <PROXY> with the address (and credentials if needed) of your target proxy server:

Run Akamas

Set the following variables to configure your working environment, taking care to replace <PROXY> with the address (and credentials if needed) of your target proxy server:

Once configured, you can log into the ECR repository through the AWS CLI and start the Akamas services manually.

Akamas APIs and UI use plain HTTP when they are first installed. To enable the use of HTTPS you will need to:

1. Ask your security team to provide you with a valid certificate for your server. The certificate usually consists of two files with ".key" and ".pem" extensions. You will need to provide the Akamas server DNS name.

2. Create a folder named "certs" in the same directory as Akamas' docker-compose file;

3. Copy the ".key" and ".pem" files in the created "certs" folder and rename them to "akamas.key" and "akamas.pem" respectively. Ensure the files belong to the same user and group you use to run Akamas.

4. Restart two Akamas services by running the following commands:

   Copy

   cd <Akamas docker-compose file folder>
   docker-compose restart akamas-ui kong

After the containers' reboot is complete you will be able to access the UI over HTTPS from your browser:

https://<akamas server name here>

Setup CLI to use HTTPS

Now that your Akamas server is configured to use HTTPS you can update the Akamas CLI configuration to use the secure protocol.

akamas init config

You will be prompted to enter some input, please value it as follows:

Api address [http://localhost:8000]: https://<akamas server dns address>:443/akapi
Workspace [default]: default
Verify SSL: [True]: True

You can test the connection by running:

akamas status

It should return 'OK', meaning Akamas has been properly configured to work over HTTPS.

Before installing the Akamas please make sure to review all the following requirements:

Issues when installing Docker

Centos 7 and RHEL 7

Notice: this distro features a known issue since Docker default execution group is named dockerroot instead of docker . To make docker work edit (or create) /etc/docker/daemon.json to include the following fragment:

After editing or creating the file, please restart Docker and then check the group permission of the Docker socket (/var/run/docker.sock), which should show dockerroot as a group:

Then, add the newly created akamas user to the dockerroot group so that it can run docker containers:

and check the akamas user has been correctly added to dockerroot group by running:

Issues when running AWS CLI

In case of issues in logging in through AWS CLI, when executing the following command:

Please check that:

• Environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION are correctly set

• AWS CLI version is 2.0+

Issue when starting Akamas services

Akamas failed to start some services

Please notice that the very first time Akamas is started, up to 30 minutes might be required to initialize the environment.

In case the issue persists you can run the following command to identify which service is not able to start up correctly

License service unable to access docker socket

In some systems, the Docker socket, usually located in /var/run/docker.sock can not be accessed within a container. This causes Akamas to signal this behavior by reporting the Access Denied error in the license service logs.

To overcome this limitation edit the docker-compose.yaml file adding the line privileged: true to the following services:

• License

• Optimizer

• Telemetry

• Airflow

The following is a sample configuration where this change is applied to the license service:

Finally, you can issue the following command to apply these changes

Missing Akamas Customer variable

You can easily inspect which value of this variable has been used when starting Akamas by running the following command on the Akamas server:

If you find out that the value is not the one you expect, you can update the .env file and then start again the license service by running:

Once Akamas is up and running you can re-install your license.

Other issues

Kubernetes version

Running Akamas requires a cluster running Kubernetes version 1.24 or higher.

Resources requirements

Akamas can be deployed in three different sizes depending on the number of concurrent optimization studies that will be executed. If you are unsure about which size is appropriate for your environment we suggest you start with the small one and upgrade to bigger ones as you expand the optimization activity to more applications.

The tables below report the required resources both for requests and limits that should be available in the cluster to use Akamas.

Small

The small tier is suited for environments that need to support up to 10 concurrent optimization studies

Storage requirements

The cluster must provide the definition of a Storage Class so that the application installation can leverage Persistent Volume Claims to dynamically provision the volumes required to persist data.

Permissions

To install and run Akamas cluster level permissions are not required. This is the minimal set of namespaced rules.

- apiGroups: ["", "apps", "policy", "batch", "networking.k8s.io", "events.k8s.io/v1", "rbac.authorization.k8s.io"]
  resources:
    - configmaps
    - cronjobs
    - deployments
    - events
    - ingresses
    - jobs
    - persistentvolumeclaims
    - poddisruptionbudgets
    - pods
    - pods/log
    - rolebindings
    - roles
    - secrets
    - serviceaccounts
    - services
    - statefulsets
  verbs: ["get", "list", "create", "delete", "patch", "update", "watch"]

Networking

Preliminary steps

Before installing Akamas, please follow these steps:

Installation steps

Please follow these steps to install the Akamas application:

By default, Akamas uses the following ports for its UI:

• 80 (HTTP)

• 443 (HTTPS)

Depending on the configuration of your environment, you may want to change the default settings: to do so, you’ll have to update the Akamas docker-compose file.

Inside the docker-compose.yml file, scroll down until you come across the akamas-ui service. There you will find a specification as follows:

Update the YAML file by remapping the UI ports to the desired ports of the host.

In case you were running Akamas with host networking, you are allowed to bind different ports in the container itself. To do so you can expand the docker-compose service by adding a couple of environment variables like this:

Finally, apply the new configuration after updating the AKAMAS_BASE_URL environment variable to match the new protocol or port.

Create the configuration file

To proceed with the installation, you need to create a Helm Values file, called akamas.yaml in this guide, containing the mandatory configuration values required to customize your application. The following template contains the minimal set required to install Akamas:

# AWS credentials to fetch ECR images (required)
awsAccessKeyId: <AWS_ACCESS_KEY_ID>
awsSecretAccessKey: <AWS_SECRET_ACCESS_KEY>

# Akamas customer name. Must match the value in the license (required)
akamasCustomer: <CUSTOMER_NAME>

# Akamas administrator password. If not set a random password will be generated
akamasAdminPassword: <ADMIN_PASSWORD>

# The URL that will be used to access Akamas, for example 'http://akamas.kube.example.com' (required)
akamasBaseUrl: <INSTANCE_HOSTNAME>

You can also download the template file running the following snippet:

curl -so akamas.yaml  http://helm.akamas.io/templates/1.4.1/akamas.yaml.template

Replace in the file the following placeholders:

• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY: the AWS credentials for pulling the Akamas images

• CUSTOMER_NAME: customer name provided with the Akamas license

• ADMIN_PASSWORD: initial administrator password

Start the installation

With the configuration file you just created (and the new variables you added to override the defaults), you can start the installation with the following command:

helm upgrade --install \
  --create-namespace --namespace akamas \
  --repo http://helm.akamas.io/charts \
  --version '1.4.1' \
  -f akamas.yaml \
  akamas akamas

This command will create the Akamas resources within the specified namespace. You can define a different namespace by changing the argument --namespace <your-namespace>

An example output of a successful installation is the following:

Release "akamas" does not exist. Installing it now.
NAME: akamas
LAST DEPLOYED: Thu Sep 21 10:39:01 2023
NAMESPACE: akamas
STATUS: deployed
REVISION: 1
NOTES:
Akamas has been installed

NOTES:
Akamas has been installed

To get the initial password use the following command:

kubectl get secret akamas-admin-credentials -o go-template='{{ .data.password | base64decode }}'

Check the installation

To monitor the application startup, run the command kubectl get pods. After a few minutes, the expected output should be similar to the following:

NAME                           READY   STATUS    RESTARTS   AGE
airflow-6ffbbf46d8-dqf8m       3/3     Running   0          5m
analyzer-67cf968b48-jhxvd      1/1     Running   0          5m
campaign-666c5db96-xvl2z       1/1     Running   0          5m
database-0                     1/1     Running   0          5m
elasticsearch-master-0         1/1     Running   0          5m
keycloak-66f748d54-7l6wb       1/1     Running   0          5m
kibana-6d86b8cbf5-6nz9v        1/1     Running   0          5m
kong-7d6fdd97cf-c2xc9          1/1     Running   0          5m
license-54ff5cc5d8-tr64l       1/1     Running   0          5m
log-5974b5c86b-4q7lj           1/1     Running   0          5m
logstash-8697dd69f8-9bkts      1/1     Running   0          5m
metrics-577fb6bf8d-j7cl2       1/1     Running   0          5m
optimizer-5b7576c6bb-96w8n     1/1     Running   0          5m
orchestrator-95c57fd45-lh4m6   1/1     Running   0          5m
store-5489dd65f4-lsk62         1/1     Running   0          5m
system-5877d4c89b-h8s6v        1/1     Running   0          5m
telemetry-8cf448bf4-x68tr      1/1     Running   0          5m
ui-7f7f4c4f44-55lv5            1/1     Running   0          5m
users-966f8f78-wv4zj           1/1     Running   0          5m

At this point, you should be able to access the Akamas UI using the endpoint specified in the akamasBaseUrl, and interact through the Akamas CLI with the path /api.

Two installation modes are available:

Configure the registry

If your cluster is in an air-gapped network or is unable to reach the Akamas image repository, you need to copy the required images to your private registry.

The procedure described here leverages your local environment to upload the images. Thus, to interact between the Akamas and private registry, it requires Docker to be installed and configured.

Transfer the Docker images

The offline installation requires you to pull the images and migrate them to your private registry. In the following command replace the chart version to download the related list of images:

curl -sO  http://helm.akamas.io/images/1.4.1/image-list

Once the import is complete, you must re-tag and upload the images. Run the following snippet, replacing <REGISTRY_URL> with the actual URL of the private registry:

NEW_REGISTRY="<REGISTRY_URL>"

while read IMAGE; do
    REGISTRY=$(echo "$IMAGE" | cut -d '/' -f 1)
    REPOSITORY=$(echo "$IMAGE" | cut -d ':' -f 1 | cut -d "/" -f2-)
    TAG=$(echo "$IMAGE" | cut -d ':' -f 2)

    NEW_IMAGE="$NEW_REGISTRY/$REPOSITORY:$TAG"
    echo "Migrating $IMAGE to $NEW_IMAGE"

    docker pull "$IMAGE"
    docker tag "$IMAGE" "$NEW_IMAGE"
    docker push "$NEW_IMAGE"
done <image-list

This process could last several minutes, once the upload is complete, you can proceed with the next steps.

Create the configuration file

To proceed with the installation, you must create a Helm Values file, called akamas.yaml in this guide, containing the mandatory configuration values required to customize your application. The following template contains the minimal set required to install Akamas:

# Akamas customer name. Must match the value in the license (required)
akamasCustomer: <CUSTOMER_NAME>

# Akamas administrator password. If not set a random password will be generated
akamasAdminPassword: <ADMIN_PASSWORD>

# The URL that will be used to access Akamas, for example 'http://akamas.kube.example.com' (required)
akamasBaseUrl: <INSTANCE_HOSTNAME>

# The URL of your private registry
global:
  imageRegistry: <REGISTRY_URL>

elasticsearch:
  image: <REGISTRY_URL>/akamas/elastic/elasticsearch

Replace in the file the following placeholders:

• CUSTOMER_NAME: customer name provided with the Akamas license

• ADMIN_PASSWORD: initial administrator password

• REGISTRY_URL: the URL for the private registry used in the transfer process above

Configure the authentication

To authenticate to your private registry, you must manually create the Secret required to pull the images. If the registry uses basic authentication, you can create the credentials in the namespace by running the following command:

kubectl create secret docker-registry registry-token \
  --namespace akamas \
  --docker-server=<REGISTRY_URL> \
  --docker-username=<USER> \
  --docker-password=<PASSWORD>

Otherwise, you can leverage any credential already configured on your machine by running the following command:

kubectl create secret docker-registry registry-token \
  --namespace akamas \
  --from-file=.dockerconfigjson=<PATH/TO/.docker/config.json>

Start the installation

From a machine that can reach the endpoint, run the following command to download the chart:

helm pull --repo http://helm.akamas.io/charts --version '1.4.1' akamas

The command downloads the latest version chart version as an archive named akamas-<version>.tgz. The file can be transferred to the machine where the installation will be run. Replace akamas/akamas with the download package in the following commands.

If you wish to see and override the values that Helm will use to install Akamas, you may execute the following command.

helm show values akamas-<version>.tgz

Now, with the configuration file you just created (and the new variables you added to override the defaults), you can start the installation with the following command:

helm upgrade --install \
  --create-namespace --namespace akamas \
  -f akamas.yaml \
  akamas akamas-<version>.tgz

This command will create the Akamas resources within the specified namespace. You can define a different namespace by changing the argument --namespace <your-namespace>

An example output of a successful installation is the following:

Release "akamas" does not exist. Installing it now.
NAME: akamas
LAST DEPLOYED: Thu Sep 21 10:39:01 2023
NAMESPACE: akamas
STATUS: deployed
REVISION: 1
NOTES:
Akamas has been installed

NOTES:
Akamas has been installed

To get the initial password use the following command:

kubectl get secret akamas-admin-credentials -o go-template='{{ .data.password | base64decode }}'

Check the installation

To monitor the application startup, run the command kubectl get pods. After a few minutes, the expected output should be similar to the following:

NAME                           READY   STATUS    RESTARTS   AGE
airflow-6ffbbf46d8-dqf8m       3/3     Running   0          5m
analyzer-67cf968b48-jhxvd      1/1     Running   0          5m
campaign-666c5db96-xvl2z       1/1     Running   0          5m
database-0                     1/1     Running   0          5m
elasticsearch-master-0         1/1     Running   0          5m
keycloak-66f748d54-7l6wb       1/1     Running   0          5m
kibana-6d86b8cbf5-6nz9v        1/1     Running   0          5m
kong-7d6fdd97cf-c2xc9          1/1     Running   0          5m
license-54ff5cc5d8-tr64l       1/1     Running   0          5m
log-5974b5c86b-4q7lj           1/1     Running   0          5m
logstash-8697dd69f8-9bkts      1/1     Running   0          5m
metrics-577fb6bf8d-j7cl2       1/1     Running   0          5m
optimizer-5b7576c6bb-96w8n     1/1     Running   0          5m
orchestrator-95c57fd45-lh4m6   1/1     Running   0          5m
store-5489dd65f4-lsk62         1/1     Running   0          5m
system-5877d4c89b-h8s6v        1/1     Running   0          5m
telemetry-8cf448bf4-x68tr      1/1     Running   0          5m
ui-7f7f4c4f44-55lv5            1/1     Running   0          5m
users-966f8f78-wv4zj           1/1     Running   0          5m

At this point, you should be able to access the Akamas UI using the endpoint specified in the akamasBaseUrl, and interact through the Akamas CLI with the path /api.

Running Akamas on OpenShift requires some Helm configurations to be applied.

OpenShift requirements

To proceed with the installation, OpenShift version 4.x.

Installation

The following snippet must be added to the akamas.yaml to install Akamas on OpenShift.

Access Akamas - Ingress to route

Once the Helm command is invoked, ensure the routes have been created by running:

The output must list the Akamas routes with different paths.

Toolbox

The Akamas' Toolbox optional component requires privileged access to run on OpenShift.

To interact with your Akamas instance, you need the UI and API Gateway to be accessible from outside the cluster.

Kubernetes offers different options to expose a service outside of the cluster. The following is a list of the supported ones, with examples of how to configure them to work in your chart release:

Port Forwarding

By default, Akams uses Cluster IPs for its services, allowing communication only inside the cluster. Still, you can leverage Kubectl's port-forward to create a private connection and expose any internal service on your local machine.

This solution is suggested to perform quick tests without exposing the application or in scenarios where cluster access to the public is not allowed.

Set akamasBaseUrl to http://localhost:9000 in your Helm Values file, and install or update your Akamas deployment using the Helm command. Once the rollout is complete, open a tunnel to the UI with the following command:

kubectl port-forward service/ui 9000:http

As long as the port-forwarding is running, you will be able to interact with the UI through the tunnel; you can also interact through the Akamas CLI by configuring the URL http://localhost:9000/akapi.

Ingress

An Ingress is a Kubernetes object that provides service access, load balancing, and SSL termination to Kubernetes services.

To expose the Akamas UI through an Ingress, configure the Helm Values file by configuring akamasBaseUrl with the host of the Ingress (e.g.: https://akamas.kube.example.com), and by adding the snippet below:

ingress:
  enabled: true
  tls:
    - secretName: "<SECRET_NAME>"  # secret containing the certificate and key data
  annotations: {}  # optional

Here is a description of the fields:

• enabled: set to true to enable the Ingress

This page describes the requirements that should be fulfilled by the user when installing or managing an Akamas installation on Kubernetes. The software below is usually installed on the user's workstation or laptop.

Kubectl

kubectl version --short

Helm

helm version --short

Privileged access

Akamas uses Elasticsearch to store logs and time series. When running Akamas on Kubernetes, Elasticsearch is installed automatically using the official Elasticsearch helm chart. This chart required running an init container with privileged access to set up a configuration on the Elasticsearch pod host. If running such a container is not permitted in your environment, you can add the following snippet to the akamas.yaml file when installing Akamas to disable this feature.

# Disable ES privileged initialization container. 
elasticsearch:
  sysctlInitContainer:
    enabled: false

Linux

To get Akamas CLI installed on Linux, run the following commands:

curl -o akamas_cli https://s3.us-east-2.amazonaws.com/akamas/cli/$(curl -s https://s3.us-east-2.amazonaws.com/akamas/cli/stable.txt)/linux_64/akamas
sudo mv akamas_cli /usr/local/bin/akamas
chmod 755 /usr/local/bin/akamas

You can now run the Akamas CLI following by running the akamas command.

In some installations, the /usr/local/bin folder is not present in the PATH environment variable. This prevents you from using akamas without specifying the complete file location. To fix this issue you can add an entry to the PATH system environment variable or move the executable to another folder in your PATH.

Auto-completion

To enable auto-completion on Linux systems with a bash shell (requires bash 4.4+), run the following commands:

curl -O https://s3.us-east-2.amazonaws.com/akamas/cli/$(curl -s https://s3.us-east-2.amazonaws.com/akamas/cli/stable.txt)/linux_64/akamas_autocomplete.sh
mkdir -p ~/.akamas
mv akamas_autocomplete.sh ~/.akamas
echo '. ~/.akamas/akamas_autocomplete.sh' >> ~/.bashrc
source ~/.bashrc

Windows

To install the Akamas CLI on Windows run the following command from Powershell:

Invoke-WebRequest "https://s3.us-east-2.amazonaws.com/akamas/cli/$($(Invoke-WebRequest https://s3.us-east-2.amazonaws.com/akamas/cli/stable.txt | Select-Object -Expand Content) -replace '\n', '')/win_64/akamas.exe" -OutFile akamas.exe

You can now run the Akamas CLI by running .\akamas in the same folder.

To invoke the akamas CLI from any folder, create a akamas folder (such as C:\Program Files\akamas), and move there the akamas.exe file. Then, add an entry to the PATH system environment variable with the value C:\Program Files\akamas. Now, you can invoke the CLI from any folder, by simply running the akamas command.

The Akamas CLI can be accessed by simply running the akamascommand.

Verify the CLI

You can verify that the CLI was installed correctly by running this command:

akamas version

which should show an output similar to this one

Akamas CLI: 2.9.0
Akamas platform: 3.4.0

At any time, you can see available commands and options with:

akamas --help

You may find helpful some of the commands listed in the sections below.

Read database passwords

By default, access to each service database is assigned to a user with randomly generated passwords. For example, to read the campaign service database password, execute the following command:

kubectl get secret database-user-credentials -o go-template='{{ .data.campaign | base64decode }}'

The username for the campaign service can be found in the configuration file under each service section. To read the username for the campaign service set during the installation, launch the following command:

helm get values akamas --all --output json | jq '.campaign.database.user'

You can connect to the campaign_service database with the user and password above.

If you want to show all the passwords, execute this command:

kubectl get secret database-user-credentials -o go-template='{{range $k,$v := .data}} {{printf "%s: %s\n" $k ( $v |base64decode ) }}{{end}}'

The CLI is used to interact with an akamas server. To initialize the configuration of the Akamas CLI you can run the command:

akamas init config

and follow the wizard to provide the required information such as the server IP.

Here is a summary of the configuration wizard options.

Api address [http://localhost:8000]: https://<akamas-hostname>:<ui-port>/akapi
Workpace [default]: default
Verify SSL: [True]: True
Is external certificate CA required? [y/N]: N

After this step, the Akamas CLI can be used to login to the Akamas server, by issuing the following command:

akamas login

and providing the credentials as requested.

The Akamas CLI allows users to invoke commands against the Akamas dedicated machine (Akamas Server). The Akamas CLI can also be installed on a different system than the Akamas Server.

Prerequisites

Linux and Windows operating systems are supported for installing Akamas CLI.

Installation steps

The Akamas CLI can be installed and configured in two simple steps:

API Address

The CLI, as well as the UI, interacts with the akamas server via APIs. The apiAddress configuration contains the information required to communicate with the server.

Docker

The Akamas Server provides different listeners to interact with APIs:

• an HTTP listener on port 80 under the path /akapi

• an HTTP listener on port 8000

• an HTTPS listener on port 443 under the path /akapi

• an HTTPS listener on port 8443

Depending on your networking setup you can either use the listeners on ports 80 and 443 which are also used for the UI or directly interact with the API gateway on ports 8000 and 8443. If you are unsure about your network setup we suggest you start with the HTTPS listener on port 443.

For improved security, it is recommended to configure CLI communications with the Akamas Server over HTTPS. Notice that you need to have a valid certificate installed on your Akamas server (at least a self-signed one) to enable HTTPS communication between CLI and the Akamas Server.

Changing CLI protocol

The CLI can be configured either directly via the CLI itself or via the YAML configuration file akamasconf.

Using the CLI

Issue the following command to change the configuration of the Akamas CLI:

akamas init config

and then follow the wizard to provide the required CLI configuration:

• enable HTTPS communications:

Api address [http://localhost:8000]: https://<akamas server dns name>:443/akapi
Workspace [default]: Workspace1
Login method (local, oauth2) [local]: local
Verify SSL: [True]: True
Is external certificate CA required? [y/N]: N

• enable HTTP communications:

Api address [http://localhost:8000]: http://<akamas server DNS name>:80
Workspace [default]: Workspace1
Login method (local, oauth2) [local]: local

Please notice that by default Akamas CLI expects a valid SSL certificate. If you are using a self-signed certificate or a not valid one you can set the Verify SSL variable to false. This will mimic the behavior of accepting an invalid HTTPS certificate on your favorite browser.

Using the akamasconf file

Create a file and name it akamasconf to be located at the following locations:

• Linux: ~/.akamas/akamasconf

• Windows: C:\Users\<username>\.akamas (where C: is the drive where the OS is installed)

The file location can be customized by setting an $AKAMASCONF environment variable.

Here is an example akamasconf file provided as a sample:

apiAddress: http[s]://<akamas server dns name>:80[443]/akapi
verifySsl: [true|false]
workspace: default

Run the following command to verify the correct startup and initialization of Akamas:

akamas status

When all services have been started this command will return an "OK" message. Please notice that it might take a few minutes for Akamas to start all services.

To check that also UI is properly working please access the following URL:

http://<akamas server name here>

You will see the Akamas login form:

The Akamas CLI supports interacting with the API server through an HTTP/HTTPS proxy server.

To enable access via an HTTP proxy, set the environment variable HTTP_PROXY. From the following snippet, replace proxy_ip and proxy_port with the desired values.

export HTTP_PROXY="http://<proxy_ip>:<proxy_port>"

Then, run the akamas command to verify access.

akamas status debug

Access through an HTTPS proxy can be set by using the environment variable HTTPS_PROXY instead of HTTP_PROXY.

Akamas offers, as an additional container, a toolbox that contains the Akamas CLI executable, along with some other useful command-line tools such as kubectl, Helm, vim, docker cli, jq, yq, git, gzip, zip, OpenSSH, ping, cURL, and wget. It can be executed along akamas services, in the same network, for docker-compose installation, or in the akamas namespace for Kubernetes installations.

This toolbox aims to:

• allow users to interact with Akamas without the need to install Akamas CLI on their systems

Docker compose installation

By setting the following options in the .env file, you can configure your toolbox by enabling SSH password authentication (only key-based authentication will be available otherwise) and by setting a login password:

ALLOW_PASSWORD=true
CUSTOM_PASSWORD=yourPassword

To start the toolbox container just issue the following command:

docker compose --profile toolbox up -d

If you want to keep the toolbox running also after a complete restart you can also add the following line to your .env file: COMPOSE_PROFILES=toolbox

Accessing the toolbox on Docker

To access the toolbox on docker you can issue the following command:

docker exec -it toolbox bash

You will be provided with a shell inside the toolbox where you can interact with Akamas. Please read the work folder section below for more information on how to persist scripts and data on the toolbox upon restart and upgrades.

Kubernetes installation

Follow the usual guide for installing Akamas on Kubernetes but make sure to override the following variable (its default value is false) in your akamas.yaml file or in file values-files/my-values.yaml (can be created if missing):

Follow the usual guide for installing Akamas on Kubernetes, adding the following variables to values file:

toolbox:
  enabled: true
  sshPassword:
    # enable SSH password authentication. If 'false', only key-based access
    # will be allowed
    enabled: false
    # configure the password for the toolbox user. If not provided, an
    # autogenerated password will be used
    override:

Then, you can launch the usual helm upgrade --install ... command to run the pod, as described in theStart the installation (online) or Start the installation (offline) sections.

Accessing the toolbox on Kubernetes

When it's deployed to Kubernetes, you may access this toolbox in two ways:

• via kubectl

• via SSH command

Kubectl access

Accessing is as simple as:

kubectl exec -it deployment/toolbox -- bash

SSH access

For this type of access, you need to retrieve the SSH login password (if enabled) or key. To fetch them, run the following commands:

# Get the password
kubectl exec deployment/toolbox -- cat /home/akamas/password
# Get the key
kubectl exec deployment/toolbox -- cat /home/akamas/.ssh/id_rsa

With this info, you can leverage the toolbox to run commands in your workflows, like in the following example:

name: hello-workflow
tasks:
  - name: Say Hello
    operator: Executor
    arguments:
      command: echo 'Hello Akamas'
      host:
        hostname: toolbox
        username: akamas
        password: d48020ab71be6a07

You can also access the toolbox by port-forwarding from your local machine (on port 2222 in our example). Run the following kubectl command:

kubectl port-forward service/toolbox 2222:22

On another terminal, run:

ssh akamas@localhost -p 2222

and answer yes to the question, then insert the akamas password to successfully SSH access the toolbox (see example below):

$ ssh akamas@localhost -p 2222
The authenticity of host '[localhost]:2222 ([127.0.0.1]:2222)' can't be established.
ED25519 key fingerprint is SHA256:34GXnmRz1YjWr2TTpUpJmRoHYck0NzeAxni2L857Exs.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:2222' (ED25519) to the list of known hosts.
akamas@localhost's password:
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.10.178-162.673.amzn2.x86_64 x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

akamas@toolbox-6dd8b7f898-8xwzf:~$

Work directory

A typical kubernetes scenario is: Akamas running from inside a namespace and customer application running from inside another namespace. In such a scenario you will probably need to create an Akamas workflow (running from akamas namespace) that applies a new configuration on the customer application (running in customer namespace) then Akamas collects new metrics for a period of time and then calculates a new configuration based on the score of the previous configuration.

What follows is a typical workflow example that:

• uses a FileConfigurator to create a new helm file that applies the new configuration computed by Akamas on a single service named adservice.FileConfigurator recreates a new adservice.yaml file by using the template adservice.yaml.templ. Just make sure that adservice.yaml.templ contains namespace: boutique (the customer namespace, in our example)

• uses an Executor that launches kubectl apply with the new helm file adservice.yaml you just saved to apply the new configuration

• uses another Executor to wait for the new configuration to be actually rolled out by launching kubectl rollout status

• waits for half an hour to observe the canges in metrics

If you need to store Akamas artifacts, scripts, or any other file that requires persistence, you can use the /work directory, which persists across restarts. This is the default working directory at login time.

Running Akamas' studies requires a valid license.

To install a license get in touch with Akamas Customer Service to receive:

• the Akamas license file

• your "customer name" to configure in the variable AKAMAS_CUSTOMER for Docker installations or akamasCustomer for Kubernetes installations

• the URL to configure in the AKAMAS_BASE_URL variable for Docker installations

• login credentials

Once you have this information, you can issue the following commands:

cd <your bundle files location>
akamas install license <license file you have been provided>

kubectl get secret -n <NAMESPACE> akamas-admin-credentials -o go-template='{{.data.password | base64decode}}'

Akamas might collect anonymized usage information on running optimizations. Collection and tracking are disabled by default and can be manually enabled.

Docker installation

External tracking is managed through the following environment variables:

• AKAMAS_TRACKER_URL: the target URL for all tracking info.

• AKAMAS_TRACKING_OPT_OUT: when set to 1, disables anonymous data collection.

Tracking for a running instance can be enabled by editing the AKAMAS_TRACKING_OPT_OUT variable in the docker-compose.yaml file.

To enable tracking set the variable to the following value:

AKAMAS_TRACKING_OPT_OUT=0

Then issue the command:

docker compose up -d

Kubernetes installation

External tracking is managed through the field trackingOptOut in the Values file. To enable tracking set trackingOptOut to 0 as in the following example and upgrade the installation:

awsAccessKeyId: "YOUR_ACCESSKEY_ID"
awsSecretAccessKey: "YOUR_SECRET_ACCESS_KEY"

trackingOptOut: 0

To configure an external identity provider, access the Keycloak administration console exposed on the /auth page of your installation; for example, https://app.akamas.io/auth.

Now log into the Administration Console using the admin user. The password for such a user can be retrieved in different ways, depending on the installation method:

• Kubernetes. A custom password can be specified during the installation by providing a value keycloak.adminPassword in the helm chart. If this value was left unspecified, you can retrieve the auto-generated password with the following command:

kubectl get secret keycloak-admin-credentials \
  -o go-template='{{ .data.KEYCLOAK_ADMIN_PASSWORD | base64decode }}'

Note that you might need to provide the namespace in which Akamas have been installed using the flag -n namespace

• Docker.

  A custom password can be specified during the installation by providing a value for the variable KEYCLOAK_ADMIN_PASSWORD in the environment or in the docker-compose file. if during the installation you didn't specify the value, you can retrieve the auto-generated password with the following command:

docker exec -it keycloak cat /config/keycloak_admin | cut -d '|' -f1

Once logged in, select the akamas realm from the dropdown menu and navigate to the Identity providers section.

From here on, the steps required to proceed with the configuration vary depending on the provider you are integrating with. Select yours from the guides below:

This page provides a walkthrough to configure Azure Active Directory as an external identity provider for Akamas users.

Configure the App registration

Create a new App registration

• a name for the application

• the account type that best suits your use case

Complete the creation by clicking on "Register".

Get the client configuration

On the "Overview" page of the application, note the following values:

• Application (client) ID

• OpenID Connect metadata document (found in the "Endpoints" side panel)

Furthermore, in the "Certificates & secrets" section, create a new Client secret and note its value.

With these values, we can now complete the provider configuration in the Keycloak console.

Create the Identity provider

Here, specify an alias for the client ("microsoft" in our case) and optionally the display name used in the login page ("Microsoft").

In the "OpenID Connect settings" section, configure the following fields using the values from the app registration in the Azure portal:

• "Discovery endpoint": populate with the URL of the "OpenID Connect metadata document". This box should become green upon successful validation.

• "Client ID": populate with the "Application (client) ID" from the app's overview page

• "Client Secret": populate with the value of the generated secret

Complete the configuration by clicking "Add". You will land on the detail page of the new provider: here, copy the value of the redirect URI.

Complete the app registration

Back to the app registration in the Azure portal, navigate to the "Authentication" section. Add the "Web" platform (if not already present).

Finally, add to the list of redirect URIs the one from the previous step.

You have now configured Akamas to delegate to Azure your users' login.

Configure the default Akamas roles

The final setup step is to instruct Akamas to associate the default roles with the users automatically. This way, users will be added to the default workspace with read and write permissions the first time they log in.

On the Keycloak console, on the provider's details page, navigate to "Mappers":

Now, add the following configurations.

User role

• Name: User role

• Mapper type: Hardcoded role

• Role: USER

Default Workspace Read

• Name: Default Workspace Read

• Mapper type: Hardcoded role

• Role: WS_ac8481d3-d031-4b6a-8ae9-c7b366f027e8_R

Default Workspace Write

• Name: Default Workspace Write

• Mapper type: Hardcoded role

• Role: WS_ac8481d3-d031-4b6a-8ae9-c7b366f027e8_W

Test the integration

Visit the installation's login page to check that the new authentication method is displayed and works correctly.

This page provides a walkthrough to configure Google as an external identity provider for Akamas users.

Configure the App registration

Configure the Consent Screen

If the "Credentials" page displays a warning box reminding you to configure the consent screen, you first need to create an app. Click the enclosed button to start the wizard.

Create the OAuth client

Click the "Create Credentials" link on top, and select "OAuth Client ID".

Configure the client as follows:

• "Application Type": select "Web application"

• "Name": populate with the name of the new client

• "Authorized redirect URIs": leave it blank, as you will fill it in a later step

Once you click "Create" the console will show you a confirmation pop-up containing the client's configuration. Note the Client ID and the Client Secret.

Create the Identity provider

Configure the following fields using the values from the OAuth client you just created:

• "Client ID": fill in the id of the client

• "Client Secret": fill in the secret of the client

To complete the configuration, note the "Redirect URI" value and click "Add".

Complete the app registration

Configure the default Akamas roles

The final setup step is to instruct Akamas to associate the default roles with the users automatically. This way, users will be added to the default workspace with read and write permissions the first time they log in.

On the Keycloak console, on the provider's details page, navigate to "Mappers":

Now, add the following configurations.

User role

• Name: User role

• Mapper type: Hardcoded role

• Role: USER

Default Workspace Read

• Name: Default Workspace Read

• Mapper type: Hardcoded role

• Role: WS_ac8481d3-d031-4b6a-8ae9-c7b366f027e8_R

Default Workspace Write

• Name: Default Workspace Write

• Mapper type: Hardcoded role

• Role: WS_ac8481d3-d031-4b6a-8ae9-c7b366f027e8_W

Test the integration

Visit the installation's login page to check that the new authentication method is displayed and works correctly.

Akamas audit logs

Akamas stores all its logs into an internal Elasticsearch instance: some of these logs are reported to the user in the GUI in order to ease the monitoring of workflow executions, while other logs are only accessible via CLI and are mostly used to provide more context and information to support requests.

Audit access can be performed by using the CLI in order to extract logs related to UI or API access. For instance, to extract audit logs from the last hour use the following commands:

• UI Logs

akamas logs --no-pagination -S kong -f -1h

• API Logs

akamas logs --no-pagination -S kong -f -1h

Notice: to visualize the system logs unrelated to the execution of workflows bound to workspaces, you need an account with administrative privileges.

Storing audit logs into files

To ease the integration with external logging systems, Akamas can be configured to store access logs into files. To enable this feature you should:

1. Create a logs folder next to the Akamas docker-compose.yml file

2. Edit the docker-compose.yml file by modifying the line FILE_LOG: "false" to FILE_LOG: "true"

3. If Akamas is already running issue the following command

docker compose up -d logstash

otherwise, start Akamas first.

When the user interacts with the UI or the API Akamas will report detailed access logs both on the internal database and in a file in the logs folder. To ease log rolling and management every day Akamas will create a new file named according to the pattern access-%{+YYYY-MM-dd}.log.

Akamas allows dumping log entries from a specific service, workspace, workflow, study, trial, and experiment, for a specific timeframe and at different log levels.

Akamas CLI for logs

Akamas logs can be dumped via the following CLI command:

akamas log

This command provides many filters which can be retrieved with the following command:

akamas log --help

which should return

Usage: akamas log [OPTIONS] [MESSAGE]

  Show Akamas logs

Options:
  -d, --debug                     Show extended error messages if present.
  --page-size INTEGER             Number of log lines to be retrieved NOTE:
                                  This argument is mutually exclusive with
                                  arguments: [dump, no_pagination].
  --no-pagination                 Disable pagination and print all logs NOTE:
                                  This argument is mutually exclusive with
                                  arguments: [dump, page_size].
  --dump                          Print the logs without pagination and
                                  formatting NOTE: This argument is mutually
                                  exclusive with arguments: [page_size,
                                  no_pagination].
  -f, --from [%Y-%m-%d|%Y-%m-%dT%H:%M:%S|%Y-%m-%d %H:%M:%S|%Y-%m-%dT%H:%M:%S.%f|%Y-%m-%d %H:%M:%S.%f|[-]nw|[-]nd|[-]nh|[-]nm|[-]ns]
                                  The start timestamp of the logs
  -t, --to [%Y-%m-%d|%Y-%m-%dT%H:%M:%S|%Y-%m-%d %H:%M:%S|%Y-%m-%dT%H:%M:%S.%f|%Y-%m-%d %H:%M:%S.%f|[-]nw|[-]nd|[-]nh|[-]nm|[-]ns]
                                  The end timestamp of the logs
  -s, --study TEXT                UUID or name of the Study
  -e, --exp INTEGER               Number of the experiment
  --trial INTEGER                 Number of the trial
  -y, --system TEXT               UUID or name of the System
  -W, --workflow TEXT             UUID or name of the Workflow
  -l, --log-level TEXT            Log level
  -S, --service TEXT              Akamas service
  --without-metadata              Hide metadata
  --sorting [ASC|DESC]            Sorting order of the timestamps
  -ws, --workspace TEXT           UUID or name of the Workspace to visualize.
                                  When empty, system logs will be returned
                                  instead
  --help                          Show this message and exit.

For example, to get the list of the most recent Akamas errors:

akamas log -l ERROR

which should return something similar to:

       timestamp                         system                  provider    service                                                                                   message
==============================================================================================================================================================================================================================================================
2022-05-02T15:51:26.88    -                                      -          airflow     Task failed with exception
2022-05-02T15:51:26.899   -                                      -          airflow     Failed to execute job 2 for task Akamas_LogCurator_Task
2022-05-02T15:56:29.195   -                                      -          airflow     Task failed with exception
2022-05-02T15:56:29.215   -                                      -          airflow     Failed to execute job 3 for task Akamas_LogCurator_Task
2022-05-02T16:01:55.587   -                                      -          license     2022-05-02 16:01:47.426 ERROR 1 --- [           main] c.a.m.utils.rest.RestHandlers            :  has failed with returning a response:
                                                                                        {"httpStatus":400,"timestamp":"2022-05-02T16:01:47.413638","error":"Bad Request","message":"The following metrics: 'spark.spark_application_duration' were not found
                                                                                        in any of the components of the system 'analytics_cluster'","path":null}
2022-05-02T16:01:55.587   -                                      -          license     2022-05-02 16:01:47.434 ERROR 1 --- [           main] c.a.m.MigrationApplication               : Unable to complete operation. Mode: RESTORE. Cause: A request to a
                                                                                        downstream service CampaignService has failed: 400 : [{"httpStatus":400,"timestamp":"2022-05-02T16:01:47.413638","error":"Bad Request","message":"The following
                                                                                        metrics: 'spark.spark_application_duration' were not found in any of the components of the system 'analytics_cluster'","path":null}]
2022-05-02T16:01:55.678   -                                      -          license     2022-05-02 16:01:47.434 ERROR 1 --- [           main] c.a.m.MigrationApplication               : Unable to complete operation. Mode: RESTORE. Cause: A request to a
                                                                                        downstream service CampaignService has failed: 400 : [{"httpStatus":400,"timestamp":"2022-05-02T16:01:47.413638","error":"Bad Request","message":"The following
                                                                                        metrics: 'spark.spark_application_duration' were not found in any of the components of the system 'analytics_cluster'","path":null}]
2022-05-02T16:01:55.678   -                                      -          license     2022-05-02 16:01:47.426 ERROR 1 --- [           main] c.a.m.utils.rest.RestHandlers            :  has failed with returning a response:
                                                                                        {"httpStatus":400,"timestamp":"2022-05-02T16:01:47.413638","error":"Bad Request","message":"The following metrics: 'spark.spark_application_duration' were not found
                                                                                        in any of the components of the system 'analytics_cluster'","path":null}
2022-05-02T16:12:10.261   -                                      -          license     2022-05-02 16:05:53.209 ERROR 1 --- [           main] c.a.m.services.CampaignService           : de9f5ff9-418e-4e25-ae2c-12fc8e72cafc
2022-05-02T16:32:07.216   -                                      -          license     2022-05-02 16:31:37.330 ERROR 1 --- [           main] c.a.m.services.CampaignService           : 06c4b858-8353-429c-bacd-0cc56cc44634
2022-05-02T16:38:18.522   -                                      -          campaign    Internal Server Error: Object of class [com.akamas.campaign_service.entities.campaign.experiment.Experiment] with identifier
                                                                                        [ExperimentIdentifier(workspace=ac8481d3-d031-4b6a-8ae9-c7b366f027e8, study=de9f5ff9-418e-4e25-ae2c-12fc8e72cafc, id=2)]: optimistic locking failed; nested exception
                                                                                        is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) :
                                                                                        [com.akamas.campaign_service.entities.campaign.experiment.Experiment#ExperimentIdentifier(workspace=ac8481d3-d031-4b6a-8ae9-c7b366f027e8,
                                                                                        study=de9f5ff9-418e-4e25-ae2c-12fc8e72cafc, id=2)]

This section covers some topics on how to manage the Akamas Server:

The following sections describe the procedure to upgrade your Akamas instance.

Docker compose Configuration

mv docker-compose.yml docker-compose.yml.bak
curl -O https://s3.us-east-2.amazonaws.com/akamas/compose/3.4.0/docker-compose.yml

You can point to a specific version. As an example to download the artifact for version 3.2.2:

curl -O https://s3.us-east-2.amazonaws.com/akamas/compose/3.2.2/docker-compose.yml

If the old docker-compose has been changed and it is still needed in the newer Akamas version, make sure to migrate such changes from docker-compose.yml.bak to the docker-compose.yml .

Then log in to AWS with the following command:

aws ecr get-login-password --region us-east-2 | docker login --username AWS --password-stdin 485790562880.dkr.ecr.us-east-2.amazonaws.com

If the login succeeds, then you can start the upgrade by running:

docker compose up -d

Wait for a few minutes and check the Akamas services are running the command:

akamas status -d

The expected output should be like the following (repeat the command after a minute or two if the last line is not "OK" as expected):

Checking Akamas services on http://localhost:8000
service       status
=========================
analyzer      UP
campaign      UP
metrics       UP
optimizer     UP
orchestrator  UP
system        UP
telemetry     UP
license       UP
log           UP
users         UP
OK

Online

Start by updating the local chart repository:

helm repo update akamas

Start online upgrade

Ensure your kubectl configuration points to the namespace where Akamas is installed or specify it with the --namespace parameter. To start the upgrade to the latest version:

helm upgrade akamas akamas/akamas

Offline

helm repo update akamas
helm pull akamas/akamas

Useful commands

Listing Akamas chart versions

Akamas' versions can be listed by running the following command:

helm search repo akamas/akamas --versions

It is always suggested to install and upgrade to the latest chart version. The App Version field refers to the Akamas version. To ease the release process multiple chart versions may refer to the same App Version.

Retrieving the Values file

In case you do not have access to the Values file used during the last installation/upgrade, you can still get it by running:

helm get values akamas -o yaml > akamas-values.yaml

Such a command is useful only if you need to change some of the parameters during the upgrade, otherwise the old Values file is kept by Helm.

Akamas server backup

The process of backing up an Akamas server can be divided in two parts, that is system backup and otherwise start Akamas. Backup can be performed in any way you see fit: they’re just regular files so you can use any backup tool.

System backup

System services are hosted on AWS ECR repo so the only thing that fully defines a working Akamas application is the docker-compose.yml file. Performing a backup of the Akamas application is as simple as copying this single file to your backup location. you may schedule any script that performs this weekly or at any frequency you see fit

User data backup

You may list all existing Akamas studies via the Akamas CLI command:

akamas list study

Then you can export all existing studies one by one via the CLI command

akamas export study <UUID>

where UUID is the UUID of a single study. This command exports into a single archive file (tar.gz). These archive files can be backed up to your favorite backup folder.

Akamas server recovery

Akamas server recovery involves recovering the system backup, restarting the Akamas service then re-importing the studies.

System Restore

To restore the system you must recover the original docker-compose.yml then launch the command

docker compose up &

from the folder where you placed this YAML file and then wait for the system to come up, by checking it with the command

akamas status -d

User data restore

All studies can be re-imported singularly with the CLI command (referring to the correct pathname of the archive):

akamas import study archive.tgz

To optimize a new application on Akamas you have to follow four steps shown in the following picture and described in the next sections by means of a simple example.

As depicted in the picture above, to optimize a new application you should:

• Create a system that models the key parts of your application (e.g. containers, runtimes, APIs) that will be interested in the optimization initiative.

• Set up the integration with a monitoring tool via telemetry providers so that Akamas can gather metrics about the performance of your application.

• Create a workflow that allows Akamas to configure your application (e.g. write a configuration file, relaunch a process).

• Define the optimization study according to your goal and SLOs so that Akamas knows what you want to achieve.

These steps relate to how Akamas integrates with your environment, described in this section, and apply to both offline and live optimization studies.

Example Application

In the following sections, we will use a simple yet representative web application to illustrate how to onboard a new application on Akamas. The application is called Online Boutique. It is a microservices application composed of 11 microservices that allow users to browse items, add them to the cart, and purchase them in an online store.

Suppose that we are about to deploy a major upgrade to one of the microservices, the Ad Service, that handles the advertisement logic, and we want to reduce the costs of running this service while meeting our SLO on the response time given an increasing number of users.

As shown in the diagram below, our service is built in Java, deployed as a pod in a Kubernetes cluster, and exposes an API using a service. The whole platform is monitored with Dynatrace.

You can now proceed to the first step, creating the system to model this application.

External tools

You can use any monitoring tool to check the availability of the Akamas instance.

Checking Akamas services

To check the status of the Akams services please run akamas status -d to identify which service is not able to start up correctly

Here is an example of output:

Checking Akamas services on http://localhost:8000
 service	 status
=========================
analyzer       	UP
campaign       	UP
metrics        	UP
optimizer      	UP
orchestrator   	UP
system         	UP
telemetry      	UP
license        	UP
log            	UP
users          	UP
OK

The third step in optimizing a new application is to create a workflow to instruct Akamas on the actions required to apply a configuration to the target application.

A workflow defines the actions that must be executed to evaluate the performance of a given configuration. These actions usually depend on the application architecture, technology stack, and deployment practices which might vary between environments and organizations (e.g. Deploying a microservice application in a staging environment on Kubernetes and performing a load test might be very different than applying an update to a monolith running in production).

Workflows are not tightly coupled to a study and can be re-used across studies and systems so you can change the optimization scope and target without the need to re-create a specific workflow.

Creating the workflow for Online Boutique

The workflow that we will create to allow Akamas to evaluate the configurations comprises the following actions:

1. Create a deployment file from a template

2. Apply the file via kubectl command

3. Wait for the deployment to be ready

4. Start the load test via locust APIs

Even if the integrations of this workflow are specific to the technology used by our test application (e.g. using kubectl CLI to deploy the application), the general structure of the workflow could fit most of the applications subject to offline optimization in a test environment.

Here is the YAML definition of the workflow described above.

Save it to a file named, as an example, workflow.yaml and then issue the creation command:

Here is what the workflow looks like in the UI:

Offline optimization studies are typically used to optimize systems in pre-production environments, with respect to planned and what-if scenarios that cannot be directly run in production. Scenarios include new application releases, planned technology changes (e.g. new JVM or DB), cloud migration or new provider, expected workload growth, and resilience under failure scenarios (from chaos engineering).

The following figure represents the iterative process associated with offline optimizations:

The following 5 phases can be identified for each iteration (also known as experiment):

5. Recommend Conf: Akamas AI engine identifies the configuration for the next iteration until a termination condition for the study is met (e.g. number of experiments).

Thanks to its patented AI (reinforcement learning) algorithms, Akamas can find the optimal configuration without having to explore all the possible configurations.

Trials

For each experiment, Akamas allows multiple trials to be executed. A trial is a repetition of the same experiment to reduce the impact of noise on the result of an experiment.

Environments can be noisy for several reasons such as:

• External conditions (e.g. background jobs, "noisy neighbors" in the cloud)

• Measurement errors (e.g. monitoring tools not always 100% accurate)

This approach is consistent with scientific and engineering practices, where the strategy to minimize the impact of noise is to repeat the same experiment multiple times.

Steps

An offline optimization study can include multiple steps.

Typically there are at least two steps:

• Baseline step: a single experiment that is run by applying the already deployed configuration before the Akamas optimization is applied - the results of this experiment are used as a reference (baseline) for assessing the optimization and as such is a mandatory step for each study

• Optimize step: a defined number of experiments used to identify the optimal configuration by leveraging Akamas AI.

Other steps are:

• Bootstrap step: imported experiments from other optimization studies

• Preset step: a single experiment with a defined configuration

The steps to be executed can be specified when defining an offline optimization study.

Commands

User Interface

The Akamas UI shows offline optimization studies in a specific top-level menu.

The details and results of an offline optimization study are displayed when drilling down (there are multiple tabs and sections).

After modeling the system and its components, the following step is to set up the telemetry. Telemetry is essential to provide Akamas with enough data to evaluate a configuration both in terms of goal (e.g. reducing the cost) and constraints (e.g. meeting SLOs).

To instruct Akamas about the location of the data sources and how to access them, you can create a telemetry instance for your system. A telemetry instance comprises the following properties:

• Name: An optional unique name within the system to quickly identify it.

• Provider: The name of the telemetry provider that will be used to gather metrics.

• Config: Additional configuration options that depend on the provider (e.g. a URL to reach the observability tool or the location of a CSV file to import) refer to each provider reference for more information.

A system can include multiple telemetry instances from different providers (e.g. in case you need to extract some information from Dynatrace and others from a CSV file).

Components and Telemetry

Each telemetry provider supports a unique set of properties that depends on the specific data source which allows Akamas to map each component to one or more entities in the observability tool and extract the right metrics for that particular technology.

Creating a telemetry instance for the Online Boutique

In this file, we specified the URL and the token required to authenticate to our Dynatrace instance.

Save it to a file named, as an example, instance.yaml and then issue the command.

As described in the section above, telemetry instances are coupled to a specific system. For this reason, we had to provide the name of the system Online Boutique as an argument to the create command.

Here is how the telemetry instance looks in the UI.

Mapping Components

Akamas needs to be informed that the component named Adservice used in the system maps to a specific entity in Dynatrace that represents the container running in the Kubernetes cluster.

Recalling the definition of the Adservice component in the system we see that it contains a set of properties starting with the dynatrace keyword. These properties are used by the Dynatrace telemetry provider to map the component to the correct entity and import metrics such as CPU usage and throttling that can be used to gather information about the performance of such components.

Even for live optimization studies, it is a good practice to analyze how the optimization is being executed with respect to the defined goal & constraints, and workloads.

This analysis may provide useful insights about the system being optimized (e.g. understanding of the system dynamics) and about the optimization study itself (e.g. how to adjust optimizer options or change constraints). Since this is more challenging for an environment that is being optimized live, a common practice to adopt a recommendation mode before possibly switching to a fully autonomous mode.

The Akamas UI displays the results of an offline optimization study in the following areas:

• the Metrics section (see the following figures) displays the behavior of the metrics as configurations are recommended and applied (possibly after being reviewed and approved by users); this area supports the analysis of how the optimizer is driven by the configured safety and exploration factors.

• The All Configurations section provides the list of all the recommended configurations, possibly as modified by the user, as well as the details of each applied configuration (see the following figures).

• in the case of a recommendation mode, the Pending configuration section (see the following figure) shows the configuration that is being recommended to allow users to review it (see the EDIT toggle) and approve it:

A critical aspect, when evaluating the performance of an application, is to make sure that the data we use is accurate. It's quite common for IT systems to experience some transient periods of instabilities; these might occur in many situations such as filling up caches, runtime compilation activities, horizontal scaling, and much more.

A common practice, in performance engineering, is to exclude from the analysis the initial and final part of a performance test to consider only the time when the system is in full operation. Akamas can automatically identify a subset of the whole data to evaluate scores and constraints.

Looking at the example below, from the Online Boutique application, we see that the response time has an initial spike to about 7ms and then stabilizes below 1ms; also the CPU utilization shows a similar pattern.

This is quite common, as an example, for Java-based systems as, in the first minutes of operations activities like heap resizing and just-in-time compilation take place. In this case, Akamas considered in the evaluation of the experiment only the gray area effectively avoiding the impact of the initial spike.

This behavior can be configured in the study by specifying a section called windowing. Two windowing policies allow you to properly configure Akamas in different scenarios.

The windowing section in the study definition is optional and the default policy considers all the available data to evaluate the performance of the experiment.

Now that Akamas knows about your application, how to configure it, and how to monitor it, the final step is to define your optimization study.

The study defines the objective of the optimization activity. It contains information about what we want to achieve (e.g. reduce costs, improve latency..), the parameters that can be optimized, and any SLO that should not be breached by the optimized configuration.

Studies are divided into two main categories:

The setup of both studies is similar as both are constituted by the following core elements:

• Name: A unique identifier that can be used to identify different studies.

• System: The name of the system that we want to optimize.

• Workflow: The name of the workflow that will be used to configure the application.

• Goal: The objective of the optimization (e.g. minimize cost, maximize throughput, reduce latency).

• Parameter Selection: A list of parameters that will be tuned in the optimization (e.g. container memory and CPU limits, EC2 instance family..).

• Steps: The flow of the optimization study (e.g. assessing the baseline performance, optimizing the system, restoring the configuration).

Goal

The goal defines the objective of our optimization. Specifying a goal is as simple as defining the metric we want to optimize and the direction of the optimization such as maximizing throughput or minimizing cost. If you want to optimize more complex scenarios or lack a single metric that represents your objective you can also specify a formula and define a goal such as minimizing memory and CPU utilization.

Metrics are identified within a study with the following notation component.metric_name where component is the name of a component of the system linked to the study and metric name is the name of a metric. As an example, the CPU utilization of a container might be identified by MyContainer.cpu_util.

Parameter Selection

The parameter selection contains the list of parameters that are subject to the optimization process. These might include several components and layers, as in the following example.

Similarly to metrics, components are defined with the notation component.parameter_name.

Optionally, you can also specify a range of values that can be assigned to the parameter. This is very useful when you want to evaluate a specific optimization area or want to add some context to the optimization (e.g. avoid setting a memory greater than 8GB because it's not available on the system).

The parameter selection can include any component and parameter of the system. During the optimization process, Akamas will provide values for those parameters and apply them to the system using the workflow provided in the study definition.

Steps

If the goal describes where we are heading, steps describe the road to get there. Usually, when optimizing an application we want to assess its performance before the tuning activity to evaluate the benefits; this initial assessment is called the Baseline. Then, we want to run the optimization process for a definite number of iterations, this is called an Optimization step. Many other use cases can be achieved by providing additional steps to the study. Some of these include:

• Re-using knowledge gathered by other optimization studies

• Applying the baseline configuration to the test environment after the optimization has ended

• Evaluating a specific configuration suggested by the user

Optimizing the Online Boutique

As shown in the image below, you can use the study creation wizard in the UI to specify all the required information.

If you prefer to define it via YAML you can use the following file.

name: Reduce Costs
system: Online Boutique
workflow: Configure and Test Boutique

goal:
  objective: minimize
  function:
    formula: Adservice.cost
  constraints:
    absolute:
      - name: response_time
        formula: Apis.requests_response_time <= 20

parametersSelection:
  - name: Adservice.cpu_limit
    domain: [150, 1000]
  - name: Adservice.memory_limit
    domain: [64, 2048]
  - name: AdserviceJVM.jvm_maxRAMPercentage
  - name: AdserviceJVM.jvm_gcType

steps:
  - name: baseline
    type: baseline
    values:
      Adservice.cpu_limit: 500
      Adservice.memory_limit: 1024
      AdserviceJVM.jvm_maxRAMPercentage: 25

  - name: optimize
    type: optimize
    numberOfExperiments: 30

Save it to a file named, as an example, study.yaml and then issue the command

akamas create study study.yaml

This study's definition contains three main parts.

The goal

The parameters selection

The steps

This final section instructs Akamas to first assess the performance and costs of the current configuration, which we will refer to as the baseline, then run 30 experiments by changing the parameters to optimize the goal.

You can now start your optimization study and wait for Akamas to find the best configuration!

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

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.

Offline optimizations

Live optimizations