Scaling Up vs Scaling Out: SAP on the Public Cloud

 There are two types of dynamic scaling in the SAP public cloud area, scaling up/down and scaling in/out. They each come with their own set of pros & cons and it can be a bit daunting architecting this all out, so here’s the simple breakdown of what each means. 

If you’ve been considering migrating your SAP systems to the public cloud you’ve probably heard a lot of talk around dynamic scaling or the ability to add resources on the fly. Prior to public clouds or even self-hosted virtual machines, the ability to add resources such as CPU, memory, disk, etc. typically required an outage of the server itself, including SAP. With the introduction of virtual machines (VMs) the ability to scale has made outages for resource allocation a thing of the past. However, on-premise virtual machines still require the hardware on the back-end to be purchased. This is where one of the benefits of running on a public cloud is easily highlighted - there are no back-end hardware purchases, and you only pay a ‘rental’ price of what you are using. By fully understanding how to dynamically allocate these resources, you can easily and significantly reduce your cloud operating costs. Things like shutting down systems when not being used and running on a scaled down, “slim”, system using tools that can self-identify when additional resources are needed will keep your costs low.

But how does scaling work?

There are two types of dynamic scaling in the SAP public cloud area, scaling up/down and scaling in/out. They each come with their own set of pros & cons and it can be a bit daunting architecting this all out, so here’s the simple breakdown of what each means.

Scaling Up/Down

This is the most commonly used terminology when speaking about any kind of scaling in the cloud, and is often misrepresented. Scaling up resources means dynamically (or ‘on-the-fly’) adding resources to an existing server. For example, if you have a server with 4 CPU, adding an additional 2 CPU without having to take an outage, would be considered ‘scaling up’. The opposite, removing resources dynamically (on-the-fly) without an outage is considered scaling down.

Scaling Out/In

This concept has been around just as long but is not as often used in conversation. Scaling out means adding additional servers to help offload workload on a particular system, this could be adding a physical server or virutal one . In the SAP world, this typically means adding additional App servers to take on work that the primary/central instance (main SAP application layer) cannot handle. Contrary to ‘throwing’ more resources onto one server, you’re adding additional servers (& App servers for SAP) to manage the workload. This can also be used to reduce costs by scaling in (removing servers and SAP App servers) to reduce the amount of resources ‘rented’ from the public cloud providers when not required.

Scaling In/Out or Up/Down, Which is Better??

Well, this comes down to the old consulting statement ‘It Depends’, and it truly does. The common myth is that all performance issues within SAP can be solved by throwing more CPU and memory at the server running the system. While this may be true with other applications, in the SAP world most technical Basis engineers cringe when they hear this.

There are a host of issues that affect performance, and a good monitoring tool can easily identify what is the issue . It very well may be that without tools such as Xandria there will be no indications of major performance issues, but CPU and memory are near 100% usage. In this case, scaling up (adding resources to the server) may be the correct choice.

But there are other cases where the system may seem slow to the end user, but really has nothing to do with CPU and memory at all.  A common example is that of how SAP systems are comprised of many ‘work processes’. Every time an end user does something in the system they use a single work process for the length of processing time in the system.  Typically this is done in a fraction of a second. However, if end users start running transactions that may run 1 second or longer (think month end processing), they take up a work process for the entirety of that processing time.  As the work processes are tied up for longer duration, they will start to fill up and eventually a queue of end users begin to wait for a work process to free up. The server’s CPU & memory may be fine, but there are simply not enough work processes to handle all of the transactions trying to run throughout the business and this wait time appears as performance issues to the end user.  In this case, it is best to ‘scale out’ by adding additional SAP App servers and thus adding additional work processes. Other scenarios may include the need for an additional batch (background) processes or architecting an environment with additional underlying resources.

It is also important to note that not all resources that can be dynamically added to the public cloud server can be dynamically added to SAP. SAP has a host of different resources that it ‘allocates’ to itself upon starting up and reserves it so no other process on that server can use it until SAP shuts down again. These cannot be scaled up or down on that single server, but by scaling out and adding additional servers, the system may be able to use those resources from other servers.

All in all, every SAP system is unique just as each business is unique. It’s important to work with your SAP technical Basis engineers when planning your journey to the cloud to decide of the best way to scale your system. The answer is not always scaling up, it very well may be scaling out or a mix of each. Once a plan is architected and in place, take a look at a tool that can help automate the entire process. Syslink Xandria is one of the only tools in the marketplace that can identify different types of SAP performance issues and automate the scaling activities required to most effectively run SAP in the public cloud.

To learn more about these new cloud features, please join this live webinar