My time is more valuable than manually managing servers. It's an incredibly basic tradeoff: some people are more price-sensitive, others are more time-sensitive.
In my case, if I end up working on an app that reaches the scale where Heroku isn't appropriate (for cost or 'omg I need metal' reasons) again, I'm sure there will be someone else on my team who lives and breathes ops. I can manage, but I'd rather be doing almost anything else.
(and when I tried to load the article, none of the body text loaded, I had to refresh the page...)
The learning curve was fairly steep for me, but then I don't regret it, since I got to use it as a freelancer just right after on multiple gigs, and that I can now extend EngineYard recipes or think about using AWS OpsWork without much sweat.
From a purely single-person building app for yourself kind of perspective though (with one or two servers), it's a deep investment IMO...
People should have a look at http://ansible.cc for an apparently much lightweight alternative.
As an example let's say you want to install MongoDB on a new Ubuntu machine, you have the following dependencies in approximate order;
* Add MongoDB Apt Repo to apt list.
* Add MongoDB repository key.
* apt-get update.
* apt-get install mongodb.
* Configure /etc/mongodb.conf to your liking.
* Restart mongodb.
Depending on how you implement it CM will allow you to make the process cookie cutter.
Want a new test environment? Spin one up and run your CM against the servers.
Want to try that hot new cloud provider? Ditto.
I think it's worth the investment unless you're just doing apps that have a very short shelf life (e.g. marketing apps that live for no longer than a few months).
- Use chef-solo. (Edit: and use knife-solo to initially bootstrap Chef onto the machine.)
- Your first time, forget about cookbooks and just write a single site-cookbooks/myapp/recipes/default.rb. Use that to list packages, shell code, whatever.
This will get you started, and you can learn/improve from there.
Your second time, use librarian-chef, and as someone else said, freely clone cookbooks so you can adapt them to your needs.
This is key. When I first got into using Chef, I assumed things would be no problem because all the services I used already had community recipes.
The community recipes are often wrong, don't work correctly on "clean" first-time installs and have a lot of baked in assumptions about the config and modules to use.
Clone these recipes into your repo, you will be modifying them. Blindly relying on the built in functionality to pull in and update the community repos will lead to pain.
Chef is a powerful tool, but it is also evolving rapidly and requires careful attention and testing.
I started a project in Rails 4 a few months ago and it took several hours just to get compass working again... but it was still worth it.
If it's something that nobody on your team can tackle you can easily end up with completely disparate development environments (with devs running different ruby versions, app servers, even databases!) when there's no well documented system for setting up environments.
Heroku makes it dead simple to deploy and add services, but if your team can't manage to do that for local development anyway, things can end up in a really bad state.