I'm glad they changed the name. Although it's probably too much to ask that the AWS service be renamed to OpenSearch Service as well.
OpenSearch: AWS fork of Elasticsearch and Kibana
111–120 of 438 posts
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#112So as someone who has heard about Elasticsearch for years and years, and seen all this, right this moment I've decided to see what it really is. On their home page, "Why use Elastic search?", the reasons are basically: * It's fast! * It does a lot of stuff! * It has some tools to visualize data! * It's distributed!! I have to say this is not very appealing to me since it sounds like something any database could do.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#113> 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.
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 also allow re-licensing under a different license which is more clear cut and I think that's more the issue here
Amazon is trying to say that they'll never relicense the code, so they have no need to take ownership over contributions.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#114Earlier 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…
I buy the main reason being the all-in-one solution; the comprehensiveness is attractive. However, I think you're underplaying the lock-in: migrating clouds is non-trivial - mostly due to stuff that's not running in k8s/docker/etc; stateful apps (Postgres, etc), and or just static data like s3. This takes time, and careful planning and sometimes downtime - and is mostly avoided due to it being hard.
You're conflating the difficulty of migrating a complex system to anywhere with "vendor lock-in". It would be harder to migrate an Aurora RDS Postgresql instance to an Aurora RDS MySQL instance than it would be to migrate from Aurora RDS (postgres) to a hosted postgres anywhere else.
That to me screams "not vendor lock-in".
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#115It'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…
With that in mind, their behavior here makes a lot more sense, and comparing it with companies who have dramatically different products, like Facebook and Google, takes a lot of effort to understand the differences and what impact they have.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#116Naive aside, but why would I want to use ElasticSearch or OpenSearch over Solr? Are ES and Solr not both based on Lucene?
Other benefit is that you don't have to rely on Zookeeper if you're horizontally scaling.
I don't have a ton of experience with Solr but they seem pretty comparable.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#117Earlier 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…
The lock in is real, but they are also the best cloud option and its not even close in my opinion.
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#118It'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…
Elasticsearch was first released over a decade ago. ElasticSearch, now just Elastic, the company was founded over 9 years ago and now is public. Are they still a "small startup"? If so when does a company graduate from that status?
Re: OpenSearch: AWS fork of Elasticsearch and Kibana
#119Earlier quoted context omitted.
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.
> 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
#120Earlier quoted context omitted.
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.
> 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
> If OpenSearch is truely open then in theory you can find another provider
Those are the key words. With an open source solution someone else can offer a turn-key solution that benefits from economies of scale.