A note from 2026: This article was published in 2018, when SAP Commerce Cloud CCv2 was new. SAP Cloud Platform is now SAP Business Technology Platform, SAP Cloud Identity is now Identity Authentication service, and CCv2 operations, monitoring, scaling, and roadmap items such as CDN and metrics have evolved since then.

This article continues a series, “Takeaways from SAP CX LIVE Barcelona”. This time, I share my notes and thoughts based on the great presentation given by Axel Großmann, an enterprise architect for New Commerce Cloud.

The slides below and my comments in between were taken from the conference. The PDF version of them is available for participants and, as noted on the slides, has public status. The commentary between the slides is a compilation of what I took away from the session, the slides, and the author’s notes on the slides.

What is Commerce Cloud?

To avoid any confusion about terminology, let’s define what SAP Commerce Cloud is today. We know that it has been the new name for SAP Hybris Commerce since this summer. However, the cloud offering used to be a deployment or licensing option, not part of the e-commerce platform itself.

According to the new vision, SAP Commerce Cloud is not only a software package but also a cloud solution, where many components are involved, and only one of them is the good old Hybris Commerce, now rebranded. Of course, the platform has been renamed not only because of high-level marketing ideas but also because of a significant technology shift: SAP products are now braided together, and all of them are woven into the cloud software. Of course, you are still able to pick only the platform and host it traditionally, and in some cases, it may even be reasonable, but it is becoming more and more obvious that, for large businesses, the “traditional way” is no longer an option.

Another thing that adds to the confusion is that there are two different offerings named SAP Commerce Cloud. The first is CCv1, which is no longer relevant today. The second is CCv2, which is the topic of this article.

CCv1 is related to the offering SAP had four or so years ago. That was the first attempt by SAP Hybris to go to the cloud. Customers owned the build pipeline, SAP owned the deployment pipeline, and the infrastructure was provisioned and managed by SAP staff only: no automation, no self-service. Even the smallest change required filling out a form and waiting for hours or days. Personally, I have a CCv1 project in my portfolio, so this is firsthand knowledge. We developed and launched it on time, but maintenance… it was a nightmare. This offering is no longer relevant today. We are all happy to forget it now.

For the new edition of this service, CCv2, things look much, much better. The process is fully automated. You don’t need any assistance for the key operations. SAP now owns both the build and deploy pipelines. Infrastructure provisioning, build, and deployment are automated. The system is integrated with a Git repository, and there is a powerful self-service portal.

Unlike the first version, CCv2 is completely on top of the public cloud now. The key components or layers are in a sub-cloud. Technically, CCv2 is on Azure, but the strategy is to be multi-cloud, so Google Cloud and AWS are on the roadmap.

At the heart of the Commerce Cloud offering, there is a platform core, which is very similar to what we have as the “on-premise” version. The cloud version needs to be cloud-ready because it is supposed to work in containerized form. This approach creates some constraints, such as the image immutability principle (containerized applications are meant to be immutable, and once built are not expected to change between different environments) and the process disposability principle (containers need to be as ephemeral as possible and ready to be replaced by another container instance at any point in time). In the cloud version of SAP Commerce Cloud, these issues have been addressed, but the details are still hidden from us.

This article uncovers some of the ideas and philosophy underlying CCv2 as a cloud offering.

Axel Großmann highlighted the following key paradigms of the New Commerce Cloud:

There are two architectures:

Main platform component and services

SAP Commerce Cloud platform components and services diagram

Main subscription components and services

The cluster software is not very flexible, so if you want to use Nginx, for example, as a load balancer, you might find it hard to convince SAP to install it. However, the current stack is pretty good and based on battle-proven, enterprise-level components.

On the database side, SQL Azure is used. For now, it fits well because it is cloud-native, database as a service. You can subscribe to it, and you can select the desired performance tier. Azure Blob Storage is used for media storage. Azure Container Registry is used for CCv2 Docker images.

SAP Commerce Cloud subscription components and services diagram

So all you need is to specify the branch/tag for the source code and the target environment, and the automation engine will create a task for build and deployment, create a container, upload the container to Azure Container Registry, and create or update a cluster in the target environment.

Each environment has its own setup. Kubernetes ensures that the image is installed in the cluster and launched successfully.

The cluster is separated into four buckets, one per server role:

In the production environment, you have a larger number of storefronts and a fair number of backoffice instances.

SAP Commerce Cloud environment cluster roles diagram

SAP Commerce Cloud has a preinstalled logging stack: Elasticsearch + Kibana + Fluent Bit. For metrics, SAP also uses the standard stack, Prometheus + Grafana. For both logging and metrics, there is single sign-on authentication via SAP CI. The log format is JSON.

SAP Commerce Cloud logging and metrics stack diagram

Commerce Snapshot and Restore

SAP also has a standard snapshot/restore mechanism. For the database, it is backed up as a blob. Now, it is not possible to back up only a subset of tables or records via this mechanism. For the backup, the commerce part is paused, then the system creates a snapshot of the database and media, and then resumes the system.

SAP Commerce Cloud snapshot process diagram

For the restore process, the Commerce platform is stopped completely, the existing media blob and the database are replaced with the snapshots, and the platform is re-deployed. Snapshots can be copied and restored to other environments.

SAP Commerce Cloud restore process diagram

Customizations and Build Process in Commerce Cloud

How do you get your customizations into Commerce Cloud? The CCv2 system builds the system automatically directly from the source code repository. The Commerce App and other SAP modules are updated monthly, so new automation features and bug fixes will be applied regularly. The system merges the Commerce App and custom code and builds them into containers. The container is deployed into the target environment or environments.

In the diagram below, there are three components:

SAP Commerce Cloud customizations and build process diagram

There is a simplified option for non-customizable applications. It is perfect for simple or standard solutions based on the Commerce stack, or when the solution is fully managed and operated by SAP. Customers are allowed to do partial configuration and operations. For this option, SAP is developing Product Content Cloud (PCC). Unfortunately, to date, we know nothing but the name.

SAP Commerce Cloud simplified option for non-customizable applications

The new configuration file is manifest.json. It defines how your application should be built by including baseline properties with specific configurations. This file contains the following blocks:

So the build process is performed in the cloud, and the result is a set of Docker images. Platform code is not in the project repository: the system has its own artifacts repository where all versions and extensions are stored and updated with hotfixes if a need arises.

SAP Commerce Cloud manifest and build configuration diagram

There are four types of cluster component roles, or aspects: storefront, backoffice, API, and background processing. Each aspect has a number of containers of the same image. On top of each aspect, there is a dedicated Apache Web Server and Azure Load Balancer. Solr and ZooKeeper are separate roles. Apache Ingress provides load balancing, SSL termination, name-based virtual hosting, routing to services, and service discovery.

Each role (aspect) needs its own configuration:

SAP Commerce Cloud cluster aspects and configuration diagram

Initialization and Update

In the case of INIT and UPDATE, the Commerce platform will be fully stopped and started again once the changes are applied. There is a special mode, LIVE UPDATE. With this mode, non-critical aspects stay online, the system updates a copy of the type system, and then switches from the current one to the new one.

SAP Commerce Cloud initialization and live update diagram

Third party server/software

In the CCv1 legacy version, customers were able to request an additional server to host “whatever they like”. In the new CCv2, this is no longer an option. Customers have to either rely on a service provider or host the service themselves.

For example, if you need to use ImageMagick, it must be available alongside the platform, which will not happen in the new Commerce Cloud. The customer can host ImageMagick as a service in external infrastructure.

The same applies to products such as Hazelcast, Redis, Memcached, Varnish, and so forth.

Sending emails

In the legacy version, emails are sent via SMTP, and you need an SMTP Relay Server. In the new CCv2, there is an SMTP Relay Service that provides both SMTP and Web API. Batch emails are not supported.

Kubernetes Cluster

The following diagram shows the architecture of the Kubernetes cluster.

SAP Commerce Cloud Kubernetes cluster architecture diagram

Cluster scaling

Scaling is the ability of the cluster to increase the number of allocated resources in response to increasing demand, either manually or automatically.

Currently, the feature is not directly usable by customers with fixed-price subscriptions. Axel joked that if it is available to customers, they will always set the slider to the max. So this component needs to be designed wisely, and, as I understood, SAP is now checking different options.

Currently, there are no metrics or scheduling in the system available to customers. As Axel explained, in the long run, it might not be useful either, because customers will be given a guarantee if they run on Commerce Cloud and are within the boundaries of their contract. SAP takes care of keeping KPIs, such as average response time, in the agreed range.

The Scale Operator, a special component, watches for Kubernetes pods that cannot be deployed and grows the cluster by adding new worker VMs. It also watches the overall deployed pods to shrink the cluster again.

SAP Commerce Cloud scale operator diagram

SAP Commerce Cloud cluster scaling workflow diagram

This technical session revealed a lot of interesting details for me. We reconnected with Axel after the session and discussed the topic in detail. I hope I will come back to this topic with deeper details very soon here at Hybrismart. Stay tuned!