Nowadays, customers running SAP on AWS take advantage of the broadest and deepest set of native cloud services, including traditional services like compute, storage, and databases, as well as emerging technologies like IoT and machine learning, on top of a reliable global infrastructure.
One of the main features that we see customers use is the changing of instance types. As the workload changes, customers find that their instances might be overutilized or underutilized.
This concept of scalability is called vertical scaling. Simply put, it is the ability of the system to accommodate additional workloads just by adding resources.
Of course, vertical scalability at the database layer for SAP is important, but what about the application server layer? We can’t create one massive application server to support all our workloads. Even if we can, it’s probably not a good idea. Therefore, SAP designed application servers to scale horizontally. This is where the concept of auto scaling often comes into play.
For horizontal scalability, customers perform sizing and use historical data to determine how many application servers they require to support their peak workload. This leads to underutilized resources or resource bottlenecks when unplanned events occur, such as marketing-driven sales order spikes or large data volume extracts for reporting.
When horizontal scalability comes into the discussion, someone from our DevOps team or cloud engineering team might suggest Amazon EC2 Auto Scaling. But as we all know, SAP can sometimes be a square peg to a round hole. SAP doesn’t always make it easy to handle scalability given its on-premises origin.
This is where AWS helps us build a bridge connecting SAP’s on-premises scalability capabilities to a cloud-native Auto Scaling group.
Traditional automatic scaling uses a range of metrics from CPU utilization to the number of requests to the target of your load balancer. These are both great indicators of workload and the applications use of the underlying resources.
However, they don’t reflect some necessary behavior patterns that customers should consider for SAP utilization.
Every SAP application server consists of work processes that are SAP services based on the SAP kernel. This makes SAP unique. Each work process is specialized in a task type that runs at the OS layer consuming CPU, memory, network, and more. When sizing SAP application servers, the balance and distribution of these are critical to a healthy SAP system.
For microservices and most modern-day applications, standard automatic scaling metrics like CPU and request counts are often enough to handle the application automatically scaling. For SAP, we must consider work processes, especially how many are free or currently consumed.
So, how do we bridge the native automatic scaling capability to consider CPU utilization and request counts as well as work process consumption? That’s where the AWS Professional Services SAP Application Auto Scaling solution comes in.
This solution enables enterprises and SAP Basis administrators to automatically detect SAP application server consumption based on SAP-specific workload metrics for dialog, batch, enqueue, and print work processes. This solution can adapt to spikes and dips for concurrent user logins, month-end close, payment runs, and a variety of both predictable and unpredictable workloads.
The solution uses the on-demand cloud model of provisioning only the application servers that you require. It horizontally scales out (new compute is started as application servers) and back in (existing compute as application servers are stopped), based on the metrics that you define. This is like the way that your thermostat maintains the temperature of your home—you select a temperature and the thermostat does the rest.
The following diagram shows how this architecture is configured:
But wait. When we say that this solution scales not only out but also back in, are we going to shut down an application server with users and background jobs running on it? Here is another nuanced SAP challenge. Not all SAP traffic is routed through a load balancer for which we can proactively use connection draining. Some of this traffic is end users on the SAPGUI or from other systems calling your system through native SAP RFC.
To handle this natively with SAP, invoke the soft shutdown, or graceful shutdown, capability within SAP all with the serverless compute layer, AWS Lambda. This ensures that no requests or data are lost when ending an SAP instance and you minimize the overall TCO of this solution.
A soft shutdown waits for transactions to be completed in a specific order. You then combine this with the API control plane of EC2 to coordinate the application servers’ underlying EC2 instance for a holistic approach to SAP capacity on demand.
The AWS Professional Services solution, using AWS serverless computer, storage, and analytics, enables customers bound by on-premises and monolithic SAP architectures to run SAP in a more elastic, scalable, and cost-effective manner.
With AWS Auto Scaling, you only pay for what you require, helping to reduce operational cost and providing higher service level objectives. Just like a thermostat, you select metrics and the solution does the rest.