My guess is that this is going to be a pretty small box meant to pique people's interest and get them looking at the price sheet, something like 64MB or 128MB RAM.
Personally I have a use for changing numbers of many small nodes like that, dependent on the bandwidth situation at least. Getting things down to this small of a slice means you can really optimize certain tasks.
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.
Don'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.
EBS 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.
Yeah, I've been through all this too. Sounds like you want something beyond "ec2-bundle-instance" which will bundle your running instance but won't snapshot the VM from "underneath" as it's running (EBS snapshots can do that though). Another way we address issues like this is to create VMs on a local cluster (with Nimbus which is a local EC2 API compatible service that supports persistent storage) and transfer them to EC2 for big launches of the "finished product."
Yeah, I've been through all this too. Sounds like you want something beyond "ec2-bundle-instance" which will bundle your running instance but won't snapshot the VM from "underneath" as it's running (EBS snapshots can do that though).
Sort of. What I'd really like is a ec2-bundle-instance that works near instantly. As I understand it amazon copies our AMIs around their clusters anyways - but insists on mounting them read-only.
I'd like a flag to my ec2-run-instances that causes the AMI image to be mounted as read/write. Make the i/o dog slow if you must (it already is, anyways) but let me work directly on the image and make sure my changes persist across reboots for this particular instance. That requires them to make a copy my AMI-file on their server for that particular instance - so bill me extra, thanks.
With those mechanics in place I'd imagine an equivalent to ec2-bundle-instance that works near instantly on such r/w-AMIs would be possible. It'd only have to copy the modified image back to s3.
The take-home would be that we get a way to perform and test (hence the reboot) AMI-changes much more quickly than is possible now.
I think ec2-bundle-instance does something much like what you're asking for.
EC2 VMs are not mounted read-only. They are reconstructed from S3 and mounted read/write as a local file on the Xen node.
The changes to this file (your instance's storage) are saved across reboots when you type 'reboot' or use the external ec2-reboot-instances command.
It's just that the terminate operation does not copy the changed file back to replace the AMI that was launched (it would be quite limiting if it did that).
ec2-bundle-instance is a program that will bundle a running instance into a new AMI upon its next reboot. So it requires a reboot and is not like a live lvm-snapshot which is what you will get from EBS snapshots.
On the other hand we don't know how comparable it really is because there is no "Mosso compute unit" to compare to the "EC2 compute unit" (defined @ http://aws.amazon.com/ec2/instance-types/ )
Not only the processor used and how many vcpus the VM has, but the timeslice you're given (best determined by your own experimentation). The CPU scheduler rations can have profound effects on how your application runs, we've run into some issues with this on CPU intensive physics jobs.
For example, if a "compute unit" is around 1.0 GHz, it's not really the same thing to give you a 2.0 GHz chip scheduled on the real processor just half the time (competing with another VM), some thrashing can occur, especially when I/O is involved.
Anyhow, it all depends what you're after. For a lot of applications it makes no sense to pay for that much RAM per machine. Or in many cases it's not the CPU that's important. And so on.
Yeah, they just added more info to 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.
Not 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).
Thanks 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.
A 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.
My guess is that this is going to be a pretty small box meant to pique people's interest and get them looking at the price sheet, something like 64MB or 128MB RAM.
Personally I have a use for changing numbers of many small nodes like that, dependent on the bandwidth situation at least. Getting things down to this small of a slice means you can really optimize certain tasks.