The Key to Understanding PowerShell - on Windows or Linux

I've listened to a few of my Windows-friendly compatriots attempting to explain PowerShell to their Linux colleagues, and it hasn't always gone well. The problem, I think, is that a lot of Windows folks don't actually know why PowerShell exists in the first place. Let me explain.

PowerShell does not exist to automate administrative tasks. Re-read that a few times until it really sinks in. You see, you start going at the Linux guys with this "automation" argument, and they're all like, "yeah, man, we've had that for always." The existence of PowerShell on Linux makes no sense if the point of PowerShell is simply automation. In fact, PowerShell as an automation mechanism also makes no sense on Windows. Keep in mind that all PowerShell does is built on WMI/CIM and .NET Framework; there was nothing stopping you from using those things in the first place. You didn't need PowerShell.

The point of PowerShell is that .NET Framework is a terrible surface for systems administrators. Getting anything done correctly in .NET requires you to write an application of some size, compile it, and run it. .NET wasn't designed with ad-hoc, system-level "scripting" in mind; it's an application development framework. An empty .NET project starts with dozens of lines of code and configuration; that's the bare minimum to even start writing code. For admins, it's too much. Heck, it's sometimes too much for developers, which is why some of them like PowerShell as a ".NET immediate window" so much - they can just bang out a one-liner, hit Enter, and get results.

I'll argue that all operating systems rely on APIs for command-and-control. If you want to tell Windows to shut down, you need an API to do it. In modern times, that API comes via WMI/CIM or .NET, for the most part. In Linux, if you want to configure Apache to listen to a different port, you need an API. That API comes in the form of a text file. I'll also argue that, from a systems administration perspective, all APIs suck. In Windows, you're forced to learn this vast and complex .NET Framework, which is only marginally consistent within itself, and which requires a (relative) ton of code to make do anything. In Linux, you're forced to learn regular expressions and text parsing, along with a bunch of poorly-interconnected command-line tools that have improbable names invented by Dungeons & Dragons geeks in the 1960s and 1970s. "Grep," as an API for systems administration, was never a good idea - it's just what got the job done when your main configuration surface was a bunch of text files.

The entire point of PowerShell is nothing more, nor less, than to wrap a more-consistent, administrator-friendly API around those other sucky APIs. PowerShell is an abstraction layer, and that's it. Do you know how to conquer up a ServiceController reference in .NET, and ask it to restart a surface? Me neither, nor do I care to learn - I'll just run Restart-Service, which does all that under the hood. Do you know how to pull a daemon list on Linux, retrieve just the httpd daemon, and restart it? You might, but I don't, and I don't care to learn that either - I'll run Restart-Daemon (which will exist someday, I swear it).

On Windows, PowerShell doesn't replace .NET. We all know that. It makes .NET easier for an admin to use in the context of administration. On Linux, PowerShell doesn't replace grepsedawk and all the text files - it simply makes them easier, and more consistent, to use for administration. The point of PowerShell is that it allows us to deal in deterministic data structures (objects) without having to be text-parsing experts. It wraps poorly designed underlying APIs into something with a consistent, admin-focused surface. That's it.

PowerShell does not posit that, on Linux, grepsedawk is a bad idea. PowerShell simply suggests that those tools, and their friends, are a lot harder to learn and use than they should be. PowerShell's value-add is not automation - you can do that without PowerShell. PowerShell's value-add is better productivity as you automate, and that's something anyone should be able to wrap their minds around.

About the Author

Don Jones

Profile photo of Don Jones

Don Jones is a Windows PowerShell MVP, author of several Windows PowerShell books (and other IT books), Co-founder and President/CEO of PowerShell.org, PowerShell columnist for Microsoft TechNet Magazine, PowerShell educator, and designer/author of several Windows PowerShell courses (including Microsoft's). Power to the shell!

2 Comments

  1. Good article Don.
    I like the way Doug Finke describes PowerShell as the 'glue', as it interacts with .net. You can use things like C# code to leverage it through PowerShell as well. Brings tools and technologies together.

Leave a Reply