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

Organizations leveraging MuleSoft solutions, when scaling MuleSoft Runtime Fabric (RTF), deal with several high-level yet conflicting customer requirements. With leaps of experience, as an industry-leading provider of MuleSoft Integration Services, we have found that they constantly compare 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: 
 

• Limit resources using Runtime Manager
• Remove replicas using Runtime Manager
• 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.
  
  
   
•  As you deploy the application, make sure that you monitor status on the RCP in the Anypoint Platform. 

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

 

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

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

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

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

Horizontal Scaling:

• Follow with the same deployed application to perform horizontal scaling. 
  
  
   
• 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.

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

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!

About Kellton Tech

Kellton Tech is a trusted MuleSoft Partner with over 20 years of experience in providing MuleSoft solutions and MuleSoft API management services to its global clients to match any scenario.