Elastic files for an IPO(sec.gov) |
Elastic files for an IPO(sec.gov) |
Twilio, Mulesoft, and MongoDB are probably the best comparables here -- open-source and dev-tools based SaaS IPOs. All of these were very successful at IPO and afterwards, and even compared to these, Elastic looks great.
* They're growing at almost 100% per year which is incredible. Twilio filed for IPO growing at 70% per year. Mulesoft was growing at 60%. Mongo was growing at 50%
* Losing $50M on $150M of revenue. (Net margins of -33%). This is pretty reasonable and in line with Twilio and Mulesoft. MongoDB was significantly worse at -60% net margins.
With that kind of growth I'd imagine something like a 220M ARR when they actually IPO, and valuation of 15-20x that.
"It's really just a wrapper around Solr and a management layer bolted on top I don't understand all the rage!"
It should be noted:
[1] Unlike MongoDB (which is a ground-up build), Elasticsearch is basically an API layer on top of Apache Lucene. This is relevant because they haven't built and don't maintain, control, or own the source of their primary IP.
[2] Unlike MongoDB (General Purpose) Elasticsearch is a single purpose database and good at/used for one thing and one thing only. It searches text fields for text.
So its potential use cases and thus marketshare is far more limited.
[3] Posts on stackoverflow with the tag:
elasticsearch × 34,253 mongodb x 103,478
Lots of people use it for analytics (checkout their aggregation/time series queries) as well as analyzing huge logs. Some people are starting to use it for machine learning use cases too.
MongoDB aggregation feels like writing code in assembler.
Elastic is used for search, log analysis and analytics.
[1] You don't understand their IP if you think it's Lucene. It really, really isn't.
[2] It's not single purpose anything. I've used it for search engines, event buses and as document stores. It's multi-purpose and more dependable at scale and under duress than Mongo thanks to sitting on top of the JVM.
[3] Stackoverflow stats don't mean anything. What are you trying to imply?
Wall Street smoke 'n' mirrors strikes again.
WeWork and Uber can justify it by pointing out unit costs in stable markets, and say 'look we are profitable there, so all of our losses are due to growth'.
Elastic cannot say the same.
In fact Twilio and Mongo have also been hemorhaging money since the start, and it's going to take a hell of a lot of growth, then massive profitability for them to break even.
Venture Captial is now back to the dot-com bubble game of 'who's going to be the fool holding the bag' - basically, raise a pile of money, give away that money for free by selling at a massive loss, and then get naive retail investors to buy into the myth.
What if I raised $100M, bought some lumber, and sold it at a 50% discount to builders, gosh, I'd have a lot of customers! and then did an IPO -> look at the growth!
Twitter is what, 10 years old now?
They just reported their first profitable quarter ever! And guess what, userbase is shrinking!
They're billions in the hole, i.e. billions away from breaking even - they are a massive net financial loss for investors overall; the trick is of course to be an early investor (make money) and not a later investor (dupe).
This game is not designed, it's just a natural dynamic of a market with bad information and or dupes.
Just like the financial crash of 2008 could not happened if dumb German and Japanese banks were not buying up crap bundles thereby enabling local American banks to re-capitalize and go out again and make more bad loans (i.e. the system would have stopped because banks would have quickly run out of capital unable to sell their first batch of crap mortgages) ... in the same way, this VC game would not happen without rube investors somewhere who will actually pay a fortune for a stock like Twitter. There are many more reasons for this obviously.
Unfortunately, when there is shadiness, low-interest rates, not market interventions etc. - the name of the game is 'leverage' - not 'innovation' really. So it makes much more sense to buy your way into a market, than build yourself into it.
And by the way, this is not to take anything away from Twilio or Mongo as products - that's entirely separate issue. Maybe they are great, maybe they are crap, but we don't know because they are being given away at massive discounts so it's very hard to tell.
Sadly, in shady game of leverage, often 'it's the only way' because if you don't - someone else will. WeWork for example is leverage to the max with 0 wiggle room for risk. If there is a market correction and tenancy drops in any major market, they are wiped. Same for any company that's dependent on crazy valuations.
Companies going IPO while losing tons of money, without clear path to profitability ... is not necessarily a good sign.
Why is a -33% net margin “reasonable” instead of just being “less unreasonable”?
The rule states that a "sane" target for annual growth rate + profit margin is 40%. At a 100% YoY growth rate and -33% profit margins, Elastic is sitting at 70% -- making it pretty solid!
As they mature, CFO grows, CFI normalizes and CFF grows to profitability.
Woah.
Another useful section related to revenue in the paragraph just before the one you posted:
> As of July 31, 2018, we had over 5,500 customers across over 80 countries and in a wide range of industries, compared to over 5,000 and 2,800 customers as of April 30, 2018 and 2017, respectively. Our revenue was $159.9 million and $88.2 million in fiscal 2018 and 2017, respectively, representing year-over-year growth of 81% for fiscal 2018. Our revenue was $56.6 million and $31.6 million in the three months ended July 31, 2018 and 2017, respectively, representing period-over-period growth of 79%. Subscriptions accounted for 93% and 90% of our total revenue in fiscal 2018 and 2017, respectively. Subscriptions accounted for 91% of our total revenue in the three months ended July 31, 2018. In fiscal 2018, revenue from outside the United States accounted for 39% of our total revenue.
I’m happy to use their products, filebeat, kibana, elasticsearch, and their cloud offering has been top notch. They got a lot of things right.
Now elasticsearch even supports SQL as a query language.
This is a company that you don’t hear often in the news, but they just kept their focus and shipped the goods.
As you can tell by now I’m a hardcore fan of Elastic.
I was using elasticsearch 7 years ago in production already. And just for me, from the outside, it always looked like a crazy trip. I knew there was something going on when nearly half of my twitter timeline tweeted "am working for elasticsearch now". (they renamed to elastic later)
I was chatting in early 2017 with Shay and along the way he mentioned they were almost 500 then and now ~18 months later they are +800. Crazy!
> They made open source work.
Yes!
They have built and still build impressive (open source) projects and they managed to still earn money :) - this is the real big thing!
I will say I very much enjoy Elastic's suite of products, I can't say the same for MonogoDB.
Or, how hard it can be to intuit the json you need, as a naieve user. Back porting from kibana is silly.
Or how easily you can deploy a naieve cluster which hangs bigtime on large data. This thing is like PostGres and ZFS: you really can't fake it, you have to understand it.
I see good potential in Elastic training
The feature of live node removing/adding alone made my life so much easier. The performance and Machine Learning ranking is the icing on the cake!
"Hey boss, this investment has possible earthquake risk, but that seems very remote; do I have to put that in?"
"Yeah, put it in. No one reads the document anyway unless it goes to court and in that case, you can get dinged for leaving out stupid risk factors, but not for having them in."
My favorite risk factor was "Timothy Sykes doesn't like us"
Did not read the study itself. My explanation would be that since companies are not changing these for fun, they are probably changing them because they see some previously unexpected risk possibly manifesting itself and want to cover their back.
Unfortunately, I can't find the pointer to the study or the article.
Edit: Found the article, I guess this was posted to HN: https://www.theatlantic.com/magazine/archive/2018/09/the-sec... (search for NetApp to find the part about the study)
"
Implications of Being an Emerging Growth Company
We are an “emerging growth company” as defined in the Jumpstart Our Business Startups Act of 2012, or the JOBS Act. An emerging growth company may take advantage of specified reduced reporting requirements that are otherwise applicable generally to public companies. These reduced reporting requirements include:
the requirement to present only two years of audited financial statements and only two years of related management’s discussion and analysis in this prospectus;
an exemption from compliance with the auditor attestation requirement on the effectiveness of our internal control over financial reporting;
reduced disclosure about our executive compensation arrangements; and
an exemption from the requirements to obtain a non-binding advisory vote on executive compensation or shareholder approval of any golden parachute arrangements."
> JAXenter: You started Compass, your first Lucene-based technology, in 2004. Do you remember how and why you became interested in Lucene in the first place?
> Shay Banon: Reminiscing on Compass birth always puts a smile on my face. Compass, and my involvement with Lucene, started by chance. At the time, I was a newlywed that just moved to London to support my wife with her dream of becoming a chef. I was unemployed, and desperately in need of a job, so I decided to play around with “new age” technologies in order to get my skills more uptodate. Playing around with new technologies only works when you are actually trying to build something, so I decided to build an app that my wife could use to capture all the cooking knowledge she was gathering during her chef lessons.
> I picked many different technologies for this cooking app, but at the core of it, in my mind, was a single search box where the cooking knowledge experience would start a single box where typing a concept, a thought, or an ingredient would start the path towards exploring what was possible.
> This quickly led me to Lucene, which was the defacto search library available for Java at the time. I got immersed in it, and Compass was born out of the effort of trying to simplify using Lucene in your typical Java applications (conceptually, it simply started as a “Hibernate” (Java ORM library) for Lucene).
> I got completely hooked with the project, and was working on it more than the cooking app itself, up to a point where it was taking most of my time. I decided to open source it a few months afterwards, and it immediately took off. Compass basically allowed users to easily map their domain model (the code that maps app/business concepts in a typical program) to Lucene, easily index them, and then easily search them.
> That freedom caused people to start to use Compass, and Lucene, in situations that were wonderfully unexpected. Imagine already having the model of a Trade in your financial app, one could easily index that Trade using Compass into Lucene, and then search for it. The freedom of searching across any aspect of a Trade allowed users to convey this freedom to their users, which proved to be an extremely powerful concept.
> Effectively, this allowed me to be in the front seat of talking and working with actual users that were discovering, as was I, the amazing power that search can have when it comes to delivering business value to their users. Oh, and btw, my wife is still waiting for that cooking app. Now, 10 years later, it is the basis of Elasticsearch.
https://jaxenter.com/elasticsearch-founder-interview-112677....
"Immediately prior to the completion of this offering, we intend to change our corporate form from a Dutch private company with limited liability (besloten vennootschap met beperkte aansprakelijkheid) into a Dutch public limited company (naamloze vennootschap) and change our corporate name from Elastic B.V. to Elastic N.V."
As far as I know, Elasticsearch has no headquarters or offices in The Netherlands. I assume the company is only registered in The Netherlands for tax avoidance.
If my assumption is true, despite that I like their products, this makes me a little sad.
EDIT: my bad. I missed the tab Europe and Asia. They do seem to have an office in Amsterdam.
According to their contact page, their European headquarters are in Amsterdam (https://www.elastic.co/contact), so they do seem to have some kind of presence there. And if you look at their careers page, it seems that most of their engineering team is distributed/remote.
Can you say exactly what formula this is and what is a formula for?
Also what is the significance of the number 40 as a target?
Or are they just unnecessarily bloated?
In case of a market or tech hiccup, you might find yourself without "sufficient cash flow", and collapse, but that would be the investors' problem. The investors are assumed to be able to absorb the loss and disappointment without undue discomfort, and so they are. Risk to your dreams takes last place.
MongoDB (the company), has been very strategic about defending themselves from Amazon. Likely due to the AGPL licensing on MongoDB (the database), Amazon doesn't offer a hosted MongoDB - you have to buy MongoDB Atlas which runs on multiple cloud providers, including AWS, GCP and Azure. Coincidentally, Atlas subscriptions are the fastest growing part of MongoDB Inc's revenue, which is why investors are bullish on the company.
Elastic (Apache licensed) has actually had their lunch eaten by Amazon to a much larger degree. Many businesses are purchasing hosted ES instances directly from Amazon via Amazon Elasticsearch service. The problem is bad enough that Elastic Inc had to write a marketing blog post about it [0].
Say what you will about MongoDB (the database), but MongoDB Inc. is the most successful open source software-based company since Red Hat. You can see it in the outperformance of $MDB compared to similarly timed open-source IPOs such as Hortonworks ($HDP) and Cloudera ($CLDR).
[0] - https://www.elastic.co/blog/hosted-elasticsearch-services-ro...
Now, I don't have a lot of data in the cluster, so we'll see how performance is when that happens, but would definitely recommend Elastic's offering.
Also the reason Redis Labs made the controversial decision to change their licensing (and they reference Elastic in it) [1].
[1] https://redislabs.com/blog/redis-license-bsd-will-remain-bsd...
> Cloud providers have been taking advantage of the open source community for years by selling (for hundreds of millions of dollars) cloud services based on open source code they didn’t develop (e.g. Docker, Spark, Hadoop, Redis, Elasticsearch and others). This discourages the community from investing in developing open source code, because any potential benefit goes to cloud providers rather than the code developer or their sponsor.
Recently I turned off some slow query and slow index advanced logging options, again AWS completely rebuilt the entire ES cluster when these options surely should be able to be applied without copying all data.
https://aphyr.com/posts/317-jepsen-elasticsearch
https://aphyr.com/posts/323-jepsen-elasticsearch-1-5-0
Though, all those issues have been fixed for both MongoDB and Elasticsearch so it's not necessarily fair to judge them based off past performance.
https://www.elastic.co/guide/en/elasticsearch/resiliency/cur...
And as a public company, it is your obligation to not spend more money on tax than you are legally obliged to, unless you’re doing charity.
[citation needed]
…I completely understand all the rage?
MongoDB owns their code - Elastic does not own Lucene.
And distributed SQL of any complexity doesn't really scale. As soon as data that a join depends on is on other machines/nodes, you need quorums and dependent network I/O. Granted with high-speed networks that is getting to be less of a burden speed-wise, but the reliability problems still exist.
If customer acquisition costs are really high, then they're throwing good money after bad.
All of this talk of 'solid financials' while a company is losing money every quarter and whereupon there's no evidence of profit at the unit level ... is scary, it feels like one of those reddit ico pump-it-up chats.
It's all very highly speculative, is what it is. So let's hope it's a great company, with a solid offer and they manage the growth effectively.
You could also say that they are losing money today, and expecting to lose twice as much money next year.
I'm not saying that computing joins, aggegates, sorts, etc can't be done in a distributed fashion, it just takes time, a lot of network reliability/reattempts, and understanding of the approximate nature of results if there are ongoing "eventually consistent" updates rolling through the cluster(s).
Like all financial metrics (PE ratio, etc) it’s still just a crude guide.
From what I can tell, it still does. I can’t comment on the length of time though. I did it before I had many documents and it was a very small Dev instance.
[1] https://aws.amazon.com/about-aws/whats-new/2018/03/amazon-el...
Performance is miles and above better, there’s actual security options on the clusters and there’s way more features.
Elastic Cloud runs in either AWS or GCP. You get to choose but it's just between those. Unless you mean you were using AWS's ElasticSearch service... which is known to not be all that great.
You could build ES clusters on AWS directly on EC2 and it would be cheaper than Cloud, unless what you're really looking for is that support contract.
I spent a few months of my life learning ES inside and out and would choose this option every time. One of the best tech investments I've ever made.
Or you are willing to trade money for dev time. Setting up and running the ES cluster on EC2 will take time and energy (source, I did it ). Whereas setting up the ES cluster on either the Elastic Search hosted service or AWS ElasticSearch is really just clicking some buttons.
However, I'm sure the right solution also depends on the amount of data you are using and the problem you are trying to solve.
The majority of that subscription revenue (they make this clear in other statements in the S-1) is enterprise deals running Elasticsearch & Friends on enterprise datacentres or clouds where Elastic isn’t providing a managed service - they’re providing traditional enterprise software support.
This isn’t unique to Elastic. Splunk, Pivotal, Mongo, MuleSoft, all are similar. Wall Street mostly cares about the revenue model, but there’s a nuance to it.
They also say that the majority of their revenue is from enterprises running their own instances.
Anyway, the point is mostly moot for an investor, but it is interesting as a technical person to observe that many SaaS plays aren’t entirely or even mostly *aaS, they’re open source software sold as enteprise software subscriptions (priced at enterprise or SaaS levels too, not a bargain basement OSS support contract)
It's a big deal for a lot of companies to be able to pay the cloud bill in one place. Elastic used to provide the availability to pay for the Elastic cloud subscription through AWS' Marketplace. Elastic stopped this when they changed their pricing at the beginning of 2017 and we (my last employer) were negotiating a contract with them at the time. AWS billing was a hard requirement for us because it made it a lot easier on us from the finance side. We walked and I know a lot of others who did too.
The point is that AWS removes friction and Elastic chose to add friction. They're chasing big Enterprise hard and it doesn't seem to be working out.
Time is the ultimate non-renewable resource. Throw dollars at the problem when you have them and it’s cheaper than your time.
If you have strictly time-series data and are willing to make compromises around retention window, hosted elasticsearch is an easy conclusion. Invariably though, I find that where performance is a real concern, you have to carefully plan what data you're indexing and that requires operations knowledge around elasticsearch. At that point you almost might as well host it yourself anyway.
Also if X-Pack was something I _had_ to have, and tbh there are free alternatives for all of its good features, I would consider Elastic Cloud.
I'm even a customer of theirs on some clusters, but lackluster support and pushy upselling experiences have made me want to move out of it.
could you list a few?
Can't recommend Sentinl & SearchGuard enough.
Big Enterprise will not require billing through AWS (disclaimer: employed at a large enterprise, buying ~$900k software license currently). They’ll have an accounts payable department, a procurement process, and someone to cut a check or ACH to Elastic monthly/annually.
Would you want to be beholden to AWS' whims? You might as well be a Walmart supplier at that point, constantly dragged out to Bentonville having to make your case for every penny of your costs. Amazon has proven its model (all about scale), how it operates (your margin = our opportunity), and you partner with them at your own peril.
I'm suggesting the thought process to shift from, "Ahhh, those Elastic guys and their bad decisions!" to "Hmm, well, tough decision to make [forgoing revenue through AWS] but I understand why they made it".