One theory is that cloud hosting providers use memory as a metric to estimate a customer's use of resources that aren't directly paid for (bandwidth, CPU, support, etc). So even though you may be way overpaying for increased memory based on current RAM prices, their data may show that you're much more likely to also use more resources you aren't directly paying for and set the price accordingly.
Well you probably know its not really just the RAM you are paying, they just use the RAM amount as a label. If you take a large chunk of RAM, that significantly reduces the number of other users that can go on that machine. Really its the whole service is expensive when you want larger amounts of RAM.
Basically I think we are paying for all of their support people and infrastructure and also a healthy profit.
RAM is a resource that they can't oversubscribe, so it costs more.
If I have an instance with 8x CPU cores they can timeshare CPU time between multiple customers on that physical server, since it's unlikely that all instances will use 100% CPU 100% of the time.
However, if I have a server running memcached and a 30GB cache, they can't also cell that RAM to another customer. This limits the amount they can oversell server resources, thus they charge more for it.
Amazon S3 has a more competitive outgoing bandwidth pricing. That works out best for me (lots of small files with small overall storage size but consume lots of bandwidth).
You need to ask yourself, what is your main use case? More often than not, if your use case is a web service serving up files over HTTP then Amazon is more competitive. I would say bandwidth would be the greater consideration in most cases for web services.
Even S3 outgoing price are ridiculously expensive for any kind of significant bandwidth use, that's what CDN are for (and in that area, cloudfront is really not cheap either).
I'm a fan of AWS and use a lot of their services, but their bandwith price from them to the outside world are far from the best deal (of course if your bandwith is still calculated in the hundreds of dollars this doesn't apply/matter much).
I know you weren't saying the contrary, but still I wanted to point it out.
Take a look at http://www.superflexible.com/
it's a great product, updates constantly, and with lots of features. We are using it on our production env.
Seeing as you build your own 'filesystem' on top of a simple key/value interface, I think advancing the backend support might be good 'low hanging fruit'.
It doesn't even have to be something as 'cloudy' as rackspace, support for something like webdav as an ARQ backend would also be nice.
That being said, I have actually no idea about the codebase and user base, so this could be a completely wrong assumption :)
Personally, my biggest 'problem' with Arq at the moment is, that the iPhone client works, but I'm missing stupid small things like thumbnail previews for uploaded images.
Would love to see it - for cloud files - and all swift deployments (the whole cloud files source is open sourced as part of openstack). let us know if we can help in any way.
Duplicity is a simple tool for signed/encrypted (PGP) differential backups using a variety of protocols including: ssh/scp, local file access, rsync, ftp, HSI, WebDAV, Tahoe-LAFS, and Amazon S3. I'm assuming that rackspace storage supports at least one of these?
There is a very easy to use command line interace, and also a GUI (which I have not tried).
Thanks, I love duplicity from a technical standpoint, but for some reason, I'd like to have a native OSX UI and the ability to access my data from my iOS device while on the go.
I hate to seem ungrateful, but I just wish their bandwidth costs would come down a bit. That said, this is much-appreciated.
The object versioning system seems interesting if you haven't rolled your own yet, though I wonder how relying on it might affect your ability to migrate to Amazon.
This is good news. It seems to me that Rackspace Cloud services don't get much publicity compared to AWS, which is a shame. RS is a good alternative and their tech support is great.
24 comments
[ 2.0 ms ] story [ 47.9 ms ] threadBasically I think we are paying for all of their support people and infrastructure and also a healthy profit.
If I have an instance with 8x CPU cores they can timeshare CPU time between multiple customers on that physical server, since it's unlikely that all instances will use 100% CPU 100% of the time.
However, if I have a server running memcached and a 30GB cache, they can't also cell that RAM to another customer. This limits the amount they can oversell server resources, thus they charge more for it.
You need to ask yourself, what is your main use case? More often than not, if your use case is a web service serving up files over HTTP then Amazon is more competitive. I would say bandwidth would be the greater consideration in most cases for web services.
All of their comparison calculations (http://www.rackspace.com/cloud/cloud_hosting_products/files/...) also include "AWS Gold Support" (which costs an extra $400+/month).
I know you weren't saying the contrary, but still I wanted to point it out.
[0] Arq: http://www.haystacksoftware.com/arq/
It doesn't even have to be something as 'cloudy' as rackspace, support for something like webdav as an ARQ backend would also be nice.
That being said, I have actually no idea about the codebase and user base, so this could be a completely wrong assumption :)
Personally, my biggest 'problem' with Arq at the moment is, that the iPhone client works, but I'm missing stupid small things like thumbnail previews for uploaded images.
There is a very easy to use command line interace, and also a GUI (which I have not tried).
http://duplicity.nongnu.org/
The object versioning system seems interesting if you haven't rolled your own yet, though I wonder how relying on it might affect your ability to migrate to Amazon.
I haven't looked at the RS versioning offering, but I can't imagine it being any different in terms of features of the amazon one.
You can leverage these with Rackspace Cloud Files.
ssl.SSLError: The read operation timed out
I'm not the only one:
https://www.google.com/search?q=SSLError+The+read+operation+...
It's not that bad since I just retry it but it's one of the things that makes me wonder what is going on at Rackspace.