Channels ▼
RSS

Tools

Other Voices: Why Models Beat Scripting


Erik Troan is the founder and chief technology officer for rPath. Contact Erik at ewt@rpath.com.


My recent post on Why Scripting is Evil 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:

  • 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.
  • Models can be verified and have policies enforced against them.
  • Models have a much simpler testing matrix.
  • Models are invertible; just move back to the old version of the model.
  • A model-based approach supports a high level of rapid change and automation.

All of this assumes you have a reliable way of applying the model to a production machine -- but once you do, it works over and over. You're splitting the what from the how. It's exactly the same idea which lies beneath the Model-View-Controller paradigm, and it's right for exactly the same reasons.

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video