Hacker News Reader

Comment by tootie | Hacker News Reader

I'm in the right business and I still don't understand why I'd ever need this kind of software.

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.

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

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.

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.

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.

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.

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.

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...

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,

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.

We use Mulesoft a fair bit as a proxy to our various microservices. IT can do the rate limiting and redirection as a front, whilst keeping our microservices hidden behind the DMZ.

We also use it to transform data from different services when we do integrations, especially old school SOAP ones that we don't want to support directly anymore, and have been replaced by simpler to manage and develop REST APIs. Mulesoft is pretty good for that kind of thing.

Modernization efforts for Fortune 500 enterprises with 1000+s of legacy applications still exist.

I think its one of those things where it could be optional but when you're using it it's like hey it's nice that we have that ability here... that said it's gone a bit beyond it's architectural hey-day now that we have containers and infrastructure as code in general, but it will have it's customer base for years to come.

Well, the promise is a kind of drag-and-drop [1], mix-and-match [2], transform these data fields this way, make a decision off of these other data fields, and ship it there kind of integration. Extra points for having a Store for others' components [3], and optionally doing it in the Cloud [4]. Their site has been tailored to convert executive-types on every buzzword, from Microservices [5] to DevOps [6] to Mobile [7].

Whether this works out is entirely dependent on your org: it still requires competent people wiring up things -- much to management's chagrin -- but it can save a fair bit of time. Tradeoffs all around.

Mule basically started off with an ESB [8] that's a glorified reactor queue and a bunch of canned components of varying qualities that either implement an EIP primitive [9], or some domain-specific templated executor (make SQL calls, make API calls, etc). Now there's a whole ecosystem around it: a marketplace of components, an API proxy, management and monitoring layers, and fancy GUIs. The tools are (mostly) solid -- no more and no less than any other big-name commercial tool, but I'd venture to guess a lot of businesses buy this thinking it's going to be The Silver Bullet they're looking for, and it predictably rarely works that way.

[1] https://www.mulesoft.com/platform/studio [2] https://www.mulesoft.com/integration-solutions/dataweave-int... [3] https://www.mulesoft.com/exchange/ [4] https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-... [5] https://www.mulesoft.com/integration-solutions/api/microserv... [6] https://www.mulesoft.com/integration-solutions/api/devops [7] https://www.mulesoft.com/integration-solutions/api/mobility [8] https://news.ycombinator.com/item?id=13672234#13673158 [9] https://en.wikipedia.org/wiki/Enterprise_Integration_Pattern...

it's hard to understand how this actually gets used for those of us not in enterprise IT. would be great to see an example of a real project using Mule (or similar products).

Reply on news.ycombinator.com