Salesforce is buying MuleSoft at enterprise value of $6.5B(techcrunch.com)
techcrunch.com
Salesforce is buying MuleSoft at enterprise value of $6.5B
https://techcrunch.com/2018/03/20/salesforce-is-buying-mulesoft-at-enterprise-value-of-6-5-billion/
12 comments
One year after their IPO? I don't get this. Why didn't they buy it last year paying a premium over the 17 USD a share of their public offering instead of paying a premium over the current 33 USD (or 40 USD I guess)?
I don't understand the rationale behind these deals.
How do you know they didn’t try? Mulesoft doesn’t have to agree to terms of an offer.
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.
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.
That's like asking why didn't Yahoo, Google, Apple, Amazon etc. acquire Netflix after the Qwikster debacle when the stock imploded down to $7.x / share losing ~80% of its value (now $317 / share).
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.
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.
It’s not irrational. Integrating an acquired knowledge work company is a costly and risky effort in terms of management bandwidth, culture clash, and business model alignment. Unless you are buying pure assets, it rarely makes sense to acquire a questionable company and risk poisoning your own. That’s why most acquisitions are of companies too small to jeopardize the acquirer or healthy enough to be a low risk and worth the effort.
Question is why would MuleSoft sell itself if they thought they'd be worth more a year later?
MuleSoft did sell itself; that's what an IPO is.
Presumably, there was a reason.
Presumably, there was a reason.
That's not true. An IPO is just that, a public offering, of a small amount of shares to raise capital. Some shareholders cash out some of their position at IPO.
It's not like going to the super market. And it depends on more factors than price. E.g. Salesforce's competition status plays a role as well, also whatever the current power struggle between different Salesforce managers, etc.
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.
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.
The price for a reasonable amount of due diligence, market proof, and disclosure.
Got to spend those profits some how. Salesforce probably calculated that if they include integration with every deal for an additional 15% to 20% they could grow revenue X%.
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.
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.
Could this be related to the tax law changes?
I was wondering that too. Maybe cash repatriation is at work here?
[deleted]
[deleted]
This reminds me of when Oracle purchased BEA for their Weblogic platform 10 years ago. Oracle destroyed that product and company. Importantly it didn't solve their integration problems as all the best people left within the year as they discovered how hard it was to get anything done in a company of that size.
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.
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.
Makes me wonder if we will see a Zapier IPO soon. It's a crowded space, integration as a service, and in need of consolidation. Zapier doesn't have MuleSofts enterprise street cred because IMHO weak B2B marketing, but the infrastructure is there.
> IMHO weak B2B marketing, but the infrastructure is there
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.
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.
Not at all true.
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.
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.
The last part just sounds like social responsibility/good focus.
Zapier is doing amazing, but it would be a few more years to IPO. They announced 35M in ARR in January. Probably need to get that over 200 to IPO.
They're not going to get to 200 unless:
- 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.
- 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.
Where did they announce revenue?
Very impressive! Annual Run Rate is different from ARR though. Annual Run Rate is probably just taking one (or a few) months, and extrapolate that to a year.
Still great progress for having raised to little though.
Still great progress for having raised to little though.
> Annual Run Rate is different from ARR though
What exactly does ARR mean if not Annual Run Rate?
What exactly does ARR mean if not Annual Run Rate?
Annual recurring revenue
Annual Run Rate.
I'm just adding this for posterity since there 3 completely different yet acceptable definitions of ARR, so telling someone they are "wrong" for not using the same definition as you is a tad silly.
I'm just adding this for posterity since there 3 completely different yet acceptable definitions of ARR, so telling someone they are "wrong" for not using the same definition as you is a tad silly.
It's something that pirates say.
Accounting Rate of Return
https://www.investopedia.com/terms/a/arr.asp
https://www.investopedia.com/terms/a/arr.asp
[deleted]
Agreed, sharp founding team.
I worked with both MuleSoft and Zapier and while Zapier is much easier to use, they only have the basic infrastructure in place. There'a lot more complexity (unnecessary or otherwise) that goes in enterprise integration services.
I don't doubt that Zapier can get there but there is still some way to go even on the infrastructure side.
I don't doubt that Zapier can get there but there is still some way to go even on the infrastructure side.
" It's a crowded space" - Never thought it's that crowded. Wondering who are the major players there..?
Mulesoft, Zapier, Microsoft Flow, Automate.io, Tray.io, Integromat, Workato, PieSync, Dsync, OneSaas, Skyvia
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).
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).
Few more:
Dell Boomi, Segment.io, Pandium, Infomatica...
According to the Gartner Magic Quadrant[1] Informatica is number one, Dell Boomi is number two and MuleSoft is number three.
[1] https://solutionsreview.com/data-integration/whats-changed-2...
[1] https://solutionsreview.com/data-integration/whats-changed-2...
Is there any scope for differentiation? We were thinking of entering this space for some time. I felt most of the platforms are spit into two groups - either a glorified IFTTT or sophisticated, Java based systems that demand tremendous learning curve.
We are trying to place ourselves somewhere in between with market place for open source components supporting modern stacks like Python, R, Node.js etc.. We were wondering if that would unlock tremendous power to system integrators?
We are trying to place ourselves somewhere in between with market place for open source components supporting modern stacks like Python, R, Node.js etc.. We were wondering if that would unlock tremendous power to system integrators?
Wondering why there is so much disparity in price. For e.g. Workato is charging way higher than Integromat. What seems to be driving the pricing for these services?
[deleted]
I am still trying to wrap my head around why is Mule needed. There is a large push at several companies because of: Enterprise Service Bus to help integrate applications, REST API design specing and testing (Mule AnyPoint platform), and API gateways for throttling and applying security policies on API consumption.
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) ?
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) ?
No modern company is pushing esb anymore. It’s an architectural failure still being pushed by vendors and has been architects.
I use it as a canary to know if a company is technically inept.
I use it as a canary to know if a company is technically inept.
I’ve worked with MuleSoft and the ESB really isn’t an “ESB”. It’s really about having the ability to write APIs with specific standards.
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.
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.
Thanks for the detailed reply. I think I need to wrap my head around this more as I am not (fully) getting the benefits and cases you explained.
From their website, their simple definition of Mule ESB is that is used to "integrate" applications so they can talk to each other, even if using different communication protocols:
Mule, the runtime engine of Anypoint Platform, is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data. It enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, Web Services, JDBC, HTTP, and more. The ESB can be deployed anywhere, can integrate and orchestrate events in real time or in batch, and has universal connectivity.
From their website, their simple definition of Mule ESB is that is used to "integrate" applications so they can talk to each other, even if using different communication protocols:
Mule, the runtime engine of Anypoint Platform, is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data. It enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, Web Services, JDBC, HTTP, and more. The ESB can be deployed anywhere, can integrate and orchestrate events in real time or in batch, and has universal connectivity.
So ESBs is a early 2000s concept but what is so terrible about it, or why is it an architectural failure.
So what is used instead of ESBs today?
This seems strange to me since Salesforce already has an ownership stake in the chief competitor to MuleSoft, Informatica Cloud. Salesforce was one of the four companies that took Informatica private [1] three years ago but it seemed like Salesforce was still treating Informatica, MuleSoft and the other cloud data integration solutions equally. Now if Salesforce fully owns MuleSoft, I expect them to prefer it over the other solutions.
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_...
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_...
Seems more likely that they want the database connections than the revenue. Everyone in the Salesforce ecosystem is writing Integrations into other platforms and if they make it easier to ingest data in Salesforce and keep you there it will be more sticky.
As someone who just finished a custom caching solution for Salesforce-backed data I couldn't agree more. There are a number of solutions out there that attempt to mirror salesforce to i.e. Postgres, but they are expensive. Plenty of people want to leave Salesforce but are caught in by the cost of exfiltration.
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.
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.
Salesforce deserve a lot of credit for staying online for 15 years or so while upgrading and expanding the platform every six months, while minimising breakage to customers' customisations. Imagine how most projects would look if you tried that, the developers would usually want to scrap it and re-write after 18 months or so.
Also, massive credit for being a pioneer of SaaS per se. IMHO that's the most profound and impressive aspect to their success and legacy.
I'm looking for one of these 'mirror SFDC (or Zendesk) to Postgres' solutions. No fancy integrations/automated workflows: just back up a Salesforce CRM to Postgres at least every 15 minutes. Fivetran has seemed to be the best fit for this simple use case. Is there an alternative you recommend?
Informatica a competitor to Mulesoft? But at my last gig, ba Fortune 500 company, we had both! Are you implying our IS group was a bunch of idiots? Cause I can totally see that.
At my last gig, another ba Fortune 500 company, we had multiple on-premise data integration tools including Informatica, DataStage, SSIS and an open source ETL tool. Yes, the idiocracy runs deep with this company as well.
From all the commentary in the press after this deal was officially announced, it seems like no one really understands it but they say it’s about growth and increasing revenue. However, this one article summarized it nicely:
...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...
...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...
Owning Mulesoft and having an ownership stake in IC means they win regardless of who wins.
Buying a competitor isn't so strange, though
A lot of these companies - Boomi, Informatica, Snaplogic were banking on low end integration to cloud via the salesforce channel. Salesforce will package mule and then out go all these low end integrations channel for these other companies
On an average about 5- 10% sales was coming via these channels for the companies listed above.
Nice strategic move by Salesforce.
On an average about 5- 10% sales was coming via these channels for the companies listed above.
Nice strategic move by Salesforce.
I think that MuleSoft is a really great business, although I wouldn't use it personally just due to not being in the right industry.
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.
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.
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.
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.
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...
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.
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...
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).
BTW, somewhat relevant (since MuleSoft had/has an Enterprise Service Bus - an ESB, as I remember from checking the company out some time earlier):
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.
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.
What will happen to there API Management System?
We have found a successful niche for doing simple integrations without all the platform bloat and the best part is that it all runs on the Salesforce platform.
https://appexchange.salesforce.com/appxListingDetail?listing...
https://appexchange.salesforce.com/appxListingDetail?listing...
salesforce offers its api on swagger/openapi format and MuleSoft was promoting RAML. hope MuleSoft starts offering openapi tools in its new avatar.
The RAML just ends up generating the usual swagger/openapi stuff now
Mulesoft have been moving away from RAML I believe, although it is still petty core to their product.
https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-...
https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-...
$MULE is up 22% on this news.
As it should be. The deal spread seems kind of wide, though. I wonder why.