Elastic Cloud on Kubernetes 1.0 | Hacker News Reader

Elastic Cloud on Kubernetes 1.0

elastic.co

78 pointsablekh10 comments

Open Source vs. Basic could not be more confusing. This seems to be a Basic licensed product, which I guess means hosting companies can’t host ECK on behalf of anybody?

Correct, if you want their oss builds, they have docker containers with -oss in their name as wells tar.gz, rpm, deb, and other builds with similar naming conventions. You can also build these from source yourself of course.

If you know what you are doing, the OSS builds are completely fine for production usage and many companies that use their products should have all their needs covered by the OSS builds.

All this is documented and easy to figure out. There's nothing confusing, sneaky, or otherwise misleading about it. There's a tiny file called LICENSE.txt in their repository. I'd suggest reading it. Also their documentation helpfully labels features that are xpack only. Every source file states what license it is under.

Their cloud stuff is nice if you want to replicate their cloud offerings on premise and not pay them or reinvent a lot of wheels. But if you are going to compete with them, you are indeed going to have a conflict with the license terms.

If you are considering Amazon's open distro. It's fine but the added value over the -oss containers is very limited and grossly overstated by Amazon. And their track record supporting this in the field is pretty bad/non existent. You're on your own.

Also secure by default is a myth; I just joined a project that runs an AWS Elasticsearch setup a few weeks ago completely unprotected. When I say unsecured, I mean open port with full read write for both the cluster and kibana. No meaningful security whatsoever. Nothing. On an official AWS product running in their infrastructure.

And yes, we're fixing that (by ditching AWS Elasticsearch for something sane). The one thing they called out Elastic on is exactly what they ended up doing themselves: running completely unprotected Elasticsearch clusters in AWS. I'm shocked this is even allowed on their infrastructure. I'm even more shocked about the complete lack of warnings related to this after all the BS they gave Elastic last year when they launched opendistro.

AWS service quality is all over the place. New services tend to be much lower quality than older services. We had to investigate performance issues with some of these and we are not happy about the SDK code and the defaults and many more. It seems AWS does not have a single quality control process for offerings. AWS Elasticsearch is a good example of this.

AWS Elasticsearch is closed by default. You have to upload access policy first in order to access it. That port was open during configuration. You can use aws iam, cognito and sg in order to control access to ES instance.

If you click things together yes. However, most of the real world uses infrastructure as code type approaches involving things like terraform, cloudformation, etc. They give you plenty of ways to mess that up. Running unsecured should not be an option period. It's for sure not an option on elastic cloud.

I don't really like AWS ElasticSearch offering (it's subpar at the very least and I'm being kind) but what you are saying is completely unfair. If I'm using IaC then I'm a power-user and I want to be able to open an ES cluster to the Internet if that makes sense to me. What should be protected by default is the point-and-click wizard configuration (which it is, indeed).

Has 'day 2 operations' been a phrase for some time?

Yeah, maybe for five years.

It got popularized a couple years ago to distinguish the few companies that had Kubernetes products added value beyond installation.

Isn't day 2 stagnation and death?

Reply on news.ycombinator.com