It would be great, really great, if this were priced per-gigabyte of RAM and per-gig transferred. To my mind, memcache should be billed and used more like a CDN.
Until then, this makes sense only for mid-large scale memcache deployments, similar to Amazon's RDS.
Agreed, the value add isn't very high, especially since the pricing is higher than EC2. Surely there are some economies that could be found on servers with no disks and reduced CPU requirements? I wonder if ECC could even be done away with if they checksummed all the stored values?
It would be a real killer if they had incremental pricing (per-GB-hour) with an adjustable high watermark / replica count, and a name/port-based endpoint that always worked and routed requests to the proper cache server.
I agree that the value add isn't significantly high for small cluster type of situations, and I would much rather just have a caching API available that charges on usage and allows you to specify an amount of redundancy.
However, the automatic failovers is very nice. From Vogel's blog: "Amazon ElastiCache automatically detects and replaces failed Cache Nodes to protect the cluster from those failure scenarios." That is definitely nice.
Elasticache does seem to be sitting in an awkward middle ground between renting of instances and paying for usage in an API.
Edit: after thinking about it more and reading some of the comments, I think an ideal setup would be an API to a memcached like datastore with buckets so I can specify max-size, redundancy, expiration methods, etc on a per bucket basis. Even nicer setup would be all of that plus redundancy and HA across availability zones and regions.
> I think an ideal setup would be an API to a memcached like datastore with buckets so I can specify max-size, redundancy, expiration methods, etc on a per bucket basis.
Raising the question of why Amazon didn't adapt its S3 API to the task, and then layer an optional memcached-compatible wrapper on top of it.
The problem is that you need to provide the other services as well. Having your database and application server in one datacenter, but your memcached instance in another would reduce the use-cases because of latency and bandwidth restrictions.
We recently got a step closer to integrating multiple clouds now that EC2 allows peering. http://aws.amazon.com/directconnect/ To really make it easy you'd probably want federated auth and billing, but I'm not sure that's in Amazon's interest.
At current RAM prices, one can build a cheap 2U SuperServer with 144GB of ECC DDR3 1333MHz RAM, a single quad-core 40W 2.13GHz Westmere processor, a 10gig-E card, and a 4GB CompactFlash drive for ~$4,000. Assuming the server has a 3-year lifespan and costs ~$4,000 to power, cool, house, network, and administer, that's around $0.0021/GB-hr considering 143GB of it is usable. Double that to ~$0.0043 for redundancy, and they could charge $0.02/GB-hr and make a healthy profit.
Edit: Note that a lot of that profit gets eaten up in underutilized capacity, this is just a simplistic analysis.
I have a feeling the pricing on this is going to get revised pretty quickly. Since memcached is so easy to run & cluster, I'm not seeing a reason to rationalize the added expense to have amazon do it.
ELB is cheaper than running your own EC2 load balancer, but ElastiCache is more expensive than the same raw EC2 servers. It makes sense, but I was hoping it'd be as much of a no-brainer as ELB was.
You would think they should be able to offer it cheaper, as they will be able organise it to get a lot more users/ CPU usage per server than the usage they would typically get from an average EC2 server.
I'm almost certain they could offer it cheaper and have chosen not to. If you look at AWS' history they tend to price higher than they need to and then aggressively lower the prices after the service is established. I've always assumed this is part of a very conservative business plan where they establish the actual cost of running the service (as opposed to projections) over time. Once they've established they can actually run the service as cheaply as projected they lower the price accordingly.
Remember Amazon isn't a startup. It is an established company with shareholders to keep happy. Given that I think the above strategy is a sensible one (and is probably why AWS has been profitable from the very beginning)
Cheaper than running your own _external_ load balancer.
I really wish amazon released an internal only (cross AZ if applicable) load balancer with cheaper transit costs.
I would have liked it a lot more if they launched a Redis like version with persistence storage than memcache. I wonder why they considered Memcache over Redis.
It seems to be a memcache compatible interface. So its really hard to tell what they used underneath the covers. Perhaps a modified memcache for there needs...
Is the failover mechanism just a hardware replacement where you need to repopulate the cache or are they doing some kind of "slave" hotswap that the replaced hardware already has the cache?
Is there a part of the typical web stack that they don't offer a solution for or does this pretty much cover it. I know you can always run whatever they don't yourself just on another ec2 instance, but I think you can offload everything (but your app) now to their services.
This would have been more awesome if the clusters had an address and handled the sharding for you.
As it stands, getting a memcached server up and running is so trivial that this probably isn't worth the extra cost for anyone on a small scale and already using things like chef or puppet.
So this is just a simple way to get some memcached instances running. I guess it makes sense for amazon to target memcached since it's still the most popular caching system in use, and probably the easiest for newbies to get into, but it is very old technology at this point. There is no built in support for clustering, replication, or durability. There are solutions out there that provide a much better feature set. Heh, where did the original dynamo paper come from? All in all, underwhelming.
EDIT: I guess i forgot to mention the most obvious reason of all to go with memcached - what they have rolled out is by far the easiest caching system to implement. Not trolling, just stating the facts..
It may or may not be memcached -- it merely speaks the same protocol. I would not be totally amazed if something else is running underneath now or in future.
In the FAQ it states "Each Cache Node runs an instance of the Memcached software and has its own DNS name and port". So it looks like it is running memcached and not just talking it.
That is definitely plausible, but I'm more referring to the feature set, i guess i would clarify as the contract between them and the developer. That is basically memcached, from what i understood from their blog posts. As far as memcached itself goes, i hear it does what it does quite well, but that's ot.
Until then, this makes sense only for mid-large scale memcache deployments, similar to Amazon's RDS.