Declarative vs. Imperative Models for Configuration Management: Which Is Really Better?

As a group of concepts, DevOps has converged on several prominent themes including continuous software delivery, automation, and configuration management (CM). These integral pieces often form the pillars of an organization’s DevOps efforts, even as other bigger pieces like overarching best practices and guidelines are still being tried and tested. Being that DevOps is a relatively new paradigm - movement - methodology - [insert your own label here], standards around it have yet to be codified and set in stone. Organizations are left to identify tools and approaches most suitable for their use cases, and will either swear by or disparage them depending on their level of success.

In terms of CM, it's a given that one particular methodology may work for a company but not for another. However, seldom do differing approaches generate as much dissent as the declarative and imperative models for CM. The recurring debate over which is superior has garnered staunch supporters on both sides and warrants a closer inspection.

Defining Declarative and Imperative Models
Differences between the declarative and imperative models can be summed up in one sentence: imperative focuses on how and declarative focuses on what. In a software engineering context, declarative programming means writing code to describe what the program should do as opposed to how it should do it. One describes what needs to happen; the minutiae for making it so are left to the system. In contrast, imperative programming involves writing code that follows explicit steps to solving a problem, completing a task, or achieving a desired result. It's telling the system specifically how to do something with the expectation that the desired outcome will result.

An example of imperative vs. declarative code. Image courtesy of Puppet Labs.

Imperative/declarative constructs also carry over to IT domains such as CM. In fact, a particular CM tool's approach is greatly influenced by the underlying language upon which it was built (which is in turn either imperative or declarative by nature).

The following is a list of prominent offerings and their respective approaches to CM:

	Declarative	Imperative
	X
		X
	X
	X	X
	X	X

Puppet, for instance, is declarative: the sysadmin describes a desired end state and the tool attempts to reach it. Its domain-specific-language (DSL) is used for creating high-level descriptions of desired server state, as opposed to instructions and actions to be carried out. Manifests-- Puppet files that contain configuration information-- can be used any number of times to achieve the same results. If the desired end state has already been reached, Puppet simply ignores the item in question. Users need only worry about the desired end state of the system to be configured, not the sequence of steps required to get there.

Here's an example of a Puppet Manifest resource declaration:

This entry describes an end state containing a file called /tmp/test123 with the contents "This is a test". If a matching file (and contents) is found on the target system, Puppet assumes the desired end state has already been reached. Subsequently, one doesn't need to worry about the Manifest executing this piece numerous times.

In contrast, Chef (Puppet's arch-nemesis) is imperative. Users define commands and their execution order in configuration instructions called Recipes, which can in turn be organized into Cookbooks for easier management.

Take a look at the following Chef Recipe:

This Recipe checks for JDK 7 on the target node-- if it exists, Chef will install OpenJDK 7. If not, a warning is raised. Note that Chef Recipes are structured as sequential lists of commands, as opposed to Puppet Manifests, which only contain descriptions of desired end states.

A growing trend among CM vendors is to make their offerings open to either model, thereby winning the hearts of both camps. Even tools like Chef that are primarily imperative in nature can be set up in a declarative manner:

In contrast to the previous example, the above Recipe describes a desired end state as opposed to listing a series of commands to be executed.

Sizing Up The Big Boys: How Does Puppet Compare to Chef?

So which model is better for CM? To address this question one needs to qualify for who and what. Also-- given the current buzz level and adoption rate of DevOps, it's no surprise that pundits are progressing in sophistication: conversations around DevOps have evolved from what it is to how to do it. And how to do it depends on who you're asking.

Let's therefore analyze the debate from three perspectives: that of a programmer, sysadmin, and full stack developer.

Passionate about writing efficient, structured, and easy-to-understand code, the programmer isn't the biggest fan of declarative models that employ unwieldy abstractions. He's accustomed to dictating how things should happen with for loops, conditional statements, variables, and the like. The business logic of the software he works on is mostly imperative in nature.

Best Fit: Imperative CM tools like Chef

The sysadmin likes to run a tight shop, and for good reason: if infrastructure goes down, the company screeches to a halt. He's a Bash wizard, proficient in Python and Perl, and prefers using them over learning new languages like Ruby. He prefers the declarative over the imperative model, but is cognizant of the challenges the former has in managing dynamic cloud infrastructures.

Best Fit: Hybrid CM tools like Ansible, or SaltStack

The full stack developer can traverse the stack with ease and loves the idea of abstracting infrastructure to code. A Ruby/RoR ninja, she's a fan of both Chef and Puppet. She can appreciate the merits of each model; to her, either type of tool makes her job of continuously building and releasing quality software faster, more efficient, and less error-prone.

Best Fit: Either model. Puppet, Chef, and SaltStack are viable options.

Note that our programmer could just as likely be a Python pro and thus highly proficient with Ansible (whose modules are written in Python). Whatever the case, matching an organization's IT skills makeup to the appropriate model/tool is a pragmatic approach for determining which is more suitable. If a firm is into traditional software development with programmers at the helm, an imperative tool might be the best fit. A fast-moving SaaS on a schedule of continuous rollouts will appreciate the flexibility and scalability of a well-implemented declarative CM solution. A shop that swears on Ruby and has the expertise to boot may choose to "cook" with certain tools, overriding the model debate entirely.

A key point to remember is that both declarative and imperative models are fallible: the former requires trusting that desired states have been reached (with little means of verification), while the latter requires complicated troubleshooting when things go awry. Both models can be problematic in certain edge scenarios; subsequently, no individual tool should be implemented as the be-all and end-all for CM, regardless of which approach has been adopted. The chosen solution should instead comprise only part of the CM toolchain, with another rounding it out as an overwatch, making sure all CM and automation tools are performing as expected.

GuardRail serves this purpose: by providing total systems visibility through robust scanning, monitoring, and comparison capabilities, our platform bridges the crucial gap between expecting your systems/environment to be a certain way and actually verifying that it meets those expectations.

Try GuardRail for Free

In short, competing vendors vying for mind and market share will passionately champion their offering's respective approach. Though debates around declarative/imperative models take on new levels of intensity and fervor in commercial CM arena, the truth is that many tools possess qualities from both-- albeit they may be based more heavily in one mode. Therefore it's perhaps more useful to think of the declarative and imperative models as a spectrum of possibilities with respective solutions falling closer to either end.

Source(s):

http://searchdatacenter.techtarget.com/news/2240187079/Declarative-vs-imperative-The-DevOps-automation-debate

http://sharknet.us/2014/02/15/automated-configuration-management-language-choice/

http://devops.com/features/approaches-to-application-release-automation/

http://networkenhancers.blogspot.com/2014/10/what-is-difference-between-declarative.html

http://cloudn1n3.blogspot.com/2014/11/from-devops-to-puppet-part-2.html

http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/

https://ifireball.wordpress.com/2015/01/03/comparison-of-puppet-and-ansible/

http://docs.saltstack.com/en/latest/ref/states/ordering.html