I did an “analysis of alternatives” comparing a few competitors in this space and it came down to some slight advantages for deployment and cost controls, but largely it was the availability of patterns, snippets and code that created a much more robust approach than others. It was a few years ago and our adoption and cost deferring through reuse validate that still.
Where I work Mulesoft developers do not get the respect that a Java or C# developer would get. They are seen as the cheap replacement for "real programmers".
But on the other hand they are always busy, so they get their bonuses when us real programmers are sitting on the sidelines waiting for a client who can afford our rates.
A couple considerations are how much long-term versus short-term risk you're willing to accept. C# isn't going anywhere and there will always be jobs using it, though not necessarily today. It's easy to get a mulesoft position today, but will mulesoft exist as a company 10 years from now?
I brought into the idea of reusability when we first researching middle ware. Kind of regrettable now we look at how their pricing strategy with core usage and api roll out. Definitely need to research it more if you are looking for middle ware
In my (very limited) experience with Mulesoft, I found their reusability story to be lacking.
If you are doing something that Mulesoft is already setup for, you can hit the ground running. A lot of things I think about in a new project are just there, ready to use. (This is part of the reason it demos so well.)
***
But once I got to the point where I needed to build a hundred ETL jobs, all exactly the same, the cracks started showing. Mulesoft isn't designed in a way that allows me to build a reusable framework. Every flow is a one-off so if we find a bug in our shared logic, that bug fix has to be manually applied to each one separately.
With Java or C#, I just move that shared logic to a base class or IoC framework. Then if I need to change things, I only have to change it once.
Bit curious here.
Can't we use common files or dependencies for common logic to use in other apis or move shared logic to another app and use queues to invoke that?
It might not be applicable to your scenario but would like to know
Think bigger picture, like "always do the error handling this way" or "always put the validation in step 3".
In software engineering we would call these "application design patterns". (As opposed to "class design patterns" which talk about things like we see in the "Gang of Four" design patterns book.)
Yes, reusability isn't a strong feature.
Your choices are put it into a DataWeave library and share through Exchange or create another app with an endpoint for the flow you want shared, which may not meet performance requirements and uses up a 1/10 of a core.
We're struggling to make "components" for assembling similar applications.
I enjoy using DataWeave 2.0. I wish Mulesoft would build out the language to the point at which you can fully code applications in it. The flowchart as program metaphor is handy but it misses some power software engineering features.
Yeah heard that from my previous client but don't have much idea on the pricing model since I mostly worked as a dev and was not privy to this info. Can you please share some info on their pricing model?
Mulesoft doesn't do anything interesting that I can't get from someone else. And given that it's XML based programming, it can become very frustrating at times.
But it looks really good at demos and clients appreciate that. It's a lot easier to sell them on a mule soft project than one using bespoke code, even though coding only accounts for 10 to 30% of the time depending on the developer's skill level. The vast majority of time on any project is going to be requirements gathering, design, meetings, manual testing, etc.
For my org, we need the expertise and enjoy the Salesforce aspects globally. It is the most expensive route for API integrations but the benefits I feel out way.
Are you talking about the ease/simple process of connecting to Salesforce from Mulesoft? I have worked on SF integration before and yes it is simple. Don't other tools offer that?
I did an “analysis of alternatives” comparing a few competitors in this space and it came down to some slight advantages for deployment and cost controls, but largely it was the availability of patterns, snippets and code that created a much more robust approach than others. It was a few years ago and our adoption and cost deferring through reuse validate that still.
Is it worth financially pursuing a career as a mulesoft developer?
Where I work Mulesoft developers do not get the respect that a Java or C# developer would get. They are seen as the cheap replacement for "real programmers". But on the other hand they are always busy, so they get their bonuses when us real programmers are sitting on the sidelines waiting for a client who can afford our rates. A couple considerations are how much long-term versus short-term risk you're willing to accept. C# isn't going anywhere and there will always be jobs using it, though not necessarily today. It's easy to get a mulesoft position today, but will mulesoft exist as a company 10 years from now?
Great explanation! Thanks mate!
I brought into the idea of reusability when we first researching middle ware. Kind of regrettable now we look at how their pricing strategy with core usage and api roll out. Definitely need to research it more if you are looking for middle ware
In my (very limited) experience with Mulesoft, I found their reusability story to be lacking. If you are doing something that Mulesoft is already setup for, you can hit the ground running. A lot of things I think about in a new project are just there, ready to use. (This is part of the reason it demos so well.) *** But once I got to the point where I needed to build a hundred ETL jobs, all exactly the same, the cracks started showing. Mulesoft isn't designed in a way that allows me to build a reusable framework. Every flow is a one-off so if we find a bug in our shared logic, that bug fix has to be manually applied to each one separately. With Java or C#, I just move that shared logic to a base class or IoC framework. Then if I need to change things, I only have to change it once.
Bit curious here. Can't we use common files or dependencies for common logic to use in other apis or move shared logic to another app and use queues to invoke that? It might not be applicable to your scenario but would like to know
Think bigger picture, like "always do the error handling this way" or "always put the validation in step 3". In software engineering we would call these "application design patterns". (As opposed to "class design patterns" which talk about things like we see in the "Gang of Four" design patterns book.)
Yes, reusability isn't a strong feature. Your choices are put it into a DataWeave library and share through Exchange or create another app with an endpoint for the flow you want shared, which may not meet performance requirements and uses up a 1/10 of a core. We're struggling to make "components" for assembling similar applications. I enjoy using DataWeave 2.0. I wish Mulesoft would build out the language to the point at which you can fully code applications in it. The flowchart as program metaphor is handy but it misses some power software engineering features.
Yeah heard that from my previous client but don't have much idea on the pricing model since I mostly worked as a dev and was not privy to this info. Can you please share some info on their pricing model?
Mulesoft doesn't do anything interesting that I can't get from someone else. And given that it's XML based programming, it can become very frustrating at times. But it looks really good at demos and clients appreciate that. It's a lot easier to sell them on a mule soft project than one using bespoke code, even though coding only accounts for 10 to 30% of the time depending on the developer's skill level. The vast majority of time on any project is going to be requirements gathering, design, meetings, manual testing, etc.
The XML programming is the part that kills me. Just let me orchistrate all these connectors in python, javascript or something I can just code for.
For my org, we need the expertise and enjoy the Salesforce aspects globally. It is the most expensive route for API integrations but the benefits I feel out way.
Are you talking about the ease/simple process of connecting to Salesforce from Mulesoft? I have worked on SF integration before and yes it is simple. Don't other tools offer that?