Hosting SAP Hybris Commerce on AWS with Piksel Retail

By Jonathan Kirby, General Manager at Piksel Retail
By Michal Stypik, Technical Architect at Piksel Retail

In many retail environments, SAP Hybris Commerce is deployed into production in what could best be described as a traditional way. Hybris Commerce is implemented as a static cluster with in-place code releases, meaning that any configuration changes require files to be replaced or updated on a running server. Updates need careful release planning, downtime needs to be well managed, changes are implemented behind a holding page, and the whole process can be highly disruptive.

Some organizations have opted to migrate SAP Hybris Commerce to the cloud, but have done so through “lift and shift” methods. This means it has been moved to the cloud, but not re-architected in the process. As a result, the platform runs in almost exactly the same way it would in an on-premises environment.

At Piksel Retail, a Piksel Group company, we recently created the Digital Commerce Channel (DC2) to address these challenges. DC2 is our SAP Hybris-based e-commerce solution, deployed on Amazon Web Services (AWS).

Piksel Group is an AWS Partner Network (APN) Advanced Consulting Partner with the Amazon CloudFront Service Delivery designation. We specialize in the design, implementation, and management of cloud technology solutions for major retailers with global portfolios. Piksel Group works with some of the biggest names in UK retail to help them tap into the inherent cost, speed, and agility benefits of the AWS Cloud.

Piksel Retail’s DC2

DC2 provides comprehensive infrastructure management, low maintenance overhead, and a platform for the rapid development and deployment of customer code.

Our aim with DC2 is to re-architect SAP Hybris Commerce for the cloud and provide customers with a more compelling way of deploying Hybris Commerce that takes advantage of the features of the AWS Cloud, such as elasticity and scalability. To achieve this, we built DC2 from the ground-up to be a fully-automated, Infrastructure-as-Code approach to deploying Hybris Commerce on AWS.

Changes to both the infrastructure and application code are managed in a continuous delivery pipeline. That doesn’t mean we deploy to production every day; simply that we run the platform in such a way that applications and infrastructure can be deployed at any point we choose. Releases that affect the Hybris Commerce platform and custom extensions are managed separately.

Faster Provisioning of Hybris Commerce Components

Hybris Commerce is shipped with install tools that allow you to build components, accelerators, and a back-office environment. The actual server build is typically initiated on a running server. Because we built DC2 as immutable infrastructure, servers need to be re-deployed in order to apply code releases. While this would traditionally be a time-consuming manual process, it’s one that has been automated within DC2 and is incredibly useful for automatic scaling, automation, security, and an all-around streamlined deployment process.

One of the tools we used is Terraform, which helped us achieve fast infrastructure provisioning, code versioning, and to create the phoenix environments we need for development and blue-green deployments.

The DC2 template enables the deployment of AWS Auto Scaling Groups. We use scheduled horizontal scaling by default, but we are currently working on solutions for dynamic, demand-based auto scaling.

SAP Hybris Commerce tends to have a relatively lengthy start-up cycle—default installation on our lab environment takes more than five minutes to start. We have invested heavily into ways to reduce Java Virtual Machine (JVM) start-up time, also we build one Amazon Machine Image (AMI) for all server roles, like storefront and back-office, but these are started differently. Storefront is started without any of back-end services which decreases JVM star-up time dramatically.

On our roadmap, we are investigating solutions to improve the solution to be more dynamic and on-demand, including deploying into Kubernetes, Amazon Elastic Container Service (Amazon ECS), and Amazon Elastic Container Service for Kubernetes (Amazon EKS). We’re also looking at adding additional features for blue-green deployment (including canary deployments) and caching (eliminate cold start SAP/Hybris nodes ).

Example of Hybris ASG Build in Terraform

module "hybris" {
  source = "git::ssh:/…/infrastructure-modules.git//hybris?ref=v0.1.6"
 
  stage        = "${var.stage}"
  default_tags = "${var.default_tags}"
 
  vpc_id          = "${data.terraform_remote_state.network_state.vpc_id}"
  private_subnets = "${data.terraform_remote_state.network_state.private_subnets}"
  public_zone_id  = "${data.terraform_remote_state.network_state.dns_zone_id}"
  private_zone_id = "${data.terraform_remote_state.network_state.dns_private_zone}"
  lb_frontend     = "${module.loadbalancers.hybris_frontend}"
  lb_backend      = "${module.loadbalancers.hybris_backend}"
 
  db_writer       = "${module.aurora.writer_endpoint}"
  db_reader       = "${module.aurora.reader_endpoint}"
  sessions_writer = "${module.elasticache_redis.dns_endpoint}"
 
  additonal_security_groups = [
    "${module.aurora.aurora_security_group}",
    "${module.elasticache_redis.security_group}",
    "${module.efs.efs_security_group}",
  ]
 
  blue_version       = "${var.blue_version}" # build number, AMI ID lookup
  green_version      = "${var.green_version}" # build number or latest AMI
  backoffice_version = "${var.backoffice_version}" # build number
  released_version   = "${var.released_version}" # blue or green
}

The SAP Hybris Commerce platform and custom extensions are built as a pre-baked AMI in a delivery pipeline that runs HashiCorp Packer builds. The same template is used for all environments and are rolled out during live deployments. Environmental differences are handled by custom variables with a special focus on secrets that are managed in the AWS System Manager Parameter Store and injected to the starting system via user data script.

Figure 1 – Hybris Commerce Build Pipeline.

AWS Components

Within DC2, customer storefronts are deployed behind AWS CloudFront, both for static and dynamic content. The Application Load Balancer serves as the origin, sending traffic to Hybris Commerce nodes. A proxy server like Apache can be used optionally, but wherever possible, DC2 is deployed without web tier.

The preferred caching layer is AWS CloudFront, and AWS Lambda@Edge can be used to replace web server functionality like HTTP redirects, serving maintenance page or sending some specific requests to a different origin. This particular function is used for blue-green deployments. CloudFront is connected with Shield Advanced and AWS WAF, which provides protection against OSWAP Top 10, blocks unwanted traffic, and protects access to admin endpoints and pre-production environments.

In case a web proxy is needed, DC2 has an optional Apache web tier; the front-end load balancer sends requests to web nodes instead of directly to Hybris Commerce nodes, and then another, internal traffic balancer is used as back-end for web. Hybris ASG automatically updates Hybris targets in the load balancer, so Apache config does not need to be updated when Hybris nodes are removed or added.

SAP Hybris Commerce’s recommendation is to use sticky sessions, which works well in static clusters, but this is problematic for auto-scaled, dynamic systems. DC2, when web tier is added, is built with Network Load Balancer, which does not support stickiness by design but allows the use of AJP protocol (recommended by Hybris). Alternatively, when stickiness is necessary, we can deploy another, internal Application Load Balancer to connect web nodes with Hybris.

Default DC2 installation runs on an Amazon Aurora MySQL-Compatible database. Aurora has been chosen for the benefits it provides, highly available, performant, scalable, and secure. More details can be found in this blog post about Amazon Aurora Database being certified for SAP Hybris Commerce. The application is connected to a writer endpoint, although many additional tasks like indexing and reporting are connecting to a reader endpoint (Aurora replica) by using slave reader data source, a configuration setting provided by Hybris.

User sessions are exported from the SAP Hybris server to an external data store, AWS ElastiCache Redis, which allows for dynamic clustering and auto scaling, where a Hybris node can be terminated without losing user sessions. The default Hybris installation does not support external, centralized session storage, but it can be added by updating Tomcat context.

As with any other customization, this update is part of the Packer AMI build process where we add required additional libraries, add required configuration and allow values to be dynamically updated. ElastiCache Redis cluster is an optional component in DC2 Terraform code.

Properties Additions to Store User Session in Redis

yacceleratorstorefront.tomcat.context.Valve.className=com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve
yacceleratorstorefront.tomcat.context.Manager.className=com.orangefunction.tomcat.redissessions.RedisSessionManager
yacceleratorstorefront.tomcat.context.Manager.host=<CHANGE_ME>
yacceleratorstorefront.tomcat.context.Manager.port=6379
yacceleratorstorefront.tomcat.context.Manager.database=0
yacceleratorstorefront.tomcat.context.Manager.expireSessionsOnShutdown=false
yacceleratorstorefront.tomcat.context.Manager.notifyListenersOnReplication=true

Note the special property value <CHANGE_ME> that can be used to protect secrets and for environmental differences like endpoints or database passwords. You must also ensure that variable is set, as the system will not start up otherwise.

SAP Hybris media are typically stored locally. While network storage is used in a traditional multi-node setup like Amazon Elastic File System (Amazon EFS), in a DC2 dynamic architecture we prefer to use a cloud-native solution. For media, the best option is to store in an Amazon Simple Storage Service (Amazon S3) bucket and serve it using CloudFront’s static web distribution.

Customer deployments of DC2 can be backed by Piksel Retail’s managed services offering. Typically, we use integration with Amazon CloudWatch for basic monitoring in combination with advanced third-party tools like Datadog, AppDynamics, Dynatrace, and more. Alerts generated in CloudWatch are sent via the Amazon Simple Notification Service (SNS) to an AWS Lambda function, which posts events to Piksel’s Platform Operations Manager (POM) for logging tickets and alerting on-call engineers.

DC2 Infrastructure Diagram

Figure 2 – DC2 Infrastructure Diagram.

DC2 Benefits

DC2 has been designed to make SAP Hybris Commerce more effective when it’s migrated to the cloud. It does so by tackling four key issues:

• Static clusters: Moving away from static clusters allows for the dynamic removal and addition of nodes, which enables auto scaling.
• Overprovisioning infrastructure to handle peak: Auto scaling allows Hybris users to optimize scaling costs while ensuring they can meet any demand.
• In-place deployments: Doing so creates a new way of building artifacts, enabling faster deployment times.
• Code releases behind holding page: Blue-green deployments enable code releases without a holding page, resulting in little or no controlled downtime (i.e. read-only operations allowed).

Overall, DC2 allows for the rapid migration and deployment of SAP Hybris Commerce on AWS.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

Piksel Group – APN Partner Spotlight

Piksel Group is an APN Advanced Consulting Partner. Their goal is to drive transformation and implement secure solutions that scale. Piksel specializes in retail, media and broadcast, transportation, healthcare, startups and telecos.

Contact Piksel | Practice Overview

*Already worked with Piksel? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.