Azure Chronicles - Scaling Mule

Overview

In the previous post, we saw how to install and test Mule run time on a standalone VM in Azure. In this post, we will take it a step further to scale out the Mule run time.

There are several ways one could scale a Mule runtime. They are -

1. Anypoint Cloudhub
2. Anypoint Runtime Fabric (internally uses Docker and Kubernetes at the moment)
3. Container as a Service provided by multiple cloud vendors - Google Container Engine, Amazon Container Service, Azure Container Service etc.
4. Build your own cluster with containers

As we go down the above list, the level of details we need to get into is more. So, this post will get into explain how to implement option 4 above.

We will make use of various technologies and Azure components such as - Docker, Containers and Azure VM Scale Set to achieve it. For those of you are new to these concepts, we will go through each of the steps in detail.

Application

Let's use the same Mule API that was created in the previous post. The code is available here. Import this application in Anypoint Studio 6.5 and test it locally.

Container

Next, we need to 'package' this application in a container. As Docker is the prevalent tool in this area, let's use it. The container used in this example is built using this Dockerfile. The Docker image created is available in Docker Hub. The image can be pulled from Docker Hub to a Docker host machine and tested locally.

Scheduler

In this example, we just have one container. But, if we have a more complex example where multiple containers make up an application, then we need to use a Scheduler. Like Docker, the most popular scheduler is Kubernetes. Just like the containers are deployed to an auto scaling VM cluster, Kubernetes can also be deployed in the same way. Perhaps, in another post, we will cover this too.

Cloud

Now, for the main part of this post. In this example, we are going to take it a step further and create an auto scaling cluster that can add/remove VM's based on the load on the application.

Now, that we have the container ready, we need to deploy this container to the VM in an automated manner. Using Azure Custom Extensions, the container can be deployed. The  custom extension comprise of two files - a shell script that is executed for each VM and a configuration file. Both can be found here. The container is deployed to a VM whenever it is created for the first time.

In addition, the VM Scale Set also has scale-out and scale in rules defined. If the CPU goes above 50%, an additional VM is added (and the container deployed). This is the scale-out rule. If the CPU goes below 30%, the VM is deleted. This is the scale-in rule.

1. We initial start with a VM Scaled Set which has the minimum VM's set to 2 and maximum to 4. Initially, with little or no load, the 2 VM's are running (as our minimum is set to 2 for resilience). the minimum and maximum are configurable.

2. The CPU usage in both the VM's is negligible.

3. The load test used in the last post duplicated and modified to point to the public IP of the load balancer of the VM set. The load test results this time are much better. We will see in a moment, why.

4. While the load test is running, the CPU in the VM's jumps to above 50%. In the portal, there is also an 'Updating' message which shows that the VM Scale Set is being updated.

5. When the instances tab is viewed, the additional VM's have been created. The Docker container have also been deployed automatically to these VM's.

6. The additional VM's have also been added to the load balancer automatically. The incoming requests to the Mule API are now load balanced across 4 VM's.

7. Once the load test ends, the CPU usage across all VM's comes down to the original state.

8. One by one, the newer VM's are also deleted completely.

9. The status of the deletions can also bee seen in the Azure Portal.

10. Finally, we are back to the original cluster size of 2 VM's.

11. Once the test is over, we can also see the amount of CPU credits utilized. The below image shows that more CPU credits were consumed only when the 2 additional VM's were created.

Summary

• Scaling out an application horizontally in the cloud helps when an application faces unexpected load. Generally speaking, this approach is more scalable than vertical scaling. Having said that, depending on the type of application, horizontally scalable applications come with their own challenges such as maintaining consistency and state across a cluster of VM's.
• As this example shows, the benefit of the elastic scalability is that money is spent only when needed. This ends up saving money, if we had a fixed VM capacity.
• The combination of Docker and VM Custom Extension is quite powerful as almost any kind of application (like web applications, databases, 3rd party software) can be deployed and scaled automatically.
• One could say that the auto scaling and orchestration using Docker Swarm or Kubernetes is faster and more powerful. 
• However, if there are use cases such as a Python based web application, this approach might be simpler and equally beneficial because languages such as Python are available by default in most Linux distributions. Also, it saves the effort for a team of learning and supporting additional technologies.
• In this example here, the assumption is that this API will have an unpredictable or varying load on it. For this kind of use case, the 'burstable' B-series VM types are ideal. We get charged for the actual CPU utilization and not the vCPU's allocated in the VM. More details can be found here. So, the above VM Scale Set is using the B1ms VM type.

Finally, it is quicker and cheaper to try out various application architectures and deployment models in the cloud. This example took a a day to build and test. And, it cost around 80 INR (roughly equivalent to 1.1 USD). And, that is roughly the same price as a McDonalds Chicken Kebab Burger in India!