Automation when I started in IT was mainly a tool for reaction. If something went wrong, you could quickly write a VBScript to correct something that might of affected hundreds to thousands of systems. As things like Group Policy, SCCM, Zenworks and others came along, you could do the same but it was a different approach. Though these are great tools, over the lifetime of a system or service there are bound to be issues that just were not envisioned during the implementation process. It could be that the operating system is now out of date, the disk/storage layout is no longer relevant, you need to scale, etc. With many of these things you could create a one time processes that would automate the migration to a new environment.
Today, many people look at the new tools like PowerShell DSC, Chef and Puppet and think, that it is just a new spin on what I already had in Group Policy and traditional scripting. I will admit that the shoe does fit if you think about it in that constrained view. What you may not see is that this framework is much more. Yes you can configure one server and keep it in a desired state just like you have in the past, but that is not the point! These new tools are designed for environments.
Think of an environment as a single server running a host of services or a datacenter connected to service providers around the world just running one service. The pieces of the puzzle are exactly the same. Basically what I am saying is, don’t think of a desired state as something that only applies to a single system or category or systems. Think of desired state as it also applies to the environment. The scope of an environment can be anything an application, datacenter, service, production, non-production.
Over the next few weeks, I will fill you in on how to better understand this concept and achieve it no matter what your current environment looks like.
This post will be updated as we progress.