In my last blog post about SAP Cloud Platform ABAP Environment release 2002, I promised to provide some updates in the area of sizing flexibility very soon. And here they come! 😊
Since the introduction of SAP Cloud Platform ABAP Environment in 2018, it has always been a main target by us to provide “cloud qualities”. To achieve this, we shipped many new features covering different areas of the platform, e.g. innovations in the programming model, tools, lifecycle management, just to name a few. You can read more about them in our release notes. In many customer and partner interactions during the last time we got asked the question how ABAP environment behaves in terms of sizing options. The good news is that our development teams have been working hard over the last months to provide a good answer to this question!
But let us start with a short recap of how sizing worked for ABAP environment in the past until today:
How did it work in the past?
When we released ABAP Environment as product to the market in 2018, we started off with a fixed system size according to the technical minimum configuration that was, on the one hand side, necessary in order to operate the full stack in a stable fashion, but also capable of handling productive use cases with small or medium amounts of users. Therefore, we chose a size of 16 GB of ABAP server memory and 64 GB of ABAP persistence (HANA database) memory. If you have used ABAP environment already, you might have come across the famous 16_abap_64_db service plan in SAP Cloud Platform Cockpit – either when assigning it as entitlement to your accounts or when starting up a system and choosing the system configuration.
Following screenshots illustrates how an entitlement screen looked like:
This situation persisted for the last one and a half years and we saw many use cases going productive successfully with this system size.
Nevertheless, from the beginning on, we knew that this single configuration would not be enough from a mid-term perspective. Consequently, we had to find a way to offer a new service plan (replacing 16_abap_64_db) in order to provide more flexibility – which leads me to how we have solved this requirement.
How does it work now?
First of all, the existing service plan 16_abap_64_db will not be used anymore, starting today. This affects new customers, but also existing ones that will have a migration option to the new service plan (more info below).
We have introduced a new service plan named standard that enables you to size ABAP server and persistence independent from each other in 16 GB units. These units are represented in so-called quota plans having the names abap_compute_unit and hana_compute_unit.
Consequently, the entitlement screen now looks as following:
As soon as you have assigned an entitlement for the three plans with respective amounts to your subaccount, you can go to your desired Cloud Foundry space and start creating a system. The dialogue will ask you to choose service plan “standard” and proceed with setting system parameters in a JSON key. This is the point where you decide how many 16 GB blocks of abap_compute_unit and hana_compute_unit you want to assign to your new system.
It is important to mention that the minimum configuration stays. So, the minimum system size consists of 1 * abap_compute_unit and 4 * hana_compute_unit.
In total, following system configurations can be used for the two dimensions:
ABAP server memory (ABAP Compute Units)
16 GB (1), 32 GB (2), 64 GB (4), 96 GB (6), 128 GB (8)
HANA database memory (HANA Compute Units)
64 GB (4), 128 GB (8), 256 GB (16)
What happens to existing customers?
As mentioned, all new customers will use the new service plans automatically. For existing customers with quota of service plan 16_abap_64_db there is a migration: every unit of service plan 16_abap_64_db will be converted into service plan standard with 1 unit of abap_compute_unit and 4 units of hana_compute_unit. This conversion will not affect running systems in any way! We will soon provide a migration option from 16_abap_64_db to standard for existing systems.
I hope that this brief overview of the topic gives you some insights into how the new approach looks like. Feel free to post questions in case something should be unclear to you!