Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon ElastiCache - Now With a Dash of Redis

aws.typepad.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Amazon ElastiCache - Now With a Dash of Redis

#21

Post by progx »

willejs wrote: post #16
level09 wrote: post #14

Based on a personal experience, I found that setting up a dedicated machine is way cheaper than using those services. I ended up replacing the following: - Mongodb on a EC2 instance instead of Dynamodb - EC2 Mysql instance instead of RDS - Redis instance instead of Elastic Cache - Solr on EC2 instead of Cloud Search - FFmpeg instance instead of Elastic transcoder

At scale this is probably cheaper, if your a startup trying to scale, probably not.

It depend on the service. Usually scale is not a problem, but scale in a short time (hours) can be a huge problem. But most companies would love to have this problem ;-)

Re: Amazon ElastiCache - Now With a Dash of Redis

#22

Post by yesbabyyes »

pashields wrote: post #15
AznHisoka wrote: post #5

Of all the things that you can put to the cloud, I'm not sure why people would want a cloud-hosted memory store. It's easy as heck to set it up in your own server, probably costs less to maintain and host, and faster too as it's closer to your data centers.

They handle automatic failover, which redis does not currently do out of the box. That part is pretty cool. Maybe not worth the price, but definitely useful.

Actually, Redis has a pretty clever failover solution now, in redis-sentinel: http://redis.io/topics/sentinel

Re: Amazon ElastiCache - Now With a Dash of Redis

#23

Post by j_baker »

level09 wrote: post #14

Based on a personal experience, I found that setting up a dedicated machine is way cheaper than using those services. I ended up replacing the following: - Mongodb on a EC2 instance instead of Dynamodb - EC2 Mysql instance instead of RDS - Redis instance instead of Elastic Cache - Solr on EC2 instead of Cloud Search - FFmpeg instance instead of Elastic transcoder

Two things:

1. What kind of EC2 instance are we talking about for MongoDB? If you're not using an SSD, comparing Dynamo and Mongo wouldn't be an apples-to-apples comparison.

2. I buy that the strictly technical costs of these systems is lower, but I'm not certain I buy that the overall cost (including engineer time to set these services up and monitor them) is lower.

Re: Amazon ElastiCache - Now With a Dash of Redis

#24

Post by j_baker »

derefr wrote: post #4

So, how does ElastiCache fare compared to all the hosted Redis-as-a-service (or Redis-as-a-PaaS-addon) products?

I think the main benefit would be for people already running on EC2/AWS. I would imagine (but don't know) that you'd get better latency and throughput between an EC2 instance an elasticache instance than between an EC2 instance and a hosted redis provider.

Also worth pointing out: if you're running on AWS, you'd get integration with your existing tooling like CloudWatch, VPCs, etc.

And last but not least, Amazon is a mature company that you can be confident will be around another 5 years. I don't have that same level of confidence with the majority of Redis-as-a-service providers.

Re: Amazon ElastiCache - Now With a Dash of Redis

#25

Post by nostromo »

level09 wrote: post #14

Based on a personal experience, I found that setting up a dedicated machine is way cheaper than using those services. I ended up replacing the following: - Mongodb on a EC2 instance instead of Dynamodb - EC2 Mysql instance instead of RDS - Redis instance instead of Elastic Cache - Solr on EC2 instead of Cloud Search - FFmpeg instance instead of Elastic transcoder

+1 for Mongodb on a EC2 instance instead of Dynamodb

We're transitioning off Dynamo as soon as possible as the billing structure makes it either a real headache or very expensive.

For example: if you want to make a backup of a large table or move data around, it'll either take days or cost you an arm and a leg. This is just one of many annoyances. Ever since making the decision to go with Dynamo over Mongo, I've been getting dirty looks from my team.

Re: Amazon ElastiCache - Now With a Dash of Redis

#26

Post by acdha »

level09 wrote: post #14

Based on a personal experience, I found that setting up a dedicated machine is way cheaper than using those services. I ended up replacing the following: - Mongodb on a EC2 instance instead of Dynamodb - EC2 Mysql instance instead of RDS - Redis instance instead of Elastic Cache - Solr on EC2 instead of Cloud Search - FFmpeg instance instead of Elastic transcoder

This is true only if your time is free or you're cutting corners on reliability. For example, using an EC2 medium instance on-demand is $0.120/hour and RDS is $0.160/hour. If you use enough MySQL, that $0.04/hour (in reality, $0.022 at reserved rates) can reach the point where it's worth rolling your own management stack, backups, failover, etc. but there are many people who will never reach the point where they don't have higher-priority investments to make.

Re: Amazon ElastiCache - Now With a Dash of Redis

#27

Post by andrewvc »

nostromo wrote: post #25
level09 wrote: post #14

Based on a personal experience, I found that setting up a dedicated machine is way cheaper than using those services. I ended up replacing the following: - Mongodb on a EC2 instance instead of Dynamodb - EC2 Mysql instance instead of RDS - Redis instance instead of Elastic Cache - Solr on EC2 instead of Cloud Search - FFmpeg instance instead of Elastic transcoder

+1 for Mongodb on a EC2 instance instead of Dynamodb We're transitioning off Dynamo as soon as possible as the billing structure makes it either a real headache or very expensive. For example: if you want to make a backup of a large table or move data around, it'll either take days or cost you an arm and a leg. This is just one of many annoyances. Ever since making the decision to go with Dynamo over Mongo, I've been…

The set of problems where you're really struggling between mongodb and dynamodb as a choice is practically non-existent. They have hugely different characteristics and vastly different trade-offs. You might want to spend some time reading about the architecture of various databases before just picking one.

Re: Amazon ElastiCache - Now With a Dash of Redis

#28

Post by giovannibajo1 »

derefr wrote: post #4

So, how does ElastiCache fare compared to all the hosted Redis-as-a-service (or Redis-as-a-PaaS-addon) products?

Compared to normal Redis-Paas, it's on the same line, probably cheaper than the average price on ther market. ElastiCache is basically a way to spin up a EC2-backed instance of Redis, with automatic failover and replication. It only handles one node per cluster, and doesn't handle scaling (you need to manual provision, replicate, switch, etc.).

But if you go with a true clustering solution (like Redis Cloud, www.redis-cloud.com), then you get automatic transparent scaling with zero downtime thanks to dynamic sharding:

http://redis-cloud.com/redis/redis-comparison

To me, such a cluster solution justifies the PaaS price over a manual Redis installation.

Re: Amazon ElastiCache - Now With a Dash of Redis

#29

Post by svmegatron »

progx wrote: post #19
whalesalad wrote: post #10

Earlier quoted context omitted.

Well unless you roll with a Micro instance (213mb of RAM and dismal performance), the price for a Small on-demand instance (1.3GB memory) is ~$54 per month. You save quite a bit by going with a reserved instance, where you pay about $70 up-front but then your monthly instance price is almost halved, coming in at around $32 per/mo. Either way, it's going to be more cost-effective at a lower level to go with something…

The prices of many Redis-Service-Provider will drop rapidly after amazons release ?

Or they will all start making more money.

Re: Amazon ElastiCache - Now With a Dash of Redis

#30

Post by seanmccann »

skyebook wrote: post #9

Good on them for doing this, its missing one substantial configuration option though: Redis Authentication. Security groups are great, but it would be comforting to have some challenge when hitting cache.

Exactly. This is especially important when using it in conjunction with Heroku.
Post reply on HN