MuleSoft’s 4.1 went GA in January of 2018, before my start at Silverline. At the time of the launch there were two deployment options — standalone (aka “Naked Mule”), and Cloudhub. This was around the time the team at my previous employer finalized the decision to use MuleSoft and we chose to go with standalone deployment of Mule Runtime 4.1. Fast forward about 10 months: the containerized deployment option called Runtime Fabric was added. Since most of the development efforts at the time were rather new, we took a closer look into the offering. 

Runtime Fabric vs. DIY

For those who are not familiar, Runtime Fabric is an appliance version of Mule Runtime that uses Kubernetes for orchestration. When we compared it to our standalone deployment, we noted the following differences:

• Runtime Fabric had access to Secret Manager
• Runtime Fabric offered automated vertical and horizontal scaling
• Runtime Fabric offered log management
• Each application deployment for Runtime Fabric costs at least .07 vCores

Source: https://xkcd.com/905/

I like to consider myself a DIY person. I have quite a few once-used woodworking tools and Ikea spare parts to prove it. This, along with MuleSoft and other more impressive skills, gives me a unique perspective on the bullet points above.

• Secret Manager: We had HashiCorp Vault at our disposal so this was not a must-have feature
• Automated scaling: Our traffic volume was consistent and did not need automated scaling
• Log management: We had Splunk at our disposal and the “bring your own logging” mandate for standalone deployment was not a showstopper 
• Minimum of .07 vCore for each app deployment: This was a dealbreaker. We had close to 40 apps deployed in a standalone cluster with 2 vCores on each server; 2 vCore divided by .07 

The graph below show resources used by 46 applications on a standalone, 8GB JVM on 2 vCore VM. Other than occasional CPU spikes during deployments and re-deployments, the standalone deployments were quite stable. 

Development instance of standalone Mule Runtime 4.2.0

The production resources below are even more encouraging as the app deployments are few and far between. 

Production instance of standalone Mule Runtime 4.2.0

What did it cost?

We were so focused on the cost savings for each app deployment that we overlooked the number of hours spent adding DIY features. Here is a look at some of the DIY features created for standalone deployments:

• Log management for system, application, and VM logs using Splunk
• Localized secret management and a custom mutual SSL security policy
• Custom upgrade/downgrade procedures and other maintenance guidelines
• Custom Powershell/Bash scripts to manage VM/JVM resources

Verdict: Runtime Fabric vs. DIY

Hindsight is 20/20. We spent so much time developing the features above that the C4E team did not have enough capacity to focus on application features and platform evangelization. Given the size of our C4E team, I think it would have made more sense to go with Runtime Fabric instead of sticking with the standalone. However, if we’d had capable sys admins and DevOps engineers, the “Naked Mule” choice would have been just fine. 

Review our MuleSoft solutions and see how Silverline experts can help with your business needs.