Save a file, change the world
There is something deceptively powerful about saving a file. For most of us, saving a file means we\'re finished with something: a document, a script, a configuration, a report. We save it and move on. But what if that file could recreate an entire environment?
What if the file wasn\'t simply a description of what we had done, but a definition of what should exist? That is where Infrastructure as Code and Desired State Configuration become much more interesting. And it is one of the reasons I\'ve always liked DSC.
Stop documenting. Start defining.
For years, infrastructure administrators have documented environments after building them. They created servers, installed roles, changed settings, configured applications, created accounts, modified permissions, and then tried to document what had been done. The problem is that documentation describes history, however code can describe intent.
Instead of writing: "This server has IIS installed, these features enabled, these services configured, and these settings changed..." a configuration that says: "This is what this server should look like."
That is a fundamental shift in how we should think about infrastructure. The configuration becomes the source of truth. And once infrastructure can be represented as code, something remarkable happens.
We can save it, version it, share it, test it, modify it, and recreate it. We can give it to someone else and have them build the same thing. That little file suddenly has a lot more power than its size would suggest.
DSC taught us an important lesson
Desired State Configuration was Microsoft\'s answer to an increasingly important infrastructure problem: how do we consistently configure systems without relying on someone remembering every step?
The idea behind DSC is straightforward. Define the desired state and let the system work toward that state.
A configuration can describe resources, settings, dependencies, and relationships. Instead of treating a server as a unique artifact that someone manually assembled, we can treat it as something that can be configured from a repeatable definition.
That idea is bigger than DSC itself. It is the foundation of a much broader infrastructure-as-code mindset. Infrastructure should be something that is described. And if we can describe it, we can automate it.
Then along came the lab
One of the places where this philosophy becomes particularly obvious is in lab environments. Building a lab manually is fun the first time. The second time, it\'s work. The tenth time, it\'s a problem.
Imagine needing an Active Directory environment, a certificate authority, Exchange, IIS, a few client machines, networking, and perhaps some additional infrastructure. While you could build all of these machines manually and configure them, that would take a really long time. However, if you can just describe it, then let code build it, that is where AutomatedLab becomes interesting.
AutomatedLab is a PowerShell-based provisioning framework designed to create complex lab environments on Hyper-V and Azure. Its documentation describes everything from single-machine labs to much larger environments containing multiple products and services.
The project supports a wide range of Windows versions and products, including Active Directory, Exchange, SQL Server, Azure DevOps Server, IIS-related scenarios, PKI, and DSC Pull Server scenarios. The really interesting part isn\'t the list of products, though.
It is the model. You write some PowerShell code, save the file to a repo, and an action kicks off. This then becomes the recipe for your environment.
AutomatedLab makes it possible to describe an environment in PowerShell rather than clicking through a collection of wizards. Think about what that means.
Instead of saying: "I built a lab last Tuesday."
You can say: "Here is the code that builds the lab."
Define → Save → Version → Provision → Configure → Rinse and Repeat
Suppose I build a lab today. However, tomorrow I discover that I made a configuration mistake. If the environment was built manually, I might have to figure out what had changed, fix it, and hope it didn\'t miss anything.
A saved file becomes institutional knowledge
This may be the part I find most compelling. When an experienced administrator leaves an organization, a tremendous amount of knowledge can leave with them, sometimes that knowledge is in documentation, sometimes it\'s in scripts, and sometimes it\'s simply in their head. Infrastructure as Code gives organizations another mechanism for capturing that knowledge.
A configuration file can encode decisions that otherwise might only exist in someone\'s memory. It can answer questions such as:
• What servers do we need?
• What roles should they have?
• What software should be installed?
• What configuration should be applied?
• What dependencies exist?
• What should happen if we rebuild the environment?
That\'s more than just automation; it is knowledge preservation.
Version control makes the file even more valuable
Put the configuration into Git and another transformation occurs. Now anyone can see history.
Who changed it?
What changed?
When did it change?
Why did it change?
What did the previous version look like?
We can review it.
We can collaborate on it.
We can roll back changes.
We can build processes around it.
At that point, infrastructure starts behaving like software. Which is one of the defining ideas behind DevOps. The file isn't the environment, which is an important distinction, but the declarative state. The code isn't valuable because it magically eliminates infrastructure, it is valuable because it describes infrastructure in a form that machines and humans can both work with.
The environment is still made up of networks, storage, compute, operating systems, applications, identities, permissions, and data. The code simply gives us a better way to express how those pieces should fit together.
Save a file, change the environment.
And maybe, eventually...
change the world.