DevOps: Declarative is where we want to be

If you have ever tried to write scripts to configure operating systems, you’d realize just how hard that is to get correct.

For example, if you need to ensure that your virtual machine has two network adapters, and they need to have a specific set of IP addresses, how do you do that?

[caption id=“attachment_2743” align=“alignnone” width=“461”] Image by Markus Spiske[/caption]

The traditional approach for PowerShell (and similar tools) was to try to write a step-by-step script to configure the network adapters the way you want. But where do you start? Do you write a script to check for any existing adapters and loop through them to try to remove them? Do you try to add the ones you want, and then remove the others?

You’ll quickly realize that you get into very, very complex coding because you might not be able to be sure what your starting point is. Everything has to stay on the path that you prescribed.

And worse, what happens if you run this script more than once?

That’s the problem with imperative code. You are telling the operating system the steps required for configuration.

We don’t want to be doing this.

With a declarative approach, we tell the system how we want it to end up ie: the desired state, and let it worry about how to get configured that way. This is what we want to be doing instead of writing imperative code.

PowerShell offers DSC (desired state configuration) where you describe in a JSON file, the way you want the configuration to end up. A bonus in this approach is that it’s idempotent ie: no matter how many times you run it, you end up with the same outcome.

It’s important wherever possible to be doing declarative configuration not imperative configuration. In later posts, I’ll talk more about how.

2018-02-16