Introduction

This blog describes the most common issues that customers are experiencing in on-premises SAP Commerce deployments. It gives a concrete way to achieve blue/green deployments on Amazon Elastic Kubernetes Service to have faster and more secure implementations of SAP Commerce applications.

The deployment procedure is based on what is described in the SAP official documentation regarding performing rolling update on the cluster.

The SAP Commerce application is deployed with an Helm Chart that supports blue/green deployment strategy.
The deployment is then automated with a simple Continuous Integration and Continuous Delivery/Continuous Deployment (CI/CD) pipeline using AWS CodeCommit, AWS CodePipeline, and AWS CodeBuild.

Assumptions

This blog assumes that the required infrastructure to run SAP Commerce has already been provisioned.
It is expected that the following components have been already deployed and configured:

• An Amazon Virtual Private Cloud (VPC) with public, private, and isolated subnets has been created.
• Amazon EKS cluster has been provisioned in the defined Amazon VPC.
• The AWS Load Balancer Controller has been deployed in the Kubernetes cluster
• An Amazon Route53 public-hosted zone has been created.
• The ExternalDNS configured with the created Amazon Route53 hosted zone has been deployed in the Kubernetes cluster.
• An Amazon RDS for MySQL has been provisioned in the Amazon VPC subnets and it’s reachable from the private subnets.
• A database schema in the MySQL database has been created for SAP Commerce.

Deployment challenges in on-premise environments

SAP Commerce is a popular e-commerce platform provided by SAP and consists of an enterprise java web application.

Traditionally, in on-premises environments, SAP Commerce is deployed in a mutable infrastructure of servers or VMs. An SAP Commerce production environment consists of several application server nodes to scale to customer demands.

The automated CI/CD pipeline performs a rolling update strategy at the cluster node level at every new release.
Sequentially each node is removed from the Load Balancer to avoid serving customer requests, and upgraded to the new release.
After the node upgrade, the node is included back to the Load Balancer, and it’s ready to serve customer requests using the codebase of the new release.

SAP Commerce deployment in on-premises environment

Since the cluster consists of several application nodes, the deployment can take several hours before the completion and have all the cluster nodes upgraded to the new version.

Long running deployments are a significant obstacle for e-commerce business and marketing teams that need to quickly cope with innovative solutions to remain competitive and thriving on the market.

The solution with blue/green deployments

By running SAP Commerce workloads on Amazon EKS, it is possible to implement multiple deployment strategies, including blue/green deployments.

The blue/green deployment technique enables to release of applications by shifting traffic between two identical environments that are running different versions of the application.
Blue/green deployments can mitigate common risks associated with deploying software, such as downtime and rollback capability.

Blue/Green deployment approach of a SAP Commerce application

The deployment procedure

Before a new release (v2) is deployed, only one release (v1) actually is deployed in the cluster.

Blue/Green deployment step one

At the database level, using SAP Commerce type system definitions allows handling multiple schema modifications related to multiple codebases of different releases on the same database schema.

When the new (v2) release is deployed, two Kubernetes jobs are created in sequence to:

• create a new type system for the latest release (v2)
• perform a system update on the new type of system (v2)

Blue/Green deployment step two

With blue/green deployment strategy, the new release (v2) is then deployed in the new green slot alongside the current version (v1), in the Amazon EKS cluster.

Both versions are then available simultaneously in different slots (blue and green) in the same production environment.
At this moment, the end customers continue to browse the current production release (v1) on the blue slot, and the testing team can access the new release (v2) on the green slot to enforce the testing strategies.

Blue/Green deployment step three

When the new release (v2) can be promoted to become productive, a switch is performed at the load balancer to direct the end customer request to the green slot and the old release (v1) to the green slot.
End customers can immediately access the application on the new release (v2) at the full scaling.

Blue/Green deployment step four

The old release (v1) is still available in the cluster and can be switched back to production in case of problems on release v2. Otherwise. it is possible to decommission the blue slot to free up the resources and allow to perform deployments of new releases.

Blue/Green deployment step five

The artefact

The artefact consists of a Helm chart to handle the application deployment and a CI/CD pipeline definition to automate the deployment process.

The Helm chart

A Helm chart has been implemented to support blue green deployments strategies with SAP Commerce on Kubernetes (AmazonEKS).
The Helm chart comes with a set of scripts to perform installation and upgrade the helm chart in the CI/CD pipeline deployment automation.

The helm chart

The deployment pipeline

A pipeline has been defined to use AWS CodePipeline and AWS CodeBuild to install and upgrade the helm chart to deploy the SAP Commerce application.

The pipeline is created and started when a release-* branch is created in AWS CodeCommit.
To support a multi-branch strategy with AWS CodePipeline, this solution has been adopted.

The deployment pipeline

Important Notes

The helm chart supports the creation of Kubernetes Namespace and Kubernetes Service Account.
This blog assumes that these resources are created as prerequisites of the helm chart installation.
Additional logic can be implemented while designing the pipeline to handle the creation of the Namespace and Service Account when deploying the helm chart.

When deploying for the first time the helm chart, it is assumed that the Type System of the first release is DEFAULT. This allows us to deploy without the need to create a dedicate type system for that release. The next release will be deployed in specific Type Systems that are created before the release is deployed with the same name of the release.

It is assumed that the Type System of the new release is not existing in the database. This means that when deploying a new release, a new Type System is always created.
When designing your own pipeline a mechanism must be implemented to ensure that the Type System for the new release is created only when necessary (eg; using an AWS Lambda Function).

Installation Guide

To setup the SAP Commerce deployment pipeline for blue/green deployments, please follow the installation guide available in the github repository.
Please make sure to follow the cleanup instruction to remove all the AWS resources and avoid incurring into additional costs.

Conclusion

A blue/green deployment strategy can be a game changer to speed up the deployment of new releases in e-commerce contexts.
I hope this blog can help you to get some insights to modernize and improve your SAP Commerce deployment pipeline.

Next Steps

This blog describes a simple proof of concept to deploy an SAP Commerce application with helm and a simple deployment pipeline.
To manage a production workload of SAP Commerce, additional steps including monitoring, observability, security, and performance tuning, are required.