Mike Vizard recently authored a very interesting article “Rethinking Patch Management in the Era of the Cloud” in IT Business Edge. As a patch management software provider, we want to share our perspective.
In the article, patch management automation is positioned as if it is a real possibility. And, when selling a software solution to C-Level executives, this positioning sounds fantastic. What manager wouldn’t love to automate a process that has taken a huge investment of time and money in the past? In this period of tight budgets, automation sounds like the answer …
But for the actual IT professionals who are down in the trenches doing the work, these words are the butt of many server room jokes.
We completely agree that patch management is vitally important to any organization and is only getting worse with the growth of custom and third-party application updates; however, automation is not the answer. Let’s also make sure we are on the same page on what automation means. The software company quoted in the article has a tagline that says, “let us patch you servers’ auto-magically.” To us this means there is some defined intelligence which does things without human intervention -- the ability to schedule a task is not automation. What consumes a large chunk of engineers’ time is watching for when new patches are released, and then researching what are all the various data points needed for a patch: e.g., Where are the installers/updates? What are the dependencies with other applications or previous versions? How do I determine which machines are applicable, etc.?
The problem historically with many patch management solutions is that they are hard to use and require custom scripting and packaging of updates. They are better than nothing, but just barely. What IT professionals need is a product that is extremely easy to use and provides them a starting point for managing third party updates and content. They need software to notify them when new updates are out and to do much of the leg-work on packaging this content and delivering it to them so they can test, tweak and deploy it in their environment.
The reason why automation has no place in real-life patch management is very simple and two fold -- every environment is different and engineers just don’t trust automation. Now we are not saying automation does not have any place in IT; however, in the scope of configuration management (which includes patch management), to an engineer, this is just a marketing buzz word. The primary challenge that affects patch management operations is dealing with exceptions and unanticipated dysfunctions, and that mandates extensive testing on any machines that are not what we might call “stock”. That is, they have line-of-business apps not tested by the patch builder, or they have custom configurations, or they’re simply too critical to be offline for any more than the absolute minimum time required to apply the patch and successfully restart the system.
We were recently speaking with an engineer at a U.S. Federal installation who uses our Patch Manager software, and due to the variety of OS versions, hardware and third party applications, including custom applications; they have a very strict and rigorous lab testing and validation procedure before they ever attempt to deploy an update out to the production environment. They will NEVER let a piece of software scan their environment and based on rules or policies that push updates out without some form of human intervention and checking.
And don’t get us started on trying to deliver this type of a service in a SaaS based fashion, which in itself is ripe with tons of other issues. Do YOU think patch management can be automated?
Brandon Shopp is SolarWinds' Director, Product Management. He has more than 10 years of experience in the IT technology field either as an Engineer/IT Admin or working for a software company to help makes those folks lives easier.