Re:AWS services to avoid
by FireBeyond on Sunday May 10, 2020 @02:04PM
(#23134623)
> Not knowing that such tooling exists, or explicitly choosing not to use such tooling, and experiencing pain as a result seems to be common theme in this article. If you dive into architecting a system using AWS's product offerings without understanding the tradeoffs you're making, you will experience greater cost and greater friction -- hands down.
Which I think is one of the underlying points of the article.
> Many a startup has fallen prey to ElastiCache. It usually happens when the team is under-staffed and rushing for a deadline and they type in Redis into the AWS console:
I think this is a good article in the sense of "these are things that may or will bite you if you've not put a bit of thought into them".
Even the replies on this story upstream hint at that, with people debating Redis' durability, based on this:
> It’s best to design your system assuming that redis may or may not lose whatever is inside.
completely ignoring the follow up:
> Clustering or HA via Sentinel, can all come later when you know you need it!
It's like the first sentence was read and people leaped to the keyboard to reply passionately.
Which I think is one of the underlying points of the article.
> Many a startup has fallen prey to ElastiCache. It usually happens when the team is under-staffed and rushing for a deadline and they type in Redis into the AWS console:
I think this is a good article in the sense of "these are things that may or will bite you if you've not put a bit of thought into them".
Even the replies on this story upstream hint at that, with people debating Redis' durability, based on this:
> It’s best to design your system assuming that redis may or may not lose whatever is inside.
completely ignoring the follow up:
> Clustering or HA via Sentinel, can all come later when you know you need it!
It's like the first sentence was read and people leaped to the keyboard to reply passionately.