Sure, I was a bit flippant in my post, but I think many of the critics are falling into the common trap of thinking that tools vary in functionality but not in fundamentals. Paul Graham does a great job discussing this in his article about beating the averages; it is about languages but it’s just as valid here. Just like languages, tool power varies considerably.
I don’t just mean tool functionality, that is, the specific features of the tool; I mean the overall power. I think of this variance in power as deriving from difference in models: Tools with low-level models are not very powerful.
For instance, take one of the big differences between cfengine and Puppet; cfengine focuses mostly on managing textfiles, while Puppet manages semantically more powerful constructs like users, services, and packages. Thus, Puppet has higher-level models than cfengine, and if you accept my premise that model power derives from how high-level it is, that generally makes Puppet a more powerful tool than cfengine.
Note that that doesn’t make it more functional — it could be less stable, there could be lots of interesting things it can’t do, whatever.
This is one of the things I think are really lacking in the sysadmin world: High-level models. Do you think in terms of
/etc/passwd, or users? If you think about
It’s not just about how powerful the modeling of the tool is, though, it’s about the power of the models it creates.
Take dependencies and relationships between resources. Are there any sysadmin tools that effectively model these relationships? Of those tools, do any of them make the information exportable to other tools, so you’re encouraged to spend a lot of time developing these comprehensive models? No, not really. Sure, some of the monitoring apps allow you specify basic dependency information, but they’re extremely limited, and you can never export them so they’re useful elsewhere.
What really sets Puppet apart from Cfengine isn’t that it models higher-level resources instead of files, it’s that it allows you to model the relationships between those resources. Puppet’s lowest layer is responsible for the resource modeling (e.g., what it means to be a User on Solaris vs. OS X), but its language handles the high-level relationships between those resources, including how they’re grouped (e.g., they’re all part of the class of resources that makes apache work) and how they relate (e.g., apache should restart if its configuration file changes, and changes to the file should happen before the service is checked).
This is why better tools are so important: The models our tools use set an upper limit of the size of the problems we can comfortably work with. Unless we develop a whole slew of new tools with more powerful models, we’ll be forever stuck thinking about bits on disk.
That means it’s not just about configuration management, it’s about everything on your network. If my configuration management system can’t model the network, then I can’t set up IP addresses or firewall ports; if it can’t model the backup system, then I can’t provide guarantees of data availability or perform automated restores; if it can’t model change, then I have to do all migrations manually.
These models are critical, and they’re all in our heads instead of in our tools. This fact is a severe limitation on our field’s ability to move forward.