6 ms·
The details are: Here are the different plans available along with pricing per hr. * 256 MB (20GB Storage) $0.015 * 512 MB (40GB Storage) $0.03 * 1 GB (
by streety 18y ago
The details are:
Here are the different plans available along with pricing per hr.
* 256 MB (20GB Storage) $0.015
* 512 MB (40GB Storage) $0.03
* 1 GB (60GB Storage) $0.06
* 2 GB (80GB Storage) $0.12
* 4 GB (160GB Storage) $0.24
* 8 GB (320GB Storage) $0.48
* 15.5 GB (620GB Storage) $0.96
bandwidth will run $0.08 per GB for the incoming and $0.20 per GB for the outgoing
OSs available:
* Ubuntu 8.10 (Intrepid Ibex)
* Ubuntu 8.04.1 (Hardy Heron) LTS
* Debian 5.0 (Lenny)
* Gentoo 2008.0
* Centos 5.2
* Fedora 10
* Arch 2007.08
The folks behind the live chat aren't keeping these details secret. I've no idea why they aren't on the web page.
- kylec 18y agoThanks for posting these. I'm currently using the lowest tier of Slicehost, but it sounds like I can easily halve my costs with this new service without a decrease in RAM or storage. I hope Rackspace will make it easy to move from Slicehost to this new cloud service (both of which they own). The only thing that sounds rather odd is that they're charging more for outgoing traffic than incoming traffic - most websites send much more data than they receive, so I would think that Rackspace would configure their network and their prices accordingly. Granted, this cloud compute service doesn't have to be used for websites, but Rackspace has traditionally been a web hosting company.
- olefoo 18y ago> charging more for outgoing traffic than incoming traffic That's probably why they can afford to offer the cpu time at or below cost.
- wmf 18y agoA large hosting company cannot configure their network asymmetrically because AFAIK the backbones only sell symmetric connections. So Rackspace has symmetric pipes that are mostly empty on the inbound side and they charge less to encourage usage.
- dawson 18y agoJust to let you guys know, #slicehost staffer are reporting those storage prices as incorrect.
- kylec 18y agoYeah, they just added more info to http://www.mosso.com/cloudservers.jsp http://www.mosso.com/cloudservers.jsp. Most of what streety said is correct; however, for the first three tiers, the provided storage is 10/20/40GB (not 20/40/60GB) respectively.
- kylec 18y agoNot that it makes much of a difference, but it looks like the price will be $0.22/GB outgoing, not $0.20/GB. I'd edit my post, but I guess it's been too long (the edit link has disappeared).
- davepeck 18y agoAt first blush, this looked far cheaper than EC2. But, actually, it's the 2GB Mosso machine (at 12 cents/hour) that's most comparable to the EC2 Small Instance (at 10 cents/hour). The EC2 Small Instance has twice the local storage, but a little less RAM. So, they're roughly comparable, with Amazon perhaps coming out a tad ahead in price. That said, I think offering S (1GB), XS (512MB), and XXS (256MB) sizes is a great idea that could be a solid differentiator for Mosso.
- moe 18y agoDon't forget that amazon's local storage is volatile and dog slow, too. So all in all, if those prices are correct, this seems like a very competitive offering. I for one would seriously consider to trade in the hassles of maintaining those AMI images for a few bucks of monthly markup. But on the other hand: Amazon is a battle-tested platform by now, whereas we have yet to see how Mosso performs. Also just today Amazon revealed their new pricing model where you can get away with $48/month for a small instance if you commit for a year (or even $36/month if you commit for 3 years). Anyways, in summary I welcome every new contender to this space. Choice is good.
- timf 18y agoAmazon also has EBS which is fast and should be very reliable. Slicehost (also acquired by Rackspace) has RAID 10 for the images and is pretty good. Still hard to tell what they're offering here.
- moe 18y agoEBS is not the same as having fast and persistent local storage, though. The whole volatility of AMI images is a big burden. You can't just make changes to your images as you go - you can't even snapshot a running image into a new AMI. Instead you have to port all changes back to a local copy of your AMI and re-upload that AMI for updates - which is a cumbersome and lengthy process. To add insult to injury you have to maintain two AMI-images if you want to take full advantage of both small and large instances. One 32bit and one 64bit AMI is required in that case. Ofcourse there are workarounds and our AMI-images are, by now, setup in a way where they provide only a bare, baseline system that updates itself upon boot. Still, this remains one of the biggest pain points with EC2 and will drive many users away when viable alternatives become available.