Mulesoft

Choosing Worker Size in CloudHub

Written by:
Published on February 10, 2019

Choosing Worker Size in CloudHub

Running applications in Mulesoft’s CloudHub is probably the easiest way for any organization using Mule to manage and deploy applications. It guarantees; 99.99% up-time per annum, zero downtime during application deployment, easy management of properties, flow monitoring, application insights, persistent queues, schedulers tracking, persistent object stores, and the list goes on.

CloudHub is a component of Mulesoft that provides hosted and managed servers capable of running any supported version of Mule run-time. CloudHub allows a high level of application isolation by running only one mule application per mule worker. This ensures that issues created by one application will not affect any other application in any environment.

MuleSoft hosts its entire cloud infrastructure on AWS(Amazon Web Services). It is important to understand the different plans and server types offered by AWS in order to make efficient decisions on how many vcores and how many workers to choose for any application deployment in CloudHub.

Where does AWS fit into this?

CloudHub mainly offers two sizes of workers, 0.x and x.0. The various machine sizes in 0.x are 0.1 and 0.2 vcores and in x.0 are 1 vcore, 2 vcores, 4 vcores, 8 vcores, 16 vcores, 32 vcores (for selected accounts). Although these two types are totally different, they may not seem so to someone not aware of AWS machine types.

When comparing these to AWS machine types, 0.1 vcore and 0.2 vcores are AWS T2 micro equivalent which means these machines come with something called Burstable Performance. Whereas comparing x.0 vcore machines to AWS machine types are A1 medium, large, etc. equivalent which means the machine has fixed performance plan.

What is Fixed Performance?

Fixed performance servers in AWS are just like any other server in general where a certain amount of memory and CPU power is guaranteed from the very beginning and there is no consideration if the CPU is getting used or not. You can visit AWS documentation for the same to learn more about AWS instance types: https://aws.amazon.com/ec2/instance-types/.

What is Burstable Performance?

Burstable performance machines are closely monitored for the extent of CPU that is consumed. If the machine is not using CPU power, then corresponding credits are added for that machine in AWS. These are added every hour and can be accumulated for a total of 24 hours. These credits are basically CPU processing credits and offer higher processing power (more than given) when used. A detailed explanation on AWS Burstable Performance can be found here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html

How does all this come together?

After understanding the different instance types offered by MuleSoft CloudHub, the next critical step is to understand how to put this to use.

For – An application with a scheduler

A typical scheduler application would be the one which runs a once or twice a day depending on the requirement and usually stays idle at all other times. When the scheduler is running to process records in bulk it requires a significant amount of CPU power to function with acceptable performance. If the memory requirements are met, it is wise to deploy such an application to 0.1 or 0.2 vcores at one or multiple instances (workers) to ensure the successful running of these application with the lowest possible cost.

For – An application which is an API

APIs built by an organisation also have a peak usage time within a day. No API gets continuously high usage for 24 hours unless it’s an exceptional case. At peak times this API would also need high processing power for its computations which can be obtained by the using the credits accumulated during non-peak hours.

Is there a catch to this?

While all the information and strategies mentioned above can be used to make smarter decisions for choosing vcores, this is only applicable for the processing capacity and requirements of the application. It does not take into consideration the amount of memory to be used by the application. If the memory requirements of the application are not met, there is no other option other than upgrading to a higher vcore.

End Note:

Hope you found this article interesting, do drop us a comment below with your inputs, views, and opinions regarding Choosing Worker Size in CloudHub

Also, if you are interested in learning more about an exciting new code quality product that reduces your Mule project costs by 79%, follow the below link :

2 Replies to “Choosing Worker Size in CloudHub”

Leave a Reply

Your email address will not be published. Required fields are marked *

Other Blog Posts

Other Blog Posts

IZ Analyzer – Scanning API Projects

In an API and microservices world, the quality of the deliverable becomes paramount – since a weak link can break the whole chain. In the previous blog posts, we had seen how Mulesoft code implementations could be quality tested in an automated manner with IZ Analyzer. Now with API Analyzer plugin, APIs can be quality …

Read more

Mind Your Code Quality; It’s an Asset

When comes to code quality, I have seen discussion rather than an argument that the main task of a developer is to deliver working code to the customer. Is it true? I don’t think so. It must be fully covered code; that means not only functionality-focused code, but the quality of code also matters. A …

Read more

Mule 4 Scheduler in Multi-Worker Environment

In MuleSoft projects, when there is a business requirement to self trigger a process, it can be realized in two unique ways:  Without human intervention Or Without external system invocation This is based on two further basic approaches: Schedule based (cron)  Time interval based  MuleSoft Scheduler MuleSoft provides the following scheduling mechanisms: Fixed Frequency schedule: Can …

Read more