I have been touring several countries over the past few years trying to promote good DevOPS practices for SharePoint and Office 365 admins when it comes to writing configurations for their environments. Every time I do a presentation on this topic, I am amazed at just how little understanding of the basics concepts of the topic there is out there in the field. Folks, in the DevOPS world, everything is represented as code! Infrastructure-as-Code, Documentation-as-Code, Configuration-as-Code and even our Continuous Integration and Delivery pipelines are coded as code (with YAML).
Let’s forget about the actual technology we are using for a second. Configuration-as-Code involves you writing a definition of how you want your environment to be configured. Then automated processes will make sure that this definition is applied onto your environment. It doesn’t matter what tool you are using for Configuration-as-Code, the underlying idea is this, write the definition of how you want your environment to be configured, not the steps you need to take to bring it in that Configuration State. For example, if you want your server to have 2 Inbound Firewall Rules, one on port 80 and one on port 90, you don’t write a script that calls into functions that will create those rules (e.g. New-NetFirewallRule); Instead you write a definition that represents the end goal:
Ex:
- FirewallRule Rule1
{
Name = “Rule1”
Port = 80;
Direction = “Inbound”
}
FirewallRule Rule2
{
Name = “Rule2”
Port = 90;
Direction = “Inbound”
}
By writing this Configuration-as-Code “Definition”, the tool you are using will automatically take care of creating these two rules. You don’t need to know of care how it does it under the hood. Truth is that it’s probably going to call into that New-NetFirewallRule under the cover. But remember, you don’t care! All you need to do is write the “story” about what you want the end goal to be. It doesn’t matter how often you tell your environment to apply that definition, every time you apply it, it will bring the environment in that exact state. If we compare it to the traditional way of configuring environments (we refer to it as Imperative code), this does not apply. Let us once again take our previous example with the 2 Firewall rules. If instead of using Configuration-as-Code, I have a script that calls the New-NetFirewallRule function twice to have the rules created, what would happen in the case of a Configuration Drift? Once again, if a user in the organization changes the rule on port 90 to be outbound instead of inbound. Simply re-running our initial imperative script will have no effect in making sure the environment goes back to matching our definition. It will attempts to recreate the two rules and it will error out because the rule on port 80 already exists and because there is already a rule on port 90 defined (even if it no longer matches the definitions for its outbound/inbound direction).
Now, you may be wondering why you would even need to bother with Configuration-as-Code if your organization already has a set of scripts they developed back in the days that do the job. That is a valid question, but the truth is that Configuration-as-Code is MUCH more than just being about configuring an environment to be matching the definition you provide, it is about making sure that you environment stays configured based on it. This means that if a configuration drift happens, your Configuration-as-Code engine should be able to, first detect it, and secondly act upon it. If we take our previous example with the two firewall rules. Let’s say a user in you organization goes onto the machine and deleted the Inbound Rule on port 90, this means that your environment is no longer configured according to your definitions (Configuration-as-Code). This is a Configuration Drift, and your tool will detect it. Configuration-as-Code tools do frequent consistency checks, meaning that on a regular basis, they will do a “self-introspection”. They basically will take your Configuration-as-Code definition and ask themselves, am I still configured in a way that matches that definition. They will analyze their current configuration, and if they realize that their current configuration doesn’t match the definition, then a Configuration Drift is detected!
In the Microsoft world, our Configuration-as-Code engine is name Desired State Configuration and it is included inside of PowerShell. This means that the moment your server or machine has PowerShell installed on it, it can leverage Microsoft’s Configuration-as-Code engine (needs PowerShell 4.0 or above). Desired State Configuration is very often referred to by its acronym, DSC. Desired State Configuration is interchangeable with the term Configuration-as-Code in the case of Microsoft. The service that regularly does a self “introspection” of our environment to make sure it is still matching our desired Configuration Definition is named the Local Configuration Manager. You may stumble upon information material that refer to it as the LCM. It is the core engine of Desired State Configuration at Microsoft, but it is nothing more than a services whose sole purpose is to bring a given environment in a configuration state that matches whatever configuration you sent its way.
Bringing the focus of the discussion back to DevOPS now. Configuration-as-Code is core to any IT Admins DevOPS processes. Let’s step back for a minute and consider the following scenario. Let’s assume you are the admin of an environment in your organization (say an Office 365 tenant, or an on-premises environment). If a developer walks up to you and tells you I need a new Search Managed Property to be setup in Office 365 for my new piece of code to work, how would you proceed? With Configuration-as-Code the answer is easy! You simply update your Master Definition to include that new Search managed property and save that file. The your Configuration-as-Code engine will automatically pick up that updated definition and make sure that your environment is brought in a state that matches it (e.g create that new Search Managed Property).
The goal of this article was to introduce you folks to the concept of Configuration-as-Code in general. For the past two paragraphs I’ve been talking about Microsoft technologies, but really the goal here is to introduce your folks to the larger concepts. I couldn’t care less what technology you use to manage your environments’ configuration as code…as long as you do it in an efficient and managed way!
