Companies that create a culture of innovation are more competitive. If you’re not planning ahead, market advantages that you had just a few months ago can suddenly disappear. And getting great ideas out quickly is the key. In practice, there’s a lot of undifferentiated heavy lifting that stands between your idea and that success. One solution to this problem is the shift to higher levels of abstraction than virtual machines (VM). However, moving to Kubernetes can be a big cultural shift. In this blog post, we show how you can quickly pivot from an SAP Commerce system based on Amazon EC2 discussed in our previous blog post into one based on Kubernetes.

Overview

We start with the deployment and explain why the Amazon Cloud Development Kit (CDK) is so powerful for infrastructure as code. Then we discuss the fully managed control plane and node group and how these features free us from undifferentiated heavy lifting. Finally, we show you how easy it is to deploy a containerized SAP Commerce application into the Amazon Elastic Kubernetes Service.

Prerequisites

1. Download the SAP Commerce software from SAP and place in an Amazon S3 bucket
2. Containerize SAP Commerce. You can refer to the SAP commerce repository in the AWS sample GitHub to automate this. Just select the option to create Docker image and this will automatically upload an image to Amazon Elastic Container Registry (ECR).

Deployment of SAP Commerce on Amazon EKS using AWS Cloud Development Kit

To provision the infrastructure and deploy SAP Commerce, we will start by cloning the sample code from the CDK for SAP example repository in the AWS sample GitHub. You can set up the AWS CDK using the “Getting started with the AWS CDK” guide or follow the README in the GitHub repository. While we wait for the deployment to finish, let’s deep dive into some concepts we’ve used.

Cloud Development Kit

In our previous blog, we used AWS Cloudformation for the SAP Commerce deployment on Amazon EC2. We have pivot to CDK in this blog post, and let’s take a look at why we’ve done this. Here’s the code to deploy a Amazon Virtual Private Cloud (VPC) using CDK in Typescript.

    this.vpc = new ec2.Vpc(this, "VPC", {
      maxAzs: 3,
      cidr:"10.20.0.0/16",
      subnetConfiguration: [
        {
          cidrMask: 24,
          name: 'commerce-public',
          subnetType: ec2.SubnetType.PUBLIC,
        },
        {
          cidrMask: 24,
          name: 'commerce-private',
          subnetType: ec2.SubnetType.PRIVATE,
        },
        {
          cidrMask: 24,
          name: 'commerce-database',
          subnetType: ec2.SubnetType.ISOLATED,
        }
      ],
      natGateways: 2,
    });

As you can see, this is really simple. We have gone from 453 lines of code in AWS Cloudformation down to 31 lines of code by leveraging the VPC construct. You can see why the AWS CDK has taken the community by storm. You can just use the programming language that your DevOps team is already familiar with. Here, we are using Typescript but AWS CDK lets you define your infrastructure using JavaScript, JAVA and Python as well. It’s a truly exciting area and there are many new constructs, patterns and programming languages added frequently.

Control Plane

The control plane is the Kubernetes’ brain—it has a holistic view of every container and pod running on the cluster. In the past, this management required very specialized skillsets. With Amazon EKS, all you need is the CDK code snippet below to deploy the control plane. Amazon EKS then runs the Kubernetes control plane instances across multiple Availability Zones (AZ) to ensure high availability (HA). In addition, it automatically detects and replaces unhealthy control plane instances, and it provides automated version upgrades and patching for them.

And here’s the code to do this in CDK:

    //Create EKS cluster
    this.cluster = new eks.Cluster(this, "Cluster", {
      vpc: vpc,
      defaultCapacity: 0,
      version: eks.KubernetesVersion.V1_17,
      outputMastersRoleArn: true,
      outputClusterName: true,
    });

Managed Node Groups

In addition to the control plane, we are going to deploy a managed node group. With Amazon EKS managed node groups, you don’t need to separately provision or register the Amazon EC2 instances that provide compute capacity to run your Kubernetes applications. All managed nodes are provisioned as part of an Amazon EC2 Auto Scaling group that is managed for you by Amazon EKS.

And here’s the code to do this in CDK.

    //Add node group 
    this.cluster.addNodegroupCapacity("nodegroup", {
      instanceType: new ec2.InstanceType("c5.2xlarge"),
      minSize: 2,
      maxSize: 8,
      subnets: { subnetType: ec2.SubnetType.PUBLIC },
    });

Deploy Aurora Serverless Database

In 2017, we announced the certification of Amazon Aurora for SAP Hybris. In this example, we are using Amazon Aurora Serverless. As mentioned in previous blog, this is an on-demand, auto-scaling configuration for Amazon Aurora. The database will automatically start up, shut down, and scale capacity up or down based on your application’s needs. It enables you to run your database in the cloud without managing any database instances and is ideal for the non-production environment. Learn more about using Amazon Aurora Serverless by reading the documentation.

Again, the CDK code snippet is really simple. This serverless construct in the cdk-rds module was released at the time of writing this blog post. That’s just impeccable timing as this saved us writing at least 100+ lines of code.

Deploy SAP Commerce image

Let’s deploy SAP Commerce Docker image into this cluster. There are many ways to deploy a Docker image into a cluster using AWS CDK, such as Helm chart or CDK8s Charts. Here we are using the construct cluster.addManifest to apply Docker image to this cluster as we have kept our manifest very simple.

The deployment output includes a number of important output for you to access the EKS cluster. ClusterConfigCommand shows the command to update the kubeconfig, which allow you to run different kubectl command. cdk-eks.eksloadbalancer shows the Application Load Balance (ALB) hostname that you can use to login to the hybris administration console. You will need to add the port number 8088 to access the URL.

Clean up

Cleaning up the infrastructure is easy, just run the cdk destroy command. But don’t forget your SAP binaries in Amazon S3 or your container image on Amazon ECR, which needs to be deleted separately.

Conclusion

We discussed in our previous blog post the importance of an evolving architecture. In this blog post, we show you how to pivot the SAP Commerce architecture into one based on Kubernetes. Also, we have changed the deployment methodology from AWS CloudFormation into AWS CDK.

We have 85 lines of code for the Amazon EKS stack, 37 lines of code for the Amazon RDS stack and 37 lines of code for the Amazon VPC stack, a total of less than 160 lines of code to deploy a simplified SAP Commerce application in a Kubernetes cluster. This really is how simple it is, and demonstrates how far AWS has come to help customers reduce the undifferentiated yet all-important “heavy lifting” needed to create and operate a web application.

This is just a glimpse of what Amazon EKS can do for your development, and we will follow up with another blog to deep dive into the specific details on clustering SAP Commerce on Amazon EKS, so stay tuned to the SAP on AWS blog. We hope you that you find this interesting and have as much fun as we did. Download the code and give it a try. If you have questions or would like to understand the options for your SAP systems, please contact us at sap-on-aws@amazon.com or visit aws.com/sap to learn more. Start building on AWS today and have fun!