When we think about technology, we often think of it as abstract concepts.   For example, we think of a “telephone”, not a network of transducers wired through hubs and switches that create temporary channels that bridge calls together.  It is natural for us to add layers of abstraction that help us to understand the purpose or use of something.   In programming languages, we saw the rise of object oriented programming – the ability to define an object and then manipulate its attributes.   The Windows operating system is a layer of abstraction that you interact with.   These days, you can accomplish, with scripts (PowerShell), most of what you can do with a mouse.   That brings me to the latest layer of abstraction – devops.   It’s a concept that says that developers and operations join forces and share methodologies for the betterment of the company that they represent.   For example:  With a traditional sysadmin mindset, a systems administrator might click a button every day to accomplish a task.   But a developer would write a program that automates pressing that button to gain efficiency.   So devops is really about applying development concepts to systems administration.  Aside from potential gains in efficiency, there are also gains in consistency, since the code will not forget to press the button – and it will press the button each day exactly the same way as the day before.   Consistent input means more consistent output.   So the task can be considered more reliable.

Sounds great, right?    Why didn’t we do this 10 years ago?

Well, the truth is that in the Windows world, the GUI is king.  But in the Linux world, the command-line is king.   Automation in Linux is much easier to accomplish.  Linux systems administrators have been practicing the concept of devops for quite some time now – it just never had a name.  Microsoft has just in the past several years released tools, such as PowerShell, that allow Windows Systems Administrators to practice devops.    I consider the devops mindset a tool because it is a concept that has a specific function.   The function of devops is to automate, automate, automate.  Like any other tool, there are problems that it is the solution for, and problems where it just does not fit.

So where does devops not fit?   Ok, so devops is all about automation, right?   So naturally, anything that we do not want to automate is something that probably is not something that the devops paradigm is a fit for.   Here are a few examples of things that should not be automated:

• User account information entry – someone needs to type this information at some point.  From there forward, we can automate though.
•  Buidout of the automation scripts – this a tedious manual process that can possibly be partly automated, but not fully automated.
• Image building – I am talking about base images.  It is not that this cannot be automated.  It is that in most cases, building a single image manually is more efficient than building a set of scripts to build it.

Devops is a great way to look at things, and it’s about time that the Linux mentality has spread to Windows.   But as you might already understand by now, the effort required to automate is considerable.  Devops is an abstract concept, just like the telephone is.  Underneath the devops concept are additional processes and procedures that, without devops, would not be required.  If you think of devops as a layer of abstraction, then you will quickly recognize that just like virtualization, or object oriented programming, there is a penalty when applying it.   In most cases, the productivity/reliability gains of applying devops concepts far outweigh the penalty of implementing it, though.

Conclusion

Devops is best applied when the amount of manual work to be done is significantly greater than the amount of work required to automated it.

When considering whether or not to apply devops practices to an IT function, consider if the functional requirements vary too much to be automated, or if the function is used too infrequently to warrant the additional overhead required by the application of devops practices (automation).   Remember the goals.  Improve efficiency, improve consistency, improve reliability.  Prioritize those goals, and then determine if the act of implementing devops is expected to hinder any of them.   If the answer is no, devops does not hinder any of these goals, then go ahead and apply it.   But if devops challenges your most important – top priority – goals, then perhaps reconsider its application.