Rackspace (via Mosso) to Launch Cloud Servers at 1.5 cents/hour ($10.95/month) Monday(blog.mosso.com)
blog.mosso.com
Rackspace (via Mosso) to Launch Cloud Servers at 1.5 cents/hour ($10.95/month) Monday
http://blog.mosso.com/2009/03/breaking-news-mosso-the-rackspace-cloud-announces-availability-of-cloud-servers-and-more/
34 comments
After reading two paragraphs, I wanted to know how many times they used the word "cloud" on that page. It's 72: http://twitpic.com/21an7
Sometimes I wonder if people are perhaps drinking a little too much of the cloud KoolAid. This is one of those times.
I had somebody from Microsoft once tell me, in apparent seriousness, that I should cloudify my program. Because it would offer me unprecedented scalability and uptime, and let my customers access their data from anywhere.
sigh You see this tool right here? It is called a hammer. It is useful for many things. You see this problem right here? It is an ingrown toe-nail. Please do not attempt to fix the ingrown toe-nail with the hammer. It will not work out well.
I had somebody from Microsoft once tell me, in apparent seriousness, that I should cloudify my program. Because it would offer me unprecedented scalability and uptime, and let my customers access their data from anywhere.
sigh You see this tool right here? It is called a hammer. It is useful for many things. You see this problem right here? It is an ingrown toe-nail. Please do not attempt to fix the ingrown toe-nail with the hammer. It will not work out well.
It would be nice if they had a comparison document detailing the differences between the Cloud Servers and their Slicehost service. I currently have a handful of slices, all of which might benefit from these offerings. However, I know with the Slicehost offerings I have persistent storage, bandwidth, etc. However, I don't normally use all my bandwidth or storage.
It would also be nice to know if they have any details regarding whether this will be integrated into Slicehost's Control Panel, or products, to allow easier migration, scaling, etc.
It would also be nice to know if they have any details regarding whether this will be integrated into Slicehost's Control Panel, or products, to allow easier migration, scaling, etc.
Well, I think the idea is that those details are coming on monday. But there are some details that we can know now since Cloud Servers is mostly just Slicehost combined with Mosso/Rackspace's support/billing channels. So, they'll be Xen instances with persistent storage. Right now the bandwidth question is up in the air since the site doesn't specify. Given the pricing, I'd have to assume some bandwidth would be included. At $700, their 15.5GB server wouldn't look so nice against an $800 slice that came with 2,000GB of bandwidth (which would cost $400 at $0.20/GB).
They'll probably be integrating this with the Mosso control panel.
EDIT: So, talking with the Mosso support, bandwidth is not included and it will cost 22cents outgoing. Makes the pricing look a lot less appealing against Amazon's EC2 - especially since Slicehost's previous key (persistent storage) is negated by EBS.
Mosso's live help is answering any questions you have and they seem decently knowledgeable. The information doesn't seem to be embargoed at all by Rackspace.
They'll probably be integrating this with the Mosso control panel.
EDIT: So, talking with the Mosso support, bandwidth is not included and it will cost 22cents outgoing. Makes the pricing look a lot less appealing against Amazon's EC2 - especially since Slicehost's previous key (persistent storage) is negated by EBS.
Mosso's live help is answering any questions you have and they seem decently knowledgeable. The information doesn't seem to be embargoed at all by Rackspace.
Word of warning: I used their $100/mo server cloud as my host for a while, but repeated downtime issues forced me to leave.
Yea, we've had problems too - I've consistently benchmarked their cloud sites servers with a load time 5-8x slower than other hosts.
The difference is, other hosts will crash under load and you'll lose all your requests. Mosso is like a train and other hosts are motorcycles. It's slower but can haul way more tonnage.
I was going to go with them back in the day but the biggest turn off was no SSH access. Seriously, wtf?
I run two such accounts starting several months ago. I'm infuriated by some quirks of their site management system,* but the reliability has been good. I think they've gotten better.
* Especially: It's impossible to move a site from one account to another, or even from one client to another client in the same account, or even from no client to a client in the account. Impossible. They can't/won't even do it for you on the backend.
Compare to telling the mail system that your mail is somewhere else. DNS you can do yourself, mail server you have to ask them to do if you want other mosso users to be able to send to you. That's a reasonable compromise IMO.
* Especially: It's impossible to move a site from one account to another, or even from one client to another client in the same account, or even from no client to a client in the account. Impossible. They can't/won't even do it for you on the backend.
Compare to telling the mail system that your mail is somewhere else. DNS you can do yourself, mail server you have to ask them to do if you want other mosso users to be able to send to you. That's a reasonable compromise IMO.
Keep in mind that Cloud Sites and Cloud Servers are completely different; they were developed by different companies.
They say "click here for details" but it has no more information, unfortunately: http://www.mosso.com/cloudservers.jsp
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.
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.
The details are:
Here are the different plans available along with pricing per hr.
OSs available:
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.96OSs 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
At 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.
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.
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.
Amazon 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.
Still hard to tell what they're offering here.
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.
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.
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.
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.
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.
Just to let you guys know, #slicehost staffer are reporting those storage prices as incorrect.
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.
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.
> charging more for outgoing traffic than incoming traffic
That's probably why they can afford to offer the cpu time at or below cost.
That's probably why they can afford to offer the cpu time at or below cost.
The existence of a low end instance in addition to some higher end instance availablity options is pretty awesome, this makes it cheap enough for something which you might only really need VPS level availability to make sense to build on top of their platform and then if you need a bunch of instances all at once ok to fire up.
They have quotes on the site like "I couldn't even find Amazon's phone number" which seem a bit miss-leading (Amazon simply charges for phone support), but yay for competition :)
Any word on whether these will be 32 bit or 64 instances. Slicehost's ram is far less "efficient" than linode, and you only really need 64bit for addressing ram anyway.
This cloud stuff sounds great!
I can't wait to use it in 5 years when it's reliable.
I can't wait to use it in 5 years when it's reliable.
SUMMARY:
* Same as SliceHost except pricing is hourly, instead of monthly
* 1GB Slice = $43.80/mo
* Upgrade/downgrade whenever you want
* For questions, contact Will at 210-312-5181 or [email protected]
* You get root SSH access, just like SliceHost
FULL THING: ===========
Will: Hi welcome to Mosso the Rackspace cloud. How can I help you? May I also get your name and email address just in case we get disconnected?
you: Hello
you: Melvin Ram, [email protected]
you: Is Cloud Servers the same as slicehost?
Will: Nice to meet you Melvin
Will: it's a little different
Will: so with slicehost you're locked in to bandwidth
Will: cloud servers is on a utility model with bandwidth
Will: slicehost you're paying montly
Will: monthly*
Will: cloud servers is hourly
you: I currently have a 1gig slice with slice host and it's way under the bandwidth limits... how much would that cost with Cloud Servers? And will I get the same type of root access?
Will: you will get the same root access
Will: 1 GB (40GB Storage) $0.06 hourly, $43.80 monthly you: can I upgrade a server to a larger server and then shrink back down at a later time?
Will: sure, and you wont have to reupload anything just like with slicehost you: Will this be replacing slicehost?
Will: nope
Will: you'll still have slicehost if you want it
Will: this is just a little extra : )
you: Is there any reason someone would want to stay with SliceHost and not migrate to this?
you: especially since I'm assuming both system will have access to exact same hardware and network
Will: simply a comfort factor I think
Will: if you already know it
Will: but to me cloud servers is going to be the way to go
you: it's almost half the cost for exact same thing... a little pain for 200% ROI makes sense
you: anyway, thanks for the info
you: I'll be switching soon
Will: great, thanks for keeping it in the family : )
you: I was thinking of switching to heroku but I might just think twice
you: heroku is based on the AWS system
Will: Great, that's what we were going for
Will: Booooo AWS
Will: we're faster anyway : )
Will: and we specialize in hosting not books....
Will: So I see you're in marketing
Will: do you have some rather large projects that you may need this for, or just to run day to day stuff
you: small stuff for now
Will: cool, just checking : )
Will: I'll get that email out to you
you: Right now, the main app is www.BrainBankhq.com
you: its in it's infancy right now
you: Zero paying clients
you: but a lot of people promising to start using it once I add ability to charge people for the content.
Will: gotta start somewhere right
you: Yep... they'll all be membership-based websites so I'm assuming that a few of them will turn to be much better than most of them... so it's just a matter of seeing where it goes.
you: And just refining it so it's simple
Will: so what's this for, kind of link Junto with Ben Franklin?
you: huh?
you: reading about it on wikipedia... gemme me a sec
Will: Junto was a group that eventually evolved into the University of Philadelphia...basically a think tank
you: Well some of the membership sites may turn into that but it wasn't the original intent.
you: Originally, I wanted to create an app that I could use to take down notes for my chemistry class and sell it future students.
Will: ah, yes that would be very useful
you: yea, but I didnt know how to do credit card processing so I made it so it would be offer free content
you: I figured it would be a lead-gen tool
you: content creators don't like that idea
you: Or at least I haven't explained it well enough for them to like the idea.
Will: I'm sure you'll get through to them : )
you: anyway, I've come across enough people who want to create membership-based content sites that it makes sense to give it a try to go that direction
you: Btw, did you get a chance to send over that stuff?
Will: have you looked at cloud servers to host this
Will: it's a little more scaleable
you: It's on Slicehost for now
Will: just sent it
you: I'll move it here soon
you: You don't mind if I share it with a few friends to pass on the new, do ya?
Will: not at all
Will: feel free to give them my email address if they have follow up questions
Will: or they can call me direct at 210-312-5181
Will: my name is Will Conway
you: Gotcha! Thanks Will!
Will: my pleasure
you: Wait, one more Q
you: It obviously comes with SSH, right?
Will: correct
Will: you'll have full command line access
you: Just like SliceHost
Will: you bet
Will: Slicehost is the foundation of cloud servers so you'll find that it's all very similar
you: Gotcha