Getting Started with SAP Commerce Cloud
The SAP Commerce Cloud in the Public Cloud solution features the same great industry leading commerce solution as our SAP Commerce core solution, along with some new features. However, with new features, come different ways of doing things compared to an on-premises instance. This section is the starting point for anyone that is working on an SAP Commerce Cloud solution project for the first time.
Table of Contents
Why SAP Commerce Cloud?
Before we begin, it is important to differentiate between the SAP Commerce Cloud in the Public Cloud, released on the 4th of June 2018, and the previous version of SAP Commerce Cloud, which we will refer to in this document as "SAP Commerce Cloud on SAP Infrastructure".
If you are currently using an on-premise version of SAP Commerce or you are on SAP Commerce Cloud on SAP Infrastructure, you may be wondering what has changed in the newest version of SAP Commerce Cloud. The following videos provide an introduction to SAP Commerce Cloud (video link) as well as a walkthrough of several self-service features in SAP Commerce Cloud (video link).
With SAP Commerce Cloud on SAP Infrastructure, it is your responsibility to build packages for deployment (following the latest Deployment Package Guidelines). Deployments and maintenance of the environments are then managed by SAP Cloud Services. Additionally, a VPN tunnel is required to reach backoffice nodes, as outlined in the diagram below.
With the SAP Commerce Cloud in the Public Cloud, the process to provision environments, build the code, and deploy to public cloud infrastructure is self-managed through the SAP Commerce Cloud Portal.
If you are interested in learning how to migrate from SAP Commerce Cloud on an SAP infrastructure to a public infrastructure, please see the article "Migrate to SAP Commerce Cloud".
The Build Process
The SAP Commerce Cloud build process uses the standard commerce build process. However, if the build process is customized (for example, using build callbacks), there is a possibility that these customizations will be incompatible with the SAP Commerce Cloud build process. A larger degree of customization will increase the risk of build incompatibilities. Therefore any customizations, like the build callback logic, should be kept to a minimum and should be thoroughly tested on SAP Commerce Cloud.
SAP Commerce Cloud relies on the Manifest.json file to configure the build. It does not support alternative recipes or custom recipes like those found for on-premise installations of SAP Commerce Cloud. Users of recipes will need to adapt their recipe to the Manifest file (see the Code Repository section below). You may wish to set up your manifest.json file for Configuration Reuse in order to make Developing Locally simpler.
Additionally, the SAP Commerce Cloud build process cannot be customized beyond the configuration options available in the Manifest.json file, as well as the configuration and customization options that the standard commerce build process supports. Failures in the build process are reported in the build log which is available as part of the build details in Cloud Portal.
The following diagram outlines the high level build process:
This video shows a quick demo of how the provisioning and build process works through the SAP Commerce Cloud Portal.
The SAP Commerce Cloud build process picks up the code designated through the SAP Cloud Platform build options as well as all the required extensions to build the Docker images. These are then used to create the environments as per the Aspect Configuration of the Manifest.json file. You can think of an aspect as a role that a node is set up to perform. A fixed platform cluster layout is used. This means that the same base SAP Commerce Docker image is used with different aspects, enabling individual scaling per group of nodes, and separation of concerns. The aspect types are fixed but they can be configured using the aspects section of the manifest file. The following table demonstrates how functionalities and modules could be distributed across the cluster:
The following webinar helps provide some insight into the various tools and infrastructure that come with an SAP Commerce Cloud subscription: SAP Commerce Cloud Infrastructure and Tools.
Each subscription of SAP Commerce Cloud has its environments provisioned with its own Kubernetes cluster that orchestrates computing, networking, and other infrastructure aspects on behalf of user workloads. A key aspect of SAP Commerce Cloud is that SAP Commerce Cloud instances are always deployed with a consistent and fixed resource (cores and memory) footprint for each node of a particular aspect in each environment.
All server clusters and their allocated resources (CPU/RAM) in all environments are managed exclusively by SAP. Because resources are fixed, it also means only horizontal scaling (increasing the number of instances) is supported. Vertical scaling (increasing the resources on an existing virtual machine) is not supported.
The below sample configuration for go-live shows three master nodes and at least three nodes. These numbers can vary from project to project (depending on project size). Each node (described in the Nodes section below) is configured with Docker and Kubelet to allow deploying the Docker images created by the SAP Commerce Cloud build process.
A node is a worker machine in Kubernetes, previously known as a minion. A node may be a virtual machine (VM) or a physical machine, depending on the cluster. Each node has the services necessary to run pods, and is managed by the master components.
A container is a runtime instance of an image (what the image becomes in memory when actually executed). Containers run apps natively on the host machine’s kernel. They have better performance characteristics than virtual machines that only get virtual access to host resources through a hypervisor. Containers can get native access (each running in a discrete process) taking no more memory than any other executable.
There are three main environment types that can be provisioned within the SAP Commerce Cloud Portal: Development, Stage and Production. Extra instances of these environments are available for purchase.
The following diagrams illustrate how these containers are sized and deployed for each environment size (Development, Stage, Production), using the Azure definitions for VM Size (link) and DB size (link):
As stated above, only horizontal scaling (increasing the number of instances) is supported. Vertical scaling (increasing the resources on an existing VM) is not supported. The sizes of the nodes here are subject to change based on optimal performance returns.
At a minimum:
- Kubernetes cluster of one master E2 and two workers F8 VMs
- One S2 (Standard 2) database
At a minimum:
- Kubernetes cluster of three master F8 and three workers F16 VMs.
- One S4 (Standard 4) database. Does not support asynchronous replication.
At a minimum:
- Kubernetes cluster of three master F8 and three workers F16 VMs.
- One P4 (Premium 4) database; provides better reliability than other tiers, and the possibility of asynchronous replication to other data centers with the same code base.
Ephemeral Disk Storage
With SAP Commerce Cloud, the application servers provisioned do not have persistent hard drives attached. Therefore, applications should not rely on files written to disk to be available long term (disk storage is ephemeral and will therefore disappear when Kubernetes replaces the Commerce node). Cloud storage should be used for files that are required to exist beyond the lifetime of a SAP Commerce application instance. SAP Commerce Cloud provides the Cloud Hot Folders feature (see section on Cloud Hot Folders in the article), which is used for importing files from the Azure Blob Store.
SAP Commerce Cloud uses the Azure SQL Database. Any instances where projects are writing direct SQL queries should be reviewed and tested to ensure consistency with this standard. Although disaster recovery is available as per the Services Description, it is only intended for when the main data center is not available. There may be times where you wish to save the state of your database in case you want to roll back to it in the future. The Snapshot and Restore feature allows you to do this and we recommend to periodically save a snapshot of your database. In particular, this should be done before performing large deployments that will affect your data model and consequently the database. This is in addition to Disaster Recovery, which is included in your subscription. However, this is only intended for when there is infrastructure failure. Disaster Recovery will not cover the cases where you need to roll back your environment after deploying code that later is found to contain a blocker bug. If you have a snapshot prior to your deployment, you can choose whether or not to restore it as part of your code rollback.
SAP Commerce Cloud uses Apache Web Server to serve web traffic and provides a standard configuration optimized for running a SAP Commerce Cloud storefront. Access to web servers is not permitted but the following configuration options are available in the SAP Commerce Cloud Portal for the Web Tier:
- Endpoints (virtual hosts) can be mapped onto applications running on SAP Commerce Cloud. They are automatically allocated a DNS name. See documentation on creating, editing and monitoring endpoints.
- SSL Certificates can be assigned to an endpoint. See documentation on creating certificates here.
IP Filters can be defined for an endpoint, ensuring that only traffic from certain IP addresses can access an endpoint. Documentation can be found here.
- Redirects can be defined for an endpoint, enabling vanity and marketing URLs and site migrations as outlined here.
- Static Files can be uploaded and available for any endpoint, enabling search engines to better understand your site. To learn more, see the page here.
Maintenance pages can be uploaded and enabled for an endpoint to provide a friendly message during scheduled maintenance periods. The process to create and enable maintenance pages is covered here.
- Security files are a type of static file which can be used to manage sensitive information (e.g. certificates, passwords, salts, tokens, etc.). The process to upload and delete the security files is covered here.
This video outlines how you can manage endpoints.
Performance Monitoring and Logging
Each environment is connected to Dynatrace, which can be used for application performance monitoring (APM). This can be used to understand how your site is performing, be alerted when issues arise and be able to troubleshoot where in your application the issue is occurring. See here for more information.
SAP Commerce Cloud also comes with a centralized logging solution via Kibana. You can use Kibana to analyze all your application console and request logs. You can also configure your own dashboards and visualizations (or use the sample one included in our Developing SAP Commerce Cloud Locally article). For more on centralized logging please see this section of the product documentation.
SAP Commerce Cloud introduces many self-service features that allow you to control how your commerce solution runs in the Cloud. For those familiar with SAP Commerce (on-premise) or SAP Commerce Cloud on SAP Infrastructure, you will notice many of the same features and functionality. SAP Commerce Cloud takes away many of the pain points of managing the infrastructure, so that you can focus on developing a custom-tailored commerce solution that fits your business needs. If you are a developer looking to understand the impact the SAP Commerce Cloud will have on the way you work, please see Developing SAP Commerce Cloud Locally. For architects, please see the article on SAP Commerce Cloud Architecture. If you are looking to migrate from an existing solution to SAP Commerce Cloud, please see the article on Migrating to SAP Commerce Cloud .