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

381–390 of 438 posts

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#381

Post by hit8run »

fastball wrote: post #356
hit8run wrote: post #271

Perfect case for a megacorp destroying open source plus business models. I start to hate amazon with a passion. Craziest thing is they are not paying taxes in Europe though they dominate the market. Amazon needs be broken up. It's too big and too mighty.

Isn't this an example of an open source business model. Amazon is supporting development of this Apache 2.0 licensed OSS, which they plan to make money off of...

Indeed. But they are not the company supposed to make money of that project. They start to dominate several markets by cross financing and therefore need to be broken up.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#382

Post by codabool »

busterarm wrote: post #263
bmcahren wrote: post #143

I feel Amazon took the feedback from the DocumentDB/MongoDB fiasco to heart and made positive change in their approach. DocumentDB is a closed source proprietary database created by Amazon to emulate the MongoDB API. Think Google's Dalvik runtime vs Sun/Oracle's JVM. This time around we have an open source fork of ES with big backers all contributing and very permissive licensing. In both cases, Amazon gets to implem…

On the other hand, MongoDB is already sort of obsolete and trending towards death by the time that all ended up happening while ElasticSearch is hot and "new".

https://db-engines.com/en/ranking

I like to check this site every couple months for stats on DB popularity

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#383

Post by amzn-throw »

systemvoltage wrote: post #281
amzn-throw wrote: post #179

Earlier quoted context omitted.

> they can invest more resources into developing it than the original team ever could. I know this is a popular narrative, but as someone who works on AWS, I think you would be shocked by how small the individual dev teams are that build and maintain the services that everyone uses. I'm not going to downplay the network effects involved. Of course AWS has a tremendous advantage in being able to standardize the custom…

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.

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.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#384

Post by amzn-throw »

throwdbaaway wrote: post #330
amzn-throw wrote: post #179

Earlier quoted context omitted.

> they can invest more resources into developing it than the original team ever could. I know this is a popular narrative, but as someone who works on AWS, I think you would be shocked by how small the individual dev teams are that build and maintain the services that everyone uses. I'm not going to downplay the network effects involved. Of course AWS has a tremendous advantage in being able to standardize the custom…

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 p…

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

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#385

Post by tannhaeuser »

Just want to mention that "OpenSearch" is/was also an AWS^H^H^HAmazon initiative for websites to expose a search URL to browsers in HTML metadata, similar to exposing an RSS feed URL. They may want to consider renaming it to avoid complete and utter confusion, like searching "OpenSearch" (no the other one) using "OpenSearch" (no the ES fork).

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#386

Post by pjmlp »

reducesuffering wrote: post #290
galaxyLogic wrote: post #242

Earlier quoted context omitted.

I would add Kotlin to Google's credit. But I think it's important to note that these companies don't contribute to open source out of any moral obligation, do they? I think they do it to tie more developers and development around their eco-systems and products. Maybe Amazon should get smart and start doing something similar. Or maybe they don't need that. But in any case I don't hold it morally against them that they…

No I would not add Kotlin to Google's credit. All the initial work and exponential adoption started with JetBrains. Google only greenlit it as an official Android dev language eventually (barring whatever OSS work they're doing on it only now).

Google is surely pumping lots of money into Kotlin, had it not been for them, and Kotlin would just be yet another runner up in the long list of JVM guest languages.

It is also due to Android Studio performance issues that Kotlin compiler improvements came to be, and also the compiler plugins for stuff like kapt and Jetpack Composer.

Android Java might be stagnant, not kept up to date with standard Java, yet it still rules in Studio tooling performance.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#387

Post by jillesvangurp »

shawnz wrote: post #313
sdesol wrote: post #303

Earlier quoted context omitted.

A lot of the projects looks like they were created to make it easier for Amazon to manage elasticsearch on their infrastructure and/or to overcome license limitations for features that already exists in Elasticsearch. Are there specific repositories that you know of that would contain functionality that Elasticsearch does not have, that would be a strong differentiating factor? I'd be curious to index these projects…

Most of the modules replace modules which Elastic provides, but not in the free distribution. For example, alerting, SAML auth/SSO, field and document filtering by user/role, etc. However note that the most substantial module, the authentication module, is actually a fork of another product called Search Guard. The differentiating factor in my case is simply the price. I think Elastic's X-pack modules actually provid…

Most of x pack does not cost anything.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#388

Post by imhoguy »

codabool wrote: post #382
busterarm wrote: post #263

Earlier quoted context omitted.

On the other hand, MongoDB is already sort of obsolete and trending towards death by the time that all ended up happening while ElasticSearch is hot and "new".

https://db-engines.com/en/ranking I like to check this site every couple months for stats on DB popularity

Ugh, no MS Excel /s

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#389

Post by berkes »

est wrote: post #378

Off topic, is there a lightweight alternative to ES? Preferably can be run in small RAM vps.

Have a look at Meilisearch.

I love it for its simplicity. No schema's, no clusters, no transformations, no calculations.

Just documents and search over HTTP.

Re: OpenSearch: AWS fork of Elasticsearch and Kibana

#390

Post by StreamBright »

hintymad wrote: post #94
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…

It sounds trivial to "wrap open source software", but surprisingly it is big value-add to thousands of companies. We can't just look at successful companies like Netflix to downplay the challenges of operating a service. Not every company knows how to operate complex systems under manageable cost. How many companies can really manage a Kafka cluster, let alone scaling it, for instance? Indeed, even companies that peo…

90% of the companies do not know how to manage software. They got weird dogmas, no KPIs, no ability to measure performance or debug problems. This is why they got external consultants and cloud vendors. What is really funny how they think internally about these issues. If Netflix and Amazon was publishing efficiency numbers and we were able to compare with the bottom 95% of tech users people would be shocked. The difference between the numbers I am aware of (number of computers / engineer for example) is 100x.
Post reply on HN