Behind the Scenes of the New SAP Commerce Cloud: Architecture details
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 them, has a public status. The commentaries between the slides is a compilation of what I took away from the session and slides and the author’s notes at the slides.
What is Commerce Cloud?In order to avoid any confusion as to terminology, let’s define what is SAP Commerce Cloud today. We know, that it is a new name for SAP Hybris Commerce since this summer. However, a cloud offering went as a deployment or licensing option, but not as part of the e-commerce platform. According to the new vision, SAP Commerce Cloud is not only a software package, but it is also a cloud solution, where many components are involved, and only one of them is a good old Hybris Commerce, now rebranded. Of course, the platform has been renamed not only of the high marketing thoughts but also because of significant technology shift: the SAP products are now braided together and all these 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 be even reasonable, but it is getting more and more obvious that for the large business the “traditional way” is no longer an option. Another thing that adds to the confusion is two different offerings named SAP Commerce Cloud. The first is CCv1 which is no longer relevant today. The second is CCv2 which is a topic of this article. CCv1 is related to the offering SAP has four or something years ago. That was the first attempt of SAP Hybris to go to the cloud. Customers owned the build pipeline, SAP owned the deployment pipeline, infrastructure was provisioned and managed by SAP staff only, no automation, no self-service. Even the smallest change required filling out the form and waiting for hours or days. Personally I have a CCv1 project in my portfolio, so it is a firsthand knowledge. We developed and launched it on time, but maintenance… it was a nightmare. This offering is no longer relevant today. We 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 provision, build and deploy are automated, the system is integrated with 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 and AWS are in the roadmap. In the heart of the Commerce Cloud offering, there is a platform core, which is very similar to what we have as “on-premise” version. The cloud version needs to be cloud-ready because it is supposed to work as in the containerized form. This approach creates some constraints, such as image immutability principle (containerized applications are meant to be immutable, and once built are not expected to change between different environments) and 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 the 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:
- Self-Service. Central Management Portal and Common tasks without tickets.
- High Degree of Automation. Environment setup, deployment, backup and restore.
- Standard Facilities. Central logging, maintenance controls. Performance analysis and scaling are not yet available now, but will be available in 2019.
- Standard Build Pipeline. Build, test and release within Commerce Cloud. The system operates with container images.
- Pre-defined Commerce Setup. Pre-defined cluster roles, one database and one media storage.
- Standard Cluster Deployment. Kubernates operator, Apache Ingress and non-interactive initialization/update.
- Platform. Contains centralized components which are common for all customers
- Subscription. Contains customer project specific components. The configuration of these is under control of the customer.
Main platform component and services
- Automation Engine
Main subscription components and services
- Azure services and API, namely
- External services
- CatchPoint monitoring (availability)
- CDN. It is not available yet, but it is in the roadmap.
- Open source solutions
- Metrics. It is not available yet, but it is in the roadmap.
- Storefront (SF)
- Backoffice (BO)
- Background processing (cronjobs, BG)
- API and SOLR (SO)
Commerce Snapshot and RestoreSAP also has a standard snapshot/restore mechanism. For the database, it is backed up as blob. Now it is not possible to backup 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 back. 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 on other environments.
Customizations and Build Process in Commerce CloudHow 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 merge the commerce app and custom code and build it into containers. The container is deployed into the target environment or environments. At the diagram below, there are three components:
- CCv2 Platform (blue)
- CCv2 Commerce Release (yellow)
- CCv2 App XYZ (black) – a module or application from SAP supposed to extend Commerce and Platform functionality (mix-in features)
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:
- a version of the Commerce Suite
- list of extensions (similar to what we had in localextensions.xml)
- properties (key / value / environment /or persona as it is called here/)
- storefront addons (addon / storefront / template)
- aspects configuration (for example, backoffice or background processing specific)
- tests configuration
- Frontend type traffic (from shop web app)
- Many small concurrent requests = high amount of CPU
- Needs big cache = high amount of memory
- No background processing enabled
- Backend type traffic (from backoffice web app)
- Medium amount of concurrent requests = medium amount of CPU
- Medium cache size = medium amount of memory
- Exclusive background processing enabled for ‘backoffice’ process types
- Client / Integration type traffic, for example, from Kyma
- Medium amount of concurrent requests = medium amount of CPU
- Mostly transactional non-cacheable requests = low amount of memory
- Exclusive background processing enabled for API process types
- “Background processing”
- No traffic, event and self-driven processes
- Medium amount of concurrent processes = medium amount of API
- Some ‘heavy’ processes = medium amount of memory
- General background processing enabled