OpenSearch: AWS fork of Elasticsearch and Kibana
101–110 of 438 posts
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#102Earlier quoted context omitted.
Uhmmm I’m pretty sure David vs Goliath is talking about scale between competition. Saying that $11B is Goliath just because you’re sitting at $1M doesn’t mean they’re not in a crazy mismatched fight against a $2T company. In the same way you could be in a David vs Goliath situation yourself if you with $1M in wealth tried to sue someone with $25K of wealth. Everything is relative. Doesn’t mean it’s not a crazy unfair…
When there are two large entities (and I take this to mean way larger than you or your company) then you’re better off rooting for the one that at least releases code you can use. If OpenSearch is truely open then in theory you can find another provider. But for ElasticSearch you’re stuck with them.
I am a bit at a loss about that statement, you can run Elasticsearch on your on infrastructure
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#103Earlier quoted context omitted.
> If you're "cloud-agnostic" and could migrate away from AWS in the blink of an eye then you're paying for an overpriced VM offering and should probably migrate to a cheaper hosting provider immediately. No this is what everyone suggesting this does not get. The offerings are not equivalent. There are a baseline of services that the cloud providers offer that can be made functionally-equivalent. It's not just EC2 but…
> all of these available within the same VPC (talking to each other without paying bandwidth costs). That's one of the real key issues, I think. If bandwidth is 10x cheaper, then maybe you decide it's fine if only half your inter-server bandwidth is free.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#104If Amazon fixed that, I would be firmly on their side. Also, any improvement over Kibana would be welcome.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#105I have mixed feelings about this server side license stuff that mongo db started. Imagine where the internet would be today if the creators of apache and mysql had tried to prevent shared hosting providers in the early days of the web from using their software
The time when Apache or MySQL started out was very different. Imagine where the internet would be if cloud computing itself didn't take off. Do you remember a time when there were hundreds of hosting providers? Do you remember WebHostingTalk where admins would go to check hosting offers from suppliers around the world? The monopolies finished that era. So I don't think that software companies trying to adapt now can…
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#106Earlier quoted context omitted.
I mean if they were truely best of breed they wouldn’t have needed a license change now would they?
Indeed, although I'd say for a majority of situations, Amazon's hosted Elasticsearch service is a complete non-starter.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#107Imagine if they went after Mongo next? Atlas is a virtual monopoly for Mongo solely due to SSPL, and it has created a ridiculously overpriced ecosystem for hosted and managed services, and tooling around it. Parking the technical merits to one side, considering the sheer number of devs and early-stage products that are built on Mongo, I'd love for someone to go after them next.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#108Imagine if they went after Mongo next? Atlas is a virtual monopoly for Mongo solely due to SSPL, and it has created a ridiculously overpriced ecosystem for hosted and managed services, and tooling around it. Parking the technical merits to one side, considering the sheer number of devs and early-stage products that are built on Mongo, I'd love for someone to go after them next.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#109It's hard for me to know whether to feel bad for ES in this case. Did they bring it on themselves? Is Amazon too big and a bully? From my perspective, Amazon has made most of its profit price gouging consumers on bandwidth after vendor locking them into their ecosystem, where they bootstrap new services by wrapping open source software with some provisioning scripts, management dashboards and cookie-cutter API / cons…
I think the claim that Amazon is winning through "vendor lock-in" is pretty silly. Honestly anyone who can't quickly migrate the stuff they're hosting on AWS onto one of the many other cloud platforms is pretty bad at DevOps. If you're using K8S/Docker/etc it should be trivial . But even if you're not, the vast majority of AWS offerings were either built to be API-compatible with other existing tools (e.g. postgres-c…
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#110It's hard for me to know whether to feel bad for ES in this case. Did they bring it on themselves? Is Amazon too big and a bully? From my perspective, Amazon has made most of its profit price gouging consumers on bandwidth after vendor locking them into their ecosystem, where they bootstrap new services by wrapping open source software with some provisioning scripts, management dashboards and cookie-cutter API / cons…
We already know Amazon isn't interested in doing that (either at all, or at whatever price ES wanted, we don't know that).
They had no legal requirement to when ES was open source. So ES changed the licensing to no longer be open source.
So, Amazon could... a) decide to give ES a cut after all, b) decide to stop hosting ES, or c) fork the last open source version.
I don't think anyone is surprised they chose c? Presumably ES isn't either? Maybe ES thinks this will be good for them/bad for Amazon anyway, because they are hoping potential customers will abandon the Amazon fork and stay on the original ES fork?
Not sure why they'd be confident in that exactly. Maybe they know what they're doing.
As users/customers, we would rather have a choice of hosted vendors/platforms, and that it remain un-forked (so we can use/write software compatible with either vendor/platform). Competition is good for us as users/customers, that's in fact one of the reasons we choose open source, so no one vendor can set the hosting price all on their own without competition. We want to be able to choose among competitors for hosting, based on price, customer service, performance, uptime, whatever.
But ES didn't want that, they didn't want hosting competition to exist -- at least not without permission and agreed upon cut for them -- because, I guess, hosting was how they planned to make money as a company to fund development as well as profits for investors etc. So they changed their license to no longer allow it. So of the possible outcomes remaining... this one seems as good as any for the user/customer, I guess?
So, when you say "I'm doing my part by not building anything with vendor lock-in" -- I'm not sure which course you are suggesting. In fact, between ElasticSearch and new OpenSearch fork.. it's OpenSearch that is the one without vendor lock-in, right? OpenSearch is Apache licensed, and can be hosted by any vendor and still forked by anyone . It's ElasticSearch that has a license limiting what vendors can host it (without permission of ES), it's the one with vendor lock-in, right? So not building anything with vendor lock-in means... ?