Editors Note: This article is part two in a two-part series, published under Creative Commons License. For those that may not know, Erik Troan is one of the original authors of RPM (Red Hat Package Manager). As Erik describes, it seems the declarative approach may extend beyond programming languages and into better system management.

I’ve made a couple of posts recently about Why Scripting is Evil. It has generated some conversation about what a script is and what the alternatives are. One commentator must have anticipated this follow-up post when he said:

"So, somewhere in the process, a script is a necessary object, whether it is explicit (written by the user) or inherent (created through abstraction and based on the user’s description of desired outcome)".

In short, the only way to do away with scripting is to create an application that abstracts the scripting process. Automated scripting would then be based on user descriptions of the desired outcome/goal rather than having the user describe the steps to reach said goal.

This really gets to the heart of how things need to change. I wouldn’t call it ‘abstracting the scripting process’ any more than I’d call a web browser ‘abstracting the network,’ but that doesn’t make it inaccurate.

What is exactly right is his characterization of the ideal state: user descriptions of the desired outcome/goal. We call this approach model driven. What that means is administrators can describe how a system should look, and let tools move the system from whatever state it’s in to the end state automatically.

This distinction between model driven and script driven has been evolving for a while. Tools like Cfengine and Puppet have supported model-driven configuration for years (the Puppet web page describes itself as having a ‘declarative language’). They give administrators a language to (for example) specify the DNS server for a machine; the tools are responsible for knowing how to update the right files on the system in a safe manner. Before Puppet and Cfengine a simple tool called rdist was state of the art for managing distributed systems, and it was entirely script based. You don’t see it much anymore; rdist scripts are much more brittle than the more popular model-based approach.

It’s probably obvious why I like this approach better than writing scripts for each change:

1. Models are understandable. It’s much easier to look at a model and know that it’s correct than to look at a script which implements the model.
2. Models can be verified and have policies enforced against them.
3. Models have a much simpler testing matrix.
4. Models are invertible; just move back to the old version of the model.
5. A model-based approach supports a high level of rapid change and automation.

When I was speaking with a prospective customer last week they described the same idea using slightly different language. They described their goal as being able to completely describe the “goal state” of the system and have “viewers” which could see how a system differed from the goal state. “Controllers” would be responsible for moving a system to its goal state. This is exactly the same idea as model-based system management, just using different language (I’d just about finished reading Neal Stephenson’s book Anathem, so I obviously found the idea of systems moving between points in a Hemn space quite appealing!).

Model-based approaches are a compelling alternative to scripts. It’s the right approach for managing large numbers of machines without employing large numbers of people.