This is an interesting development. I had a good friend and respected local technologist mention this to me the other day, and he wasn’t happy. “Why would they take away features? Just to be ‘consistent’?” Apparently his take on this is that Microsoft is reducing something that was powerful down to a subset of its former usefulness.
Here’s what he was referring to…
In a DSC future direction update on the PowerShell Team Blog the other day, Microsoft announced a new direction for DSC. For those not familiar with DSC, it stands for Desired State Configuration. According to Jeffrey Snover (the architect of PowerShell), PowerShell DSC was the whole reason why PowerShell was invented. We want the ability to define and apply a configuration as a “desired state” to a machine (or machines), and have it applied consistently and, optionally, perpetually. Write up some simple text, and “Make it so.”, with all the benefits of text (source control, among others).
Initially, of course, PowerShell DSC was addressing the configuration of Windows-based servers, but it was no secret that, being built with standards in mind, it was built to support the ongoing configuration of Linux workloads as well. In fact, this really caused two worlds: PowerShell DSC for Windows and PowerShell DSC for Linux, because both had their own unique set requirements, dependencies, supporting frameworks, and allowed commands. Somewhat understandable, sure. Feature parity? Um, no.
So now Microsoft announces “DSC Core”.
“What is DSC Core?”
I’m glad you asked. It is “a soon to be released version of DSC that aligns with PowerShell Core”.
“PowerShell Core? What’s that?”
PowerShell Core is the open-source cross-platform version of PowerShell that runs on Windows, Mac, and Linux. It runs on top of .NET Core…
“.NET Core? What the…”
Yeah.. okay. .NET Core is “a general purpose development platform maintained by Microsoft and the .NET community”.
“Oh, I get it.”
You do? Okay. Well, anyway… back to DSC Core. DSC Core (built using PowerShell Core which is built upon .NET Core) now becomes a common, cross-platform version of PowerShell DSC.
From the “Future Direction” blog post:
“Our goals with DSC Core are to minimize dependencies on other technologies, provided a single DSC for all platforms, and position it better for cloud scale configuration while maintaining compatibility with Windows PowerShell Desired State Configuration.”
So this subset (if we can call it that) will still be compatible with PowerShell, but it won’t have the large numbers of unique Windows dependencies bogging it down.
“What about compatibility? What about the CmdLets? Will they be the same, or will I have to use different ones? What about DSC Resources? Will they have to be recreated?”
All of those and a few other questions (like what to do about Pull Servers) are addressed in the “Future Direction” blog post.
So, “Why would they take away features? Just to be ‘consistent’?”
What do you think? Feel free to discuss/rant/pontificate in the comments section below.
And again, read the full article on the PowerShell Team Blog
Absolutely Full of I.T. 