Experiences with MuleSoft

Forums › IT Pro and developers › Experiences with MuleSoft

ShinyChrome

1603 posts

Uber Geek
+1 received by user: 686

ID Verified

Trusted

#290238 29-Oct-2021 11:39

Hi folks, I was hoping to get the scuttlebutt from longtime MuleSoft enterprise users, namely technical users, devs, ops etc.

We are looking at implementing the full Anypoint stack at work (Small-to-Medium Enterprise) using CloudHub and I'm particularly interested in how well it has aged after a few turns around the ole' ball of fusion. Especially so for orgs beginning their cloud journey, and looking at migrating from predominately on-prem deployments.

I'd also be interested to hear from users who have elected to go the opposite way, using a more DIY method with products the likes of Apache Camel

TIA

timbosan

2199 posts

Uber Geek
+1 received by user: 294

Subscriber

#2803498 29-Oct-2021 12:58

Hi, I implemented Mulesoft a while back for the external API's and associated workflows for a company I worked at. We used the free version (the pricing of Mulesoft has always amazed me, it is NOT cheap at all, either free of $$$$, unless they have recently changed models).

I liked Anypoint Studio, nice tool to get things up and running, yet still had integrations to Git for versioning (so was a 'true' dev tool, not just a nice looking frontend); the ability to add Java classes for components that didn't do what was exactly needed, the ability to communicate with products like SQL Server, etc.

In the end the project was replace with a .Net Core solution after I left as the remaining devs all new .Net more than Java :-)

I have also used it in home projects for standing up external API's.

ShinyChrome

1603 posts

Uber Geek
+1 received by user: 686

ID Verified

Trusted

#2805844 2-Nov-2021 08:15

Thanks for the feedback @timbosan

Interesting that there is a free version... but no, they certainly love their cost-add options from what I have seen of the pricing!

Good to know about Anypoint Studio; how much of a real IDE it was and things like using our existing source control was a concern.

We are a primarily a .NET team, but since we are pivoting away from bespoke in-house development, picking up Java is no real concern. We had more concerns about too many guard-rails being built into the product and whether that would constrain us in future as we have high number of systems to integrate, but on the other hand, we don't have a whole heap of complex use cases.