But I can't understand from their site what services/products they provide ? Why do people pay them? Can someone explain it to me like I'm a 10 years old?
The "chef client" is a program that runs on servers, either on-demand or just periodically.
It runs a ruby program called a "chef recipe". Roughly speaking, this program computes the correct configuration for the server, examines the actual configuration, and fixes disparities.
As an example, my recipe might say (in effect) "Apache should be running. The config files should be the lastest versions of package X but the virtual server names have to be rewritten depending which users are hosted on thsi server." The chef client checks to see if Apache is running and the config files are so -- if not, it fixes things.
Information about how particular servers are to be configured may be stored on a separate "chef server". The recipe running on the chef client can read and update the chef server records.
The firm sells the on-line service of hosting a chef server for you, if you like. They would appear to charge in proportion to the number of server configurations you host (judging by the "up to 5, free" freemium).
The firm additionally sells training. I would guess that training is value priced but with discounts for customers who also make a commitment to pay a subscription fee.
It sounds as though all of the code, client and server, is under a free software (but non-copyleft) license.
Notice that they do not make it easy to anonymously download the software from their commercial site.
I would guess / hope that they are also selling support subscriptions which don't involve hosted "chef server" service but do include convenient access to at least mildly warranted distributions along with weakly guaranteed issue report response times (and just general good will).
If the facts and surmises above are correct:
1) They are theoretically vulnerable to a rival that subscribes to them (to get the lastest distributions) but then separately sells the same services for less money. This isn't important because it's worth going to the upstream source.
2) They are theoretically vulnerable to technical staff quitting the firm and opening an office across the street. This would be such a reputation hit for the whole product and team that the stars are unlikely to align that way.
3) At first glance it looks like their hosted "chef server" is a lame lose because it's so technically thin. If they don't already I think the notion is that they tie service subscriptions to preferential access to the data set comprising their "cookbook" (resources to speed up recipe development). In other words, they're main subscription "added value" may turn out to be a walled-garden open source community. That's a pricing challenge, though. If you're hosting the chef server you can charge-per-server-config and that's an OK proxy for value-based pricing (hence, scalable profits -- mostly passive income that grows roughly linearly with the number of server configs hosted). If, on the other hand, you're charging just for nice access to the low-walled-garden customer community and core development/support team: how do you do value based pricing? A customer who is a 5 person small business needs just about exactly as much from you as, say, a division or large department of IBM: they'll want to pay roughly the same amount.
4) They are hugely vulnerable, in my view, to security lapses on multiple levels which, owing to the nature of their business, can have an enormous, immediate, and irrevocable impact on many customers within a short period of time.
Some people who have little technical operations experience will write their code and copy it over to their production server to deploy it. As time goes on, the server needs to be changed; perhaps you need to add a library to extend the function of PHP. More time goes on, and then all of a sudden you need to build out a second web server, identical to the first. How do you do it? The first web server has been hacked and modified, and it's not necessarily trivial to build out a new one.
Opscode uses Chef to create "recipes" that determine everything you want on a box. So instead of logging into the first web server and hacking on it to get it in your desired state, you modify your recipes to add your PHP module there. Then, when you need to build out more boxes identical to the first, you run your Chef recipe and away you go.
What I'm not sure about with Opscode is how they do Configuration Management. If I have three applications on the box, and each of them have independent configuration, does Opscode manage that versioning for me, so that I really can take a new server from nothing and have it up and running with identical versions of my code and identical versions of my configuration files, substituting values in where appropriate? You might want every web server to be identical except for X, Y, Z (maybe you route one web server to one MySQL slave and one web server to a second MySQL slave, for example). I'm not sure what Opscode is doing to make that simple.
I've built out a web interface and underlying architecture for the company I work for to do exactly this sort of thing (and a whole lot more) via Puppet (http://puppetlabs.com). My interface handles rolling upgrades to eliminate downtime and a whole host of other slick things. Our developers do not hand over code to a deployment team; they do their own deployments. I can't recommend Puppet over Chef as I have no Chef experience, but can say that I've been thrilled with what Puppet can do for me.
If you want more information, let me know either here or via email, I'm happy to go deeper if you want.
Disaster recovery is another area where these tools can help. Imagine your database server goes down. Downtime can be really expensive, depending on your application. With Puppet / Chef and an interface on top, you could click a button and have a new box spooled up and your data automatically restored from your most recent backup. Downtime would be reduced pretty dramatically.
Auto-scaling is yet another possibility; if you can detect when you need another server, you could script it so that another server gets reserved and deployed and brought up to snuff. Then, when your traffic drops down, you could release the server.
At some point, it makes sense to either hire a DevOps guy, and / or spend money to have the deployment cycle consistent, dependable, and repeatable.
http://wiki.opscode.com/download/attachments/2883634/Chef-10...