Q&A
Why Is Modern Patching Still So Difficult?
SQL Server Expert Allan Hirt breaks down the hurdles organizations still face when keeping on top of patching and updates.
Even with the latest automation tools and vendor patching services, staying current with patching and upgrades is more complex than ever. Allan Hirt, founder of SQLHA, LLC, and a seasoned expert in SQL Server mission-critical environments, is no stranger to these challenges. In a recent conversation with Redmond, Hirt shared his insights on why many organizations struggle with patching, the risks of falling into technical debt and how a modern approach can help avoid the pitfalls.
In his upcoming Live! 360 session, "A Modern Approach to Patching, Upgrades, and Technical Debt," Hirt will expand on this subject by exploring how organizations can navigate these challenges. He’ll offer practical strategies for minimizing downtime, distinguishing between patching and upgrading, and addressing technical debt that accumulates due to delayed maintenance.
Join us in Orlando, Fla. this November to get the latest insight from Hirt and our great lineup of speakers to help strengthen your IT game. Save $400 when you register by Sept. 27!
Redmond: Your presentation alludes to a "modern approach" to patching and upgrading. How would you describe the "outdated" or "traditional" approach to these tasks, and what are they missing?
Hirt: Patching and upgrades have never been "easy," but modern IT is both similar and very different than it was years ago. In the not-so-distant past, scheduling a night or weekend for updates/patches/upgrades was often possible. These planned outages could be properly devised and tested.
Today, especially with security the foremost concern in most organizations, the mantra is "patch now" (or as soon as possible) after a security fix is released. That affects all systems, not just ones running SQL Server. People expect IT to be miracle workers and patch hundreds or thousands of systems in a short period with little to no testing and have things work as they did before patching.
The modern twist is the approach and mindset necessary to update many connected, dependent servers successfully. Planning for "what if" in the event something goes wrong is no longer a "nice to have." There is no one size, fits all solution that works for everyone. Automation is not the savior but can be a crucial part of the solution. Things are too complex today to bring an outdated, traditional IT mindset to patching, updating and upgrading. Downtime is money and you certainly do not want to be part of a resume generating event.
Is it easier for organizations to fall into technical debt now than before? Is the pace of technological change today very different than what it used to be?
Most organizations have technical debt somewhere. It is not a new concept. With the amount of change that happens today, it is easier to fall behind. This is also magnified by our security conscious world because falling behind has direct implications. The irony -- we allow our personal technology to be automatically updated, yet touch that production system? Over my dead body!
Technical debt is more than just technology. How a company gets there is often a combination of factors both technical AND non-technical. Where there are traditional OSes and software that need to be maintained, when do you upgrade? What does that mean in our virtual, cloudy world? How do budgets and cost affect technical debt? If the old solution just works, should you/do you have to upgrade it? These are just some of the questions that need to be answered which I will touch upon in the session.
When it comes to SQL Server, what mistakes do you see organizations falling into that cause them to fall into technical debt?
It is often a series of technical and non-technical decisions/choices over time that results in technical debt. In my experience, applications are the number one blocker for many patching and upgrade scenarios for SQL Server.
Whenever a server product falls out of support, Microsoft urges organizations to upgrade to the cloud version of that product. Is cloud the best panacea to technical debt?
This is not just a Microsoft "thing." Most vendors would prefer you use a cloud-based version of their products. There are different variants of cloud implementations for databases, each of which has their own pros and cons. However, switching how you deploy may not change the debt scenario for your company. Even where it might, you can encounter different challenges to be resolved. TL;DR no, deploying to a cloud provider of choice is not a panacea for eliminating technical debt.
What about security patching? Why are organizations failing to stay on top of their security patches? Is there something that they can do to fix this, or is this a problem on the vendors' side?
Security is top of mind at every company I have worked with or talked to, often taking priority over everything else. Security drives patching efforts before other types of updates such as a SQL Server cumulative update (CU). As noted earlier, scale is a factor when it comes to security since security touches everything, not just servers (physical or virtual, on premises or cloud) running SQL Server.
There is no easy fix -- neither for the vendors that need to ensure patches get in the hands of customers in a timely fashion nor for the customer who must apply the patch to hundreds or thousands of servers. Downtime and outages make the news … and you want to stay out of the headlines. Look at what recently happened with Crowdstrike as a perfect example of the intersection of security, patching and downtime.