I have taken a break from coding ruby and rails for a couple of weeks to try and get my company’s administration is order. To do this I have been using the sysadmins automation tool called puppet, which is written in ruby, but uses an external DSL, meaning that you don’t get all the power of ruby, just the amount that they let you have.
I actually even went to Belgium last week to a training course run by the company responsible for maintaining the puppet code. And while there I came to the conclusion that I like the idea of having an external DSL… in theory. Because it means that it is tailored to the task at hand, and it is actively parsing the code you write to make sure that it adheres to a set of rules for the task. But like I said in theory this is a good idea. In practice, well being a ruby developer means that I find puppet extremely restrictive. Simple things that I take for granted in ruby (in any programming language in fact) are just not available in puppet. Which is very strange to me, as the company claims to have been around for as long as rails and you would think that in the about 4 years that rails have been around puppet would have matured to a much higher level than where they are. In fact in using puppet I always have a feeling that I am using some outdated version of the code because it just does not allow me to do the simplest of things. For example before version 0.24.5 (or something like that) and bearing in mind that they are on 0.24.8 at the moment, you couldn’t even do
if $variable == something_else
Which means that because I am using ubuntu as my server and the version of puppet that ships with that is older than this, I cannot even do this. I asked on the irc channel about the best way to install puppet and they kept telling me to stick with the distributions copy or create a package for the distribution myself. I am obviously dealing with a bunch of sysadmins here, they never want anything to stray off the beaten path. And the thought of installing myself from souce, nooooooooo, burn him at the stake they cry.
But anyway, I mean come on, for a configuration tool that claims to have been around for so long this is just poor in my eyes. I start to wonder that if it is just because the guys that produce puppet just are very paranoid and just don’t trust people to use the full power of ruby correctly. And if this is the case, it is kind of an insult and we as developers (or indeed sysadmins, which is who the tool is primarily designed for) don’t need to be babied in this way.
Chef on the other hand (which I have no experience with, except for a lot of reading and research that I have done) seems to embrace the ruby (and rails) philosophy more. They give you a tool, written with an internal ruby DSL, meaning that you can do anything that you can do in ruby when writing the scripts, this means that there is not much momr learn for us ruby developers, just some new methods, and it has a top down order of execution, which mean that code is executed in the order it is written in, which puppet isn’t. I mean, why make things more complicated than they need to be? Companies systems are complicated enough, but to then go and invent, what in essence is a whole complex new language (a feature poor one at that), just to manage those systems is insanity if you ask me.
But I digress. I will continue to battle the puppet in the coming weeks and see if I can get it to do what I want. But if it were my choice I would have gone with Chef, it might not have solved any of the bigger problems in any a simpler manner that I am having with puppet, but it would have been a hell of a lot less frustrating to be using a language I know, with rules that I know, and could debug problems within 5 – 10 mins instead of half a day. Oh and I must add that while there is a lot of puppet documentation out there, I find it disorganised, and unclear.I could be reading something and trying to apply it, only to find out through the irc channel that the way I am doing it is deprecated or it applies to another version of puppet.
Oh and just on the off chance I was reading an article in Linx-mag.com, and they just happen to mention both puppet and Chef, which is strange because system automation isn’t even the topic of the article. But here it is for you anyway
http://www.linux-mag.com/id/7348/
And here is what Ezra of Engine yard fame has to say on the subject.
http://brainspl.at/articles/2009/01/15/chef-suck-on-my-chocolate-salty-balls
and
http://brainspl.at/articles/2009/01/31/cooking-with-chef-101
I must admit that I have a basis towards Chef because of its pure rubyness, but then why make life harder than it needs to be. Ruby was made to bring the fun back into development, and it has spoilt me for any other languages, and without it I certainly wouldn’t be a developer anymore. Why? Life is too short. Puppet seems to want to more in the opposite direction to this.
I have heard it said that ruby developers and stuck up and arrogant about their language, we have a right to be, it is a language designed for humans first, not machines.
I seriously don’t understand how so many companies use puppet, but I guess the mind of a developer (especially a ruby one) is far removed from that of a sysadmin. Thank God!
“Chef on the other hand (which I have no experience with, except for a lot of reading and research that I have done)…”
From a reader attempting to make a decision… If your research doesn’t include hands-on then be polite enough to say you don’t have enough information to make an informed decision and don’t pass judgment on something you know little about.
As a programmer you should know that “on paper” and “in action” are two different beasts entirely.
Just a thought.
Thanks for the great links though.
September 10, 2009 @ 10:41 pm
I’ve been using Puppet for 3 years, and a big part of that decision was because it was either Puppet or CFEngine.
I expect the same applies to a lot of other people.
Looking at Chef it seems over complicated for 99% of our needs, where as Puppet is only too simple for about 1% of our needs.
October 9, 2009 @ 4:59 pm
Well in the end we ended up not using either. Puppet is too simplistic, and as a ruby developer it is so frustrating to have to jump through hoops just to do something in puppet that is very easily achievable in ruby. And while Chef has all the power of ruby, its set up is too complex.
We ended up going with automateit, which I as a developer, feel strikes the right balance.
I think I will never see eye to eye with sysadmins that profess that Puppet is a great system to use. Reason being, we are coming from 2 very different view points. I want to get things done in the simplest, cleanest and quickest way possible. A sysadmin, may not know how ruby works and so from their view point the power puppet gives them is a refreshing change to what they are used to. Or they may be fully aware of the power of ruby and are just paranoid that someone well use that power in a negative way on their network, because we all know how paranoid sysadmins are, and with good reason too.
So you see, 1 goal, 2 view points.
But I think everyone should use what works best for them in their situation and provides them with the best balance of automation, speed and reliability for their needs.
Just in my case both puppet and chef get a big thumbs down.
October 9, 2009 @ 5:21 pm
It’s interesting that Puppet’s language is criticised for not being Ruby. Of course, that makes sense when you’re a Ruby developer. Sysadmins, coming from a background of shell scripting and maybe a little cfengine, seem to find Puppet’s simpler declarative language easier to cope with.
The Puppet language is one of the 10 advantages of Puppet over Chef that I’ve listed in my take on the subject:
http://bitfieldconsulting.com/puppet-vs-chef
January 13, 2010 @ 2:25 pm
This is a really fascinating post. Its crystal clear in being from a developer for developers, but because I’d hazard 99% of people searching for “chev vs. puppet” are sysadmins you’re winding up making the opposite of your case to everyone reading. Clearly, as you say, two different mindsets.
As a sysadmin, here’s what I’m reading from this:
- developer setting aside some time “for the sysadmin stuff” because even he started to realize the environment is getting out of control. Usually by the time the devs notice its been on an entropic collision course for months. And usually when the devs just dive in head first they reinvent the wheel so much the result is unmaintainable by anyone but themselves.
- you mention the immaturity of puppet vs. the maturity of rails, which is just such an odd apples-and-oranges comparison it makes me skeptical of where you’re coming from for the rest of the post. As though time is the barometer of product quality. It only makes sense if you live in a bubble world of only using extremely popular software with rapid development cycles and progress. I wish.
- you use a code example for your criticism I didn’t even “get”. I mean, I can sortof assume what you mean but I’d have to fill in a few sentences of human-to-human communication which could just as easily be putting words in your mouth, so I shrug and read on.
- I get that you’re being funny about straying from the package set… but… yea you devs always want to fork everything all the time. We reaaaaaly don’t want to stray from the package set, especially for a systems management tool.
- your trust/paranoia/baby paragraph is jarringly off kilter. sysadmins don’t want a restrictive box to contain zany ruby devs (well, yes we do but in the office more than metaphorically via config management). We just don’t want to have to learn ruby. I know you ruby devs think everyone should learn ruby and that just solves everything, but a.) i’m not a developer and b.) we don’t even use ruby in our environment (where “we” = “most people googling ‘chev vs. puppet’”).
- you conclude you prefer the tool you admit you haven’t even touched! I had an Intro to Logic philosophy professor that was this angry 60-odd year old irish man that would yell INVALID! at the end of proofs. I can hear him now. Its making me flinch he’s so loud.
- your paragraph on chev’s “rubyness” sets off all kinds of “language-X-zealot” alarms. devs always love their particular language (at a particular point in time) but sysadmins aren’t devs. We don’t care about where something falls on the “rubyness” scale. Actually we do, and ideally the answer is “zero”. If my next project on my to-do list is “setup config management so things are more consistent” I sure as shit don’t want step 1 to read “learn to be a ruby dev”.
Now the core job of all sysadmins is to put themselves out of a job. So maybe someday we’ll all be unemployed and rubydevs will instantiate full blown operating systems in an amourphous cloud of just in time abstract high level resources. But right now I’ve got an already-existing LAMP stack, my fibre channel network is all fucked up requiring my primary attention, and and I’ve got new developers starting next week so I have to build a couple dev copies of the live environment anyway. What tool is going to help me do that without requiring those new devs sit around and twiddle their thumbs while I switch careers to rubydev.
Anyway cool post, I’m gonna add your rss and come back, see if maybe I’ve found an arch nemisis.
February 6, 2010 @ 5:15 pm
Haha. I love it.
The only thing I would say about your post is if you would refrain from swearing. Apart from that I am all for free speech.
Also I must admit when I write these long posts they are a reaction of some sort, either to frustration, or joy, or something like that. So what you see in my posts are raw emotion that I am feeling at the time. This may at times skew my point of view but I try to see things from both sides of the fence as much as possible. But hey, I like what I like, and puppet just doesn’t cut it for me.
February 6, 2010 @ 5:52 pm
We haven’t provided pure ruby not so much because of paranoia but because we’re a model-driven system and I’ve had a hard time seeing how we can remain model-driven without a simplified interface.
I think I’ve got it all figured out now, though, which is why the next version of Puppet will support a pure-ruby interface alongside its external DSL.
The model-driven aspects of Puppet really do matter – we have multiple phases in a run, and one of them produces a complete catalog of all resources we’re managing. This catalog is pure data, and can be pushed around to various hosts, version controlled, introspected, etc. Not only that, but it’s actually a graph of the resources and their relationships, so you have even more power with it.
So I think the language isn’t everything – the model matters quite a lot. Else we wouldn’t provide additional languages so trivially.
–Luke (original author of Puppet)
February 9, 2010 @ 5:45 pm
@philip you got it, sorry about that. I too (as you can clearly see) tend to post a touch more emphatically in the reactive moment.
@luke awesome move picking up mdehaan. As an existing cobbler user looking into puppet vs. chef it made the decision for me.
February 10, 2010 @ 2:06 am