Migrating Apps from MuleSoft to Red Hat Fuse/Apache Camel

Christopher Scalise
WW Tech Blog
Published in
3 min readFeb 22, 2022

About a year ago, the integration team at WW was investigating alternatives to the MuleSoft platform for our integration work. After evaluating different possibilities, we determined that Red Hat Fuse with Apache Camel was the best fit for us. We won’t dive too deep into the low-level details of the migration, but we wanted to describe some of the benefits and what we learned.

The engineering team was excited to take on this new technology. And having “buy in” from the team definitely helped with the migration, which was able to successfully migrate over 200 apps in about 8 months. Very impressive!

Some benefits we’ve seen since migrating include a much lower memory footprint for our deployed apps as well as a considerable increase in speed and performance.

From the start, we scheduled weekly demo sessions for knowledge sharing. We also created a Slack channel for sharing information and ideas. If anyone solved a problem, it could quickly be shared with the entire team. If anyone ran into an issue, other team members could easily offer their assistance. And WW has outstanding online training resources available.

The old MuleSoft environment provided a drag-and-drop graphical UI and a proprietary programming language called DataWeave. The new Red Hat/Camel environment allows us to work in Java and take advantage of its framework and capabilities. Camel has more than 300 supported components and handles dozens of data formats. We use the Spring Tool Suite for our IDE.

Migrating, or essentially re-developing, all of our integration apps gave us an opportunity to re-think things and improve our design. We developed a robust “common core,” which includes many shared functions and interfaces that reduced previous code duplication. We started using common properties for our interfaces. If a host name or credentials for a connection need to be updated, it can be easily done in one place now.

Emailed notifications were sometimes inconsistent before. Our new email notifications use a standardized subject format that indicates the source environment (i.e. production, QA, DEV) and includes a high level status. This makes it easier to notice errors or failures that have been detected by the apps.

Another enhancement was to use Elasticsearch for logging information. This enables us to create a user interface to use this logged information and provide better monitoring.

And finally, due to the migration, we needed to update all of our documentation. Some old documents were missing details or contained obsolete information. Revisiting this resulted in better, more up-to-date documents that accurately describe our current apps. And the updated documentation helped our QA team with their testing.

The whole experience has been excellent! The team was eager to learn to use new tools and to leverage their programming expertise in Java to develop the new apps. Also, the reduction in required memory resources and the increase in performance has been a big win. The new apps are very stable and have been running successfully without any issues.

Christopher Scalise
Data Engineer II

Interested in joining the WW team? Check out the careers page to view technology job listings as well as open positions on other teams.

--

--