Hacker News Reader

Comment by nethergoat | Hacker News Reader

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.

View on HN

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).

1. Quite true

2. I think it's always important to be explicit about, and have backups, of the packages used in these scripts.

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.

disclaimer: I work for RightScale

Reply on news.ycombinator.com