Today I’ll be explaining you a story you may have heard of or even experienced yourself, if you are an SAP Basis admin:
“The end of the month is near. HR system is on fire calculating payrolls and letting the workforce know when they pay is ready. The ERP system is fully busy calculating god-knows-what that seems to be needed for this month closure process and you don’t want to think about the BW system, which has been busy all night long querying all its neighbors for data for its infocubes.
Your inbox is full of messages asking about why some of the systems’ response are so bad each end of the month/quarter/fiscal year.”
Sounds familiar? If so, probably, you may have put some solutions in place:
- Have some application servers for the peak periods deployed in infrastructure that is not used at 100%
- If you enjoy proper virtualization, probably you created clones of your SAP application servers and started them on peak periods, only to stop them afterwards because the VM farm is pretty overloaded and the VM platform team growls at you when you ask them for resources.
- Ask the business to distribute the processes in more extended timeframes, just to get a bad answer saying that IT should serve the business, and not otherwise (which is true, actually)
- Evaluate some very expensive solutions from some vendors that facilitate the deployment of new servers, but do not solve the fact that you don’t have spare servers and your VM farm is at 90%.
Here at Rocket Steam have seen this in a lot of customers of different sizes and sectors. And when we learned about AWS Auto Scaling features we wondered if it would be possible to adapt them to SAP workloads.