Follow me!

Connect

From my experience in IT, mainly in what we call IT operations or more specifically platform Engineering, there’s an emphasis on some noble design principles such as reliability, resiliency, high availability, monitoring, MTTR, MTBF and so on, but something is missing.

None of them should be ignored, obviously, but the capacity for change is often overlooked. I’m convinced it should be a core design principle, re-evaluated for each change, especially for automation architecture.

As I was (and still am) working on a post to explain What’s happening to DSC, I found it was necessary to explain the context around it, or at least my interpretation of it.

This is from a traditional IT Infrastructure point of view, so only looking at what would a traditional IT Pro see within Microsoft’s offerings, communication and especially in the PowerShell ecosystem.

It’s meant to help understanding the changes in products (especially DSC), and the impact it may have on your day to day job, by looking back at what happened in recent years.

Another common challenge with DSC, is how to compose DSC configurations.

People have seen the trick of having a Configuration, and the following code within:

This is a good way to get started and works well for small-ish configurations, but it gets out of hand pretty quickly, as it’s hard to read all the if statements and their content. Some variant of this are using Where clauses around the Node expression.

I’m writing and using a PowerShell module called “Datum” to manage DSC Configuration Data, and raise cattle at work. This is a write up to explain the problem, and why I’m writing it.

I assume you already know a bit about Desired State Configuration, but if it’s new to you or vague, go grab yourself The DSC Book by Don Jones & Missy Januszko, which packs all you need to know about out-of-the-box DSC, and more.