At the moment of writing this post, SAP Cloud Platform includes 83 services. It’s a very powerful platform which helps developers to build amazing solutions in different areas. But even the most powerful weapon would be useless if you don’t know how to use it properly.
In this blog post, I would like to touch one of the fundamental cloud computing patterns – workload. It’s extremely important to consider workload when you are working on the solution design.
Workload can be measured in the form of user requests, processing load on servers, network traffic, amount of data stored etc. There are different types of workload:
- Static workload – only changes minimally over time;
- Periodic workload – has recurring peaks;
- Unpredictable workload – changes frequently and randomly;
- Continuously changing workload – grows or shrinks over time.
It’s very simple to manage static workload – you just need to define how much of resources you want to allocate to the application and that’s basically it.
For all other types of workload, you need to be flexible. Of course, you can calculate the peak value and allocate resources accordingly, but then most of the time your app will use just a tiny amount of the resources. It’s not how the design of cloud solution should look like.
To address the challenge of dynamic workload, SAP Cloud Platform offers Application Autoscaler service. With help of this service SCP can provision and kill instances of the application depends on the workload.
In order to demonstrate the capabilities of the service, I will use 2 applications:
- webserviceApp – simple application with implemented API;
- simulatorApp – the application which dynamically sends requests to webserviceApp;
First, log in to SAP Cloud Platform trial instance:
Get the list of available services in the marketplace. Autoscaler service should be available:
Create an instance of the service:
Now we need to deploy the webserviceApp to SAP Cloud Platform and bind autoscaler to the app.
Prepare the configuration for the autoscaler:
Bind the service instance to the application:
Eventually, we have one up and running instance of the app:
Now let’s deploy the simulator which will send requests to the webserviceApp and monitor its behaviour.
Deploy the simulator:
And after a couple of minutes we can see, that the second instance of the webserviceApp is up and running automatically due to increased workload:
Now, let’s stop the simulator:
And after a while we can see that the second instance of the app has also been killed:
In this example, we could see how SAP Cloud Platform Application Autoscaler service automatically provisioned the second instance of the same app due to increased workload and later on killed it when workload shrinks to the normal value. This is how developers should address the issue with the workload.