in Best Practice

How Do You Design a Scalable SAP Hybris Architecture on Amazon Web Services?

Are you planning to migrate your SAP Hybris implementation to Amazon Web Services (AWS)? Many companies are considering, or have made the decision to migrate their SAP Hybris implementation to AWS. This article provides a cogent starting point for deploying Hybris to AWS.

Several months ago, I worked on a Hybris-AWS migration project. At the beginning of the project, I spent a considerable amount of time researching Hybris on AWS best practices. Your first question might be,  “What does a scalable Hybris architecture on Amazon Web Services even look like?” The following diagram depicts a simple — yet scalable –, four node Hybris implementation on the AWS platform.

Scalable SAP Hybris Architecture on AWS

Let’s review the architectural diagram layer by AWS layer.

AWS Region

An AWS Region is a collection of AWS Availability Zones (analogous to data centers) in a particular region of the World. Many AWS customers select the AWS Region closest to them for obvious reasons, but it’s also important to consider the AWS Region that’s in close proximity to the end-users, or the number of Availability Zones in the AWS Region.

AWS Availability Zones (AZ)

In AWS, it’s critical to implement your Hybris architecture on at least two Availability Zones, which increases your system’s up-time potential as your Hybris implementation is hosted on two different physical locations within the AWS ecosystem.  This is widely considered a best practice, and should be strongly considered for your Hybris implementation on AWS.

AWS Virtual Private Cloud (VPC)

AWS VPC is your virtual network on AWS. A VPC should be divided into public and private subnets. The Hybris storefront located in the public subnet. The Backoffice application located in the private subnet, inaccessible to the public Internet.

Auto Scaling

The Hybris architecture represented in the above diagram will scale well both horizontally and vertically. As your Website traffic increases, adding Hybris nodes is relatively straightforward with this Hybris architecture. You may even decide to earmark additional standby nodes to automatically “go online” as certain memory or CPU thresholds are detected.

Conclusion

A robust SAP Hybris architecture on AWS should take the following aspects into consideration:

  1. Storefront and Backoffice nodes have different routing and security requirements.  The storefront is Internet-facing, and the Backoffice is for internal-use only. Spend time understanding how private and public subnets impact Hybris’s architecture on AWS.
  2. Every Hybris implementation should have fault-tolerance as part of its go-live strategy.  As a result, workload distribution across multiple Availability Zones is an absolute requirement.
  3. Leveraging Amazon RDS has been successful for many Hybris implementations on AWS, and works very well with Hybris OOTB.
  4. Place the Apache Solr nodes behind AWS’s Elastic Load Balancer to improve the search engine’s scalability and availability .

 

 

Written By:

Marc is the Founder of HybrisArchitect.com. He enjoys helping others learn more about SAP Hybris Commerce. Marc has held the role of Hybris Architect at Exemplis and Nasty Gal. He is a long-time Java/Spring developer. Marc holds an M.S. Software Engineering from Carnegie Mellon University and a B.S. in Accountancy from California State University, Fresno. He can be reached at: info@hybrisarchitect.com

4 Comments

  1. Vikas Bhumireddy September 12, 2017 Reply
    • Marc RaygozaAuthor September 12, 2017 Reply
  2. Katja November 8, 2017 Reply
    • Marc RaygozaAuthor November 8, 2017 Reply

Add a Comment

Your email address will not be published. Required fields are marked *