As the author mentions AWS Elasticsearch does lag behind in versions. They still only support 1.5.2[1] which is over a year old at this point and is missing a lot of performance optimizations and operational improvements.
Elastic (the company behind Elasticsearch) provides an AWS based SaaS Elasticsearch product https://www.elastic.co/cloud/as-a-service with a very sane version policy[2] that keeps pace with the latest Elasticsearch releases.
We've looked into using Elastic hosted Elasticsearch ourselves but what really put us off is that even if your whole cluster fails the only support method you get is a forum. You have to purchase a support package for the whole of Elasticsearch at some unspecified price just to get proper support for the hosted service itself. We don't want support for using Elasticsearch just for the hosted service we're paying for.
the "unspecified" price is a lot. I think they reworked their pricing structure sometime around ElastiCon this year, but prior to that a subscription (which includes support, and all their products; only way they sold stuff then) was ~$5k /server/year.
Our company had a horrible experience with Elastic Cloud:
1. We were provisioned hardware that was less performant than promised (HDD rather than SSD-backed.)
2. The dashboard suggests significantly lower memory utilization than reality. We spent days going down the wrong rabbit holes, when we were getting timeouts simply related to out of memory errors.
3. When there's a shard failure, your only option is to reach out to support. You can't upgrade the database or anything.
We switched to Bonsai and it's been much more stable.
One of the main issues i had with it was that getting the IAM policies correct on the cluster was an extremely slow process. Each change requires a rolling cluster update, replacing the underlying EC2 instances with the correct roles.
Secondly access control sucks. You can only whitelist by external IP, and you cant access elasticsearch from your VPCs directly, as they sit outside your VPC.
I abandoned it, wrote some chef and terraform and had a much more stable and flexible setup. However at an increased management overhead.
If it works for you thats cool, but there are caveats, so beware.
We ran into the access control limitations as well. They are caused by the fact that for some reason AWS ES only supports resource based policies which is imho the wrong way around to manage your policies.
We did get it to work in a useable manner by having the ES policy apply to a role (i.e. the principal is a role).
If you than apply that role to your instances it will work for with instance profile based auth.
Thats exactly what i was doing with the elasticsearch plugin for logstash, but i still couldent figure out how to auth vanilla http requests to it from kibana or the like... Then i decided id wasted way too much time on this, and would just build it myself. Other services such as bonzai support basic auth which i would have almost preferred :/
Another annoying point: the documentation only lists the api methods you can call, but not the ones you cannot. I was a bit irritated to find out that the /_update method is not supported on AWS ESS
I hear 2.3 support is coming in the next few weeks.
Being stuck on an old version is painful but if your needs are simple then it's very useful. Ultimately if your needs are not simple then you probably should be running it yourself, just like anything else. Managed hosting for any database is never going to be as customizeable as you need if you operate at a huge scale.
This intel is like gold, where'd you hear it from?
The lack of transparency is my least favorite thing about AWS. I see the value in keeping brand new services or huge feature additions secret until they're released. But for small issues like when they'll update elasticsearch version or when they'll fix an acknowledged bug, I don't get why they can't share that information with customers (e.g. the way many open source projects track next version milestones on github).
Is it any different at the Enterprise support level?
It's a crappy service. When the cluster autoscales to deal with load the cluster becomes unavailable for a minute or two while it restarts. In my previous role we had a very large cloud search cluster that was always under high load and very frequently threw 500s when the environment scaled up.
Have you ever managed your own non-trivial Elasticsearch cluster personally? Elasticsearch is filled with so many subtle gotchas that aren't present in other non-distributed databases.
I personally feel once you've managed your own ES cluster for awhile, you tell yourself there's no freaking way any cloud system can abstract all these ugly (but important) configuration settings and corner cases into a neat, nice cloud product. No freaking way. I'm gonna manage this myself.
The main issue of this service is just that it is very outdated (it only supports ES 1.5.2) when the latest is 2.3.3 and ES 5 is just around the corner.
The recent versions are far more stable and includes lots of efficiency in terms of memory usage.
Forget enterprise time, it's about to be two major versions old in major version time, once v5 is official. Not sure what happened to v3 and v4, I think Elastic skipped them to get all of their products aligned to the same version.
Elastic says they don't backport fixes either, so in this case, it might be a good idea to stay near the leading edge of the release cycle.
True. As much as a service entices us, old version and having no timeframe of when we can expect an update to a newer version made us keep our self-managed cluster on EC2.
Elasticsearch is one of the easiest clustered databases to administrate, and it's a lot cheaper to just run your own EC2 instances with ES than it is to use the managed ES service.
A roll-your own deployment is basically "install Elasticsearch, install cloud-aws, configure cloud-aws with a security group ID to identify other machines in the cluster, add that security group to all machines you want to cluster together, start the service". Totally braindead-easy.
> Elasticsearch is one of the easiest clustered databases to administrate
You seem to have installation confused with administration.
Off the top of my head you forgot security, monitoring, logging config, backups, handling common production issues such as splitbrains, write multiplication, garbage collection snafus, upgrades between versions with questionably compatible internal apis.
Running any database in the cloud is non-trivial, and, running elasticsearch effectively in the cloud is harder than running Zookeeper or Cassandra, for example.
Source: I founded and sold an ElasticSearch hosting company.
Much of that isn't specific to Elasticsearch; security, backups, logging config, etc is all going to be extremely common across just about every similar product. I didn't say that Elasticsearch was "trivial", I said that it's one of the easiest clustered DBs to administrate. Anything distributed has a whole set of caveats that you have to be aware of and know how to handle, but using managed ES vs hosting your own doesn't really change any of that.
My point is that the value-add from AWS' managed ES product is much, much smaller than it might be for other similar products because of the relative ease of administrating ES.
I do among other things elasticsearch consulting and a significant part of the urgent jobs I do is fixing braindead-easy ES setups. It's easy to install and configure, it will probably even run fine with a small dataset or few queries, but it will start to fall apart if you're putting load on it and haven't thought at least a little about your setup. That's not a surprising thing in itself, practically no piece of software will just eat any garbage you throw at it, so ES is at least on par with a lot of other options out there. It's often just a small thing, tweaking shard counts and index sizes, using the appropriate instance type, something like that. But it's still easy to get wrong and a lot of people do.
The part you forget with this is the people cost. A company moving to an AWS (or other cloud provider solution) may be able to drop a human from their staff. This is worth a lot more than saving a few dollars rolling your own ES. Also when you roll your own you usually maintain, if not increase staff count. Cloud providers afford businesses the ability to look at decreasing staffing while increasing capacity.
In terms of AWS costs, running your own cluster will cost significantly less, specially if you use reserved instances. The AWS ES instances cost ~1.6x more than their regular counterparts. Also, you can't reserve ES instances.
Amazon's typical approach for AWS products is to MVP them, and iterate functionality.
This often means that early services work very well for a handful of use cases. If your case deviates slightly in requirements, you will be better off in the short term running it yourself--assuming you can't change requirements.
In my experience, the AWS teams are very responsive to feedback and work pretty hard to add functionality to their mvp services.
Readit News
Elastic (the company behind Elasticsearch) provides an AWS based SaaS Elasticsearch product https://www.elastic.co/cloud/as-a-service with a very sane version policy[2] that keeps pace with the latest Elasticsearch releases.
Disclaimer, I work for Elastic
1. https://aws.amazon.com/elasticsearch-service/faqs/
2. https://www.elastic.co/guide/en/cloud/current/version-policy...
I think it may be cheaper now though.
1. We were provisioned hardware that was less performant than promised (HDD rather than SSD-backed.)
2. The dashboard suggests significantly lower memory utilization than reality. We spent days going down the wrong rabbit holes, when we were getting timeouts simply related to out of memory errors.
3. When there's a shard failure, your only option is to reach out to support. You can't upgrade the database or anything.
We switched to Bonsai and it's been much more stable.
Secondly access control sucks. You can only whitelist by external IP, and you cant access elasticsearch from your VPCs directly, as they sit outside your VPC.
I abandoned it, wrote some chef and terraform and had a much more stable and flexible setup. However at an increased management overhead. If it works for you thats cool, but there are caveats, so beware.
We did get it to work in a useable manner by having the ES policy apply to a role (i.e. the principal is a role). If you than apply that role to your instances it will work for with instance profile based auth.
Being stuck on an old version is painful but if your needs are simple then it's very useful. Ultimately if your needs are not simple then you probably should be running it yourself, just like anything else. Managed hosting for any database is never going to be as customizeable as you need if you operate at a huge scale.
The lack of transparency is my least favorite thing about AWS. I see the value in keeping brand new services or huge feature additions secret until they're released. But for small issues like when they'll update elasticsearch version or when they'll fix an acknowledged bug, I don't get why they can't share that information with customers (e.g. the way many open source projects track next version milestones on github).
Is it any different at the Enterprise support level?
I personally feel once you've managed your own ES cluster for awhile, you tell yourself there's no freaking way any cloud system can abstract all these ugly (but important) configuration settings and corner cases into a neat, nice cloud product. No freaking way. I'm gonna manage this myself.
The recent versions are far more stable and includes lots of efficiency in terms of memory usage.
Elastic says they don't backport fixes either, so in this case, it might be a good idea to stay near the leading edge of the release cycle.
A roll-your own deployment is basically "install Elasticsearch, install cloud-aws, configure cloud-aws with a security group ID to identify other machines in the cluster, add that security group to all machines you want to cluster together, start the service". Totally braindead-easy.
You seem to have installation confused with administration.
Off the top of my head you forgot security, monitoring, logging config, backups, handling common production issues such as splitbrains, write multiplication, garbage collection snafus, upgrades between versions with questionably compatible internal apis.
Running any database in the cloud is non-trivial, and, running elasticsearch effectively in the cloud is harder than running Zookeeper or Cassandra, for example.
Source: I founded and sold an ElasticSearch hosting company.
My point is that the value-add from AWS' managed ES product is much, much smaller than it might be for other similar products because of the relative ease of administrating ES.
Amazon's typical approach for AWS products is to MVP them, and iterate functionality.
This often means that early services work very well for a handful of use cases. If your case deviates slightly in requirements, you will be better off in the short term running it yourself--assuming you can't change requirements.
In my experience, the AWS teams are very responsive to feedback and work pretty hard to add functionality to their mvp services.