What if Ansible used XML for configuration management?
You don't have to go far to find people claiming that one of Ansible's strengths is its "declarative" configuration. Some claim this declarative language is better than, say Ruby (used in Chef) or Puppet's custom language. Now, this may indeed be true, but let's get into the details. What declarative language does Ansible use? YAML. This does not seem to raise eyebrows.
My goal is simple. Next time you see any person or project using YAML as a declarative programming language, I want you to raise an eyebrow. If you do this, then I will be happy.
Let's have some fun. What would people say if Ansible had chosen a different "declarative" language? Pick your favorite. Go on.
Oh, you picked XML? Me too! Let's think about it: what would happen if Ansible went with XML instead of YAML?
Madness. Chaos. People would run Ansible straight out of town! The pain from XML is still too fresh.
This is strange, though, because YAML isn't fundamentally different. Yes, I realize that YAML is easier on the eyes (and soul) than XML, but both are fundamentally languages for data transport, not programming.
Perhaps Rails made YAML hip. Perhaps others have not yet despoiled YAML. I suggest to you that Ansible may have, under your very noses, taken YAML too far. Let me explain.
But back to our thought experiment: Ansible + XML! There is little love lost on XML. Big surprise. In addition to being an unwieldy data format for humans to write without significant tool support, it also has come to embody the idea of configuration-gone-too-far. In order to use XML for logic, one often re-invents ways of handling variables, control flow, iteration, and more. To do so, one must create a programming language. Alas, it may not be a good one.
Here is my point: if you find yourself creating a new programming language, why use data exchange format as the substrate? I have a few guesses.
Guess #1: Perhaps you don't realize that you are creating a programming language. You just went for it.
Guess #2: You thought about using an existing language, such as Ruby or Python, but were concerned about users abusing the power.
Guess #3: You didn't want to have to write a parser for a custom language. You chose a data language (e.g. XML or YAML) because it is syntactically easy to parse.
To comment on the last theory: parsing the syntax is the easy part. Afterwards, you have to build additional logic (that acts effectively as a run-time) that can execute your programs. Maybe this is easy too, at least at the beginning.
Perhaps, to start, you only need a few language features; perhaps only some basic looping. But then what about sorting, conditionals, custom functions, and so on? As your tool becomes more popular, I predict you'll find that your users, which happen to be software developers, will ask for more programming-language capabilities.
Personally, I felt a bit uneasy when I saw Ansible using YAML. This uneasiness became more pronounced when I saw `with_items`. Some might say that `with_items` is a helpful hack given the YAML constraints. That's my whole point: Ansible has invented a programming language (a DSL within YAML), probably without admitting it.
My tentative view is that Ansible is taking an Icarus-inspired risk in using data-exchange language for configuration management. My hunch is that an existing programming language would be better suited.
Thankfully Ansible is not using XML, but that don't let that comfort you. YAML isn't fundamentally better, since it is still a data-interchange format.
I see YAML-as-configuration-management as a problem because there have to be better options. Hundreds, if not thousands, of programming languages have evolved to address abstraction, composability, and readability in various ways. It seems like a shame to fall back on YAML without a very good reason.
Yes, this is a one-sided argument. Otherwise, Ansible seems to be a nice configuration management (and remote execution) tool. As a practical matter, YAML may have been a reasonable place to start.
And please don't tell me YAML is a nice choice simply because it is declarative. It is a declarative data language, not a declarative programming language. There are declarative languages that solve particular problems very well. Some of my favorites are: Prolog, SQL, and Verilog. (I realize that if you made it this far into this rant, I might as well compliment SQL while I had the chance.)
That's all I've got for now. If you have ideas for building an elegant declarative language for configuration management, please get in touch.
P.S. I'm not particularly satisfied with the configuration management tools I've seen. They seem too complicated from a data modeling point of view. There seem to be too many arbitrary names being created. It seems to me that all we need are basic functions that can be called, composed, serialized, and versioned. I certainly don't have it figured out, but I have the impression that no one else has really nailed it either.
UPDATE 9:36 PM: I was wrong in saying "Ansible has invented a programming language (a DSL within YAML), probably without admitting it". Ansible's playbook documentation says that "Playbooks are Ansible’s configuration, deployment, and orchestration language."
