4 ms·

I'm in the right business too, and one of the things I've realized is that it's not about building software developers need. It's about building software that

by treis 9y ago

I'm in the right business too, and one of the things I've realized is that it's not about building software developers need. It's about building software that people authorized to spend a lot of money think the enterprise needs. It's dazzling to listen the Mulesoft folks talk about experience APIs and system APIs while dragging and dropping stuff. I can see why people would go for it.

valuearb 9y ago
At my previous job I had to write code to consume mulesoft APIs. Was miserable project, Mulesoft is literally hot garbage.
- nvarsj 9y ago
  Same - I had the unfortune to do a brief contract on a mulesoft mandated project. It was unpleasant to say the least. The UI was also nearly useless, you had to drop to code to do anything meaningful. But the company paid a lot for it, so we had to use it.
- Maven911 9y ago
  Can you explain? It's being pushed heavily as an api spec, api catalog and middleware, and it's notclear to me why we really need it.
  - treis 9y ago
    A huge part of the benefit of software like Mulesoft's is being a common standard. If your the type of company that will have 50 developers working on your ESB and services that's big. So is the expectation that in 30 years you can hire a new batch of developers that will quickly grok your ESB because Mulesoft will still be a thing. Mulesoft does have a lot of cool functionality, but my impression is that unless you are the type of organization with dozens of systems, decades long timespan, and dozens of developers that Mulesoft isn't worth the money.
    - tootie 9y ago
      I think microservices obviates ESB. If you have a legacy system that you can't replace, build a shim layer. Or, better yet, take the money you had allocated for building an ESB and spend it deprecating your legacy systems.
      - treis 9y ago
        What is an ESB if not a collection of shim layers? What you said in the second sentence is one of the purposes of Mulesoft. Creating a unified and consistent shim layer for all of the legacy systems you can't replace.
eecc 9y ago
Ah something like AWS step functions? It always amazes me how management believes that dragging & dropping boxes is more efficient than writing an if statement...
konradb 9y ago
It always seemed to me that spring integration got me to the same place but without he ceremony nor the murkiness around whether you would need to pay for anything,
flarg 9y ago
I'm in the right business and Mulesoft hits the mark when your star devs leave and you're left with maintenance staff because it constrains the degree of complexity in the initial implementation. Obviously nothing that could not be done with a bunch of decent Python devs, but that is not sustainable in the long term for most enterprise business models.

by treis 9y ago

valuearb 9y ago

At my previous job I had to write code to consume mulesoft APIs. Was miserable project, Mulesoft is literally hot garbage.

nvarsj 9y ago
Same - I had the unfortune to do a brief contract on a mulesoft mandated project. It was unpleasant to say the least. The UI was also nearly useless, you had to drop to code to do anything meaningful. But the company paid a lot for it, so we had to use it.
Maven911 9y ago
Can you explain? It's being pushed heavily as an api spec, api catalog and middleware, and it's notclear to me why we really need it.
- treis 9y ago
  A huge part of the benefit of software like Mulesoft's is being a common standard. If your the type of company that will have 50 developers working on your ESB and services that's big. So is the expectation that in 30 years you can hire a new batch of developers that will quickly grok your ESB because Mulesoft will still be a thing. Mulesoft does have a lot of cool functionality, but my impression is that unless you are the type of organization with dozens of systems, decades long timespan, and dozens of developers that Mulesoft isn't worth the money.
  - tootie 9y ago
    I think microservices obviates ESB. If you have a legacy system that you can't replace, build a shim layer. Or, better yet, take the money you had allocated for building an ESB and spend it deprecating your legacy systems.
    - treis 9y ago
      What is an ESB if not a collection of shim layers? What you said in the second sentence is one of the purposes of Mulesoft. Creating a unified and consistent shim layer for all of the legacy systems you can't replace.

eecc 9y ago

Ah something like AWS step functions? It always amazes me how management believes that dragging & dropping boxes is more efficient than writing an if statement...

konradb 9y ago

It always seemed to me that spring integration got me to the same place but without he ceremony nor the murkiness around whether you would need to pay for anything,

flarg 9y ago

I'm in the right business and Mulesoft hits the mark when your star devs leave and you're left with maintenance staff because it constrains the degree of complexity in the initial implementation. Obviously nothing that could not be done with a bunch of decent Python devs, but that is not sustainable in the long term for most enterprise business models.