I dreaded this day would come. As a recent ex-Microsoft alumnus, and with years of System Center insanity behind my back, I saw this coming, and even heard faint echoes of it in the hallways as I left.
I have deep respect for Jeffrey and what he's accomplished (there's a great video of Jeffrey talking to Linux sysadmins and explaining the genesis of PowerShell, including the insane amount of money we burned before he wrote the bits that actually worked over Christmas break), but the grand (corporate) motivation for sponsoring something like this is more driven towards making sure the MS datacenter management tooling (which comprises trendy things like OMS and System Center) attain minimal mindshare in both the on-premises datacenter and on Azure.
That is not something most people would care about, but Enterprise IT likes having a single hammer for all its nails, and PowerShell's promise is to be the one thing that your garden variety IT sysadmin would love to use to automate every single system in your company.
Ironically, PS is effectively lousy at automation because of its inconsistent error handling and incredibly hard to maintain over time due to constant changes and updates, so I'm curious to see how it will evolve to manage all the different abstractions in the UNIX world (knowing my former colleagues, it will likely follow the OMS route of "Windowzifying" those abstractions and making them "uniform" - i.e., Windows-like).
The underlying issue where it regards PowerShell is not the language itself (although yes, something better, more coherent and with an actual standard library would have been nice, like Ruby or Python). It's Windows.
Windows (the enterprise platform) has always been a hectic patchwork of multiple components (AD, SQL, IIS, etc.) that evolve at their own pace, and PowerShell grew to encompass them not merely because basic automation was an actual checkbox we had to have to be able to sign some hefty deals, but, technically because _none of it had open APIs_. Nor would it be feasible at the time to go back and re-do any of it with proper language-agnostic APIs.
It's very nice to iterate over AD entries and set some fields with a couple of lines of PowerShell, yes. But it's also fundamentally impossible to do so with just about anything else.
Tying it all to the .NET stack (which is still prevalent in everything done internally, because that's what customers invested in) turned out to be a lazy-ass way to ensure we could check all the boxes in terms of automating new things as they came along (mostly - WMI is still iffy). Effective and "scriptable", but essentially still proprietary.
And right now, since my former colleagues are betting the farm on Azure, I expect PS for Linux to become the de facto scripting language for managing Linux on it (it already is, to a degree, since PowerShell DSC already lets you "manage" Linux VMs).
For interactive use, PS was a pain to learn (I was a VMS guy, originally), but, most importantly, it was a nightmare to maintain, because cmdlets would pop up and disappear between releases, change semantics, and were quite often inconsistent among themselves.
I shudder at the level of technical debt would-be adopters will be buying into, and wish them luck.
I have deep respect for Jeffrey and what he's accomplished (there's a great video of Jeffrey talking to Linux sysadmins and explaining the genesis of PowerShell, including the insane amount of money we burned before he wrote the bits that actually worked over Christmas break), but the grand (corporate) motivation for sponsoring something like this is more driven towards making sure the MS datacenter management tooling (which comprises trendy things like OMS and System Center) attain minimal mindshare in both the on-premises datacenter and on Azure.
That is not something most people would care about, but Enterprise IT likes having a single hammer for all its nails, and PowerShell's promise is to be the one thing that your garden variety IT sysadmin would love to use to automate every single system in your company.
Ironically, PS is effectively lousy at automation because of its inconsistent error handling and incredibly hard to maintain over time due to constant changes and updates, so I'm curious to see how it will evolve to manage all the different abstractions in the UNIX world (knowing my former colleagues, it will likely follow the OMS route of "Windowzifying" those abstractions and making them "uniform" - i.e., Windows-like).
The underlying issue where it regards PowerShell is not the language itself (although yes, something better, more coherent and with an actual standard library would have been nice, like Ruby or Python). It's Windows.
Windows (the enterprise platform) has always been a hectic patchwork of multiple components (AD, SQL, IIS, etc.) that evolve at their own pace, and PowerShell grew to encompass them not merely because basic automation was an actual checkbox we had to have to be able to sign some hefty deals, but, technically because _none of it had open APIs_. Nor would it be feasible at the time to go back and re-do any of it with proper language-agnostic APIs.
It's very nice to iterate over AD entries and set some fields with a couple of lines of PowerShell, yes. But it's also fundamentally impossible to do so with just about anything else.
Tying it all to the .NET stack (which is still prevalent in everything done internally, because that's what customers invested in) turned out to be a lazy-ass way to ensure we could check all the boxes in terms of automating new things as they came along (mostly - WMI is still iffy). Effective and "scriptable", but essentially still proprietary.
And right now, since my former colleagues are betting the farm on Azure, I expect PS for Linux to become the de facto scripting language for managing Linux on it (it already is, to a degree, since PowerShell DSC already lets you "manage" Linux VMs).
For interactive use, PS was a pain to learn (I was a VMS guy, originally), but, most importantly, it was a nightmare to maintain, because cmdlets would pop up and disappear between releases, change semantics, and were quite often inconsistent among themselves.
I shudder at the level of technical debt would-be adopters will be buying into, and wish them luck.