4 ms·
Article is a bit naive about what it takes to run a shared service. Any API that AWS ES exposes has to be there forever, clearly pending_tasks had some risk of
by cavisne 9y ago
Article is a bit naive about what it takes to run a shared service. Any API that AWS ES exposes has to be there forever, clearly pending_tasks had some risk of leaking internal implementation details that either couldn't be exposed, or that they didn't want customers building a dependency on.
Likewise with the doubling of nodes, this is obviously a blue-green style deployment. In place updates would be quicker but ES can get into all sorts of weird states that require manual debugging to fix, with blue green for most of the deployment you can simply flip back.
I've been pretty impressed with AWS ES compared to running it myself (other than the poor fit of IAM auth)
- dmix 9y ago> Any API that AWS ES exposes has to be there forever, clearly pending_tasks had some risk of leaking internal implementation details that either couldn't be exposed, or that they didn't want customers building a dependency on. If this is a reality of using cloud based ES then clearly it's something to seriously consider before using it - which is all the author is saying. The article is titled 'things to consider' not 'things AWS needs to fix'. ES is big complex beast of a Java app. This is good advice regardless from someone who has used both approaches (self hosted vs AWS) in production. I did not get the impress that he's saying that AWS can resolve this easily.
- jack9 9y ago> Article is a bit naive about what it takes to run a shared service. This is a bad assumption. Loggly is a shared service. > Any API that AWS ES exposes has to be there forever This a bad assumption. No API is forever. Maybe you meant a different timescale. AWS has removed and made breaking changes to APIs over the years (e.g. random breaking change: https://forums.aws.amazon.com/message.jspa?messageID=513640 https://forums.aws.amazon.com/message.jspa?messageID=513640).