Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: