Comment by calcsam | Hacker News Reader

Comment by calcsam | Hacker News Reader

Some notes from the S-1:

* "Subscription and support" revenue is about $150M, with "professional services" about $30M. This is a software company with a services side, not the other way around. That's good as software companies tend to be valued around ~10x revenue and services companies only around 3x revenue.

* The company made $180M revenue in 2016, growing at ~70% / year, so it's probably on a ~$250M run rate right now.

* Last round of funding was raised at a $1.5B valuation. I imagine they'll try for 10-12x revenue, or $1.8B - $2.2B. Twilio is currently trading at around ~10x revenue.

* Sales & marketing spend is very heavy -- $122M of their $240M expenses, so about half, were due to sales and marketing. Engineering aka "research and development" only costs them 1/4 of that, or $30M / year. That's...okay I guess? It means growth is pretty expensive, but if they ever want to dial back that growth, they can rake in the $.

* Ownership: Big VCs own 68% of the firm, the original founder owns 6%, the current CEO owns 3%, other execs own another couple percent. Ownership of the other ~20% isn't clear, prob split between smaller VCs and employees.

> It means growth is pretty expensive, but if they ever want to dial back that growth, they can rake in the $.

This is the fundamental premise behind SaaS companies valuations:

http://a16z.com/2015/05/15/a16z-podcast-why-saas-revenue-is-...

Excerpt from that podcast paraphrased "NetSuite and SuccessFactors had their most profitable years during the economic downturn in 2008"

How about a description of what the company does that a mere mortal could understand?

Their main product is an Enterprise Service Bus, a piece of technology that is supposed to help make it easy for software developers to integrate with multiple disparate third party solutions (and potentially internal solutions). So you can get a "Connector" for SAP, and another for Salesforce and consolidate, transfer or do practically whatever with the data in both systems, without having a bunch of developers working on an in-house solution to consume the requisite APIs.

My one criticism of them would be they focus very heavily on cloud, and their on-premises offering is woefully anaemic, lacking fundamental functionality, such as messaging.

I'd say their support for on-promises deployments is anaemic too.

For an open source product in the same niche, have a look at http://servicemix.apache.org/ which includes http://camel.apache.org/ and other bits.

I would also look at https://zato.io/ which is a really nice Python based one.

So basically an API for APIs?

Catchy, but no. Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern; these flows then execute in in a runtime that uses SEDA [1]. They give you some built-in components that help in creating APIs, and this design is a good fit for APIs and data munging, but it can be used as "just" a runtime for event-driven code. For a clearer example, see my other post here [2]. Their other products include an API proxy and a client-facing API gateway.

[1] http://dl.acm.org/citation.cfm?id=502057

[2] https://news.ycombinator.com/item?id=13673158

Worked with the on-premise version, and I'd avoid it like the plague. Badly designed mix of XML and old-school Java, if it wasn't for political reasons we would have kicked it out.

XML/Java is very much it's ancestry. Back in the day, it competed eye-to-eye with ServiceMix and Camel. Both of those have remained firm Apache products. Mule ESB was heavily commercialised, for better or worse.

> Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern

I hope I don't sound too snarky here, but from bird's-eye view, this description sounds like business-speak for:

"It could have been normal programming with external services, with all perils and pitfalls. But in addition to the common pitfalls, you get a badly designed domain-specific language (DSL), using XML syntax to make it even harder to understand, with the promise that you can hand it over to non-programmers, except that you need programmers to extend the DSL with custom components anyway, to make it actually work for you."

Hoping this superficial judgement is wrong: How does the real product deviate from that snarky description?

It's an API for APIs, that collects and connects everything in one place (incoming and outgoing events, data, etc) with it's own specific language.

Apart from the non-programmers bit, you're not wrong.

I've been using the open source version on a project between 2013 and 2015 and it was exactly as you described: it essentially was a very convoluted and un-debuggable way of attacking a class of trivial problems, on which it failed miserably.

Basic functionality (watch a directory for incoming files, apply some processing, move the files to a second directory) would fail without any useful error message. You could "program" it by writing XML files with an Eclipse plugin, but anything non-trivial would involve hundreds of lines of "magic" XML.

I consider myself lucky enough to have moved on.

A couple of ways to describe Mulesoft (depending on your background):

Enterprise version IFTTT/Zapier, but connects to literally anything

Competes with Google's Pub/Sub

Cloud version of BizTalk (but way better)

Would you say that it completes with Azure Logic Apps also?

Wasn't familiar with Azure Logic Apps, but yes it would appear so.

The niche is often called ESB or Enterprise Service Bus but I think a much better description is Integration Service, i.e. something that implements

http://www.enterpriseintegrationpatterns.com/

A good website for info and books about this area.

See also http://stackoverflow.com/questions/8845186/what-exactly-is-a... which has some useful links.

Nice, thanks for breaking down the S-1.

Great comment, thanks for this.

This is a time saver for always busy developers!

Reply on news.ycombinator.com