Skip to content
  • There are no suggestions because the search field is empty.

Quick Start Guide

This document will help you get familiar with DataLark.

Select the relevant version for your installation.

v1.1.59.12 (May 23, 2025) and later

v1.1.59.12 (May 23, 2025) and later

AWS Infrastructure Deployment

Version 1.1.59.12 (May 23, 2025) and later

This article describes requirements, architecture, and deployment options for running the Migravion backend in an Amazon Web Services (AWS) Kubernetes environment.

Introduction

One of the options for using Migravion by a client is to deploy its backend to a Kubernetes cluster owned by him. This document describes requirements and options for the setup of such a cluster in the Amazon Web Service (AWS) cloud.

Infrastructure setup

There are three options of application's deployment to a Kubernetes cluster:

  • Deployment to an existing Kubernetes cluster already managed by the client in his AWS account.
  • Deployment of a new Kubernetes cluster as Elastic Kubernetes Service (EKS) integrated with existing client's resources in his AWS account.
  • Deployment of a whole new landscape in a client's AWS account.

The first two options can be implemented only by the client. The product team can provide some recommendations for the process but the resource deployment should be done by the client's team.

The third option can be implemented in two ways:

  • The client's team deploys the landscape in his AWS account, using their own approach or using Terraform code and commands provided by the product team and described further.
  • The product team deploys the landscape in the client's AWS account using Terraform code and commands provided by the product team and described further. This option has some prerequisites described later in this article.

DNS and SSL certificates

The default configuration of the Migravion backend deployment described here implies its public networking accessibility. The access to the application itself is protected by an authentication process.

The traffic to the backend should be encrypted and thus the backend is accessible only through the HTTPS protocol. Public DNS configuration and certificates are needed accordingly.

The setup might require from 1 to 3 unique DNS records pointing at the same public IP address:

  • For the Migravion backend application (obligatory).
  • For the Connectivity Proxy service (optionally, only when the service is used).
  • For the monitoring setup (optionally, only when the setup is used).

There are two options for implementing the DNS configuration:

  • The client creates DNS records in his registrar pointing to the ingress IP address of the landscape and provides the FQDN of the created records to the product team. The product team uses them to configure and deploy the Kubernetes manifests for the application.
  • The client provides the product team with a DNS zone that can be delegated. The product team deploys a Route53 public DNS zone with the provided name in the client's AWS account and provides the client with the name servers of the created zone. The client adds the name servers in his registrar for delegating the zone to those servers. Then the product team created required DNS records in the Route53 zone. For example, the client mainly uses the DNS zone mycompany.com and can delegate the subzone like migravion.mycompany.com. The product team creates such a public DNS zone in the Route53 service and creates required records for subdomains, for example, be.migravion.mycompany.com.

After the DNS records are set up the SSL certificates for the used FQDN(s) should be provided. There are also two options:

  • For each of the DNS names used the client provides a valid SSL certificate (and its private key) as files or as a Kubernetes secret (of the TLS type).
  • The product team deploys CertManager service to the Kubernetes cluster and uses it to issue and automatically periodically renew SSL certificates using the LetsEncrypt provider. The CertManager automates certificate management but requires access to the internet to get certificates from the LetsEncrypt provider.

AWS infrastructure

Proposed infrastructure diagram

The diagram of an infrastructure in the AWS cloud for the Migravion application deployment with a minimal footprint:

AWS Infrastructure Diagram
Figure 1: AWS Infrastructure Diagram

Proposed infrastructure description

The proposed landscape for a client's Migravion environment in AWS contains the following main components:

  • A VPC with two Subnets:
    • A public one for NAT Gateway and Network LoadBalancer
    • A private one for EKS nodes
  • Network LoadBalancer for receiving inbound connections from the internet.
  • NAT Gateway to provide outbound connectivity for the private Subnet.
  • Internet Gateway to provide outbound and inbound connectivity for the public Subnet.
  • EKS cluster spawned across two Availability Zones (AZ) for additional fault-tolerance.
  • Elastic File System (EFS) for the EKS to spawn File Shares backing ReadWriteMany PersistentVolumeClaims.
  • Route tables to route the outbound connections through the gateways.
  • IAM roles that provide permissions for interactions between the components.
  • Route53 DNS zone and records (optional) for application's DNS.

After infrastructure deployment the EKS cluster is populated with the following add-ons and services:

  • Metrics server - using official Helm chart, needed for monitoring, pod autoscaling and top commands.
  • Pod identity add-on - as an EKS add-on, is needed for pods to securely access AWS services without storing and using credentials.
  • Cluster autoscaler - using official Helm chart, to implement node autoscaling for the EKS cluster.
  • AWS Load Balancer Controller - using official Helm chart, to enable the EKS cluster to configure a Load Balancer for implementing its services of type LoadBalancer.
  • HAProxy ingress controller - using official Helm chart, to implement the application ingress inside the EKS cluster.
  • CertManager - using third-party Helm chart, optional, to issue and renew SSL certificates using the LetsEncrypt provider.
  • EBS CSI driver - as an EKS add-on, to implement usage of the EBS volumes for the ReadWriteOnce PersistentVolumeClaims.
  • EFS CSI driver - as an EKS add-on, to implement usage of the EFS File Shares for the ReadWriteMany PersistentVolumeClaims.

After deployment of infrastructure and application the EKS cluster can scale out nodes if the default single node's resources are not enough.

Resource dependencies

  • EKS cluster's nodes use Network LoadBalancer for receiving incoming traffic.
  • EKS cluster uses EFS for creating File Shares that back the ReadWriteMany PersistentVolumeClaims.
  • NAT Gateway manages outbound traffic for the EKS cluster's nodes.
  • Internet Gateway manages traffic between the Network LoadBalacer and the internet.

Custom deployment

The Migravion application is containerized and can be deployed to a Kubernetes cluster that wasn't created using the approach provided by the product team (the existing-cluster deployment options). It has the following prerequisites to be deployed to an existing Kubernetes cluster or to an EKS cluster deployed in any other way:

  • The Kubernetes cluster should support StorageClass that provides ReadWriteMany volumes for PersistentVolumeClaims (its name should be provided to the product team if it differs from efs).
  • The Kubernetes cluster should support StorageClass that provides ReadWriteOnce volumes for PersistentVolumeClaims (its name should be provided to the product team if it differs from default).
  • Provide a dedicated namespace for deploying application objects.
  • The Kubernetes cluster should have an HAProxy-based ingress controller deployed or allow deploying such an ingress controller (some of the application ingress objects use HAProxy's annotations).
  • DNS records mentioned above pointing at the Kubernetes cluster's ingress.
  • In case the client won't provide the SSL certificates for the DNS records mentioned above, then the Kubernetes cluster should allow deploying CertManager service (or have it already deployed and serving ingresses).

Managed deployment

The product team can deploy the required resources into a client's AWS account. In order to do that the client's team should provide the product team with corresponding permissions. The preferred way here is for the client to create a new empty AWS account and provide the product team with the role that has elevated access for the period of deployment (this improves security, simplifies access management and provides application isolation). However if using a new empty account is not an option the product team will provide a list of required AIM policies.

The role can be provided in two ways:

  • Create a dedicated user in the client's AWS account for the product team.
  • Delegate the role for the product team's AWS account users so that they could assume the delegated role.

After resources and application are deployed and proved to work then the access for the product team to the client's AWS account is revoked by the client after the deployment is complete. It can be done in several steps proposed by the product team.

Cluster size

By default the Migravion environment is planned to fit one node with 2 CPU and 8 GB of RAM. That is the size of the node for the EKS cluster deployed by default - selected to fit the basic application requirements.

If the EKS cluster is deployed using Terraform code provided by the product team then it has node autoscaling enabled. It allows extension of the application containers' resource boundaries without changing the node size but occupying more than one node (the product team's code allows the EKS cluster to scale-out up to 3 nodes).

For more dense workloads the node size should be reconsidered. Since application resource consumption may change from project to project considerably we recommend using monitoring while experimenting with the containers' resource boundaries.

Deploying infrastructure using Terraform

Prerequisites

The following tools are needed to deploy the infrastructure code:

  • Terraform - version 1.9.8
  • Terragrunt - version 0.72.9

Infrastructure code description

The product team provides a pack of Terraform code for deploying the resources shown in the Proposed infrastructure diagram in the AWS cloud. The code consists of the following folders:

  • modules/client_env - contains subfolders with three modules used to deploy resources:
    • a module with the networking layer that contains VPC, Subnets, Gateway and others (vpc)
    • a module with the EKS cluster layer that contains the cluster and corresponding IAM roles (eks)
    • a module with add-ons deployed to the EKS cluster and corresponding IAM roles (kubernetes-addons)
  • deployment/<client_name> - contains Terrugrunt root module that deploys modules described above.

The listed root folders (modules and deployments) should be put one beside the other. In case the code is organized in a different way the terragrunt.hcl files in the Terrugrunt root module subfolders should be updated: the source = "" paths should be pointing at the corresponding module subfolders.

Infrastructure code deployment

To plan the deployment of all modules run the following command in the deployment/<client_name> path:

terragrunt run-all plan

To apply the deployment run:

terragrunt run-all

Pay attention that this command leads to resource deployment/update and may result in costs incurred for the resources in the client's AWS account.

Also each module can be planned and deployed individually by running the following commands in the corresponding module subfolder (vpc, eks or kubernetes-addons):

terragrunt plan
terragrunt apply

Check the terragrunt.hcl files in the Terrugrunt root module subfolders for the environment parameters that can be tuned.

Application deployment

The Migravion application is deployed to the client's Kubernetes cluster using a pack of Helm charts and is done by the product team. Some configurations from the client's side might be needed to do the deployment.

The application uses container images stored in a Container Registry supported and populated by the product team. The access to the registry is provided using a Kubernetes secret.

Core application deployment

Application deployment is mostly done by the product team. If an existing EKS cluster is used to deploy the application or the EKS cluster is deployed not by the product team then the product team should be provided with a Kubernetes config that allows deployment of any resources to specified namespaces (one for the application and another one for the monitoring if it is deployed).

If the client's team provides the DNS SSL certificate(s) for the domain name(s) then it should provide corresponding files to the product team or create Kubernetes secrets in the corresponding namespaces and provide secret names to the product team: one secret for the application ingress and one per monitoring and Connectivity Proxy ingresses if any of them is required.

The product team hands over the deployed application to the client when the application has been checked to be accessible and working.

Connectivity Proxy deployment

The Migravion application has an optional component, Connectivity Proxy, that can be used to connect the application with some SAP workloads through a special connectivity endpoint in SAP Business Technology Platform (BTP).

The product team deploys the Connectivity Proxy along with the core application services in case it is requested by the client. In that case the client provides required configuration parameters. List of the parameters and their source will be provided by the product team.

The Connectivity Proxy deployment also requires its own DNS name (one of the DNS names mentioned in the DNS and SSL certificates section) and may require the client to provide an SSL certificate for it (if the CertManager option is not used).

Monitoring

At a certain point the resource boundaries of the application containers might become too low and their tuning might be required. Using pod metrics acquired from a monitoring system can be helpful for that. An existing client's monitoring system can be used for that or, as an option, the product team can deploy a monitoring stack to the client's EKS cluster.

We recommend deploying the monitoring services to a dedicated namespace.

Monitoring deployment also requires its own DNS name (one of the DNS names mentioned in the DNS and SSL certificates section) and may require the client to provide an SSL certificate for it (if the CertManager option is not used).

Monitoring deployment contains the following main components deployed using corresponding official Helm charts:

  • Prometheus (Deployment) - for storing node and pod metrics. A single binary deployment is enough for the application scale.
  • NodeExporter (DaemonSet) - for collecting node and pod metrics on pods and providing them to the Prometheus.
  • Grafana Loki (StatefulSet) - for storing node and pod logs. Also as a single binary deployment.
  • Promtail (DaemonSet) - for collecting node and pod logs and pushing them to the Grafana Loki.
  • Grafana Tempo (StatefulSet) - for storing application traces.
  • AlertManager (StatefulSet) - for implementing alerts based on the metrics stored in the Prometheus.
  • Grafana (Deployment) - for providing dashboards that visualize metrics, logs and traces queried from the Prometheus/Loki/Tempo.

Main dashboards provided in the Grafana:

  • Main node metrics (CPU, RAM, disks, networking).
  • Main container metrics (CPU, RAM, disks, networking) - provides container metrics based on the namespace, pod and container names.
  • Container logs - provides container logs (stdout and stderr streams) filtered by the namespace, pod and container names.
  • Node system logs.
  • Application traces.

To implement alerts the client should provide a channel for broadcasting them, like a SMTP server or a Slack channel with a bot or any supported by the AlertManager, and recipients. Main alerts implemented in the AlertManager:

  • High CPU usage in a pod.
  • High RAM usage in a pod.
  • High volume usage in a pod.
  • If a pod is not healthy.