Optimise your SAP BTP, Cloud Foundry runtime costs

[Marco_Dorn]

Recent talks with customers motivated me to write this blog post on how you can optimize your consumptions and therefore charges for SAP BTP, Cloud Foundry runtime when using the consumption-based models of SAP BTP. The runtime is charged by "GB of memory”, but it wasn’t obvious which amount of memory is taken into consideration.

When you deploy an application either via the user interface or by defining its attributes via YAML, you set the amount of memory which is reserved for each instance (or a default of 1024 MB is set). In the UI, this is called “Memory Quota” and inside a YAML, this is the value

modules.parameters.memory

This value is reported in the respective Cloud Foundry App Usage event (further described here at “memory_in_mb_per_instance“) along with the number of app instances.

Each hour, this is metered for each application instance in each Space inside a Global Account. At the end of a month, the hourly values are summed-up, divided by 730 hours, and rounded-up to the next full GB which is then charged in case the Global Account is based on the consumption-based model (CPEA or Pay-as-You-Go). An elaborate example for this calculation is given in the SAP Help Portal.

Start analysing

To start optimizing the above value, open your deployed application. You can see the defined value in the UI at “Quota Information > Memory Quota”. The maximum you can define for each instance is the “Instance Memory Limit“.
The memory available for the whole subaccount is shown in the brackets of “Memory Quota” called “available memory“ (see the second "Note" box here).

Further down below in the “Instances” section, you can see how much of the memory quota per instance is currently used. This is visualized with by the green bar of “Memory Usage”.

If you want to analyze the memory usage over time, you can use the “SAP Application Logging Service for SAP BTP“. It retains logs for 7 days and inside the Kibana dashboard of the service instance, you can open “Four Golden Signals > Saturation” and there see the “Memory load” over time. At the top right, you can change the time frame for the charts.

Furthermore, keep in mind that the assigned memory relates to the assigned CPUs. Each GB of memory relates to 1/4 CPU. Therefore, it is important to consider as well the “CPU load” over time which is displayd above the memory load chart.

After learning about the required memory+CPU and potential peaks, you can apply changes to the Memory Quota. Keep in mind that “if an instance exceeds this limit, Cloud Foundry restarts the instance. If an instance exceeds its memory limit repeatedly in a short period of time, Cloud Foundry delays restarting the instance.“ (source)

On top, keep in mind that apps based on certain technologies require a minimum of memory, like Java-based applications.

Avoiding trouble with help of the Application Autoscaler

Once you know the limits you need to set per instance for the vertical scaling, you can start thinking about horizontal scaling to dynamically add instances upon load or time schedule. Have a look into the “Application Autoscaler” service offered inside the SAP BTP to learn more about this.

"Efficient Workload management on SAP Cloud Foundry using Application Autoscaler" elaborates on the topic, too.

[enric101]

Thanks a lot Marco for these tips.

About the database, exist any strategy to optimize the HDI deployer app?

I observed that after the deploy the application "DB deployer" is not necessary but automatically it's not possible delete as a last step in deployment.

Regards

 

Enric

 

 

[Marco_Dorn]

Hello enric101,

Could you please elaborate which database you refer to or which section of my post? I am not sure that I get your question.

Best regards,
Marco

[enric101]

Hi Marco,

Sorry, I have not expressed myself well. I was referring to a CAP project, when deployed to the sub-account foundry, these projects generate an application:

These applications seem to be used only for deploying, but if they are deleted afterwards, it does not affect the database or the API.

My question was if there is any recommendation or mechanism to clean this type of applications and thus reduce the consumption of the account.

Thanks in advance

Regards

Enric

[Uwe_Klinger]

Hi Enric,

Unfortunately, I'm not aware of such a mechanism. But you can simply delete the app after successful deployment. Maybe you can add it to your deployment pipeline:

cf delete my-api-db-deployer

But what do you think cause costs? AFAIK only used memory is charged and the application will be automatically stopped. So it doesn't consume memory anymore.

Best regards,

Uwe

[kevin_hu]

I think to put static web content in the HTML5 Repository instead and leveraging managed app router can be another factor to reduce cost of cf.

Good to know SAP Application Logging Service for SAP BTP can be used to do this analysis, which is not a free service either . But I think the cost can be minimum as it is charged by tenant not by app.

My Kibana dashboard btw. Looks good. Thanks.

[kevin_hu]

I think db deployer will be in stop status after the deployment. So shouldn't consume anymore memory usage.

just checked mine, looks like no usage.

You can safely leave it, or just delete the app. It will be re-created next time the developer deploys.

[Marco_Dorn]

Hello kevin_hu,

Thanks for your interest in my post! You are right, there are paid plans for the Application Logging service. Next to that, there is as well the "lite" plan which is included in the overall SAP Business Technology Platform "Cloud Platform Enterprise Agreement" contract. It's not included in the PayG contract though.

Best regards,
Marco

[geert-janklaps]

Hi marco.dorn

I'm looking into ways to optimize costs for CF-based applications, your blog already helped me optimize some of the applications. Thanks for these insights!

Do you perhaps know if stopped applications are also counted towards the total consumed memory each hour? (I always thought that the actual consumed memory would be taken into account for consumption-based global accounts honesty)

Reason for asking: in case of test / demo sub accounts in a consumption based global account we could e.g. automatically stop the running applications with some scripts running periodically. For example stop all applications at 10h PM and restart them at 8h AM. (saving about 10 hours of runtime every day and even more if we would not start the applications during the weekends for example)

I can't seem to find a clear answer in the help documents or in other blogs.

Best regards,

Geert-Jan

[Marco_Dorn]

Hello 8d8214c7f9734f45be69f95cc0d5aeee,

Stopped applications are not reserving any memory, hence their instances are not charged. You could go ahead with such a script.

Best regards,
Marco

[geert-janklaps]

Hi marco.dorn

Thanks for the information!

Best regards,

Geert-Jan

[former_member33674]

 

Hi Marco , thank you for the great blog.

A couple of questions :

- in the following screenshot lte's say that the consumpiont will remain stable in the time , do i will be charged the cost for 69 MB or 256 Mb (tha is the memory quota available for the instance regardless the consumption) ?

- How the cost/memory would be deducted if I'm in CPEA Scenario with 50 GB available ?

 

Thank you in advance.

 

[Marco_Dorn]

Hello Marco,

You are being charged of what you reserve per instance, i.e. 256 MB. Compare it to a flat with 256 m^2: even if you only use 69 right now, nobody will move into the remaining 187. You could get a smaller place, but if you at some point need again 256, it might not be available anymore.
Now the example breaks because at the end of the month, all the used MB of the whole Global Account are summed up and rounded up to the next GB.

Even if you could in theory use up to 50GB in that subaccount, it is only metered what you reserve for all instances.

Best regards,
Marco

[gregorw]

Hi Kevin,

you've completely right. The deployer is only used to deploy the initial DB schema and update the schema. Its normal state is stoppend. And as far as I've seen stopped instances do not cost anything.

Best Regards
Gregor

[former_member690953]

Hi Marco Dorn,

Thanks for the descriptive blog. There is a query with respect to above thread.  If the cost will be charged based on what we reserve per instance, how the application scaler will help to reduce the cost?

 

for my nodejs instance, the reserved memory is 512. which will be costed per hour as per the above explanation.

 

I have used application autoscaler, and condition written in that if "memoryused">100 add +1 <=100 then -1 instance.

But I wanted to understand how this will save cost? total resverved memory is  512 , but actual consumed memory is 266.5 (190.4+76.1)

As the previous explanation is is stated that, cost will be charged based on reserved memory (512)

 

Can you please help me to understand it clearly?

[Marco_Dorn]

Hello shimna_c9138,

If I read it correctly, each of the two instances in your screen shot is reserving 512 MB memory. Hence, if nothing changes throughout the month and you keep those two instances, you'd be charged for this application 1 GB of CF runtime.

The application autoscaler could help you e.g. to remove the second instance if memory usage is below 100 MB (based on how you configured it), thus release the 512 MB reserved memory. Nevertheless, if usage goes up, the second instance is created again and your application is fine. It might even create a third instance if required and remove it again after a peak workload is gone.

Without the autoscaler, you'd always have to create as many instances as your all-time-peak-workload would require - just to be safe. That makes no sense for you though and only increases cost.

Best regards,
Marco

[former_member690953]

Hi Marco Dorn,

Thanks for your quick response.

Please note that the two instances are created by the application autoscaler based on the policy what I mentioned("memoryused">100 add +1 <=100 then -1 instance);

Without autoscaler, there were only single instance available. So as per your explanation, it will take 512 mb.

But after autoscaler implementation, as per your explanation what i understood was it will create two instances and charge us double.

If the maximum memory usage will be 512, how an autoscaler will help to reduce the cost? Can you help with my scenario as we are looking for autoscaler to reduce the cost. can you please guide me how autoscaler configuration should be done in my scenario.

[Marco_Dorn]

Hello Shimna,

Please note that i am no developer and I was the product manager for the CF runtime when I posted the blog. Therefore, my remarks are based on the learnings and discussions with the product team of the CF runtime from back then, but might need technical validation by you and your development teams wrt. stability of your app.

Back to the cost part: You reserve 512 MB per instance and that's what you are charged for as the CF runtime reserves that much memory at the hyperscaler side and SAP is charged for that. Even if you tell the autoscaler to spin up new instances at 100 MB.

How you could save money (again: disclaimer if that causes any trouble on the application stability, that's to be validated by you) is by reserving only 256 MB memory per instance and still spinning up new instances at 100MB. I can see in your screen shot that one instance uses 190 MB, hence you still have some buffer up to 256 MB. But you might need to check peak memory loads per instance and configure the reservation of memory accordingly.

Alternatively, you could tell the autoscaler to create new instances when using more than 300 MB. That would mean you'd only have one instance in the above screen shot, saving you the second reservation of 512 MB until 300 MB memory usage is reached.

Hence, the autoscaler saves you cost by only spinning as many instances as required based on your configuration and takes them down again based on the configuration. Without the autoscaler, you'd manually need to add new instances or always keep x instances running where each one reserves the configured memory.

Does that clarify?

Best regards,
Marco

[former_member690953]

Hi Marco Dorn,

Thanks for the details and for the great explanation. This gives me an idea that how we can save cost.

If we can figure out the average memory used in most of the time, we can set that as a threshold and add/delete instances using the application autoscaler policy. Else we need to either reserve a high memory for our instance or we will need to create multiple instances manually and manage manually every time.

Hope my understanding is correct.

[Marco_Dorn]

Hello Shimna,

Once you know the peaks and the average, I think you can start saving with the application autoscaler. As I wrote above:

If you want to analyze the memory usage over time, you can use the “SAP Application Logging Service for SAP BTP“. It retains logs for 7 days and inside the Kibana dashboard of the service instance, you can open “Four Golden Signals > Saturation” and there see the “Memory load” over time. At the top right, you can change the time frame for the charts.

Then you can see the consumption over the past days.

Best regards,
Marco

[former_member690953]

Hi Marco Dorn,

 

Thanks for the detailed explanation and useful blog!.

 

Best Regards,

Shimna

[JaySchwendemann]

Hi Marco,

you may be the wrong tree to bark up to, but I think SAP should have a viable interest in selling their Platform. Restricting Monitoring tools for effective cost control and other tools in this vicinity to paid plans or only making them available on certain levels of engagement (read CPEA) hinders platform adoption.

 

Customer refrain from investing into the platform if they feel they are subject to uncertaincies and or legal dispute when it comes to costing.

Cheers

Jens

[former_member443787]

Hi Jens, Hi Marco,

From the Application Logging team - just wanted to add few points!

• Application Logging offers “Lite” plan and it is a free offering:  https://discovery-center.cloud.sap/index.html#/serviceCatalog/application-logging-service/?region=al...
• I see lite plan is also listed under PayG in discovery center.
• The dashboard that is shared “Saturation” – is part of container metric capability which is also outside the quota restrictions of any plan: https://help.sap.com/docs/application-logging-service/sap-application-logging-service/produce-logs-c...
• + This is one of the features offered by the Application Logging service which I guess Marco leverages in his blog post to get insights to cost – it offers extensive logs & container metrics analytics capabilities for CF apps for 7 days with all its plans. Retention of logs longer than 7 days is not possible with Application Logging Service due to shared stack. It is also not possible in paid plans. A possible more flexible offering is in internal state and still under planning.