Skip to Content
Product Information
Author's profile photo Florian Wahl

Flexible Sizing Options for ABAP Environment

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!

Assigned tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Alejandro Sensejl
      Alejandro Sensejl

      Thanks for the update. Much appreciated. So that means it will be possible now to update application servers (ABAP Compute Unit) without having to buy HANA memory? Tools like https://www.sap.com/products/cloud-platform/pricing/estimator-tool.html or https://www.sapstore.com/solutions/40191/SAP-Cloud-Platform%2C-ABAP-environment are not supporting that yet. Are there any options for SMALLER setups? DEV machine with 0,5 ABAP Compute Units and 1 HANA Compute Unit would be the dream.

      Author's profile photo Florian Wahl
      Florian Wahl
      Blog Post Author

      Thanks Alejandro, we are working on applying the new model to the tools. Regarding smaller setups, 1 ABAP Compute Unit and 4 HANA Compute Units are still the technical minimum. However, we have support for multi-tenancy on the roadmap which will allow you to create multiple smaller tenants within one system.

      Regards,

      Florian

      Author's profile photo Benjamin Kunold
      Benjamin Kunold

      Is the setup totally flexible or are there any dependencies between the size of abap_unit and hana_unit?

      Author's profile photo Florian Wahl
      Florian Wahl
      Blog Post Author

      Hi Benjamin,

      there is no dependency between the two dimensions (except for the minimum size which has 1:4).

      Regards,

      Florian

      Author's profile photo Swathi Vuddala
      Swathi Vuddala

      Good to hear Florian! So this will affect the price as well then...

       

      Thanks for the update

       

      Regards

      Swathi V