I am simultaneously kinda embarassed and also not that I've never actually been able to get Chef to actually work. I've tried two or three times, put two or three hours into it each time, and then said "fuck it" and either did it by hand or "git push heroku."
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...)
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).
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).
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.
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.
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.