CCv2 General

// SAP COMMERCE CLOUD v2. IS IT REALLY A NEXT-GEN CLOUD FOR YOUR COMMERCE?

Published on 3/24/2022


Darek Smolarek

Dariusz Smolarek, CHIEF SOFTWARE ENGINEER


SAP, alike other providers, is moving its services – including SAP Commerce – to a public cloud. Cloud infrastructure can introduce significant enhancements to commerce projects in terms of performance, scalability and security. New clients are compelled to use Commerce Cloud v2 (CCv2) as a runtime environment for their platforms. However, those who already host their infrastructure, have the choice to either stay on-premise or move to the cloud.

Should you bother about CCv2?
Is it really better than your current infrastructure setup?
How does it compare to CCv1?

To help you answer these questions, let’s analyze each approach by highlighting their benefits and drawbacks.

This is the first part of the whole series about Commerce Cloud v2 – articles that will follow share our practical thoughts on CCv2, especially in the context of its architecture, capabilities and migration approach.

Read below about
On-Premise installations
SAP Commerce Cloud on SAP Infrastructure (CCv1)
SAP Commerce Cloud on Public Cloud (CCv2)
Comparison

On-Premise installations
Infrastructure dilemmas

Before SAP CCv2, providing a runtime environment for SAP Commerce (former Hybris) demanded considerable effort. Typical installations require multiple components: application, web, search engine and database. Countless numbers of software and hardware components create a complex system making the journey of every request more complicated than ever. If anything goes wrong in the chain – you’re doomed. It is often difficult to prevent performance issues or misconfiguration effects. And, in the worst case scenarios, there is tremendous time pressure for problem to be resolved while system remains unreachable for customers.

We are more than certain you’ve faced these problems before. Usually, once they occur, the nature of the network makes them hard to troubleshoot. Furthermore, SAP Commerce is rarely the only system in your architecture landscape. ERP, CRM or CMS are only few of several other common integration points. They also require multiple infrastructure components to work properly and additional routing configuration to allow efficient communication.

Platform management can become tricky when it comes to tackling multiple environments. Depending on the type of solution it can include, but may not be limited to the development, testing, staging, and production. The number of components and an amount of configuration overhead can become a real problem, especially when you have to take care not only of software but hardware maintenance as well.

Running your own infrastructure involves responsibility for environments and operating system updates. It is a vital factor in making your e-commerce stable and high performing. Nevertheless, it is a tough grind to remain up-to-date at all times. Longer maintenance windows might be necessary even if your customers are reluctant to accept them and your e-commerce platform might be unavailable or run on limited resources during those times. Unfortunately, in most cases, this is the only way to allow administrators to make changes when it comes to on-premise installations.

To oversee overall platform condition and anticipate problems, a good telemetry approach and set of monitoring tools are crucial. Collecting system logs, events and metrics provides valuable insight into your platform which helps you detect potential bottlenecks and identify traffic peaks. But choosing the right tools for the telemetry system and feeding it with metrics is only the tip of the iceberg. Finding balance between processing the amount of collected data, its relevance and demand for immediate feedback loop requires hours.

While running on-premise SAP Commerce installation, all the decisions regarding tools and configuration are up to you. Unfortunately, there is no clear path for setting up monitoring process, not to mention an appropriate set of metrics that need collecting and analyzing.

SAP Commerce Cloud on SAP Infrastructure (CCv1)

The way the software is delivered in the on-premise model results in an individual approach to infrastructure and differentiates between SAP Commerce projects. Variety of database technologies, third-party components and customizations used throughout the build pipeline could cause problems regarding scalability or upgradeability of platforms. The compatibility issues between software components and the platform version make the upgrade process more complicated and expensive. A good example of the above would be upgrading your platform to SAP Commerce 1905 where Oracle Java 8 had been officially replaced by SapMachine 11. Many third-party software components were simply incompatible with newer Java plus there were changes in SAP Commerce API making it even harder to upgrade.

SAP, after upgrade problems caused by infrastructure variety, proposed Commerce Cloud on SAP Infrastructure (CCv1) as an alternative solution. CCv1 shouldn’t be seen as a cloud-based solution, but rather as a standardized set of virtual machines running your SAP Commerce platform in SAP Data Centers. The reasons behind SAP being an infrastructure provider are pretty straightforward – they know the best SAP Commerce requirements to provide the best performance and upgradeability. On top of providing a runtime environment, SAP took care of setting essential tools for monitoring and log management.

Migration from on-premise to CCv1 had multiple advantages for clients:

  • Infrastructure responsibility was moved outside clients jurisdiction – there was no longer need for the client to take care of system backups, network issues, OS updates and lots of other DevOps activities. Clients could finally focus on activities essential for the project instead of infrastructure maintenance.
  • Standardized environments – every client was running a comparable environment. The idea was to introduce more manageable platform upgrades with fixed infrastructure configuration. One of the advantages was also the fact that performance issues could be identified and solved much earlier. The biggest motivation behind standardized environments would probably be their manageability. But here comes the most significant CCv1’s disadvantage – you had no control over system architecture and software components that are being used. You’re compelled to use whatever SAP recommends.
  • Monitoring and log management – since SAP run the platform, monitoring using Kibana or Splunk was accessible to every client out-of-the-box.
  • (Almost) seamless migration process – CCv1 didn’t require nearly any changes for your project team: application development looked exactly the same as for the on-premise systems. The most complicated aspects of migration were copying the media folder to SAP Data Center and migrating the database.


Nevertheless, the introduction of another partner taking care of the infrastructure had multiple downsides:

  • Ticketing – almost all tasks were executed by SAP Support directly. This meant that every activity had to be scheduled and followed by a ticket in the SAP ticketing system. If there were issues, clients and partners couldn't perform most of the actions available to them when running on-premise. You had to wait for your ticket to be processed depending on its priority.
  • Limited environments – by default SAP equipped you with only three environments: development, staging and production. You had to request and pay for any additional environments.
  • No self-service – you couldn't perform any administrative tasks on staging and production environments. This meant you couldn’t configure continuous integration (CI) or even install an SSL certificate. Any change had to be reported via ticket and handled by the SAP representative. The only environment you could manage was the development one.
  • SAP HANA DB – SAP HANA was the database you were compelled to use when hosting in CCv1. Due to its high system requirements, installing it on the developer’s local machine was not easy. After the deployment to CCv1 there were cases of broken functionalities and even more serious model issues. All due to HANA's uniqueness.
  • Additional overhead for deployments – all the deployments had to be done by the SAP Support team. You needed to plan a deployment window ahead but, what was more important, you also had to provide a built application package and detailed step-by-step release notes. They were often required to assist SAP during the deployment in case of any potential issues. Not to mention that different employees could perform the deployments which added to processing time. The rolling update was officially unsupported by CCv1 so you ended up with your system down in longer maintenance windows.
  • Fixed infrastructure – additional microservices could not be introduced inside CCv1. It was designed to run SAP Commerce only (and Data Hub, if needed). If clients wanted to use other services, they had to deploy them on-premise or in the public cloud. This made functional decomposition inside the CCv1 difficult, to say the least, or almost impossible at the worst.

Limited environment management possibilities, relatively long SAP response time to tickets and complicated deployments contributed to CCv1’s failure. The idea of providing standardized environments sounded great initially but the significant involvement of SAP support employees in many client-specific activities quickly made it clear that such approach was neither effective nor practical.

SAP Commerce Cloud on Public Cloud (CCv2)

The insight gained after the introduction and failure of CCv1 led to a simple conclusion. Clients and partners should be enabled to do as much as possible independently before contacting SAP directly. SAP went a step further and used public cloud instead of its own infrastructure. This approach proved highly beneficial for both SAP and clients.

Broken cloud under the hood

Alike in CCv1, the client is not required to take care of infrastructure anymore. However, this time Microsoft Azure was selected to be the infrastructure provider. Microsoft provides multiple modern solutions with their cloud making it much easier for SAP to set up and manage all CCv2 environments such as VPN, storage, backups, software resiliency, databases and many more. System management is highly automated allowing SAP to enlarge or establish a new environment within few hours. It’s night and day compared to on-premise installations where many tasks had to be performed manually. However, being in the CCv2 cloud doesn’t mean you have access to Microsoft Azure features – you’re limited to functionality implemented and exposed by SAP.

SAP CCv2 uses the Kubernetes engine to orchestrate and run a commerce solution. This, theoretically, opens up the possibility of real-time environment size management. Unfortunately, real-time management is currently not accessible to CCv2 users. Another thing that comes to mind when you think about the cloud is dynamic scaling. This feature allows systems to scale depending on the traffic to deliver maximum performance while optimizing costs. But again, this element is also out of reach for CCv2 users. Does this remind you of anything? Yes, it does. You still have to monitor your traffic and, in case of any peaks, request environment re-scaling. These challenges are well known from the on-premise installations. With a CCv2 subscription the client is given three of the environments: development, staging and production. They differ in size and performance capabilities. It is possible to request additional environments, however, at an extra cost.

Self Service Capabilities

SAP Cloud Portal is a gateway for clients to manage their environments. Unlike with CCv1, clients can finally perform most of the standard activities by themselves. After logging into the Cloud Portal, they can assign administrators or developers and define required access rights to restrict environment visibility or other administrative privileges. CCv2’s clients are given great, market-proven monitoring tools. SAP in turn, in addition to Kibana, provides its client with DynaTrace – an extremely powerful tool for monitoring and profiling. Building and deploying your application is the most common activity for software delivery. It’s relatively easy to do. However, it takes time. Single deployment can take around 1 hour, or more, from start to finish. First, you have to trigger the build process which then can be deployed to an environment. More on this topic in upcoming articles on CCv2. Besides, the client can finally deploy their SSL certificates, define host aliases, perform full system backup, set environment variables, etc. Nevertheless, the client is still limited to Cloud Portal functionality. If you would like to carry out any administrative tasks though – yes, you are right – you have to create a ticket to SAP.

CI/CD – better but not ideal

If you have already gotten the idea of replacing your CI solution with CCv2, there is a disappointment coming your way. SAP CCv2 doesn’t provide any CIs currently (and probably will not support them in the future either). Nonetheless, unlike with CCv1, there’s finally a way to integrate Cloud Portal build process with your pipeline via API. We recommend integrating your CI server with Cloud Portal API soonest possible to automate builds, do backups and track deployment process.

Integrations and functional decomposition

If you are using Data Hub to integrate, for instance, an ERP system, there is a possibility to migrate it to CCv2. Unfortunately, there are two downsides to this approach. Firstly - it’s considered an additional extension to CCv2 and this raises subscription costs. Secondly – Data Hub has been deprecated a while ago already. There’s a direct replacement for Data Hub within CCv2 – SAP Cloud Platform Integration (SCPI). Unfortunately, SCPI is also considered as an optional CCv2 extension which also elevates the subscription fee. If you decide to move from Data Hub to CPI, you have to consider migrating integration customizations from DH to SCPI as well as extending your SAP Commerce platform with additional modules enabling you to communicate with the new component.

If you’re extending SAP Commerce functionality with your own microservices, you probably started to wonder about migrating them to CCv2 as well. In the end – it’s Microsoft Azure cloud under the hood. Here comes another disappointment. As Cloud Portal covers every Azure cloud feature, there is no way to run your services inside CCv2 – you have to deploy them by yourself.

Does this mean there is no way to decompose SAP Commerce within CCv2? There is: you can request SAP Extension Factory as an addition to your subscription. It’s built on top of an open-source SAP project – Kyma – and it lets you extend the application with microservices and serverless functions and much more.

Migration process

Updates are essential for every commerce project not only because of the new features but also security updates and other crucial project aspects (you can read more about importance of updates and how to make it succeed in Krzysztof’s article: HOW TO SUCCEED IN SAP SYSTEM UPGRADE). Before starting the migration process, you need to make sure you’re running supported SAP Commerce version. Currently, the CCv2 supported minimum is version 6.7. SAP recommends to run at least version 1811 as it contains additional extensions which makes it easier to utilize CCv2’s potential.

There are three approaches you can adopt when migrating to CCv2:

  • Migration guided by partner – this is probably the most common approach to migration project. You and your implementation partner are responsible for making all necessary code changes to move to SAP CCv2. Unfortunately, because you’re not allowed to access storage and database servers within CCv2, it is impossible to perform the migration without SAP involvement. It’s SAP that moves all your data (mostly images and other resources) and your database to CCv2.

  • Migration done by SAP – if you would like SAP to do the migration for you – it’s 100% feasible. SAP provides you with dedicated team responsible for current code assessments, making the necessary changes and storage and database migration to CCv2. This approach, however, is probably the most expensive one and is much more time consuming as SAP doesn’t know your business domain and code.

  • Initialization –this approach doesn’t involve SAP in the migration process at all. After adapting your code to run inside CCv2, you perform system initialization and then import data from your existing system. You need to be extremely careful here about your data quality and consistency to be able to minimize the amount of time needed for imports and to ensure system stability. Nonetheless, when it’s done right - you can significantly reduce migration time and optimize your database.

The migration process is complex and there are many pitfalls you may fall into. We will share our thoughts on approaching CCv2 migration in a separate article.

CCv2 alternatives?

SAP speaks openly about CCv2 being the only option for new clients. What about existing ones running their on-premise systems? It looks like there are no real alternatives at the moment, especially when you consider the SAP roadmap and their focus on cloud features like SCPI or Extension Factory. Of course, you can still run your system within your own infrastructure or even set up a cloud replacement for CCv2.

Summary

This article will not suggest any solutions regarding CCv2. Nevertheless, the information given here should make your view on it clearer and more coherent. Migrating your current solution might be a long and bumpy road but at least you would know what to expect. The knowledge and experience gained over the years of using your on-premise solution will not go to waste and some of its areas will certainly help you deal with the limitations of CCv2.

Comparison
Darek Smolarek
Darek Smolarek
Let's talk

Our team has 12+ years of experience in working with SAP Hybris. We have a unique knowledge of decomposing frontends and backends for SAP Commerce clients. This includes successful takeover of launched projects that other agencies failed.

We demonstrated the quality of our work in numerous successful projects for customers with revenues of 500M to over 1B EUR where commerce is the key to generating sales. We can help. Drop me a line.

CHECK OUT OUR WHITE PAPERS

Be prepared for your transition
to composable commerce.

Carefree and smooth

GO TO OUR BLOG

OUR CLIENTS

Ivoclar Vivadent
TUI Logo
Nikon logo
TX Group logo
Play Logo
Vision Express Logo
GrandVison Logo
Trendy Opticians Logo