The Endless End of Life Cycle with MuleSoft

Sometimes it’s not easy being a MuleSoft customer. While we’ve never been there, plenty of our customers have. 

The licensing model is expensive, with support and maintenance also taking big bites from the bottom line. Training (or hiring) people to work with the technology is another kick in the pants, with special certifications and courses chewing up IT budgets and sidelining the only people able to make MuleSoft work. According to our annual survey, maintenance and training are top of the list for non-iPaaS integration budgets, eating up almost 40% of the spend. So we’re not talking peanuts.

The technology, back in its heyday, was pretty amazing, delivering integration capabilities for SaaS, on-premises software, legacy systems, and other platforms. But technology from the early 2000s is not sufficient for organizations that need meaningful change. Today, enterprise integration is an enabler of innovation and agility. If it’s constraining the business, then it’s not doing its job.

One MuleSoft Tipping Point: End of Life

A big motivator for companies stepping off the MuleSoft train is the chaotic and expensive end of life (EOL) experience. For example, the Mule Runtime Engine V4.3 which recently devolved from standard to extended support.

While extended support for the Runtime Engine may sound reasonable as a final leg in the end of life journey, you need to read the fine print. Once a release enters extended support, baseline enterprise functionality is denied until the customer upgrades to the new version. And we’re not talking about a minor inconvenience. We’re talking about the ability to restart apps or create new ones in CloudHub, the MuleSoft integration platform. How well would your business run if these app activities were suspended?

Un-Appy Apps

Upgrading to the next Runtime Engine version is not a seamless experience, particularly when managing your existing apps.

When a Mule application is created, the developer selects the Runtime Engine upon which the application will run, a.k.a the target Mule version. Each app is built this way and since apps are created over time, it’s not uncommon for target Mule versions to differ by app. You can see where we’re going with this.

MuleSoft does provide a feature flagging mechanism. It helps to identify apps and change the behavior of the Mule instance depending on the minimum Mule version assigned to the app when it was created. Confused? Here’s the MuleSoft article to provide you with even more details.

This capability is meant to support backward compatibility, but it’s complicated. While touted as “automatic”, there is still a lot of manual work required since each app will need an individual feature flag. 

Once apps are identified that need the target Mule version changed, a developer must touch every one, importing the app to Anypoint Studio as a Mule project and changing the Mule version manually, selecting it from the Server Runtime Menu. This adds up to a lot of time for expensive, certified developers to spend on manual EOL house cleaning.

A Conflict of Compatibility

It would certainly help if compatibility was guaranteed. But this is never a given. In fact, it’s rarely guaranteed if the new release is considered major (for example, Runtime 4.x to 5.x). 

While MuleSoft promises “potential compatibility” across minor releases, there is no certainty and little insight, making it difficult to plan and resource for the next cycle.

The Hard Costs of MuleSoft EOL

With such a complicated and labor-intensive model, it’s no surprise the Mule Runtime EOL experience comes at a cost. A few considerations:

1. Resources: We’ve already covered the cost and time needed to certify some or all of your workforce to learn how to use MuleSoft. Assigning these people to work on basic maintenance tasks lessens an already teetering ROI.
2. Bandwidth: While those trained hands are busy tapping applications one at a time, more important work sits idle and IT backlogs continue to grow. Out of control IT backlogs are one of the top motivators for MuleSoft customers to step up to Digibee.
3. Repetitive cycles of work: Release life cycles are getting shorter, forcing MuleSoft customers to do it all over again at an ever faster cadence. For example, Runtime V4.3 ended standard support on June 7, 2023, while 4.4 will end on February 7, 2024. 
4. Disruptions to the business: If you don’t have a full complement of MuleSoft developers sitting around looking for work, odds are you won’t be upgrading on day one. The inability to restart and deploy new apps presents real risks to your operation, increasing the potential of downtime and disruptions to the business.

The Digibee Difference

The best MuleSoft upgrade for many enterprises is when they upgrade to Digibee’s modern integration platform as a service (iPaaS) technology.

Here are just a few of the high points:

• No upgrades for you to worry about. Ever.
• There is no need for engineers and developers to invest 8-10 weeks to learn and be certified. With Digibee, the learning curve is days. Specialized skills are not required, plus it’s free. Our customers will never pay to learn.
• The easy to use drag-and-drop interface is accessible to junior and experienced workers, allowing everyone to contribute with fewer errors and faster time to value.
• There is no reliance on custom integrations and other support. Digibee’s low code for pro-coders platform allows in-house teams to scale, monitor, and build integrations from scratch, all in one place.
• Digibee is cloud-native, engine-based, and built on Kubernetes, leaving MuleSoft’s on-premises architecture in the dust.

To learn more about the advantages of Digibee’s iPaaS technology versus MuleSoft, book some time to talk to us.