More than 11 years ago, Microsoft renamed its fledgling command-line interface with an accompanying language from Monad to Windows PowerShell. The name was new, but its purpose unchanged: Bring the scripting capability of Unix to the world of Windows.
Microsoft technical fellow Jeffrey Snover, the inventor of PowerShell, continues to nurture its expansion as a key automation and management tool. Snover produced PowerShell to help IT manage local Windows servers, but Microsoft has invested resources to develop the tool to run services in Microsoft's Azure cloud platform and Office 365 -- and most recently to control other OSes, such as Linux and macOS. PowerShell is also a prime ingredient for many companies that use DevOps for application deployment. Snover was recently in Boston to discuss the future of PowerShell at a meetup held at Wayfair, where company engineers use PowerShell Desired State Configuration as part of its application deployment process.
Snover is also the architect behind Azure Stack, the upcoming hybrid cloud appliance that will bring Azure into enterprise data centers. Azure Stack was originally scheduled for release toward the end of 2016, but Microsoft pushed that out to sometime in late 2017. Snover said he took his cue to delay the project from the notoriously difficult-to-implement OpenStack, which often requires numerous engineers to deploy and manage.
Snover met with SearchWindowsServer to discuss how to help administrators learn PowerShell and why he thinks Azure Stack is a better alternative for companies that want to use private cloud.
Microsoft appears determined to make PowerShell the de facto management choice for administrators. Why has the company expanded PowerShell to Linux and beyond?
Jeffrey Snover: The model of taking it from Windows-only to cross-platform really has four value propositions -- I like to think in terms of Geoffrey Moore value propositions. Number one is: Any vendor that wants to provide heterogeneous management, both in the cloud and of heterogeneous systems on premises, PowerShell on Linux allows them to have a single platform to manage their full, addressable market. Instead of different sets of tool[s] and protocols with different semantics and different skill sets, you can have one technology to manage your entire estate. We're a management vendor, and so we're sort of doing it for ourselves there.
Second, for Windows admins, PowerShell on Linux allows them to be a hero to their companies by being able to manage more. It's a problem for companies to have the Windows guys and the Linux guys. This allows them to use their tools to expand the things that they can manage.
Third, our ecosystem of partners have invested in PowerShell to do their automation -- companies like VMware -- so PowerShell on Linux for them allows them to take their investment and apply it to all their relative platforms.
Lastly, Linux admins get shell. There's a gazillion shells, but PowerShell on Linux really excels when you get structured data.
Linux is becoming more Windows-like. There is more exposure of Linux services through APIs returning structure objects. So, as more and more of the Linux world produces APIs and structured documents, PowerShell becomes a stronger and stronger shell for them.
Do you see a day when the GUI will disappear completely from Windows Server?
Snover: There is an operating system for different marketplaces. In the cloud, you've got hundreds of thousands, millions of servers. You don't want a GUI anywhere near that. You want that as automated as possible. But then, you have small businesses -- they're going to need a GUI for a long, long time.
People are still intimidated by that command line. What are some resources you recommend to help them get over that fear?
Snover: Don Jones has the definitive starting point with Learn [Windows] PowerShell in a Month of Lunches. The number of people that have started with that and have been successful is great.
Jason Helmick and I did a PowerShell Jump Start series at the Microsoft Virtual Academy ["Getting Started with PowerShell 3.0"]. In PowerShell version 3, we had the critical mass in the language. It's totally relevant today.
Third, oddly enough, is the help. We've spent 30 years teaching people it's a waste of time to read the help, but they should really just stop and actually read the help. It's shockingly good.
Why did Microsoft decide on a pay-as-you-go model for Azure Stack?
Snover: What we tried to do is to make it as much Azure as possible. In Azure, if you use it, you pay for it. You shut it down; you stop paying for it. My success is now coupled with my customers' success. If they can't get Azure Stack installed, I get no money. If they get it installed and they're having problems, I'm not getting money.
Why is Azure Stack an attractive option for an enterprise that might already have a significant hardware investment or its own private cloud?
Snover: We believe Azure Stack is a cloud model and that there will still be a virtualization model. Those are two different things. In a virtualization stack, you can do anything you want. You pick your own hardware. You can have mixed hardware. You can put any management agent on it. Put any security agent on there. You can patch the systems. I'm giving you a set of tools, and then you are turning it into something that people use.
Azure Stack is an integrated system. It's like the cloud equivalent of a storage area network. It comes in, you plug it in and then it delivers services. Storage area networks deliver storage. We deliver [infrastructure-as-a-service, platform-as-a-service] and cloud solutions.
We go in, and we support it.
Now, what about private clouds? Turns out, when you go talk to people, most private clouds are not terribly successful. Organizations build a snowflake cloud. There's no community. You built yourself this little, isolated thing. With Azure Stack, it's Azure.
Why was Azure Stack delayed?
Snover: Public cloud running in your data center -- guess what? That's hard.
The real answer is the code. The code made the call [to delay Azure Stack]. As much as possible, we are trying to be Azure-consistent. Azure services were built for Azure; they were never built to be on-premises. So, we've had to work to get that code in a way it can be delivered on-premises and serve a host at a different cadence.
We've got to have snapshots. We have to have servicing. We have to patch and update. We have to do deployment. We have to take the components that are the same and get them in a position where they can be shipped on premises with a different servicing schedule.
At some point, I became very hardcore. We are going to deliver an Azure-consistent experience. We are not going to deliver a "best of [expletive] luck" experience.
I wouldn't say it was the thing that caused a delay, but this thing is ultrasecure. In Azure, because it's a public cloud, we control the physical environment. Because we control the physical environment, there's a certain set of assumptions that we can make
With Azure Stack, I've got this thing locked down with four layers of network protection.
PowerShell script examples and reference guides for admins
How PowerShell for Linux differs from the Windows version
Azure Resource Manager aims to ease private cloud issues