Now that cloud computing has become more popular, it's no longer the scary notion it used to be. It's all considered good practice, whether it's using one of the major public clouds such as AWS, Microsoft Azure, Google Cloud, or one of the specialist SAP hosting businesses.
Cloud hosting has revolutionized how we think about server administration. The ability to provision a server for a few dollars or euros, run a little program for a short time and then tear it down when you're done, while also providing robustness and infrastructure to support huge scale & major business applications was unheard of just a few years ago.
When cloud computing was first introduced, it shook the infrastructure industry and opened the door for a variety of new sectors. The days of budgeting for hardware, ordering required resources, and taking outages to physically add those resources to a server are over. This is accomplished by introducing an event-driven architecture, in which changes to resources such as RAM, CPU, and storage can be made immediately. This allows the apps to scale as needed.
SAP Is Different From the Rest
Adding resources to an SAP server on the fly is quite simple; however, having SAP recognize them is still not an automated operation. A system outage may be required for SAP to acknowledge those added resources, depending on the specific resources.
So, is it true that all of the advantages of flexibility and scale go away when SAP moves to the cloud? - Certainly not.
How to Scale SAP in Public and Private Clouds
Let's assume that an SAP instance and its database are getting clogged up, the logical solution would be to add resources (memory, CPU). Natively, though, SAP does not detect any changes in the system. It needs some modifications and generally a restart.
It's possible to work around this by adding an application server and integrating it into the main instance - allocating resources and freeing up space. Each of these application servers may run on its own operating system or ‘server' (virtual one in the cloud scenario).
One of the most significant advantages of public and private clouds is the ease with which servers can be stood up and removed.
The Bad News
So it appears that we've discovered the solution! ...Well, actually, I'm sorry to disappoint you. There is still hope at the end of the tunnel, albeit dimly. Many businesses find that deploying application servers manually is a time-consuming and laborious process. Installing an app server in the cloud may be quick, but correctly setting it up with the central instance and connecting it to the database can be painstaking.
And as soon as we start to mention human interaction, we know this means scheduling meetings, and arranging a time, and here it is, we’ve lost our quick scalability.
The Good News Is...
The good news is that the business has recognized this problem and is attempting to solve it. Managed Service Providers (MSPs) and hosting firms are rapidly creating unique automation software to be able to set up an SAP application server on the fly, connect to the main instance, and customize itself.
In contrast to the application servers found in traditional Java web applications, which are generally permanent, application servers in Spring MVC provide dynamic components and therefore must be recreated when necessary. They might also be created as needed because they are dynamic; this reduces operational costs for both the organization and its customers.
Why spend all of this money on extra servers for month-end processing when you'll use them just once or twice a month? It's a really unique idea that is hard to automate in any way. Even after the automation is completed, it still requires a person to recognize resources are required and start the automation process manually.
The Missing Link
The most serious issue for many IT managed service providers (MSPs) and hosting firms in automating this process is determining when additional application servers are required. The capacity to spot performance indicators and start an automation procedure seems simple, but it all depends on the foundations of a good SAP monitoring solution. A monitoring tool must meet three distinct criteria to successfully connect the first phases of the SAP cloud automation process:
1) The tool must be an SAP-specific monitoring application. If the monitoring software is unable to access SAP, it will have to report on server performance metrics, which aren't accurate reflections of the SAP system's efficiency.
2) It must be able to combine individual performance checks into a single group that may suggest an issue. There are several performance checks, some of which might not indicate full SAP performance issues alone but when combined correctly identify system-wide performance difficulties.
3) It requires the ability to interface with the automation process. This may appear to be a simple objective, but many SAP monitoring solutions have trouble communicating outbound. The monitoring tool must have a strong set of APIs (Application Program Interfaces) in order to communicate correctly with the correct toolset and start the automation process.
Contact us to learn how we can help your business with our SAP monitoring solution.
