This is tremendously useful and lowers the barrier to entry for new adopters. Unfortunately, it's also a temptation to make poor design decisions.
One of the key benefits of EC2 and other cloud offerings is that, in a properly automated environment, it is faster and easier to replace a faulty node than to troubleshoot it. The same is true for upgrades - simply boot a new instance from an updated AMI or Chef/Puppet/Cfengine/RightScale config and point traffic at the new server. Minimal wheelspin, minimal downtime.
Those who use this new feature to take a, for lack of a better term, "server-hugger" approach to cloud computing will miss out on this. Though it may reduce their cloud onboarding time, it's inefficient in the long term and will be an operational burden as the environment grows.
One man's 'cloud onboarding time' is another's 'undifferentiated heavy lifting'.
Increasingly, it seems that the man-years we've collectively invested in EC2's bizarre APIs were entirely for their own development convenience, rather than actually being their best practice. The complexity of AMIs vs the simplicity of cloning disk images - there's little practical difference other than the latter is obviously simpler and more powerful. And the latter has existed for 15 years, if not a lot longer.
As cool as they are, I have 2 problems with Chef/Puppet/CFengine/Rightscripts.
1. Long boot times. This gets worse as your recipes get beefier.
2. Same script, different results. Running your recipe next year might not yield the same result (e.g. if you don't specify a precise version of a package to install).
I agree. I do use Chef and Capistrano to automate creating AMIs, but then I like to just save the AMIs and boot from them. Also, creating a new AMI from an old one is quick and easy.
1. This is certainly true, but hopefully we can find a good way to combine the benefits of booting from EBS and having a fast root partition, with that of the agility of Chef/RightScript model, to decrease boot times.
2. You can version server templates to use specific revisions of RightScripts and recipes. In fact, the Chef implementation is built around using a branch or commit SHA1 to specify what versions of the recipes you want to use from your repository.
EBS costs $0.10 per GB and $0.10 per million I/O requests. Any ideas how much it would cost per month to replace a "normal" AMI (which is free) with an EBS-backed one like this?
You store a normal AMI on S3, which is $.15/GB. If you care about costs, you should be doing all of your high IO tasks on the /mnt swap drive, so your IO costs should be pretty low. It's probably a wash.
This is great for people who have 1-2 machines running a website, but doesn't really make any difference to people who are actually elastically scaling.
In fact, maintain state between stops/starts increases headaches for me. It's a lot more tempting to incorporate manual voodoo instead of baking it into the build process.
after i just spent all day yesterday building and rebulding amis... this is great.
i can see a lot of advantages in terms of boot time and having a much bigger root but for us since boot time is negligable compared to puppet config time, the biggest saving will come the next time we're doing the
the whole configure/test/ec2-bundle-vol/ec2-upload-bundle/ec2-register cycle, which is so tedious.
I wish they had released this new feature a year ago - it would have saved me a lot of effort setting up both customers and my EC2 backed applications.
I'll use this in the future, and I will convert my own permanent EC2 instance. There is a bit of trickery that I had to learn to auto mount EBS volumes when my AMIs start up - some Ruby scripting code I probably won't have to use anymore.
You mention conversion ... Anybody have any suggestions about how to convert an S3-backed AMI to an EBS backed one (linux)? I'm wondering if there's some grub trickery that needs to happen over and above the file copies to make booting work?
One of the key benefits of EC2 and other cloud offerings is that, in a properly automated environment, it is faster and easier to replace a faulty node than to troubleshoot it. The same is true for upgrades - simply boot a new instance from an updated AMI or Chef/Puppet/Cfengine/RightScale config and point traffic at the new server. Minimal wheelspin, minimal downtime.
Those who use this new feature to take a, for lack of a better term, "server-hugger" approach to cloud computing will miss out on this. Though it may reduce their cloud onboarding time, it's inefficient in the long term and will be an operational burden as the environment grows.