By restricting their clients to only talk ES instances, they are shooting themselves in the foot. This gives AWS opensearch clients a great opportunity to enhance their clients SDKS that can support both.
ES should focus on competing be with DDOG/App Dynamics and other incumbents in SIEM space. I dont understand, why would they get into petty fights with AWS.
It's no small feat to maintain compatibility with other product and reverse engineer changes as they happen. Good luck with that.
How many people does AWS have people working on their version of elasticsearch? and on the client libraries in various languages?
From previous discussions on HN, I was under the impression that the answer is very little if any.
My bet is that AWS will keep the service as it is now and never makes patches or upgrades. That's how they operate services usually. And it's not that bad to be fair, the product is good enough as it is.
Based on their current GitHub contributions, I'd say they have quite a few folks. 50+ across opensearch, opensearch dashboards, and the various plugins if I were to guess.
You know we're living in a society! We're supposed to follow SemVer!
Regardless of whatever beef is going on between AWS and Elastic, they could at least have the professional courtesy not to ship breaking changes in a minor release.
Sure, so StarCitizen (the game) used Cryengine at first but Crytek (the company behind Cryengine) was not doing well, and some talents left it. In the meantime Amazon took Cryengine over and renamed it to Lumberyard (now Open 3D Engine). StarCitizen then turned to Lumberyard because..well the because the state of Crytek, and Crytek sued SC, it a bit more complicated why CT sued SC sure, but no one want to work with Crytek nowadays because of that.
I think in long run AWS will just lost their momentum or community support and people will realize AWS won't be able to deliver.
I had used AWS hosted Elasticsearch and it's subpar even at fundamental level. That signal to me they just don't care at all about search and this whole opensearch thing is just they want to be look like a good guy.
If AWS doesn't even care about their own UI/UX of the dashboard or the UX of their API, how can I expect them to do a good job at Elasticsearch? They right now still ride on the high and stay close to ES, but the further into the future, when they drift from ES, expect to have a crappy API from them.
In fact, looking at the Github Opensearch repo for Es and dashboard(Kibana equivalent) they are clearly less active than ES. So how can we expect them to keep the pace in next few year?
Oh they care, there are just some major issues with execution. Amazon, because of their much-panned internal culture, struggles to hire the required developers for many areas. Elasticsearch... is especially bad; because that org is absolutely swamped with operating issues. It's a pressure cooker inside a pressure cooker. There are so many high-priority tickets waking up devs in the middle of the night all the time. Many reports of developers juggling 60+ high severity tickets a week.
Then because of this, few people want to work there because the conditions are extra bad and the current devs leaving.
It's been a mess for a long time. Not for lack of care about the business opportunity, but because management is unable to figure out a healthy way of approaching it.
It sounds like they've done the math leading to cheap out both on headcount and on licensing FOSS. How long until users get annoyed enough to use other clouds?
> A few years ago, AWS basically forked ElasticSearch to offer it as a service, much to the open source community’s dismay. In response, and after some time, Elastic decided to change the licensing on ElasticSearch earlier this year to restrict its downstream use, again, much to the open source community’s dismay
I get annoyed a little when people try to ascribe a feeling to a large group. I don’t think “the open source community” was dismayed about either of these actions.
It may not be open source, but it still offers much of what I think is important. Development is done in the open, very much following the bazaar model. Users of the software are free to read, modify, and release forks/patches of the source code. For the vast, vast majority of users that are not trying to sell elasticsearch as a service the terms of the license may have changed, but in practical terms all the things I care about are still there.
Just look at the the github repo activity between elastic and opensearch. Overwhelmingly, elastic is doing 100x better. AWS doesn't care as much as elastic about these products.
I dont think repo activity is an accurate representation since its been less than a year since Elastic made their license changes and Opensearch was shortly announced in January 2021.
I would disagree here. AWS has to be strong out of the gate to push opensearch as more than just "elasticsearch, but on AWS". Elastic has proven its worth, or this fight wouldn't even be happening. AWS is simultaneously David and Goliath in this fight - they obviously won't have ES' newest, coolest features immediately, but companies will sign up with them instead of Elastic if it means they get good-enough software at a reasonable pace.
Elastic's playbook is almost diametrically opposed to this: they need to prove that they're worth paying a premium for, over AWS' offering. The repo activity clearly shows that they're working on more stuff, building faster, whatever signals you want to glean from that. Change is happening, and if it's good change I can see the gambit AWS is pushing turn into a losing proposition.
The endgame for Elastic is a partnership on AWS, on "equal" terms; license fees, a cut of the profits, the whole shebang. The endgame for AWS is an end to Elastic as a company, but not heavily increased profits one way or another - AWS still gets its cut if Elastic succeeds.
The incentive models aren't equal here, and that's what kills AWS' agenda. I'm not affiliated with either company, so I don't have any inside info, but I have to imagine that Elastic will succeed here in carving out a niche for themselves - unless there's been a silent exodus from the company I understand that these are smart folks building software under, shall we say, extrenuous motivational circumstances. A little stress is good for productivity :)
> Elastic's playbook is almost diametrically opposed to this: they need to prove that they're worth paying a premium for, over AWS' offering. The repo activity clearly shows that they're working on more stuff, building faster, whatever signals you want to glean from that. Change is happening, and if it's good change I can see the gambit AWS is pushing turn into a losing proposition.
As an Elastic customer managing my own cluster, the main issue I have with their approach, and the main reason I'm tempted to switch to OpenSearch, is their all-or-nothing license model.
We only use ES as a place to centralize logs, look them up, maybe whip up a dashboard now and then. No fancy ML or what have you. We don't (yet?) care for those. But we also need access control. There's no such thing in the free version, so we have to pay up quite a hefty sum. We could also get by with 3 data nodes. Tough. Minimum is five. We'd really like it to have some kind of SSO, like pretty much all our other apps. We'd have to pay up even more.
So yeah, we'd be getting all kinds of ML-laden features and whatever. So what? Those bring 0 value to us today.
So my thinking is, what if OpenSearch doesn't have the latest and greatest features? Aside from a few things around snapshot management, I was never really interested in those. Plus the license premium is so huge compared to our usage, we could just be spinning a tad bigger VMs and keep everything on-line.
I wonder how many clients like us they are alienating with, what looks to me, a petty war. But as someone said on some other threads on this subject, Elastic isn't a mom-and-pop company, so our annual license costs are probably pocket change for them.
Theres a long list of features we don't use. We primarily use Grafana for our dashboarding needs.
If I had to make a short list. Data streams, index lifecycle management and security on top of the OSS distribution of ES is all I need to view and manage K8S pod logs.
Worth noting that the developers of searchguard which the Opensearch / Opendistro security plugin is based on is also being sued by Elastic.
Making the client work only with only a specific ES version seems like an oversight[1], but it is really difficult to say given the back and forth between AWS and Elastic here. I hope it is not intentional.
I guess at an extreme Elastic could do some public/private cryptography with the open source client using a public key to verify headers encrypted per request with a private key kept in their cloud service. It sounds ridiculous for an open source project to do that, but it must be completely controlled by Elastic for them to have made the change they already have. So ultimately they probably do need to move to new clients that Elastic don’t control even if they can do that for now.
They’re not going after the same customers. AWS is targeting people who are already using AWS and who want to use an ES type service, but without managing their own servers running the ES software. They want something they can plug into their CloudFormation templates and let AWS do all the low-level admin work.
ES the company is going after people who want all the latest bells and whistles and geegaws, and are willing to build and maintain their own ES clusters to make that happen.
Yes, there’s some overlap in the middle, but not much.
And no matter how bad the ES service is on AWS, it will always have a large customer base who will choose it, simply because it’s good enough, as well as easier and lower administrative overhead.
The OpenSearch thing is new. So far as I know, they didn’t create their own forks of MySQL or Postgres and then try to build communities around that. But that is what they’re doing with OpenSearch. IMO, that’s a mistake. They’re better off working with the ES community and contributing changes back to an existing community, as opposed to trying to build and maintain their own separate but equal community.
Sometimes forks are a good idea. Sometimes not. Sometimes those forks live on, and sometimes not. This is a case where I think the fork is a bad idea, I believe it is likely to not live on, and I think a lot of harm will be done on both sides of that war, above and beyond whatever else might have happened if they had just chosen to support the existing ES community.
Amazom were contributing changes back to Elasticsearch before the license change - the license change basically explicitly says "you can't run this as a service and sell it to people".
With this in mind what could Amazon do? Their options were:
A. Stop selling their Elasticsearch service, or
B. Fork Elasticsearch.
This change from Elastic is really shitty though, and sort of proves that all their finger pointing at Amazon saying that they're acting against the spirit of open source was all bullshit.
> Amazom were contributing changes back to Elasticsearch before the license change
Not very many by my count; something like 2 patches/month on average. I mean, of course this is great, but there are several ES-based companies that contributed more, and about >95% of ES was written by Elastic.
It's based on looking at the ElasticSearch commit log; some details in [1].
Lucene is not included in this; as far as I can tell it's just imported as a dependency. I mean, obviously Lucene is an important part, but by this standard something like "Jane Doe wrote about half of Docker" would also be "wrong" because we'd have to count the people who worked on cgroups and all the other Linux stuff Docker uses, all the Go dependencies, etc. Realistically, almost everything we do is based on various things other people did. "To make an apple pie from scratch we must first invent the universe."
Maybe that would be fairer/better to also count Lucene, but that's a different discussion and wasn't really my point, which was that almost all code in the ElasticSearch GitHub repo comes from Elastic employees, that Amazon never contributed all that much code, and that based on this plus the severely reduced levels of activity of OpenSearch vs. Elastic don't really paint the most rosy long-term prospect for OpenSearch vs. ElasticSearch.
There is no more committing to the ES community for AWS. I agree a single project would have been great but lets just be clear the necessity for the fork was entirely on Elastic Co.
> The OpenSearch thing is new. So far as I know, they didn’t create their own forks of MySQL or Postgres and then try to build communities around that. But that is what they’re doing with OpenSearch. IMO, that’s a mistake. They’re better off working with the ES community and contributing changes back to an existing community, as opposed to trying to build and maintain their own separate but equal community.
MySQL and Postgres are still open source. ElasticSearch is not.
Looking to upgrade a cluster running 7.5 - should I go open search or elastic? Who will be the better maintainer? Reminds me of Mariadb and MySQL… either path was a fine choice IMO but hard to say in this case…
Elastic.co one thousand percent. I just finished a migration from AWS managed ES to Elastic.co. You literally only need to use both for a couple of hours to notice that AWS treats ES as an afterthought. I could name many things such as better security, interface and cold/warm storage configuration.
Then you have no reason not to go with elastic unless you host on aws. From the drama described in the article it sounds like elastic will try to keep clients working only on its own fork while amazon will play catch up.
It's a matter of interpretation really and more of the perspective of the reasons you require something to have its source code available. For example if you just need to be able to scrutinize the code for security purposes then it's good enough.
That's what "source available" means. Open Source is a much stricter definition, which includes not discriminating what your user is going to do with the software.
> 6. No Discrimination Against Fields of Endeavor
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
For a lot of developers, there is no practical difference because they are not building a managed service around Elasticsearch (like Amazon is). They are using it for their own private, commercial purposes, whatever it may be.
Stick with elasticsearch of course, it's "the real thing", made by the people who have been working on the product for over 11 years.
That's what I do.
I wouldn't touch things related to Amazon with a 10 feet pole.
ES should focus on competing be with DDOG/App Dynamics and other incumbents in SIEM space. I dont understand, why would they get into petty fights with AWS.