MuleSoft RTF

Scaling MuleSoft Runtime Fabric (RTF): Objective, Implementation, and Key Considerations

When it comes to scaling MuleSoft Runtime Fabric (RTF), we deal with several high-level yet conflicting requirements from our customers. With leaps of experience, we have found that they are always comparing the possibilities—good and bad—of choosing on-premise deployment over the cloud, and vice-versa. 

Interestingly, MuleSoft has done a commendable job by shoring up the capabilities of both on-premise and cloud deployment methods. 

As a step-up, MuleSoft gives enterprises the ability to automate the on-premise deployment while experiencing the flexibility of using the script or the runtime control plane (RCP) in Anypoint platform. 

MuleSoft Runtime Fabric – In a Nutshell

Anypoint Runtime Fabric (RTF) is a software platform you install on your infrastructure to orchestrate and automate the deployment of your mules. You can install it on your AWS or Azure accounts, your data center, and more. It operates consistently on each of them. By using RTF, clients across industries can: 

  • Run multiple versions of the MuleSoft Runtime within the same Runtime Fabric;
  • Scale horizontally with ease, use built-in load balancing capabilities;
  • Redeploy mules with no downtime;
  • Centrally manage using the control panel hosted by MuleSoft;
  • Do all—without needing to front the expertise to manage what’s running under the covers. The Runtime Fabric is holistically supported by MuleSoft. 

What Does Scaling Mean in RTF?

Auto-scaling isn’t an option with RTF. The process needs manual intervention, as stated above. There are two ways to perform scaling: Horizontal and Vertical.

Horizontal Scaling: 

  • Adds more worker or controller nodes to the cluster
  • Removes worker or controller nodes from the cluster
  • Adds more replicas to the same worker node
  • Removes replicas from worker nodes

Vertical Scaling:

  • Assigns more resources (vCores/Memory) to nodes
  • Limits resources

Following Runtime Control Plane to Perform Scaling
 

For scaling up, follow the steps below: 
  1. Add/remove resources using the Runtime Manager.
  2. Add/remove Pods (replicas) using the Runtime Manager.
  3. Add Nodes using OpsCenter (recommended) or KubeCTL.
    • No automatic creation of new VMs.
    • Provide a properly configured VM before scaling.
    • Newly created VM can join the cluster. 
  4. Add more resources using the Runtime Manager.
  5. Add Pods (replicas) using the Runtime Manager.
  6. Add Nodes to Kubernetes.
    • No automatic creation of new VMs.
    • Provide a properly configured VM before scaling.
    • Newly created VM can join the cluster. 

Scaling down works in the same way: 

  1. Limit resources using Runtime Manager
  2. Remove replicas using Runtime Manager
  3. Remove nodes using Gravitational


The Screenshot View: Explaining the Sequence of POD (Runtime) Scaling in RTF


Vertical Scaling
 

  • In a first, deploy the application using the runtime manager.

    runtime manager
     
  •  As you deploy the application, make sure that you monitor status on the RCP in the Anypoint Platform. 

Runtime Manager1 
 

  • After deployment, the status change will be deployed on the RCP in the Anytime Platform. 

Runtime Manager3 

Upscale horizontally with extending assigned resource to POD:

Monitor the assigned resource. You can see Heap Size Max, just half of the value assigned to the application while deploying. The increase in the size of the value is because of the parallel processes consuming available resources

Anypoint

  • Let’s assign additional memory to the process request. Increase the assigned memory for application from 1.5 GB to 1 GB.

Runtime manager 4

  • Applying changes process status will populate in Anypoint Platform as below: 

Runtime Manager5

  • After the extended resource in memory to the application, validate the assigned resource. Extend memory from 241 MB to 483 MB.

any point1

Horizontal Scaling:

  • Follow with the same deployed application to perform horizontal scaling. 

    Runtime manager6
     
  • The status of the operation in configuration will be populated in RCP in Anypoint platform.

    Note: In RFT, jvm will never be shared between the PODs. It promotes microservices and independent deployment capabilities in the controlled environment by using RTF.

Runtime Manager7

  • The status with replicas will be deployed on the control plane, as highlighted below

Runtime Manager 8

Request Distribution Validation: 

 While performing stress testing on the deployed application with multiple PODs, below are the observations.  

  • If the capability for a cluster gets enabled, the distribution of the request will be with resource availability. The request will be distributed to pods properly.
     
  • If the cluster is not enabled, the behavior of the request for multiple pods, which is associated with the same application, will have some initial hiccups. However, after a little while, the request distribution would be taken care of. 

That’s a wrap to this guide. Happy Learning!