I tracked my time when initially learning chef, and it took me ~100 hours to be comfortable with what I needed (2.5 years ago roughly if I remember well).

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.

100...hours? Wow, the documentation for Chef must really be bad because I guess I still don't know what it's meant to do, despite going through the Hello World process. I thought it was just a framework for the batch commands needed to set up a machine. What was the hardest part to feel comfortable with? The syntax? The conventions for maintaining and executing recipes?

Hi Danso, fundamentally Chef, CFEngine and Puppet are all Configuration Management (CM) systems. They are a programmatic way to specify what a "host" or group of "hosts" should look like using a dependency graph. Basically it builds the dependency graph and works from the root to the leaves one level at a time.

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

Kind Regards, Nathan

The documentation for Chef is not great, but what makes it problematic (at least when I was first learning it) is that it has a tendency to not correspond to the currently released version (sometimes it's outdated, but more annoyingly, sometimes it's pre-dated).

My two bits of advice for learning Chef:

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

It takes experiences like this to realize one of the advantages of Puppet's architecture, namely that you can bootstrap it by installing one of two system packages (the server or the client). The agent and the master are just processes, whereas in Chef you have to set up MongoDB and a bunch of other network services just to get started, which ends up making your configuration management system Yet Another Precious Service With Lots Of Moving Parts.

This is simply not true. Chef solo does not require a server.

The learning curve of Chef is pretty steep. The article touches on that, saying that documentation is bad, and I would add that the community provided recipes aren't very good either. But, the whole interest is that it's a one time investment. Once you've figured out how to handle your deployments with it, and have a few helpers/examples, you end up saving quite a bit, both in time and money.

> and I would add that the community provided recipes aren't very good either.

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.

It also comes down to how much you value learning new technologies.

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.

Same here. Was working on a rails 4 project last weekend for fun. Ended contributing a few patches here and there.

I think the whole sysadmin/devops thing is an inescapable problem to some degree.

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.

https://www.cloud66.com/ Seems like an easy way to get something up.