Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSearch: AWS fork of Elasticsearch and Kibana

aws.amazon.com

Post reply on HN
Print view View original

121–130 of 438 posts

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#121

Post by fastball »

StreamBright wrote: post #109
fastball wrote: post #12

Earlier quoted context omitted.

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…

Do you know can I migrate my sophisticated security setup easily over? Including users, groups, roles, policies and instance policies.

Everything on AWS is accessible via API, which means you can easily automate the migration process. So do that?

Obviously the more complex a system is the harder it will be to migrate, but that has nothing to do with Amazon trying to "lock you in" and everything to do with it just being a complex system that there is no industry standard solution for.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#122

Post by stefan_ »

minhazm wrote: post #13
TechBro8615 wrote: post #9

It'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…

Is it really price gouging for bandwidth? Or is bandwidth just really expensive in general? I honestly don't know. I would assume if it was actually much cheaper one of the cloud's would undercut the other to get customers.

Keep in mind bandwidth gets cheaper as AWS gets bigger. If you are some random tiny colo provider, people don't necessarily care to peer with you unless you pay them for the privilege. If you are originating 20% of internet traffic, now people need to peer with you or their customers won't have a great experience.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#123

Post by zo1 »

retzkek wrote: post #64
phd514 wrote: post #4

From the announcement: "You should consider the initial code to be at an alpha stage — it is not complete, not thoroughly tested, and not suitable for production use. We are planning to release a beta in the next few weeks, and expect it to stabilize and be ready for production by early summer (mid-2021)." Given that Amazon announced the fork in January and they don't expect it to be production-ready until summer, I'…

> they've underestimated the amount of work required to package and distribute a product as complex as Elasticsearch The bulk of the work thus far has been to strip out the non-OSS components ("X-pack") and the many references to it, nothing to do with packaging, distributing, or even maintaining and developing features. https://discuss.opendistrocommunity.dev/t/preparing-opensear...

I for one will be happy when those are taken out. So many headaches trying to get bloated Kibana to start as a docker container before realizing that some random x-pack-disable flag needs to be set for it to start without a random error.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#124

Post by binarymax »

sdesol wrote: post #78

Will be interesting to see the resources that AWS will throw at this. You can get a sense of the resource that elastic.co is throwing at elasticsearch at https://public-001.gitsense.com/insights/github/repos?r=gith... I'm currently indexing the fork, so in about an hour or two, I'll provide the insights for the fork as well.

Elastic spends so much time and effort on making sure that their search is performant (and they are not shy about deprecating and removing features that are slow). I think this is where Elastic will continue to shine. It's one thing to add features, it's another to make it so they work well and make sure the integrating product team doesn't shoot themselves in the foot.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#125

Post by VWWHFSfQ »

catern wrote: post #99
VWWHFSfQ wrote: post #31

I 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 server side license stuff doesn't prevent shared hosting providers from using software. It just requires hosting providers to open source their infrastructure. I think the internet would be even better today, if shared hosting providers had been sharing infrastructure technology since 25 years ago.

I think that's missing the forest for the trees. The license is designed to prevent hosting providers from selling the software as a service to their customers. The requirement to open source their entire infrastructure and operations is just a means to do that.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#127

Post by mikepurvis »

virgilp wrote: post #119
kfir wrote: post #102

Earlier quoted context omitted.

> 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

That is not entirely true, of course. Not if you don’t want to pay. As proof - just look at Amazon, they can’t (that’s why they forked it).

I don't think it's the freedom to run it anywhere. It's the freedom to run it anywhere and make changes to it that you don't contribute back:

1. Amazon wants to make private changes to the management layer for their cloud offering and not share those.

2. ES doesn't want that, so the 7.11+ license restricts it.

3. Amazon doesn't want to have to explain to their customers why their ES offering is stuck on v7.10, so they're changing the name of it.

4. Elastic was really hoping this wouldn't happen, but they overestimated the value of their brand and Amazon called their bluff.

So yeah, nominally OpenSearch is unrestricted, but realistically few other entities are in a position to make or benefit from the private modifications Amazon will be making. For us normal people, ES and OS are equivalent today, so it's more about how they're going to diverge over time in terms of fixes, features, whatever.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#128

Post by Boulth6 »

resoluteteeth wrote: post #113
parhamn wrote: post #76

> and we don’t ask for a contributor license agreement (CLA) Makes me wonder what these are for (copyright transfer) and why they decided it’s not needed. It also makes me wonder if this sort of thing has ever been taken/tested in court or if it’s paranoid friction with little value add.

> Makes me wonder what these are for (copyright transfer) and why they decided it’s not needed. It also makes me wonder if this sort of thing has ever been taken/tested in court or if it’s paranoid friction with little value add. Some companies/projects might use them purely to avoid possible future legal headaches (I think GNU does this), and I'm not sure to what degree that has actually been tested, but they can al…

Indeed that is likely but I wonder why didn't they at least require a Developer's Cerificate of Origin [0] that kernel.org uses. This is really lightweight (just append one line to git commit message) and supposedly provides a minimum legal base for the change. IANAL.

[0]: https://blog.chef.io/introducing-developer-certificate-of-or...

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#129

Post by Graphguy »

bgorman wrote: post #108
shankspeaks wrote: post #96

Imagine 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.

This already exists https://aws.amazon.com/documentdb/

Kinda blocked on the compatibility front after the 4.0 API though, eh?
Post reply on HN