Two very different product sets. Zapier falls over as soon as you want to bring in customized data structures/flows/etc, which frankly every enterprise biz does. It also doesn't integrate with the big on-premise stuff (SAP/Oracle/etc) in a customizable/graceful way.
This is, by the way, not a bad thing.
1. Zapier is very flexible if you're willing to write a bit of Python code.
2. Zapier integrates with really any API that supports webhooks, and even those that don't via a CLI and custom language support.
I don't work for Zapier (sadly). But I do use the product every day and have customized it to some pretty unique needs.
- Better enterprise marketing. - Increase depth of existing integrations. - Add additional Zapier-hosted zaps.
I'm a very happy Zapier user and fan, but my sense is they need to hire a few seasoned senior people to level up. I may be wrong, just my sense.
At least, from the perspective of their users.
I don't doubt that Zapier can get there but there is still some way to go even on the infrastructure side.
Defining "major" is hard, I think. You either select a few big providers for integrations, or you go long tail with hundreds. I think there won't be winner take all, as there are a lot of integration dollars to go around (enterprise, SMB, freelance/individual users, etc), and each integration system has their own moat (Microsoft Flow gets access to everyone using Office cloud products, for example).
It’s not like Salesforce could have even bought a large percentage of the shares when they went on offer. You don’t make 100% of the company available.
Sometimes companies ipo to prove to buyers that they believe their market value is higher than potential buyers think. I can’t speak for Mulesoft but their stock has been mainly excellent and their transition to a public company has been fantastic.
Mulesoft brought a great company to market and Salesforce was willing to pay a 23% premium. Mulesoft thought that was fair - today.
As irrational as it sounds (and it is), companies overwhelmingly prefer to chase strength in acquisitions. It makes everything about it look and sound better. They don't care about the cost difference, it's not their money/value being vaporized. They care about protecting their job, so they want positive optics, something that is perceived to move the needle on value.
Presumably, there was a reason.
Usually in a big-enough company the least efficient thing happens instead of the most efficient thing. But the advantage of the big company is that it can play bigger games than your average small company. And if a small company succeeds at playing bigger then you can still buy it. So despite what HR and your manager might tell you, efficiency is not as important for survival.
This is going to be really good for system integrators as Mulesoft is a complex platform that requires hours of consulting. If I was in the Salesforce space I would be signing up to Mulesoft courses and getting my guys all over that.
It seems like they are cutting their own throat in a bid to gain more data integration revenue, except the other companies will reduce their partnership with Salesforce so the total revenue decreases over time.
[1] https://www.theregister.co.uk/2015/08/07/informatica_buyout_...
That said Salesforce isn't THAT bad. There are plenty of edge cases, dark spots in documentation, shitty pricing tiers, BUT there's also a lot of cool stuff you can do with it and most of the cool stuff is incredibly well geared for solving common business problems.
...customers typically want an independent vendor for the type of service Mulesoft provides, since it has to interact with so many different programs from different companies.
“Part of the value of MuleSoft is its true neutrality, and I just kind of think about what happens to that under the umbrella of Salesforce because obviously you guys are a leading applications vendor,” John DiFucci, a Jefferies analyst, said on the call. [1]
In other words, revenue may increase in the short term but in the long term Mulesoft revenue will decrease as customers choose independent data integration solutions. No one wants the old on-premise model of vendor lock-in that Oracle, IBM and others are notorious for pushing.
[1] https://finance.yahoo.com/news/salesforce-buys-mule-pays-ped...
For back-office environment with tons of point 2 point integrations, it just seems to make sense.
Business model is good. Once you're in, going out is really tough. This is exactly like the SFDC app cloud.
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.
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...
1. But there are other message middleware in place, brokers like Kafka, Tibco etc. Is an ESB really needed ? What is the actual benefit ?
2. Do web developers really benefit from using Mule's API design software ? Are there other powerful and free alternatives (technically Mule Community is free but lacks funcationality) or better tools ?
3. What do you lose out if you towards the Mule-way (ESB, API first strategy) ?
I use it as a canary to know if a company is technically inept.
It allows you to write micro services without pushing up your own instances, use kube8, or anything of that nature.
It internally uses raml as its service definition that is analogous to OpenAPI/Swagger.
Think of a number of good yet annoying things you have to do when interacting with other businesses when writing APIs.
Certs set up, QoS depending on customer, key rotation, API throttling, authentication, authorization, HA, etc. You essentially push up a lambda onto their service and config.
The power isn’t necessarily just that as well, but because they have raml, they publish and support an ecosystem of “connectors” which is mostly just a pretty version of an API and has a UI that allows non devs to do ETL on data although almost no one does that. It allows low level engineers to do it though.
Imagine having an Ubuntu machine(s) doing APIs vs an iPhone using apps. It’s packaged nicely for simple API development rather than spinning everything else up that you can.
Mind you, I’m not saying to go out and use it today as it is not cheap but there really is a business case for it.
Lastly, we integrated a lot with Rabbit to help with work that can be done asynchronously. Otherwise your bill from them would be even more expensive.
Would I use it again? Yes, if the company wanted to have the cheapest engineers or use tech savvy product managers and wanted as little DevOps as possible to maintain their code (again think of it like as nicer lambda). Just remember to fork over $200K a year for the bare minimum for what I would call a production grade set up.
https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-...
It does confuse me that Mulesoft, a tool that only the best java developers can get value out of, would be purchased by a company that focuses on ease of use or no software. Salesforce likely has its own internal integration problems and needs an enterprise class platform to integrate its own clouds. In which case Mulesoft would be a good choice. I do not see Mulesoft causing much of a problem for the leaders like Informatica or Boomi. Maybe the Salesforce reps will force Mulesoft down their customers throats but not everyone can manage a java based ESB.
Price wise, its obscene at 22x, so congrats to the mulesoft exec team for getting out while the going was good. I know they were struggling to grow beyond being a 1 product company and many execs/staff were burnt out from staying ahead of Wall St. There has been a lot of attrition from the company over the last year. I know because I hired many of their PMs.
Maybe Salesforce fell for the cool aid of Blockchain, as there was a rumor Mule had some kind of blockchain based tech they were working on.
On an average about 5- 10% sales was coming via these channels for the companies listed above.
Nice strategic move by Salesforce.
There is an ESB for Python called Zato - zato.io . I had interacted with the creator, Dariusz, earlier, and he seemed dedicated to making it a success, and recently I visited the site again, it seems to have got some traction.
https://appexchange.salesforce.com/appxListingDetail?listing...
