- Thu, May 16 2013 at 1:04 pm #13785
Why do admins have to become PowerShell devops?
I am currently working on an article about the PowerShell poll we recently had on 4sysops and there is one question that follows me already for a while for which I don’t have a good answer yet. When Microsoft’s IT pro evangelist Jeff Alexander claimed that admins have to become PowerShell devops he didn’t say why. I am wondering what exactly changed in IT that requires development skills. So far I see three possible answers:
- Conventional GUI-based system management tools can no longer cope with the increasing complexity and variety in corporate IT. Therefore, admins have to build their own administration tools that suit for their specific environments.
- The demand for development skills in IT has always been there; it is just that Microsoft neglected scripting and focused too much on GUIs. Or in other words: The Linux guys have always been right.
- Nothing has really changed in IT administration that would require more development skills than before. It is just that a few leading Microsoft managers are pushing PowerShell and admins just have to follow.
Do any of these answers make sense? Are there better answers?
- Thu, May 16 2013 at 2:16 pm #13788Timothy WarnerModeratorMember Points: 800Rank: 2
Two things come to mind for me. Number one, virtualization makes it easy for IT departments to spawn an amazing number of servers. It is a lot easier to write a PowerShell script that automates administrative activities across all those boxes at once instead of having to manually “touch” each machine.
Another idea: Microsoft increasingly adds functionality to their server products that requires PowerShell skills. Lync 2010 and 2013, for instance, have many configuration options that are accessible only through the PowerShell interface.
- Thu, May 16 2013 at 5:02 pm #13790
My opinion is that it’s similar to number 2 with a little bit of 1 thrown in. Number 3 is a “hater” position not based in the real world.
The tools have absolutely been there for a while now though with VBScript and WMI (among others). Although not necessarily as robust as PowerShell, the tools were there. The reason they weren’t adopted is simply because many/most Windows admins are hacks (to be blunt and honest IMO) that only know how to click the mouse. It’s surprising how many admins I run into that don’t know the difference between share permissions and NTFS and when/why each is used.
The focus on PowerShell is somewhat new though as Microsoft never strictly pushed the automation technologies nearly as much but in the past they didn’t have a singular focus either until the dynamic datacenter started them on the path to the cloud (both private and public).
PowerShell enables mass administration from the command-line; this is something that *Nix folks were used to simply because there was no alternative and (frankly) they had to rely on because there was no other cohesive or mass management technology.
- Fri, May 17 2013 at 1:14 am #13793
Tim, I avoided the “automation” word on purpose. I will say a word or two about it in my coming blog post. However, I agree that virtualization increased the need for automation.
Your second point appears to support my third option. Admins have to be come devops because Microsoft products now require PowerShell skills. This doesn’t necessarily entail that this new requirement is a good thing for all organizations.
Jason, that most Windows admins only know how to click the mouse appears to be a “hater position” for me. 😉 In my view, real IT knowledge is absolutely independent of the interface type you use. Real knowledge is always about semantics and not about mastering syntax.
My third option might sound a bit negative, but it was not meant that way. I actually believe that great companies do not listen to their clients, but tell them instead what they really need. If Microsoft is convinced that option 1 is correct or will be correct in the future, then it makes sense to force admins to acquire development skills even if most admins believe that they don’t really need scripting or a CLI in their environment right now.
Honestly, VBScript was/is awful. You can’t really compare it to PowerShell which is so much more powerful. The core source of its power is that almost all important Microsoft products fully support it now. This is certainly the main reason why many admins are adopting PowerShell. And of course, if everyone tells you that have to have learn PowerShell to be someone, you don’t have much choice if you want to keep your job.
- Fri, May 17 2013 at 5:22 am #13794Joseph MoodyModeratorMember Points: 1,918Rank: 3
We all constantly hear about the importance of PowerShell (and I don’t deny how useful it is). A primary point that everyone makes is that “Active Directory Administrative Center is PowerShell integrated” and has that nifty PowerShell history viewer.
My question is why haven’t other GUIs made this transition?
- Fri, May 17 2013 at 5:39 am #13795
The ADAC PowerShell history viewer is certainly great. Whenever I learn a new programming language I try to avoid text books as much as possible and learn from examples and by doing instead. We can only hope that Microsoft will add similar features to other products in the future. However, the history viewer also demonstrates nicely that what sometimes can be done with a single click often needs a lot of type-type in a CLI. I wonder how many admins are frightened by the history viewer instead of being encouraged to learn more about PowerShell.
- Fri, May 17 2013 at 6:01 am #13796
@Michael I completely disagree that VBScript is or ever was awful. Just check out the TechNet code repository and see just how much folks used it for and what it could do. It’s simply a tool and in the hands of someone with a little knowledge and a goal, could do anything they wanted/needed — no different than PowerShell. Is PowerShell more “powerful”? Of course, I don’t think there’s any doubt there, but that doesn’t make VBScript terrible. VBScript was essentially built on top of COM and PowerShell was built on top of .Net. You can’t say the P51 was a terrible aircraft because it wasn’t a jet. If anything, it reinforces my point that normal, everyday Windows admins are scared by complexity.
As for the Windows admins being “clicky-clicky”, not a hater position at all — a reality one. I can give example after example of my career working in internal IT, as a contractor, and as a consultant where the simplest, building-block concepts gave everyday Windows admins fits. It’s not an intelligence evaluation, it’s a desire and motivation evaluation — kind of like why my kids at age 5 figured out how to use the TV and cable box remote controls but my mother and mother-in-law still can’t. They simply don’t see at as part of their job and thus don’t apply themselves to learning anything that doesn’t have a GUI. Walk into any Windows IT shop today and ask the everyday admins what they think about PowerShell and most will groan and say they don’t “script”; when they need a script they ask “Bob”. also note that when I say everyday admins, I don’t mean those that attend conferences or participate regularly in forums — those are the top 15-25%.
Microsoft sees this and thus the big push for “unified” tool and approach across all products.
- Fri, May 17 2013 at 6:40 am #13797
Well, I guess that is a matter of taste. When I say that VBScript was awful I also mean this with regard of what was available before the PowerShell times. When .NET came out I quickly moved from Visual Basic to C# and not to VBScript because I didn’t like its syntax and because I found its capabilities rather limited.
As to the “clicky-clicky admins”, I have seen many excellent coders who were lousy admins and I have seen excellent admins who were excellent problem solvers but never wrote a line of code. As I have said in my previous post, mastering syntax alone doesn’t make you a good admin. What is most important is that you are able to abstract from the interface you are using. Typing a PowerShell command is fairly easy, but understanding what it really does is not. In many fields, especially at the higher ranks in IT management you simply don’t need to code and you therefore need no motivation to learn PowerShell. If a CIO has time to write PowerShell scripts he is wasting the money of his company. But obviously a good CIO needs a profound understanding of IT. Thus if some IT pros don’t see it as part of their job to code, they are often perfectly right. On the other hand, there are also certainly many admins who had better learn PowerShell sooner rather later but make a big fuss of it. I think you have to be careful with generalizing.
- Fri, May 17 2013 at 7:09 am #13798
I agree we have to be careful generalizing, but the question was a general one. 🙂
I don’t disagree with any of your points; my point though (going back to the original question) is that IT hasn’t really changed and neither have the admins and that’s the problem. Many (yes another generalization) are content with clicking (sic George Jetson) all day long instead of embracing the spirit of IT, automation, which PowerShell is one very good/excellent tool for enabling.
- Sat, May 18 2013 at 11:57 pm #13811Paul SchnackenburgModeratorMember Points: 1,440Rank: 3
Ok, here are my two cents in this debate (since I think that Jeff Alexander was interviewed by me perhaps when he said that :-)).
IT is changing and I know the word cloud is so worn out its not funny but that doesn’t mean it isn’t real.
Behind Microsoft’s (and other major players in the IT arena) push for PowerShell in every product and the emphasis for PS to be a required skill for administrators in the future is the simple fact that cloud computing models (Private, Public, Hybrid) will change the way we manage IT. Not today for most of us but in five or ten years it’ll be different. And I think the main difference will be the need to understand how to automate and orchestrate IT processes rather than doing them manually over and over again. And the push for PS specifically in all of MS product is simply saying, we’ll give you the same “UI” in all our products (with the same syntax but with different cmdlets).
- Mon, May 20 2013 at 1:30 am #13812
Jason, I do think that admins have changed. According to the poll 44% prefer to be devops. If you asked the same question before the advent of PowerShell, we would have have seen a different result. As a contractor I would be worried now. Admins more and more can do the work for which traditionally contractors would have been hired. 😉
Paul, who knows, maybe one day your interview will serve as a source for historians as the point in time when the new profession of the devop saw the light in the cloud. 😉 Seriously, I agree that the cloud is coming, and it is coming with might. However, I don’t see why the cloud would require more scripting than on-premises computing. The cloud has the tendency to homogenize IT and scripting is mostly needed in uncommon environments.
- Mon, May 20 2013 at 4:16 am #13813Paul SchnackenburgModeratorMember Points: 1,440Rank: 3
Michael, the reason scripting / automation is crucial is that a real cloud relies on standardisation and automated processes. When you spin up a VM in AWS or Azure there’s no person doing that, it’s all scripted and automated. If you build a real private cloud for an enterprise end users will go to a self service catalogue to request hardware devices, software programs, group membership etc etc. Whatever they need to do their jobs. The fulfilment (apart from the review and authorisation by superiors) of each of these request need to be automated by PS / Orchestrator or similar tools. And other parts of the IT department will request VMs or services, again this will be fulfilled in an automated manner.
If I’m hiring an IT person I want the guy who can automate processes and thus add real value to my business, not the guy who’s a real wiz at clicking through the AD Create User wizard. (Silly example but I think it gets my point across).
- Mon, May 20 2013 at 7:12 am #13815
Paul, I absolutely agree that the cloud requires automation. However, the crucial question is who does the automation. The cloud provider or the admins of the organization that uses the cloud services? The point is that in a standardized environment as the cloud all the automation has already been done by specialists who are called developers. Scripting by admins is only required in non-standardized environments because in a standardized environment all organizations share the same “automation code”. My argument is that on-premises computing is less standardized than the cloud. Therefore, scripting by admins, or devops if you will, is more often needed in conventional IT than in the cloud. Thus the rising of cloud computing cannot explain why we need devops.
- Mon, May 20 2013 at 7:29 am #13816
You’re ignoring private clouds though, along with non-infrastructure related automation tasks that effect applications or services not within the scope of hosting company’s control or knowledge. You’re also completely ignoring desktops or any application with more than a trivial number of objects like AD and Exchange.
It basically comes down to this: if you do something more than a “few” times in IT, you should automate it. Anything else is just job security or lack of knowledge. This includes performing the same task on multiple systems (desktops or servers), services, or applications or on the same system, service, or application repeatedly. Automation here isn’t specifically limited to PowerShell or scripting, but it is the one ubiquitous tool available to admins (and always has been in some form or fashion).
Note that “few” is somewhat subjective because there is point where a task is not done enough that it’s not worth automating; however, I don’t think I’ve ever seen a task in IT that if worth doing once, didn’t end up being done more than once with the need for others to be able to perform that task also.
The only reason things weren’t automated was lack of skillset or job security (I’m sure there are other reasons, but I would probably chalk most of those up to excuses and not actual reasons). Automation enables repeatability, delegatability (not a real word of course), tracking, and consistent results — none of which of easy to achieve by clicking around in a UI. Not to mention enabling scenarios that simply cannot be modeled by a UI and/or haven’t been envisioned by the UI designer. UIs for all their capability, limit what admins can do and often lead to false assumptions of a products capabilities or underlying functionality.
None of this has changed at all. IT is and has always been about automating processes. We have always dealt with multiple systems, services, and applications.
PowerShell is just the latest wave of automation that doesn’t just up the ante, it does truly revolutionize how to automate tasks. It is also nearly universal which really adds to its value and worth.
- Mon, May 20 2013 at 7:59 am #13817
Jason, I am unsure if I get your point. On the one hand you argue that nothing has changed in IT and on the other hand you mention things that have changed like private clouds in favor for your position. I think I made it clear that we are NOT talking about the need of automation. We only discuss whether changes in recent years INCREASED the need for automation or not and if we need more automation now then what exactly are the reasons.
- Mon, May 20 2013 at 8:10 am #13818
Yeah, I know, I’m jumping around a bit.
Some things, like public clouds have increased the visibility (not need) for scripting/PowerShell skills. Private clouds, simply because of the marketing blitz and focus by Microsoft have also increased this visibility — it can be argued though that private clouds are just the evolution of what we should have been doing in datacenters all along though which is part of my point — nothing has changed. The need has always been there, it’s visibility has just been ratcheted up by all of the talk of cloud lately. Clouds don’t specifically do anything new though, they are just a formalization of what we’ve always done. And of course, clouds have nothing to do with desktops where repetitive tasks have always been the norm.
So, my point is, it’s all perception and the need has always been there. Folks in IT just haven’t applied themselves to taking advantage of the tools in front of them. Desktop Deployment is a great example of this also. Ever tried to deploy 10,000+ desktops with custom settings and a dynamic? That challenge has been there for a decade at least. To your point earlier though, Microsoft has never pushed VBScript as the end all be all like PowerShell because it really wasn’t the end all be all — PowerShell is really close though and so the visibility for this need (which has always been there) has simply gone to a new level.
- Tue, May 21 2013 at 2:37 am #13828
Jason, I agree that it is mostly a matter of perception and nothing fundamental in IT has changed that would require suddenly more scripting than before. Where we disagree is that we have to script to automate IT tasks. I will explain my view in detail soon in a blog post.
- Mon, Jul 22 2013 at 3:52 pm #14824
It’s fine to allude to some forthcoming argument about using GUIs to automate. Unfortunately it does nothing to address the point that using a UI limits you to the intent of the GUI designer.
GUIs also have the additional handicap of being product specific. Learn a GUI and you’re set, until it changes, or you need to learn a new GUI. Learn how to use powershell well once, for any product, and then you know it for all the products that use it. PowerShell is a flat surface for working with every Microsoft product and for a host of third party products.
I agree with Jason that the fundamental requirements haven’t changed, using an interface like PowerShell for windows 10 years ago would have been just as useful as it is today.
I would add that PowerShell brings even more advantages than automation, PowerShell is a powerful scripting language and an amazing tool for automating processes. Beyond that it is a simple and effective way to learn every product that supports it. If I’m using VMWare, Hyper-V, UCS, NetApp, or SCOM I always use PowerShell. PowerShell provides a much richer experience than a GUI because it forces you to learn the fundamental nature of the product you’re working with. It also makes it easy to learn any new product, all cmdlets share a common syntax and a common help structure.
I’m sure you can agree that GUIs empower people without requiring them to necessarily understand the product they’re working with. PowerShell, while intuitive, requires you to know exactly what you’re doing before you’re able to do it. No wizard means no fumbling your way through a product.
Just as an add in here, I am saying that PowerShell requires a more in depth understanding of a product and also makes it easier to learn new products. By exposing the underlying APIs in Windows and other products to admins PowerShell demystifies the way OSs and applications interact.
- Tue, Jul 23 2013 at 6:50 am #14825
this post is also reply to your comments (1 2) in the blog. You are right, you don’t get to heart to my argument if you don’t understand how you can automate with GUI tools. Perhaps you get a glimpse of what I mean if I ask you some questions. Do you agree that if an admin deploys a drive mapping to a few hundred machines with Group Policy that he automated an IT task? Do you agree that if an admin installed Office on a few thousand computers with Configuration Manager that he used a GUI tool to automate an IT task and that he did it in a much more efficient way than if he used PowerShell for the task?
I agree that it is an advantage of PowerShell that you have a similar interface for different products. However, the advantage is not as big as you think. Of course differences exist between different products. Just because you can manage Windows with PowerShell, doesn’t mean that you manage Exchange. Moreover, GUI tools tend to have similar interfaces too. For instance, if you learned to use one mmc snapin you can quickly learn how the others work. Thus GUIs are not as product specific as you think.
You are right, if a new PowerShell versions comes out the old ways usually still works. Nevertheless, IT pros still need to learn about the additions. I don’t think that new features are just for simplifying PowerShell. Usually they improve the flexibility of the interface which is good. However, it also means that IT pros need additional time to learn about the new features. And you have to add this time to the time they need to learn about new products. Learning a new GUI is usually much faster than learning about a new PowerShell version.
I totally disagree with your view that you understand IT better if you work on a CLI. This myth is even older than the PowerShell automation myth. We had the same kind of discussion with Linux geeks who claimed that they know more about IT just because they can do everything without a GUI. This false view probably stems from the fact that if you work with a CLI you have to inform yourself first about the command you are using because you can’t guess what parameters are available. In a GUI you can just click a checkbox and see what happens. This appears to be easier and because working on CLI is therefore more difficult, it means that CLI admins are smarter and know more about IT. Nonsense! I can just copy a command from the web without really understanding what it does.
The truth is that the additional time you need to inform yourself about the correct syntax of a CLI command could be used to understand more about the semantics of the task, that is, about what is happening in the background. Thus a GUI admin who invests the same amount of time as a CLI admin to understand an IT task will know more about the task in the end than the PowerShell geek because he had more time to focus on the semantics.
Real IT knowledge is not about syntax but about semantics. Just because you mastered the syntax of a programming language, doesn’t mean that you know anything important about IT. A parser can perfectly verify that the syntax in a program is correct, but of course the parser has not the slightest idea of what the program does and has therefore no understanding of IT. The interface or the language you use to manage IT is totally independent of your understanding. Just because you are an English grammar expert, doesn’t mean that you are able to say intelligent things (except about English grammar, of course). The understanding of IT processes happens at a much higher and abstract level than on the syntax level of a PowerShell prompt.
I totally agree that PowerShell gives you are much better user experience than working with a GUI. And I think this is the main source of the PowerShell automation myth. An admin who enjoys working with PowerShell has to justify his positive emotions when a script finally does what it is supposed to do. The problem is that you can’t tell your boss how great your user experience is with PowerShell when you want to have more time for coding. So you tell him that you could automate a certain task. If your boss has little practical experience in IT management he will admire you for your automation skills. However, if he has a good overview of his field, he will tell you to automate the task with a tool he has used before. If he is nice he won’t tell you that the tool will do the job probably more reliably because it has been created by a professional developer and that it will cost your company only a fraction of the money as if you spend weeks with manually writing a script instead of automating the task immediately with the GUI tool.
- Tue, Jul 23 2013 at 2:26 pm #14847
I see you making the following arguments in your post, please let me know if I have correctly surmised your points before I go making counter arguments:
1. Applications provided by third vendors are superior in quality than in house automations
2. Applications provided by third party vendors are cheaper than in house automations
3. The similarities between the various application management tools in powershell, what we call cmdlets, modules, and the various system components we have access to, do not provide a significant advantage in learning a new product compared to a GUI
4. Learning new powershell versions is a cumbersome/time consuming task and it is easier/faster to simply learn a new GUI
5. Learning to administer through powershell at a minimum does not provide, or require, a deeper understanding of the System/OS/Application being administered
6. Learning to administer a application through powershell is so cumbersome/time consuming that investing the same amount of time in learning a GUI will provide a deeper understanding of the System/OS/Application being administered
7. Learning the Syntax of PowerShell does not help admins gain a holistic understanding of the OS/Application being managed
8. Running an IT environment through the use of third party tools and built in GUIs is ultimately less expensive and more efficient for an IT organization
I disagree with these arguments but I’ll wait till you confirm that I’ve gotten your key points before continuing. I’m worried about creating a “straw man” type situation here by unfavorably framing your position.
- Tue, Jul 23 2013 at 3:27 pm #14848Mike KlineParticipantMember Points: 0Rank:
Very good discussion that I saw talked about via twitter (Jason Morgan/Michael). I think powershell is important but I’ve seen some powershell trainers/MVPs make statements about admins being out of work in 5 years or working at McDonalds in 5 years if they didn’t learn powershell. That was two years ago and I have a hard time believing that will happen.
What I see happening on the ground is that the vbscript/scripting folks have taken to Powershell and are still “the scripting guys/gals” They have very secure jobs and are valued. I haven’t seen this new rush to learn powershell.
I’m also in a part of the job sector where someone can get 120k/year job based on the right security clearance #Snowden/NSA so maybe the passion and willingness to learn is not as great in the sector I’m in.
I also know a few very smart Microsoft senior PFEs in platforms/AD that are at the beginning/intermediate stages of powershell. They are no where near as good as GoateePFE for example. Put those guys in front of any Active Directory problem and it will be fixed. I’m talking about some of the biggest most secure networks on the planet. I can’t see how they will be out of a job. Again powershell is important but it is not all there is. I don’t care if you can check AD replication via a GUI/repadmin/powershell…you still have to know what it means and how to fix it.
- Tue, Jul 23 2013 at 3:44 pm #14849
I think that’s a great point and there is definitely some amount of overhype in regards to PowerShell. It is absolutely not the be all and end all when it comes to IT administration. That being said it is certainly a force multiplier, team your powershell expert up with your expert for any of your products and you’ll end up with a fantastic suite of tools and reports to keep that product working smoothly. You’ll also find it becomes easy to rapidly deploy solutions to problems once you’ve determined your solutions.
I don’t think powershell knowledge is a replacement for all other IT knowledge, that being said I think automation tools like powershell do put a downward pressure on the number of IT personnel required for a given task. I work in a Managed Services Organization and we use PowerShell, System Center, and other automation tools to reduce the man hours required to run customer equipment.
- Wed, Jul 24 2013 at 3:49 am #14850
Jason, 1, 2, 3, 7, 8 express more or less my view. The others are wrong in my opinion. However, all statements don’t capture the core of my argument which is about the PowerShell automation myth. This is my argument in a condensed form:
- One hast to distinguish between automating IT tasks and building tools that allow you to automate.
- The interface type (CLI, GUI, HTML) says nothing about the automation capabilities of a tool.
- Specialists (developers) can build more reliable automation tools in a more cost efficient way than hybrids (devops).
- Software companies can build automation tools at lower costs with better automation capabilities than in-house developers because they sell those tools to many organizations and all those organizations therefore share the developing costs.
The rest of the discussion only takes you away from the core of my argument. I am not criticizing admins who like to work with PowerShell. On the contrary, I believe all admins should learn PowerShell. PowerShell is a great scripting language and a simple script can often help solve a little automation problem.
I am criticizing Microsoft of focusing on an old-fashioned technology (CLIs) instead of building innovative new interface types. As soon as post PC devices are mature enough to also replace PCs in corporate IT, the whole Windows platform is in danger. Hybrids will drive the costs especially in small and mid-sized companies. Sooner or later some organizations will wonder why they suddenly need so many expensive in-house developers (devops). Those companies will be the first to completely move their whole IT to the cloud. If the end user devices run Android or iOS, it won’t be Microsoft’s cloud and won’t be a PowerShell driven cloud. Microsoft might then share the fate of the once mighty UNIX companies who failed to see that the future belongs to intuitive to use interfaces.
Mike, I agree. I believe PowerShell is one of the best things that Microsoft created in the last few years. However, they are now exaggerating the importance of PowerShell as the main administration interface. I also don’t think that it will make admins jobless who don’t know much about PowerShell. The Microsoft ecosystem is still healthy and third party vendors step in and offer the GUI automation tools that allow those small and midsized organization who don’t fall for the PowerShell automation myth to keep costs down. Those admins who have a good overview of the available automation tools in their niche can easily compete with the scripting guys. But I also think that some scripting skills are helpful to get a better pay. And for many administration tasks you simply need now at least some basic PowerShell knowledge.
It is all a matter of balance and I believe Microsoft has lost balance in this area. However, Microsoft has demonstrated several times that they can change course just in time to stay ahead of competitors. I am positive that it won’t different this time.
- You must be logged in to reply to this topic.