Unless you’ve been living under a rock for the last couple of days, you already know that Microsoft announced last Thursday that the shell/scripting language formerly known as “Windows Powershell” is now supported on Linux and MacOS and that Powershell has been open-sourced. And for days, thoughts of “how can I use this?” or “I wonder if ‘x’ will be supported” have been flying through the minds of every system architect as we internally grapple with the possibilities of what could be, while at the same time trying to understand Microsoft’s motivation for this radical change.
Only the change isn’t so surprising if you think about the changes that Microsoft has been making leading up to this announcement. Separating Powershell Desktop Edition and Core Edition in WMF 5.1. Announcing SQL Server on Linux – after all, IT professionals are going to need a way to administer that SQL instance and it isn’t going to be through a GUI. Supporting Powershell on Linux seemed like a logical next step.
But it is likely just a step along the road to heterogeneous system management. Microsoft Technical Fellow and Powershell inventor Jeffrey Snover isn’t at all secretive over the fact that the vision is built upon Microsoft’s Operations Management Suite (OMS), a suite of automation and management tools that needs to be able to configure, control, manage, monitor, and self-heal a workload that runs anywhere and on any operating system.
From the perspective of a system architect that isn’t typically on the bleeding edge of technology, I am still extremely excited over this announcement. Why? The possibilities seem endless. For one, applications that run on either Windows or Linux or a combination of the two can now be configured by the same language, or maybe even the same set of well-designed scripts. Second, the possibility of using Desired State Configuration (DSC), or third-party tooling such as Chef or Puppet in conjunction with DSC, means I can keep *all* servers in compliance with their configurations using the same tooling. Third, what Devops engineer wouldn’t love having spent a few years learning a scripting language like Powershell only to have its reach extended to other platforms? This change invariably makes us more valuable to the company by being able to take on additional management responsibilities by using the skills we already have. It can then lead to even more cross-platform learnings and opportunities. I definitely plan to learn more about Linux and how I can help build cross-platform tools. If you have similar interests, here are some great resources to get you started!
https://www.pluralsight.com/courses/essential-tools-red-hat-enterprise-linux
https://www.pluralsight.com/courses/linux-networking-advanced-lfce
I haven’t even scratched the surface of thinking about all of the ways I want to take advantage of Powershell on Linux, and I have lots of exploring to do to find out what can or can’t be done – but the energy of the entire Powershell community over these changes certainly carries over to me as well. I’m excited to find out what is possible, to build what may not have been possible, and to contribute back to the Powershell community. So kudos to you, “new Microsoft”, for energizing the entire community of Powershell enthusiasts. I can’t wait to see what’s next.
Come join us at @DevOpsDaysDFW and hear Jeffrey Snover in person as he gets excited talking about this announcement and all the awesome things Microsoft is working on to embrace the DevOps community. https://twitter.com/DevOpsDaysDFW/status/768134335895592960
The future is going to be quite interesting in that regard Missy. Breaking more barriers between the Operating system with the push MS is doing with Nano server (can only managed by powershell) and containers is going to eventually lead, imho, to a best of breed OS, a UniKernel, taking the good of both worlds towards a full cloud world, so the OS will no longer be a restriction to the tools we use to achieve the task. In that sense I would recommend you take time to learn ansible, the younger cousin of puppet and chef but, again to my view, the better solution to config managers (even though chef is somewhat more loved by MS). I would even go bit further and foresee ansible or ansible-like framework done completely in .net core and thus powershell.core that will be run on a windows server to manage Linux servers using ssh. To overcome one of puppet/chef biggest limitation of needing a Linux server to run the server part even if I have a fully windows network for example.
As fir Linux learning, being a windows admin and devops enthusiasts and practitioner for a long while, I’ve always endorsement investing time in learning Linux on the side just as means to understand the ecosystem, to see what’s out there and what I can use to help my employers get the best results. Its good to see some of that investments paying off. With windows 10 now offering the bits of Ubuntu I’d also recommend investing time in that distro, as well and on centOS. But to not get overwhelmed, use the same methods we have in devops, start small, take one small part, learn it, the build around it.
I’d recommend SaltStack over Ansible. 😉