How would you like to cut your SAP hosting costs by 35%?
That's the average saving for Centiq clients when using our tools to reduce their total cost of ownership.
TL;DR version: you can move SAP to the cloud and save money. Here are nine ways to do it.
1. Optimise Azure virtual machines
For most SAP customers, even with large M series instances, virtual machines eat up half of their Azure consumption costs.
Switching from pay as you go (PAYG) to reserved instances can save more than 72% over three years. That’s the low hanging fruit.
You can use reserved instances for constant usage and add use dynamic resizing and pay for peak extra capacity via PAYG as a spot buy.
Of course, you always need to model this to get the right balance.
2. Optimise storage
The other significant cost is Azure landscapes storage. This is consumed by primary storage, files services, backups as well as log analytics and volumes.
- Customers should always archive SAP data before a migration. Most do not. But people who do can cut 50% of their storage costs on the way into the cloud.
- Continuous archiving, even if quarterly, can save and offset >70% of storage growth costs.
- Tiering storage for all non-production systems is essential.
- Scheduled and automated tiering of backups >30 days retention on the coldest storage and log analytics >30 days is imperative.
- You should challenge and refresh data retention policies, remain compliant regularly and accept slower service levels for recovery purposes and infrequently-used data.
3. Tight-size and right-size resources
For most SAP customers, critical production databases and primary application systems should be reserved for three years.
- When sizing, tight-size and right-size. Assume if you are with growth approaching the next threshold ie 4 to 6TiB, that you commit to 4 TiB, archive in-memory data with the business to maintain capacity to 4TiB. Moving to 6 TiB can increase database costs by 50% but offloading and reloading is far more cost-effective when managed appropriately.
- For all other SAP landscape tiers, resources should not be permanently active. Build systems and configurations to enable an automated refresh when required.
- Implement resource scheduling and setting thresholds to forecast costs for the expected active time per tier (development, sandbox, QA, pre-production etc.)
4. Do your data management homework
Yes, storage is cheap. But think about it differently. It still uses energy, and it must remain compliant.
What value does that retention have to your business? When was it last accessed? Have you removed all duplication?
There are some excellent Azure Data Lake archiving and data tiering features that you need to implement. There are some features available in third-party solutions to enhance reporting, de-duplication and data management.
But do your homework – do not simply migrate current backup solutions to the cloud without reviewing them first. You may just end up relocating a problem, not solving it.
5. Pay attention to load management
Most SAP on Azure systems have consistent load and demand profiles so you can automate capacity and system resources.
Short term non-forecast load presents a far greater challenge which is where auto-scaling can be used. This relies on temporary PAYG resources when needed.
However, this should only apply to production application resources. Review auto-scaling parameters monthly as well as application optimisation activities, focusing on application efficiency.
6. Tame licensing costs
Many cloud options now incorporate licensing, but you may be on a 'bring your own licence' (BOYL) contract.
Model this carefully for all non-production systems.
- For Microsoft licensing, AHUB can offer a wide range of optimisation options, but if you select PAYG licenses, it will cost you up to 25% more.
- BOYL licensing for SUSE or Red Hat purchased with mobility is the optimal approach for production instances. Model all non-production systems based on actual business need to select the optimal licensing arrangements.
- For non-SAP licensing such as Microsoft Windows and SQL Server, AHUB or EA licensing can be at least 20% cheaper than PAYG or embedded licenses in marketplace images.
- PAYG licensing is optimal for test and development systems, innovation or peak load support. Always make sure these opportunities are identified and controlled centrally from a cost perspective.
7. Take advantage of dynamic resizing
Resizing has proven an effective strategy to reduce cloud costs.
Azure enables a new approach to dynamic resizing, even with reserved production instances.
This means scaling up resources, such as virtual machines or storage, when needed and automatically scaling it back down again when they are not required.
Many customers removed high availability and non-production systems immediately from their landscapes with minor business impact to cut cloud costs by more than 35% in 24 hours.
Define the criteria in your business that affect the short and long term sizing of Azure systems and plan accordingly.
Always consider other optimisation steps before you resize for growth. For example, have you archived? What is the expected load profile increase? Can you reassign other resources? What is the effect on high availability and business continuity in other regions?
8. Consider resource scheduling
Another new feature, alongside dynamic resizing, is resource scheduling. This is particularly useful for non-production systems where landscapes and systems can be switched on and off based on business hours or after a certain period of inactivity.
Azure Resource Scheduler (or similar tools) enable businesses to coordinate resource availability while setting cost goals. Justifications can be added to increase usage as required or related to business demand or activities.
9. Automate, automate, automate
You can use tools such as Azure Resource Manager (ARM), Terraform, Ansible, Cucumber, Vagrant, SaltStack, Chef and Puppet to deploy resources automatically using standardised configurations and templates.
The result is highly repeatable, automated and consistent outcomes.
This minimises the cost of build time and lets you provision systems rapidly from a central source of truth. It also minimises the cost of storing system images and snapshots.
Our ROI calculation for ARM and infrastructure-as-code (IAC) is simple. It takes 2.5 times the effort to write the initial automation approach and test it compared to one manual build. However, we typically build at least 30 systems in an average Azure resource landscape from that code, and rebuild at least three times for a total of 90 builds.
But once we automate the build process, it takes 5% of the manual build time, leading to a 92% improvement overall. It is always more consistent, repeatable and scalable, so the automation process simplifies future updates and upgrades.
Bonus recommendation: Get expert help
If these recommendations resonate and you are looking to cut the cost of your SAP estate, we can help. Contact us for an initial estimate of how much we can help you save based on your specific requirements and infrastructure.
