Do you know what a Paradigm Shift is?

Well, it'll take you 5 seconds to google it but here you go:
Paradigm Shift: a fundamental change in approach or underlying assumptions.

The first time I encountered that phrase was with the release of Visual Studio Team Edition for Database Professionals. This excellent VS add-in was the very first tool that enabled SQL developers and DBAs to put their database schemas under source control using an integrated development environment and to validate the schema before deploying it to a server! This was something that application developers had been working with for ages and provided the opportunity for the database to join all stages of the software development life-cycle. The problem however, was that SQL developers and DBAs were not accustomed to using source control, to 'compiling' their code or to 'kicking off a build'. What was needed was a radical some significant upskilling and a complete change of mindset - they needed to start thinking like application developers.

DevOps is to infrastructure and operations guys the same kind of shift in thinking and skills. The things you need to learn are:

• obviously PowerShell - including how to write advanced functions, modules and package management concepts
• Desired State Configuration - including class-based custom resources, composite resources and composite configurations
• Source Control - which should really be Git rather than TFS, if you want to be in with the crowd
• Unit Testing with Pester
• Continuous Integration
• Release Management

...and that is not exhaustive. However, if you are thinking "no way Josẻ!" then just hold your horses dude, it ain't that bad. Just start with PowerShell and slowly build up your knowledge; within a few months you'll be cooking with gas!

As for the mind-shift, well that is really down to you and how adaptable you are to change. This is where I recon most will struggle. Building a pipeline for automation is easy to understand (if not to implement) and difficult to argue against (as anything else must involve repetitive, error-prone manual effort) but continual, frequent releases and relying on open source DSC resources to configure infrastructure! If  all the other stuff hasn't pushed your neurons to the limit then the obvious risk of these two approached may just push you over. But this would be an error in judgement because the risks involved in the alternative are far greater.

Think about it this way, which is riskier: to deploy a large change including months of effort using a mostly manual process that is difficult to repeat exactly or to deploy a small change using an automated, 100% repeatable process? No rocket scientist required.

And as for relying on community based, open source PowerShell resource modules to install and configure infrastructure...ask yourself which is better: to manually install software using wizards that are mostly inflexible and time consuming or to use pre-written PowerShell scripts that are readable, easy to edit and must faster to use?

So far we have used about 10 DSC resources modules to deploy a clustered SQL Server and SharePoint and so far I have found 4 syntax errors in 3 different modules - but the thing is, they are easy to find and to fix and I have the opportunity to contribute to their improvement using GitHub. That is a powerful mechanism for improvement given the hundreds of thousands of PowerShell users there are in the world.