ABAP Environment - The right size (sizing)

Table of contents

• Introduction
• Sizing
• System landscape
• Equipment
• Costs
• System Hibernation
• Data retention
• Update/Maintenance
• Comparison
• Conclusion

In this blog you will find some information about the right size of the ABAP environment if you want to set up your first environment. We will discuss the costs, performance and size of the system. The article was created in collaboration with Burcu Karlidag (SAP).

 

Introduction

You want to use the ABAP environment for your side-by-side development and build decoupled applications in the BTP? Would you like to operate a Central ATC (ABAP Test Cockpit) in the BTP? Are you and your colleagues particularly good at ABAP and want to work with it in the BTP? Then you can use the SAP BTP ABAP Environment to implement various scenarios.

 

Sizing

Once you have made the decision to use it, the next step is to consider the size of the system and the size of the system landscape for operation. You should pay attention to various points, more on this in this section.

 

System landscape

When designing your future landscape, you should consider what you want to use it for. If you want to use the system for training or just as a central ABAP test cockpit, one system is probably enough. You should plan for at least two systems so that you have development and production. In principle, it is also possible to connect test systems to the development environment so that you can develop but also test.

If the specialist department is to work in a stable test environment independently of development, then you should use a 3-system landscape. This also gives you the opportunity to carry out a pre-upgrade. With a pre-upgrade of your test system, you can check your system two weeks before the actual upgrade. From our own experience, a pre-upgrade is worthwhile because we were able to identify errors that would otherwise have led to a production downtime. If you want to run critical applications in the ABAP environment, we recommend this setup.

The last size would be the 5-system landscape, which is particularly suitable for long-running projects and longer release cycles. This allows you to decouple the release from maintenance and remain able to act quickly. In principle, you can also achieve this if, for example, you work with release branches in a 3-system landscape. This way, you can save your current development in the release branch, implement the hotfix in the main and then put it into production.

 

Equipment

Once you have defined your system landscape, it is now a question of the size of the systems. Let's look at the estimator to see which sizes we can define. We currently have three sizes available that we can actively influence.

 

• Hours - The standard here is 730 hours per month (365 days / 12 months * 24 hours). If you don't want the system to run 24 hours a day, every day, you can change the number here. More about this under System Hibernation in the Costs chapter.
• Runtime - This affects the memory for runtime, i.e. the simultaneous execution of Fiori applications and jobs in the system. The calculation is done in blocks of 16 GB each and you have one block (16 GB) to 128 blocks (2 TB) at your disposal.
• Persistent - This concerns the database storage, i.e. the backed up data on the HANA database. The calculation is done in blocks of 16 GB each and you have two blocks (32 GB) to 128 blocks (4 TB) at your disposal.

 

Hint: From my own experience, the smallest configuration of a system is sufficient for development and test systems, i.e. 16 GB runtime (1 block) and 32 GB persistence (2 blocks). Depending on what you want to do with production, the smallest version is sufficient here too. Since the applications in the system are built stateless, no session needs to be maintained. Upsizing production is possible at any time; see the SAP blog below for more details.

 

Costs

In this section we will look at the costs and where you can save money when operating the systems in order to have a cost-effective landscape.

 

System Hibernation

System hibernation is the option of shutting down the systems at certain times and thus saving money. You can use the BTP service "Landscape Portal" to manage your systems and set when which systems are shut down. You can find out more about this topic in the linked SAP Community article below.

Here's a small example. Let's assume that we use the smallest system and let it run 24/7, then we pay around 2200 euros per month. But if we only use the system from 7 a.m. to 8 p.m. and stop it completely at the weekend, then we only pay around 880 euros per month for this environment. That definitely makes sense for development and test systems.

 

Data retention

The more data you want to persist in the system, the more expensive the system will be for you. But here you should ask yourself why you should keep all the data in the current system. Basically, the point of the system is to expand the on-premise systems, where the actual data is located. The data can be loaded at runtime via OData, RFC, SOAP or SDA. If you have a lot of read access to the on-premise, the use case may not make sense because it is a closely coupled application. You would implement this application on the on-premise system using ABAP Cloud.

It therefore makes sense to think about archiving, deletion processes and data storage right from the start in order to avoid provisioning an unnecessarily large system.

 

Update/Maintenance

If an update or maintenance is pending, the machine must be restarted if the system is in system hibernation during this time. We as the customer currently bear the costs for this runtime.

 

Comparison

The cost block of a system looks very high at first glance, but you should also note that all services are already included (runtime, HANA storage, transport management, job management, launchpad). If you are building a CAP (Cloud Application Programming Model) scenario, you will need the various services individually:

• Cloud Foundry
• SAP HANA Cloud
• SAP Build Workzone 
• SAP Cloud Transport Management
• SAP Job Scheduling Service

 

Image: Symbolic progression of Costs

 

With low usage and small scenarios, you will save money. Depending on further use, the individual costs of the services can quickly exceed the total costs of the ABAP environment.

 

Conclusion

This article is intended to help you find the right system landscape and the right size for your ABAP environment. We would like to give you a few points to consider.

 

Further information:
SAP Community - Manage System Hibernation
SAP Community - Elastic Scaling