PowerShell: A Curse in Disguise
I rarely think of technology as a problem, as most of the time people or processes are usually the root of organizational concerns. Many times will developers blame technology for being badly documented, or testers blame developers for not writing proper code, or database administrators blame IT for not having enough memory on a server. But there are exceptions; some technologies can become severe burdens on an organization, and PowerShell, in my opinion, could be one of them. But as you will see later, perhaps there is nothing wrong with the technology itself.
Before digging into the problems PowerShell can cause, I will start with some of the benefits. First and foremost, PowerShell is a scripting environment with powerful capabilities allowing IT organizations to program their environments, such as managing server configuration, cloud deployments, software release, provisioning, security and more. While scripting was available before, PowerShell enables enterprise automation to a level never achieved previously. And as a result, PowerShell has become a de facto standard in the Microsoft space for larger IT organizations.
However PowerShell comes at a cost. Not understanding the downsides of PowerShell can spell disaster in the future, and even increase IT operational costs in the long run. Here are the top three issues I see with the use of PowerShell in larger IT organizations, followed by thoughts on how to minimize their impact.
1. It's a programming language too
PowerShell is not just a simple scripting technology; it is almost a full-blown programming language, in which you can create objects, call methods, include other scripts and more. While not as powerful as .NET or Java for example, PowerShell still allows you to tap into complex operations and access the entire .NET stack. What this means is that people that code in PowerShell need to be well versed in programming in general; not just simple scripting, or you risk having hundreds of isolated PowerShell scripts laying around created with a copy and paste mentality, increasing your maintenance cost significantly over time.
2. It's for IT admins, not developers
This is another important issue, compounded with the first one: since PowerShell is a scripting language, it's not powerful enough for developers, and usually leaves IT with the responsibility to build and maintain these scripts over time. And developers don't usually understand the underpinnings of infrastructure, such as Active Directory configuration and so forth. As a result the part of IT that builds and maintains PowerShell scripts has virtually no prior training or experience in proper software development practices that can take years to fully understand, such as code reuse, object modeling, software encryption, error silencing and/or trapping, eventual consistency, asynchronous programming and more. This typically leads to under-performing and sometimes poor quality PowerShell scripts.
3. Software Development Lifecycle
Last but not least, and possibly more important than the above two points, PowerShell scripts become programs that need unit testing, proper source control, regression testing, refactoring, and in some cases, yes... design. Treating PowerShell as purely a scripting technology, that as a result does not deserve proper software development guidelines, is a recipe for failure for larger organizations.
So how do we fix this? It's actually rather simple. IT Managers need to start thinking that they are becoming a software development organization, too; perhaps not in the sense of building business applications, but certainly from the standpoint of generating lines of code that need to be reused over time, securely, and with quality.
If your organization is large enough to use PowerShell extensively, and you are not convinced your IT organization is not writing code, simply ask yourself "how many lines of code do we maintain in PowerShell?" And if you can't answer this question within the next 30 seconds, you know you have a problem. Treating your IT organization like a software development group will enable you to begin the transformation needed to address all the problems outlined in this post. This means starting to think in terms of software repositories, hiring staff with prior formal software development experience, training existing IT staff with the basics of software development and using tools and technologies that enable you to manage your scripts. Sorry... your code.
About Herve Roggero
Herve Roggero, Microsoft Azure MVP, @hroggero, is the founder of Enzo Unified (http://www.enzounified.com/). Herve's experience includes software development, architecture, database administration and senior management with both global corporations and startup companies. Herve holds multiple certifications, including an MCDBA, MCSE, MCSD. He also holds a Master's degree in Business Administration from Indiana University. Herve is the co-author of "PRO SQL Azure" and “PRO SQL Server 2012 Practices” from Apress, a PluralSight author, and runs the Azure Florida Association.