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.
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.
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.
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.