SAP cloud automation - behind the scenes

Running SAP in the cloud is no longer the scary concept it once was and is actually pretty common practice now. Whether it’s one of the large public clouds such as AWS, Microsoft Azure, Google Cloud, or one of the private cloud based companies that excel in SAP hosting - it’s all received as good practice.

Cloud hosting has changed the way we think about managing servers these days. The ability to spin up a server for a few dollars or euros, run a small application for a limited time and tear it down when you’re finished, all while providing the resiliency and infrastructure to support large scale & major enterprise applications was unheard of just a few years back.

Read more about SAP Cloud Automation Platforms.

The cloud concept shook the infrastructure world when it arrived, has opened the door for whole new industries, and forced many of us to rethink what managing servers really means. No longer are the days of budgeting for hardware, ordering required resources and taking outages to physically add those resources to a server. The ability to add resources such as RAM, CPU and Disk can now be added and removed dynamically on the fly, allowing the applications to scale as required.

But SAP is Different

The ability to add resources to an SAP server on the fly can easily be accomplished, but having SAP recognize those added resources is still is not an automated process. Depending on the specific resources, a system outage may still be required for SAP to recognize those added resources.

So does this mean that all of the benefits of flexibility and scale get lost for SAP in the cloud? - Absolutely Not

Scaling SAP in Public & Private Clouds

Lets say an SAP instance and its database are starting to run slow, the obvious step would be to add resources (memory, CPU). However, natively, SAP doesn’t recognize the additional resources dynamically. It requires some changes and typically a restart.

A way around it, is to add an application server and add it to the central instance - distributing the workload and freeing up resources. Each of these application servers may reside on their own operating system or ‘server’ (virtual one in the cloud case).

Ahha! There it is! The ability to quickly stand up and remove servers - one of the strong points of public and private clouds!

The Bad News

So it looks like we found the answer! Well…kind of. Sorry to get your hopes up, but there is light at the end of the tunnel. Adding application servers is still a manual practice for many organizations. The ability to quickly stand up the server in the cloud is pretty easy, but installing the app server, connecting it to the central instance and correctly configuring it is not. And as soon as we start to mention human interaction, we know this means scheduling meetings, arranging time, and here it is, we’ve lost our quick scalability.

The Good News

The cool thing is the industry has recognized this challenge and is doing something about it. Managed Service Providers (MSP) and hosting companies are quickly developing proprietary automation to have the ability to build an SAP application server on the fly, connect to the central instance and configure itself. These application servers can be temporary, as a way to add additional resources in times of heavy load, such as month end processing and then spun back down when not needed. This flexibility is not only great from a technology standpoint but it also reduces end customer costs as well. Why pay for all of these extra servers required for month end processing, when you’ll only use them for a day or two per month? It’s a very cool concept that is not easy to automate by any means. And even when the automation is ready, it still requires a human to recognize resources are needed, and manually kick-off the automation process.

The Missing Link

The largest pain point for many IT managed service providers (MSPs) and hosting providers in automating this process is understanding when additional application servers are needed. The ability to identify performance indicators and spawn an automation process sounds easy, but actually comes down to the fundamentals of a strong SAP monitoring tool. There are three main things a monitoring tool requires to correctly connect the first steps of the SAP cloud automation process: 

1. The tool absolutely needs to be a SAP specific monitoring tool. Monitoring tools that cannot reach inside SAP will be forced to take the performance metrics from the server level, which do not accurately reflect the SAP system performance. For more information click here
2. It has to be able to combine individual performance checks into a single group that can indicate an issue. There are a handful of performance checks, which individually may not result in full SAP performance issues, but when combined accurately identify system wide performance issues click here .
3. It needs the ability to communicate with the automation process. This sounds fairly easy, but many SAP monitoring tools struggle to communicate outbound. Having a strong set of APIs (Application Program interface) will allow the monitoring tool to correctly communicate with the correct tool set to spawn the automation process.

Read more on cloud infrastructure automation. 

To see how Syslink Xandria helped many IT managed service providers to closed this loop and offer dynamic, scalable, SAP resources using cloud systems watch this demo