It is Imperative to be Declarative

Posted on Posted in blog, technical

In previous blogs (The path to hell is paved with good automation steps and Cover all bases), we have explained how complex it is to automate multi-domain service delivery using pre-defined workflows and lists of static tasks. This is called the imperative way. Most automation scripts are good examples of imperative programming as they have to be executed in sequence. Let’s find out how a different approach invented more than 2 decades ago by computer scientists can overcome this challenge.

The state of desirelessness

For some people, true happiness requires to be desireless. However network automation can benefit a lot from enforcing a desired state. The desired state is a typical feature of a programming paradigm called declarative programming. Long story short, declarative programming consists of defining the end goal. Software developers and DevOps engineers also use the word “intent” or “desired state”. No need to document the sequence of tasks required to reach it as opposed to the imperative approach. For instance, HTML is a declarative language as it does not focus on the low-level details. The focus is about the rendering of the web page. Another example is the once famous configuration management tool called Puppet, a complex automation software. We will address in a future post the limitations of Puppet.

Configuration drift

Avoiding configuration drift is a major benefit of declarative programming. Yet not all configuration management tools offer it by default. Let’s take an example of an infrastructure that is modified on a regular basis. After a while the infrastructure may not be in sync with the original design of the network and IT architect. For instance due to manual changes of a resource configuration. DevOps engineers call this phenomenon a configuration drift. It may happen when your automation does not track and record changes of the resources it has provisioned. This is the case for Ansible. Of course, writing complex YAML playbooks can somehow fix this issue. It also requires to run them on a very regular basis and to interpret the outputs. Such an additional work is once again performed at the expense of time and costs whereas a desired state approach guarantees by default idempotence.

The benefits are obvious when an orchestration engine automatically derives the sequence of steps or actions, taking into account the current environment/configuration. The level of abstraction offered by the intent-based approach enables lower total costs of ownership. For instance, network engineers can swap their underlying resource vendor without re-writing all the automation scripts/playbooks. Lastly, the scope of modifying service catalogs is more contained than when using an imperative approach. This is why it is imperative to be declarative.