I was nodding along until this:

> and THEN we think about how do we make money from it

Do you really need to think? Looking at the on-demand pricing in US East, a m5.4xlarge.elasticsearch instance costs $1.133 an hour, while a m5.4xlarge instance costs $0.768 an hour. That's 47.53% of extra money. And like you said, it only requires a small team to build and maintain the service.

It is no coincidence that all cloud providers are trying to ramp up their hosted services for open source software, even GCP, who historically only focused on their own proprietary stack. There's a lot of money to be made.

What people often forget is that cross-AZ traffic is included in those .elasticsearch instance prices. In a 3-AZ deployment and given the frequent rebalancing/replication traffic that is a significant line item if you run it yourself. I'm not arguing it's not expensive, but when you look at the TCO it's less obscene than if you just look at EC2 pricing alone.

That's a very good point, I wasn't aware of that.

Do you really think that all it takes to operate an elasticsearch instance is to white-label an equivalent ec2 instance and execute some shell scripts on it?

If that were true, people wouldn't pay for it...

Of course not, don't be ridiculous. My point is that whatever man-power and resources required to run the elasticsearch service can be considered as fixed cost, while the same 47.53% profit margin can continue to "scale" indefinitely, regardless of whether you have 10 customers or 10,000 customers. That's the beauty of it.

As we can see elsewhere in the comments, your biggest competitor appears to be the various kubernetes operators. With kubernetes as the common stack across multiple cloud providers as well as on-prem datacenters, the 10,000 customers can now contribute to the same operator project, to possibly get somewhere close to, or even exceed, what AWS can do with a small team of engineers.

Perhaps anticipating this trend, GKE now has an "autopilot" mode, such that a 30% profit margin is already included in the node pricing. That's one hell of a moneymaker.

In the world of OSS, code speaks. A small team may not help the cause of Open Search. This article nails how code influences leadership in an OSS project: http://hypercritical.co/2013/04/12/code-hard-or-go-home

they have as many people dedicated to the capability as needed. at least the capabilities have owners, which from my experience is not trivial for an organization to achieve.

curious if others have noticed this as well (capabilities without clear owners)? what does this depend on? time? company size? both?

Could you please shed some light on how many people would be behind a product like AWS Lambda or AWS CloudWatch?

As an outsider, I would guess huge swaths of developers with a massive hierarchy. Buildings full of folks working on AWS services. I have no idea and extremely curious.

AWS Lambda team 3 years ago on Reddit: https://www.reddit.com/r/aws/comments/7a5anz/we_are_the_aws_...

at least 12 people. Of course they are in turn supported by many different teams, which also consist of who knows how many people.

Usually services like this start with one 2-pizza team.

Then, as the scale increases, and the number of features increase, so do the number of teams.

Lambda and CloudWatch are both a couple hundred people which wouldn't be surprising once you consider all the things that they do.

But I would venture a good half of all AWS services are built and run by one team of 10-12.

Hundreds. Each team owns a different part of the service.

Interesting. I wonder if the market can only support managed services when it’s provided directly by the cloud provider like AWS. I assume Elastic has to add margins to cover for their existence, which make them less competitive with AWS.

This sounds a little unfair, even if I agree with the argument that they’re free to fork OSS software and do whatever the fuck they want.